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.