Translated by Mikko Heikkinen (ITKST56 course assignment at JYU.FI)
[Musiikkia]
OK. Seuraavaksi puhuu Timo Longin,
joka tunnetaan myös nimellä Timo Login.
Hän tietoturvakonsultti ja tutkija. Hän tulee puhumaan uudesta tekniikasta
nimeltään SMTP Smuggling,
jolla voidaan väärentää sähköposteja
ja hyväksikäyttää eräitä eniten käytettyjä palveluita internetissä.
Kiitos. Annetaan Timolle applodit.
[Applodeja]
Kiitos esittelystä.
Ensinnäkin, pulskat pahoittelut omasta ja SEC Consult:n puolesta
tämän katastrofaalisen haavoittuvuuden julkaisemisesta.
Erityisesti pahoittelut Wietselle ja Viktorille korjausten jälkikorjauksesta
sekä kaikille järjestelmävalvojille ympäri maailman,
jotka ovat joutuneet asentamaan korjauksia joululoman aikana.
Ja lisäksi, joka tapauksessa,
suuret kiitokset Wietselle ja Viktorille
heidän sitoutumisestaan.
Ja lisäksi suuret kiitokset yhteisölle
tämän ongelman viemisestä julkaisujärjestelmiin ja niin edelleen.
Ja kaikille... Okei...
[Applodeja]
Ja kaikille niille,
joilla ei ole mitään hajua tästä.
Joten minäpä autan teidät samalle sivulle.
Noin vuosi sitten olin juuri
lopettanut tutkimukseni DNS:n parissa.
ja etsin uutta tutkimuskohdetta,
kun löysin todennäköisesti helpoimman
tavan hakkeroida yrityksen
ja kaikki tämä vain yhdellä
yksinkertaisella Google-haulla.
[Yleisön naurua]
Ja tämä saattaa kuulostaa tyhmälle,
mutta tämä johdatti minut suuntaan,
jonka jo tiesin, mutta en ollut ymmärtänyt.
Ja se on, että tietojen kalastelu on edelleen
numero 1 ensipääsyvektori yritykseen
ja sitten minulla välähti:
Miksen tutkisi SMTP:tä,
simple mail transfer protocol:aa
jota käytetään miljardien sähköpostien
lähettämiseen joka päivä ympäri maailman
kuten on tehty viimeisen 40 vuoden ajan.
Joten matkani eteni DNS:stä SMTP:hen
ja tänään esittelen uuden
SMTP Smuggling -tekniikan
sähköpostien väärentämiseksi.
Kuka olenkaan? OIen Timo Longin
ja työskentelen tietoturvakonsulttina
SEC Consult -yhtiössä ja
päivisin teen penetraatiotestausta
ja öisin teen haavoittuvuustutkimusta.
Ja viimeisen kolmen vuoden aikana olen
tutkinut paljon DNS-haavoittuvuuksia.
Ja olen julkaissut paljon blogikirjoituksia ja työkaluja.
Ja minun täytyi siirtyä eteenpäin.
Edellisen kerran, kun joku SEC Consult:sta puhui CCC:ssä...
se oli... dildoista.
[Yleisön naurua]
Ja tiedän, että joudun tuottamaan osalle
teistä pettymyksen,
mutta tämä esitys ei kerro
ihmiseen penetroitumisesta.
Esitys kertoo tunkeutumisesta SMTP-protokollan muurien läpi.
Joten nähdäksemme miten tämä toimii
on meidän ensin ymmärrettävä
miten sähköpostien lähetys yleensäkin toimii.
Joten tässä meillä on melko yksinkertainen sähköposti-infrastuktuuri.
Meillä on sähköpostikäyttäjäagentti,
kuten Thunderbird, ja Thunderbird haluaa lähettää sähköpostin
esimerkiksi käyttäjänä user@outlook.com.
Joten jos haluamme lähettää sähköpostin tällä tavalla
meidän täytyy ensin tunnistautua
Outlook mail transfer agentille tai
ulospäin menevälle SMTP palvelimelle.
Ja kun olemme tunnistautuneet,
voimme lähettää sähköpostin käyttäjänä user@outlook.com.
Ja vain käyttäjänä user@outlook.com.
Tämän jälkeen viesti siirretään vastaanottajan
SMTP-palvelimelle ja tämä palvelin
tarkistaa viestin aitouden.
Ja kaikkein yleisen tapa tehdä tämä on SPF.
Vastaanottava SMTP-palvelin saa SPF-tietueen
DNS-palvelun kautta outlook.com osoitteelle.
Ja tarkistaa sen jälkeen, että tämä IP-osoite
ja IP-alue on sallittu lähettää sähköpostiviestejä
outlook.com osoitteelle.
Tässä tapauksessa todellinen Outlook SMTP-palvelin
tai ulospäin lähtevä SMTP-palvelin lähetti viestin,
vastaanottava SMTP-palvelin
hyväksyy viestin.
Ja nyt luonnollisesti tässä on erittäin
mielenkiintoinen kysymys.
Ja kysymys on: onko hyökkääjän mahdollista
lähettää sähköpostiviesti
esimerkiksi osoitteesta admin@outlook.com tai
väärennetystä sähköpostiosoitteesta?
Tätä me selvitämme tänään
ja se on enemmän tai vähemmän
tämän tutkimuksen tavoitteista.
En tiedä oletteko huomanneet,
mutta näiden palvelimien värit
muistuttavat minusta Paavo Pesusieneä
ja Patrik Tähtöstä.
Ja sen vuoksi kutsumme niitä niiksi.
Tutkimuksen yleinen tavoite ja
tutkimuksen peruste oli löytää
tapa väärentää sähköposteja.
Ja ajattelin, että miksi en ottaisi haavoittuvuuksia
muista tekstipohjaisista protokollista,
kuten HTTP:stä, ja soveltaisi niitä SMTP:hen.
Ja oli yksi HTTP haavoittuvuus, joka sopi kuvaan
ja se oli HTTP-pyynnön käpelöinti.
Tässä meillä on taas Paavo ja Patrik,
mutta tällä kertaa HTTP-maailmassa.
Joten, mitä tässä tapahuu? Paavo Pesusieni saa
POST-tyyppisen pyynnön internetin yli
Mielenkiintoista tässä pyynnössä on se,
että siinä on kaksi otsikkoa
kuinka käsitellä POST-pyynnön data.
Siinä on Content-Length -otsikko, jonka arvona
43 tavua.
Ja siinä on myös Transfer-Encoding -otsikko.
Nyt Paavo Pesusienen täytyy päättää,
miten käsittelen pyynnön ja Paavo päättää
käyttää Content-Length otsikkoa, koska se on
43 tavua.
Joten kaikki punaisella kehystetty data
on välitetty Patrikille.
Patrikilla ei ole mitään hajua mitä tehdä - pitäisikö
minun tulkita Content-Lenth otsikkoa vai
Transfer-Encoding -otsikko? Patrik päättää
tulkita Transfer-Encoding otsikkoa ja
nyt meillä on eriävät tulkinnat:
Paavo Pesusieni käyttää Content-Length -otsikkoa
ja Patrik Tähtönen käyttää Transfer-Encoding -otsikkoa.
Ja koska Transfer-Encoding on määritetty "chunked" ("paloiteltu") ja
ja ensimmäinen pala on 0,
on loput Paavo Pesusienen lähettämästä datasta
tulkittu toiseksi pyynnöksi.
Itse asiassa tämä tarkoittaa, että Paavo näkee
yhden pyynnön ja Patrik kaksi pyyntöä.
Ja toinen pyyntö voidaan kohdistaa mielivaltaiseen
resurssipolkuun, kuten "Admin",
joka tässä esimerkissä on avoin vain sisäisesti
palvelimella.
Joka on tietenkin ongelma.
Joten ajattelin, että miksi en ottaisi
näitä tulkintaeroja
ja laittaisi niitä SMTP:hen.
Ymmärtääksemme... tai ainakin päästäksemme
lähemmäs ymmärrystä miten tämä toimii,
täytyy meidän katsoa ensin itse SMTP
protokollaa.
Joten, SMTP näyttää kuta kuinkin tältä.
Meillä on kaksi komponenttia: SMTP komennot
punaisella ja sinisellä viestin data.
Lähettääksemme viestin, meidän tulee ensin
lähettää SMTP komennot:
Meidän pitää esitellä itsemme, kertoa lähettäjän
osoite, yksi tai useampi vastaanottajan osoite ja
sitten lähetämme "data" komennon
kertoaksemme vastaanottavalle SMTP-palvelimelle
että olemme nyt vastaanottamassa varsinaista
viestin dataa.
Ja sitten lähetämme viestin datan: määrittelemme
lähettäjän osoitteen uudelleen, vastaanottajan osoitteen
ja viestin aiheen.
Ja sitten tulee viestin leipäteksti.
Ja kun jossain vaiheessa haluamme
lopettaa viestin datan lähettämisen,
meidän tulee lähettää jotain. jota kutsumme
datan lopetussekvensiksi.
Se on "<paluu rivin alkuun><rivinvaihto> piste <paluu rivin alkuun><rivinvaihto>"
[kääntäjän kommentti: jatkossa .]
Tässä vaiheessa ajattelin, että ehkä voisimme
hämätä tällä jotenkin SMTP-palvelinten toteutuksia.
Ajatus oli siis, että meillä on jälleen Paavo Pesusieni
ja lähetämme sähköpostin Paavo Pesusienelle [SIC].
Ja tämä sähköposti sisältää jotain
todella outoa, jotain joka näyttää
lopetussekvensille, mutta se ei ole sitä.
Koska se ei ole yhdenmukainen RFC:n kanssa, joku
voisi virheellisesti tulkita sen datan lopetussekvensiksi.
Joten Paavo Pesusieni katsoo tätä ja ajattelee
ettei tämä ole RFC:stä, en tulkitse tätä
"end-of-data" sekvensiksi
Ja seuraavaksi... tai viestin data siihen saakka,
kunnes varsinainen datan lopetussekvenssi tulee.
Sitten Paavo Pesusieni lähettää viestin Patrikille
Ja Patrik on "Jeah, en välitä mistään RFC:stä ja
ja tulkitsen väärän datan lopetussekvenssi
varsinaiseksi datan lopetusmerkiksi."
Ja ongelmaksi tässä tulee, että kaikki väärin
tulkitun lopetussekvenssin tulkitaan SMPT-komennoiksi
Ja nyt hyökkääjänä voimme luoda SMTP-komentoja,
jotka lähettävät toisen sähköpostiviestin.
Vaikka Paavo Pesusieni näki yhden ison
sähköpostiviestin, Patrik näkee kaksi pienempää viestiä.
Ja ongelma on se, että toinen viesti voi sisältää
mielivaltaisia SMTP-komentoja.
Kuten, että viesti tulee osoitteesta admin@outlook.com
tai mitä tahansa.
Näin ainakin teoriassa.
Nähdäkseni toimiiko tämä todella.
Tutkin muutamia SMTP-palvelinten
toteutuksia yksinkertaisesti
ottamalla niihin yhteyttä telnet:llä tai
netcat:lla.
Kun tein tämän, se näytti aluksi RFC:n mukaiselta.
Kun lähetät datakomennon, palvelin pyytää
lopettamaan datan lähettämisen . merkeillä.
Sitten löysin myös palvelimia, jotka sanoivat:
"lähetä minulla rivi, jossa on vain piste"
Ja tämä asia riippuu paljon käytettävästä
käyttöjärjestelmästä.
Windows:ssa tämä voi olla <CR><LF>.<CR><LF>
ja se voi olla .
Siinä kohtaa ajattelin, että tässä voisi
olla jotain.
Ja kokeilin jotain.
Ensimmäiseksi kokeilin työntää <CR>-, <LF>- ja piste-
merkkejä Paavo Pesusienen kautta.
Joten kirjoitin SMTP analyysisovelluksen, joka
lähettää virheellisiä data lopetussekvenssejä,
kuten <LF>.<LF> Ja lähetin viestejä eri SMTP-
ohjelmistoilla,
sisältäen sähköpostipalveluita Gmail, Outlook, GMX
ja lisäksi sähköpostiohjelmistoja kuten Postfix,
Exim, Microsoft Exchange Server ja niin edelleen.
Vastaanottavalla puolella tutkin, että mitkä
vääristä sekvensseistä menee itse asiassa läpi.
Voinko lähettää komennon <LF>.<LF> lähtevän palvelimen
kautta?
Ja useimmissa tapauksissa se ei toiminut.
<LF>.<LF> on usein suodatettu tai poistettu
alkuperäisestä viestistä.
Mutta jossain tapauksissa se menee läpi muuttumattomana.
Tämä oli tilanne GMX:n kohdalla. Lähetin sähköpostin
GMX:stä analyysipalvelimelleni
ja <LF>.<CR><LF> merkkejä ei poistettu.
Seuraavaksi tein proof-of-concept:n, jossa on
väärennetty datan lopetussekvenssi
ja sen jälkeen toinen sähköpostiviesti.
Jos tämä proof-of-concept toimii,
meidän pitäisi saada kaksi viestiä
vastaanottajan puolella.
Lähetin tämän kaiken Gmailiin.
Ja Gmail oli sitä mieltä,
että "tämä ei ei ole datan lopetussekvenssi".
Ja sen näkee siitä, että datan lopetussekvenssin
jälkeen kaikki on edelleen tulkittu viestin dataksi.
Mutta joissain tapauksissä tämä itse asiassa toimi.
Tämä oli ensimmäinen onnistunut
SMTP Smuggling tapaus, GMX:stä Fastmail:iin.
Me näemme, että se toimii. Meillä on ensin
viesti käyttäjältä user@gmx.net
ja toinen viesti käyttäjältä admin@gmx.net,
jotka läpäisevät SPF ja DMARC tarkistukset,
koska ne tulevat GMX:n palvelimelta.
[Applodeja]
Minä olin, että "tämä on aivan sairasta!"
Ajattelin, että meillä on tämä toinen viesti
ja siinä voi olla mitä tahansa.
Kuten lähettäjän osoite voi olla mitä vaan.
Joten miksi en kokeilisi muita domaineja,
jotka osoittavat GMX:n palvelimeen?
Sitten analysoin SPF tietueen ja tajusin...
Tässä on