XSS-haavoittuvuudet sähköpostipalvelussa

Elisa on tarjonnut asiakkailleen jo pitkään ilmaista sähköpostipalvelua, Kotipostia. Palvelu löytyy osoitteesta https://webmail.kolumbus.fi. Reilu kuukausi sitten Elisa otti käyttöön uuden sähköpostipalvelun, joka yhdistää sekä Elisan Kotipostin että Saunalahden sähköpostipalvelun.

Noin kahdeksan kuukautta sitten satuin huomaamaan, että Kotiposti-palvelu on haavoittuvainen useille XSS-haavoittuvuuksille. Tämä tarkoittaa, että käyttäjän on mahdollista injektoida javascript-koodia käyttöliittymään, joka suoritetaan selaimessa. Samaa ongelmaa ilmenee myös Saunalahden sähköpostipalvelussa. Myös muita tietoturvaan liittyviä ongelmia palveluista löytyi.

XSS-haavoittuvuus yleensä todennetaan suorittamalla koodia, joka näyttää käyttäjälle pienen ikkunan selaimessa (kuva 1). XSS-haavoittuvuuksia saadaan ehkäistyä sanitoimalla kaikki web-sivulla näkyvä sisältö, mihin käyttäjä pystyy vaikuttamaan. Selain kun suorittaa aina vain sisällön, mitä sille tarjotaan. Alla karkea esimerkki:

Kuva 1. Sanitointi.

Kuvassa 1 olevan esimerkin lähdekoodiin on määritelty kaksi erillistä muuttujaa:

•    muuttuja 1 = <script>alert(1)</script>
•    muuttuja 2 = <script>alert(2)</script>

Muuttujat tulostetaan sivulle, mutta vain ensimmäiselle suoritetaan sanitointi. Kuten kuvasta 1 on nähtävissä, muuttuja 2 ponnauttaa ikkunan. Muuttuja 1 ei sitä tehnyt. Kun toisesta välilehdestä tarkastellaan lähdekoodia, on huomattavissa, että muuttujan 1 sisältö on sanitoitu ja täten selain ymmärtää, ettei sitä tule suorittaa. Koska muuttujaa 2 ei ole sanitoitu, suorittaa selain sen normaalisti, eikä se näy tekstinä sivulla.

Ilmoitin havainnoistani suoraan Elisan CERTille. Hälyttävin mainitsemistani tiedoista oli, että javascript-koodia voidaan suorittaa automaattisesti, kun käyttäjä avaa vastaanottamansa sähköpostiviestin. Korjaustoimenpiteitä tulisi suorittaa mahdollisimman pian.

Valitettavasti korjaustoimenpiteitä ei ole tehty kuukausienkaan jälkeen. Tämän vuoksi tarkemmat, tekniset yksityiskohdat kuten testauksessa käytetyt lähdekoodit on jätetty pois.

XSS-haavoittuvuuksia on aina silloin tällöin ollut eri sähköpostipalveluissa. Viime vuonna bongasin kuvassa 2 olevan Venäläisen Yandexin sähköpostista pysyvän XSS-haavoittuvuuden.

Kuva 2. Yandex.Mail XSS.

Myös GMailissa on ollut hyvin vakava XSS-haavoittuvuus viime vuonna. XSS-haavoittuvuus esiintyi käyttäjän avatessa saapuneen sähköpostiviestin. Google korjasi ongelman tuntien sisään. Haavoittuvuuden huomasi hetki sitten otsikoissa olleen Rosetta Flashin tekijä Michele Spagnuolo (@mikispag).

Ajattelin esittää kaksi tapausta, joissa hyödynnetään XSS-haavoittuvuutta.

Demonstroitu hyökkäys käynnistetään lähettämällä kiinnostava sähköpostiviesti (kuva 3) kohteena olevalle käyttäjälle molemmissa esimerkeissä. Tässä tapauksessa siis omalle Kotipostin tililleni. Käyttäjän avatessa viestin, suoritetaan hyökkääjän haluama javascript-koodi automaattisesti.

Kuva 3. Kiinnostava sähköpostiviesti käyttäjälle.

Ensimmäisessä demonstraatiossa hyödynnetään apuna phishingiä, jonka avulla hyökkääjä pyrkii saamaan kohteena olevan käyttäjän tunnukset haltuunsa. Käyttäjän avattua saamansa sähköpostiviestin, hänet siirretään suoraan takaisin Kotipostin näköiselle kirjautumissivulle.

Kun käyttäjä avasi sähköpostiviestin, hyökkääjän muodostama koodi latasi sivulle täysikokoisen iframen. Kyseessä on kehys, joita voi luoda web-sivuille. Kehyksen sisältö on ladattu hyökkääjän palvelimelta ja se näyttää vastaavalta kuin aito Kotipostin etusivu. Myös osoitepalkissa näkyvä URL-osoite on Kotiposti-palvelun oma osoite.

Havainnollistamisen vuoksi muokkasin iframen kokoa paljon pienemmäksi, joka on nähtävissä kuvassa 4. Vihreällä värillä reunustettu alue on alkuperäinen sivu ja sen päälle on tehty hyökkääjän sivulta iframe, joka on ympäröity punaisella värillä. Taustalla näkyy selkeästi alkuperäinen istunto, joka on vain piilossa iframen alla. Hyökkäystilanteessa iframe peittäisi siis koko alkuperäisen sivun.

Kuva 4. Iframe luotuna sivustolle.

Kuvassa 4 esiintyvä ”sertifikaattiherja” johtuu siitä, että hyökkääjän sivulla ei ole käytössä HTTPS-protokollaa. Sisältö siis ladataan sekä HTTPS- että HTTP-protokollan yli (mixed content) ja selain ilmaisee asian.

Käyttäjän kirjautuessa takaisin sähköpostiin, ei "kirjautumisprosessi" poikkea mitenkään normaalista käyttäjän näkökulmasta. Sekä sähköpostiosoite että salasana kuitenkin lähetetään taustalla hyökkääjän palvelimelle ja kirjoitetaan tekstitiedostoon (kuva 5).

Kuva 5.  Kerätyt tunnukset hyökkääjän palvelimella.

Käyttäjän istunto Kotipostiin ei ole siis katkennut missään vaiheessa ja hänet ohjataan vain takaisin sähköpostilistaukseen ”kirjautumisen” jälkeen.

On mahdollista, että käyttäjä avaa hyökkääjän lähettämän sähköpostiviestin uudelleen. Kun käyttäjä ohjautuu uudelleen hyökkääjän muodostamaan kirjautumisnäkymään, voi tämä olla jo hieman epäilyttävää. Tämän välttämiseksi käyttäjälle asetetaan eväste siinä vaiheessa, kun sähköpostiviesti ensimmäistä kertaa aukaistaan. Kun sähköpostiviesti avataan toistamiseen, havaitaan evästeen olemassa olo ja viestin sisältö näytetään normaalisti eikä uudelleenohjausta enää tehdä.

Toisessa demonstraatiossa XSS-haavoittuvuutta hyödynnetään kahdesti. Kun käyttäjä aukaisee hyökkääjän muodostaman viestin, aukeaa viesti normaalisti. Taustalla suoritetaan hyökkääjän muodostamaan koodia, joka tallentaa käyttäjän osoitekirjaan uuden käyttäjän, joka on nähtävissä kuvassa 6. Lisäksi myös aiemmin mainittu eväste lisätään, jotta uutta käyttäjää ei yritetä lisätä, jos viesti avataan toistamiseen. Käyttäjälle nämä toimenpiteet eivät näy.

Kuva 6. Osoitekirjan haavoittuvuus.

Vaikkakin osoitekirjan merkintä näyttää normaalilta, on sen yhteyteen lisätty javascript-koodia. Kyseessä on siis myös pysyvä XSS-haavoittuvuus. Eli aina kun käyttäjä käy osoitekirjassa, suoritetaan hyökkääjän haluamaa koodia.

Hyökkääjä voi estää käyttäjää poistamasta kyseistä osoitekirjamerkintää esimerkiksi lisäämällä merkinnän yhteyteen koodia, joka ottaa ”poista”-napin pois käytöstä. Nappi näkyy tällöin harmaana. Käyttäjä pystyy ottamaan napin takaisin käyttöönsä, mutta se vaatii jonkin verran jo osaamista selaimen käytöstä ja HTML:stä.

XSS-haavoittuvuus mahdollistaa käyttäjän istunnon kaappaamisen.

Kun käyttäjä kirjautuu Kotipostiin, hänelle luodaan istuntokohtainen eväste selaimeen. Aina kun käyttäjä navigoi sivustolla, hänelle selaimeen luotu eväste tarkistetaan palvelimen päässä. Kun käyttäjä kirjautuu palvelusta ulos, palvelin kuolettaa käyttäjän istunnon. Vaikka käyttäjällä olisi vielä tällöin istunnon eväste selaimessaan tallessa, ei se enää toimi.

Hyökkääjä siis haluaa käyttäjän istuntokohtaisen evästeen. Kun eväste lisätään hyökkääjän selaimeen, on hänellä sama istunto käytössä kuin käyttäjällä.

Istunnon pituus voi kuitenkin koitua hyökkääjälle ongelmaksi, koska käyttäjä saattaa kirjautua ulos palvelusta. Tällöin katkeaa myös hyökkääjän istunto.

Jos hyökkääjä kokee tarvetta hallita istunnon pituutta, voidaan javascript-koodiin lisätä toiminto, joka näpelöi käyttäjän istuntokohtaista evästettä. Evästeen arvoa muutetaan ja käyttäjä joutuu kirjautua uudelleen sisään. Koska uloskirjautumista ei ole suoritettu, on vanha istunto edelleen aktiivinen ja hyökkääjän hyödynnettävissä.

Testasin vielä myöhemmin istunnon käyttäytymistä pollaamalla Kotipostin saapuneet viestit –näkymää 24 tunnin ajan. Istunto pystyi aktiivisena siis ainakin 24 tuntia, kun sitä aktiivisesti käytettiin. Istunto saadaan siis pidettyä hengissä hyvinkin pitkään.

Suosittelen käyttämään Elisan vastikään luomaa sähköpostipalvelua osoitteessa https://webmail.elisa.fi tai erillistä sähköpostiohjelmistoa. Jos käytät sähköpostia joko osoitteessa https://webmail.kolumbus.fi tai https://webmail.saunalahti.fi, älä avaa yhtäkään saapunutta sähköpostiviestiä.

Käytettävät palvelimet löytyvät Elisan osalta täältä http://asiakastuki.elisa.fi/ohje/22 ja Saunalahden käyttäjille täältä http://asiakastuki.saunalahti.fi/ohje/289.

Vielä ohjevideot ulkoisten sähköpostisovellusten käyttöönottoon: http://asiakastuki.elisa.fi/aihe/sahkoposti_ja_kotisivut/107/

Tämän blogipostauksen sisällön oli tarkoitus antaa osviittaa, kuinka motivoitunut hyökkääjä voi toimia hyödyntäen palvelussa esiintyviä ongelmia apunaan ja miksi XSS-haavoittuvuuksiin tulisi suhtautua myös vakavasti - varsinkin, kun kyseessä on sähköpostipalvelu.

Testaukset suoritettiin vain henkilökohtaisilla tunnuksilla.

Warbiking in Helsinki

Biking is fun and especially when it comes to exploring new places. One day while driving around I got an idea to warbike with my Raspberry Pi. As Raspberry Pi consumes a very little amount of power and fit in a backpack with all other devices, it would be an easy and a light load to carry.

In case you aren’t familiar with the term ”wardriving”, here is a short explanation from Wikipedia:

”Wardriving is the act of searching for Wi-Fi wireless networks by a person in a moving vehicle, using a portable computer, smartphone or personal digital assistant (PDA).”

I didn’t try to access or hack into any networks. The data gathered in this project won't be given to anyone.

I had to decide the area I was going to cover. Usually wardriving is done by driving just bigger streets, but I wasn’t happy doing it that way. So, I defined a little bit smaller area, but I was going to cover it more carefully than usually is done.

By ”more carefully” I mean that almost every part of the every street seen in the map below were covered. Exceptions were like restricted areas and courtyards.

Picture 1. Covered area.

Here is a full list of the devices that were used:

- Raspberry Pi model B (256MB)
- Alfa AWUSO36H WLAN USB adapter (2.4Ghz, 802.11b/g)
- GlobalSat BU-353 GPS receiver
- Anker Astro E4 13000mAh power pack

Picture 2. Devices.

Raspberry Pi was using Raspbian OS. Alfa wlan adapter was grabbing wlan signals and GPS receiver to pinpoint found access points to a map. Note that the Alfa wlan adapter is 2.4Ghz and 802.11b/g.

All this stuff was powered by 13000 mAh power bank. I haven’t done any real capacity tests, but it was enough to power this combination for hours.

I ordered also a wlan adapter to be able to establish a management connection between Raspberry Pi and my mobile phone. However, I never got the wlan adapter.

The equipment was very stable, so I thought It’s okay to warbike without management connection. On my last run Raspberry Pi probably overheated and got stuck. Some access points were missed for sure, but luckily I had already covered the area quite well.

Before the warbiking sessions, I always planned the route with Google Maps. Even though the driving sessions were sometimes very twisting, I had no really issues to stay on the planned route. You just had to remember some reference points in the areas.

The needed processes (Kismet and GPS) were started on Raspberry Pi before closing my backpack and leaving outside. GPS usually got fix in a couple of minutes after going outside. Sometimes it took more than five minutes.

Picture 3. Bike.

Next lets see some (biking) statistics.

Distance (by bike): 106.16 km

Distance (by foot): 9.09 km

Total distance: 115.25 km

Total time: 10.75 hours

Total sessions: 11

There were some places I prefered to walk so that’s why 9.09 kilometers of the total distance was performed by foot. Rest of the kilometers, 106.16 km, was warbiked.

Now the most interesting part. There were 26309 unique access points (BSSIDs) which were broadcasting ESSIDs.

The ESSID which was broadcasted by the biggest amount of access points was ”eduroam”. The total number of access points was 348. Eduroam is some kind of project to allow university students to do network roaming in Europe and all over the world.

The next place goes to ”Univ Helsinki HUPnet” network with 309 BSSIDs. It’s unprotected network owned by University of Helsinki. The network can be accessed with university credentials.

The third one was ”Private WLAN2” with 219 BSSIDs. I couldn’t link this one to any company etc, so I believe this is some default ESSID value assigned by a manufacturer.

There was also a hotel with a big amount of access points. You know, all the areas inside need to be covered for roaming. It’s the same thing with many companies.

Some other much used ESSIDs: ”Private Wlan”, ”WLAN-AP”, ”ASUS”, ”AndroidAP” (hotspot), ”ZyXEL” and ”dlink”.

The two very often seen ESSIDs in Finland are ”ElisaKotiXXX” or similar and ”SoneraGatewayXX-XX-XX-XX-XX-XX”. With these default ESSIDs, Elisa had 670 and Sonera 715 unique access points.

Some years ago the situation wasn’t too good with the used encryption. Now for a long time access points have come with WPA2 as a default encryption setting and you can see it from the results.

Picture 4. Encryption.

WPA(2) is the preferred encryption and it should be used with a strong password. 22621 (86%) of all access points were using WPA(2). WPA and WPA2 were combined because the log doesn’t indicate clearly which one is used.

WEP is totally broken and it can be cracked very easily. 557 (2%) access points had it.

3131 (12%) access points weren’t using encryption at all. Many of these were companies' guest networks according to the ESSIDs.

141 access points with no encryption had ESSID like ”HP-Print-xx-xxxxx”. As far as I know some HP’s printers have access points which allow devices to connect and deliver a print job wirelessly.

In overall the whole project was successful. However, I had forgotten the whole WPS feature and Kismet doesn’t have WPS detection by default, so unfortunately WPS data (enabled/disabled) isn’t available.

In the end I just want to say that I hate these piece of shit stones under my tires. I really do.

Picture 5. Much love for bikers.