0:00:00.310,0:00:04.830
Translated by Mikko Heikkinen (ITKST56 course assignment at JYU.FI)

0:00:05.372,0:00:13.612
[Musiikkia]

0:00:14.212,0:00:18.212
OK. Seuraavaksi puhuu Timo Longin,

0:00:19.402,0:00:22.212
joka tunnetaan myös nimellä Timo Login.

0:00:22.324,0:00:27.264
Hän tietoturvakonsultti ja tutkija. Hän tulee puhumaan uudesta tekniikasta

0:00:27.578,0:00:29.778
nimeltään SMTP Smuggling,

0:00:29.943,0:00:32.343
jolla voidaan väärentää sähköposteja

0:00:32.426,0:00:34.276
ja hyväksikäyttää eräitä eniten käytettyjä palveluita internetissä.

0:00:34.317,0:00:37.207
Kiitos. Annetaan Timolle applodit.

0:00:37.641,0:00:41.641
[Applodeja]

0:00:43.181,0:00:45.111
Kiitos esittelystä.

0:00:45.111,0:00:49.811
Ensinnäkin, pulskat pahoittelut omasta ja SEC Consult:n puolesta

0:00:49.811,0:00:53.801
tämän katastrofaalisen haavoittuvuuden julkaisemisesta.

0:00:54.784,0:01:00.734
Erityisesti pahoittelut Wietselle ja Viktorille korjausten jälkikorjauksesta

0:01:01.328,0:01:05.418
sekä kaikille järjestelmävalvojille ympäri maailman,

0:01:05.701,0:01:08.721
jotka ovat joutuneet asentamaan korjauksia joululoman aikana.

0:01:09.070,0:01:11.790
Ja lisäksi, joka tapauksessa,

0:01:12.284,0:01:16.284
suuret kiitokset Wietselle ja Viktorille

0:01:16.342,0:01:20.072
heidän sitoutumisestaan.

0:01:20.094,0:01:22.344
Ja lisäksi suuret kiitokset yhteisölle

0:01:22.391,0:01:25.373
tämän ongelman viemisestä julkaisujärjestelmiin ja niin edelleen.

0:01:25.563,0:01:27.843
Ja kaikille... Okei...

0:01:28.332,0:01:32.882
[Applodeja]

0:01:35.495,0:01:37.175
Ja kaikille niille,

0:01:37.307,0:01:39.277
joilla ei ole mitään hajua tästä.

0:01:39.349,0:01:41.729
Joten minäpä autan teidät samalle sivulle.

0:01:41.835,0:01:43.845
Noin vuosi sitten olin juuri

0:01:43.876,0:01:46.756
lopettanut tutkimukseni DNS:n parissa.

0:01:46.804,0:01:49.274
ja etsin uutta tutkimuskohdetta,

0:01:49.414,0:01:52.328
kun löysin todennäköisesti helpoimman

0:01:52.423,0:01:54.543
tavan hakkeroida yrityksen

0:01:54.672,0:01:56.772
ja kaikki tämä vain yhdellä

0:01:56.823,0:01:59.053
yksinkertaisella Google-haulla.

0:01:59.053,0:02:01.073
[Yleisön naurua]

0:02:01.211,0:02:03.921
Ja tämä saattaa kuulostaa tyhmälle,

0:02:04.025,0:02:06.275
mutta tämä johdatti minut suuntaan,

0:02:06.295,0:02:09.405
jonka jo tiesin, mutta en ollut ymmärtänyt.

0:02:09.517,0:02:12.637
Ja se on, että tietojen kalastelu on edelleen

0:02:12.656,0:02:15.566
numero 1 ensipääsyvektori yritykseen

0:02:15.645,0:02:17.535
ja sitten minulla välähti:

0:02:17.622,0:02:19.472
Miksen tutkisi SMTP:tä,

0:02:19.556,0:02:21.236
simple mail transfer protocol:aa

0:02:21.330,0:02:23.714
jota käytetään miljardien sähköpostien

0:02:23.757,0:02:26.235
lähettämiseen joka päivä ympäri maailman

0:02:26.315,0:02:28.375
kuten on tehty viimeisen 40 vuoden ajan.

0:02:28.410,0:02:30.780
Joten matkani eteni DNS:stä SMTP:hen

0:02:30.780,0:02:32.760
ja tänään esittelen uuden

0:02:32.773,0:02:34.963
SMTP Smuggling -tekniikan

0:02:35.009,0:02:37.389
sähköpostien väärentämiseksi.

0:02:37.471,0:02:39.771
Kuka olenkaan? OIen Timo Longin

0:02:39.832,0:02:41.674
ja työskentelen tietoturvakonsulttina

0:02:41.674,0:02:43.375
SEC Consult -yhtiössä ja

0:02:43.375,0:02:45.245
päivisin teen penetraatiotestausta

0:02:45.245,0:02:47.535
ja öisin teen haavoittuvuustutkimusta.

0:02:47.565,0:02:50.485
Ja viimeisen kolmen vuoden aikana olen

0:02:50.533,0:02:53.369
tutkinut paljon DNS-haavoittuvuuksia.

0:02:53.369,0:02:56.049
Ja olen julkaissut paljon blogikirjoituksia ja työkaluja.

0:02:56.257,0:02:59.007
Ja minun täytyi siirtyä eteenpäin.

0:02:59.207,0:03:03.207
Edellisen kerran, kun joku SEC Consult:sta puhui CCC:ssä...

0:03:05.093,0:03:06.913
se oli... dildoista.

0:03:07.393,0:03:08.883
[Yleisön naurua]

0:03:09.121,0:03:12.091
Ja tiedän, että joudun tuottamaan osalle

0:03:12.184,0:03:13.644
teistä pettymyksen,

0:03:13.644,0:03:15.390
mutta tämä esitys ei kerro

0:03:15.390,0:03:17.510
ihmiseen penetroitumisesta.

9:59:59.000,9:59:59.000
Esitys kertoo tunkeutumisesta SMTP-protokollan muurien läpi.

9:59:59.000,9:59:59.000
Joten nähdäksemme miten tämä toimii

9:59:59.000,9:59:59.000
on meidän ensin ymmärrettävä

9:59:59.000,9:59:59.000
miten sähköpostien lähetys yleensäkin toimii.

9:59:59.000,9:59:59.000
Joten tässä meillä on melko yksinkertainen sähköposti-infrastuktuuri.

9:59:59.000,9:59:59.000
Meillä on sähköpostikäyttäjäagentti,

9:59:59.000,9:59:59.000
kuten Thunderbird, ja Thunderbird haluaa lähettää sähköpostin

9:59:59.000,9:59:59.000
esimerkiksi käyttäjänä user@outlook.com.

9:59:59.000,9:59:59.000
Joten jos haluamme lähettää sähköpostin tällä tavalla

9:59:59.000,9:59:59.000
meidän täytyy ensin tunnistautua

9:59:59.000,9:59:59.000
Outlook mail transfer agentille tai

9:59:59.000,9:59:59.000
ulospäin menevälle SMTP palvelimelle.

9:59:59.000,9:59:59.000
Ja kun olemme tunnistautuneet,

9:59:59.000,9:59:59.000
voimme lähettää sähköpostin käyttäjänä user@outlook.com.

9:59:59.000,9:59:59.000
Ja vain käyttäjänä user@outlook.com.

9:59:59.000,9:59:59.000
Tämän jälkeen viesti siirretään vastaanottajan

9:59:59.000,9:59:59.000
SMTP-palvelimelle ja tämä palvelin

9:59:59.000,9:59:59.000
tarkistaa viestin aitouden.

9:59:59.000,9:59:59.000
Ja kaikkein yleisen tapa tehdä tämä on SPF.

9:59:59.000,9:59:59.000
Vastaanottava SMTP-palvelin saa SPF-tietueen

9:59:59.000,9:59:59.000
DNS-palvelun kautta outlook.com osoitteelle.

9:59:59.000,9:59:59.000
Ja tarkistaa sen jälkeen, että tämä IP-osoite

9:59:59.000,9:59:59.000
ja IP-alue on sallittu lähettää sähköpostiviestejä

9:59:59.000,9:59:59.000
outlook.com osoitteelle.

9:59:59.000,9:59:59.000
Tässä tapauksessa todellinen Outlook SMTP-palvelin

9:59:59.000,9:59:59.000
tai ulospäin lähtevä SMTP-palvelin lähetti viestin,

9:59:59.000,9:59:59.000
vastaanottava SMTP-palvelin

9:59:59.000,9:59:59.000
hyväksyy viestin.

9:59:59.000,9:59:59.000
Ja nyt luonnollisesti tässä on erittäin

9:59:59.000,9:59:59.000
mielenkiintoinen kysymys.

9:59:59.000,9:59:59.000
Ja kysymys on: onko hyökkääjän mahdollista

9:59:59.000,9:59:59.000
lähettää sähköpostiviesti

9:59:59.000,9:59:59.000
esimerkiksi osoitteesta admin@outlook.com tai

9:59:59.000,9:59:59.000
väärennetystä sähköpostiosoitteesta?

9:59:59.000,9:59:59.000
Tätä me selvitämme tänään

9:59:59.000,9:59:59.000
ja se on enemmän tai vähemmän

9:59:59.000,9:59:59.000
tämän tutkimuksen tavoitteista.

9:59:59.000,9:59:59.000
En tiedä oletteko huomanneet,

9:59:59.000,9:59:59.000
mutta näiden palvelimien värit

9:59:59.000,9:59:59.000
muistuttavat minusta Paavo Pesusieneä

9:59:59.000,9:59:59.000
ja Patrik Tähtöstä.

9:59:59.000,9:59:59.000
Ja sen vuoksi kutsumme niitä niiksi.

9:59:59.000,9:59:59.000
Tutkimuksen yleinen tavoite ja

9:59:59.000,9:59:59.000
tutkimuksen peruste oli löytää

9:59:59.000,9:59:59.000
tapa väärentää sähköposteja.

9:59:59.000,9:59:59.000
Ja ajattelin, että miksi en ottaisi haavoittuvuuksia

9:59:59.000,9:59:59.000
muista tekstipohjaisista protokollista,

9:59:59.000,9:59:59.000
kuten HTTP:stä, ja soveltaisi niitä SMTP:hen.

9:59:59.000,9:59:59.000
Ja oli yksi HTTP haavoittuvuus, joka sopi kuvaan

9:59:59.000,9:59:59.000
ja se oli HTTP-pyynnön käpelöinti.

9:59:59.000,9:59:59.000
Tässä meillä on taas Paavo ja Patrik,

9:59:59.000,9:59:59.000
mutta tällä kertaa HTTP-maailmassa.

9:59:59.000,9:59:59.000
Joten, mitä tässä tapahuu? Paavo Pesusieni saa [br]POST-tyyppisen pyynnön internetin yli

9:59:59.000,9:59:59.000
Mielenkiintoista tässä pyynnössä on se, [br]että siinä on kaksi otsikkoa

9:59:59.000,9:59:59.000
kuinka käsitellä POST-pyynnön data.

9:59:59.000,9:59:59.000
Siinä on Content-Length -otsikko, jonka arvona [br]43 tavua.

9:59:59.000,9:59:59.000
Ja siinä on myös Transfer-Encoding -otsikko.

9:59:59.000,9:59:59.000
Nyt Paavo Pesusienen täytyy päättää,[br]miten käsittelen pyynnön ja Paavo päättää

9:59:59.000,9:59:59.000
käyttää Content-Length otsikkoa, koska se on[br]43 tavua.

9:59:59.000,9:59:59.000
Joten kaikki punaisella kehystetty data[br]on välitetty Patrikille.

9:59:59.000,9:59:59.000
Patrikilla ei ole mitään hajua mitä tehdä - pitäisikö[br]minun tulkita Content-Lenth otsikkoa vai

9:59:59.000,9:59:59.000
Transfer-Encoding -otsikko? Patrik päättää[br]tulkita Transfer-Encoding otsikkoa ja

9:59:59.000,9:59:59.000
nyt meillä on eriävät tulkinnat:

9:59:59.000,9:59:59.000
Paavo Pesusieni käyttää Content-Length -otsikkoa[br]ja Patrik Tähtönen käyttää Transfer-Encoding -otsikkoa.

9:59:59.000,9:59:59.000
Ja koska Transfer-Encoding on määritetty "chunked" ("paloiteltu") ja[br]ja ensimmäinen pala on 0,

9:59:59.000,9:59:59.000
on loput Paavo Pesusienen lähettämästä datasta [br]tulkittu toiseksi pyynnöksi.

9:59:59.000,9:59:59.000
Itse asiassa tämä tarkoittaa, että Paavo näkee[br]yhden pyynnön ja Patrik kaksi pyyntöä.

9:59:59.000,9:59:59.000
Ja toinen pyyntö voidaan kohdistaa mielivaltaiseen[br]resurssipolkuun, kuten "Admin",

9:59:59.000,9:59:59.000
joka tässä esimerkissä on avoin vain sisäisesti[br]palvelimella.

9:59:59.000,9:59:59.000
Joka on tietenkin ongelma.

9:59:59.000,9:59:59.000
Joten ajattelin, että miksi en ottaisi[br]näitä tulkintaeroja

9:59:59.000,9:59:59.000
ja laittaisi niitä SMTP:hen.

9:59:59.000,9:59:59.000
Ymmärtääksemme... tai ainakin päästäksemme[br]lähemmäs ymmärrystä miten tämä toimii,

9:59:59.000,9:59:59.000
täytyy meidän katsoa ensin itse SMTP[br]protokollaa.

9:59:59.000,9:59:59.000
Joten, SMTP näyttää kuta kuinkin tältä.

9:59:59.000,9:59:59.000
Meillä on kaksi komponenttia: SMTP komennot[br]punaisella ja sinisellä viestin data.

9:59:59.000,9:59:59.000
Lähettääksemme viestin, meidän tulee ensin[br]lähettää SMTP komennot:

9:59:59.000,9:59:59.000
Meidän pitää esitellä itsemme, kertoa lähettäjän[br]osoite, yksi tai useampi vastaanottajan osoite ja

9:59:59.000,9:59:59.000
sitten lähetämme "data" komennon [br]kertoaksemme vastaanottavalle SMTP-palvelimelle

9:59:59.000,9:59:59.000
että olemme nyt vastaanottamassa varsinaista[br]viestin dataa.

9:59:59.000,9:59:59.000
Ja sitten lähetämme viestin datan: määrittelemme[br]lähettäjän osoitteen uudelleen, vastaanottajan osoitteen[br]ja viestin aiheen.[br]

9:59:59.000,9:59:59.000
Ja sitten tulee viestin leipäteksti.

9:59:59.000,9:59:59.000
Ja kun jossain vaiheessa haluamme[br]lopettaa viestin datan lähettämisen,

9:59:59.000,9:59:59.000
meidän tulee lähettää jotain. jota kutsumme[br]datan lopetussekvensiksi.

9:59:59.000,9:59:59.000
Se on "<paluu rivin alkuun><rivinvaihto> piste <paluu rivin alkuun><rivinvaihto>" [br][kääntäjän kommentti: jatkossa .]

9:59:59.000,9:59:59.000
Tässä vaiheessa ajattelin, että ehkä voisimme[br]hämätä tällä jotenkin SMTP-palvelinten toteutuksia.

9:59:59.000,9:59:59.000
Ajatus oli siis, että meillä on jälleen Paavo Pesusieni[br]ja lähetämme sähköpostin Paavo Pesusienelle [SIC].

9:59:59.000,9:59:59.000
Ja tämä sähköposti sisältää jotain[br]todella outoa, jotain joka näyttää

9:59:59.000,9:59:59.000
lopetussekvensille, mutta se ei ole sitä.

9:59:59.000,9:59:59.000
Koska se ei ole yhdenmukainen RFC:n kanssa, joku [br]voisi virheellisesti tulkita sen datan lopetussekvensiksi.

9:59:59.000,9:59:59.000
Joten Paavo Pesusieni katsoo tätä ja ajattelee[br]ettei tämä ole RFC:stä, en tulkitse tätä[br]"end-of-data" sekvensiksi

9:59:59.000,9:59:59.000
Ja seuraavaksi... tai viestin data siihen saakka,[br]kunnes varsinainen datan lopetussekvenssi tulee.

9:59:59.000,9:59:59.000
Sitten Paavo Pesusieni lähettää viestin Patrikille

9:59:59.000,9:59:59.000
Ja Patrik on "Jeah, en välitä mistään RFC:stä ja[br]ja tulkitsen väärän datan lopetussekvenssi

9:59:59.000,9:59:59.000
varsinaiseksi datan lopetusmerkiksi."

9:59:59.000,9:59:59.000
Ja ongelmaksi tässä tulee, että kaikki väärin [br]tulkitun lopetussekvenssin tulkitaan SMPT-komennoiksi

9:59:59.000,9:59:59.000
Ja nyt hyökkääjänä voimme luoda SMTP-komentoja,[br]jotka lähettävät toisen sähköpostiviestin.

9:59:59.000,9:59:59.000
Vaikka Paavo Pesusieni näki yhden ison[br]sähköpostiviestin, Patrik näkee kaksi pienempää viestiä.

9:59:59.000,9:59:59.000
Ja ongelma on se, että toinen viesti voi sisältää[br]mielivaltaisia SMTP-komentoja.

9:59:59.000,9:59:59.000
Kuten, että viesti tulee osoitteesta admin@outlook.com[br]tai mitä tahansa.

9:59:59.000,9:59:59.000
Näin ainakin teoriassa.

9:59:59.000,9:59:59.000
Nähdäkseni toimiiko tämä todella.

9:59:59.000,9:59:59.000
Tutkin muutamia SMTP-palvelinten [br]toteutuksia yksinkertaisesti

9:59:59.000,9:59:59.000
ottamalla niihin yhteyttä telnet:llä tai[br]netcat:lla.

9:59:59.000,9:59:59.000
Kun tein tämän, se näytti aluksi RFC:n mukaiselta.

9:59:59.000,9:59:59.000
Kun lähetät datakomennon, palvelin pyytää[br]lopettamaan datan lähettämisen . merkeillä.

9:59:59.000,9:59:59.000
Sitten löysin myös palvelimia, jotka sanoivat:[br]"lähetä minulla rivi, jossa on vain piste"

9:59:59.000,9:59:59.000
Ja tämä asia riippuu paljon käytettävästä [br]käyttöjärjestelmästä.

9:59:59.000,9:59:59.000
Windows:ssa tämä voi olla <CR><LF>.<CR><LF>[br]ja se voi olla .

9:59:59.000,9:59:59.000
Siinä kohtaa ajattelin, että tässä voisi[br]olla jotain.

9:59:59.000,9:59:59.000
Ja kokeilin jotain.

9:59:59.000,9:59:59.000
Ensimmäiseksi kokeilin työntää <CR>-, <LF>- ja piste-[br]merkkejä Paavo Pesusienen kautta.

9:59:59.000,9:59:59.000
Joten kirjoitin SMTP analyysisovelluksen, joka[br]lähettää virheellisiä data lopetussekvenssejä,

9:59:59.000,9:59:59.000
kuten <LF>.<LF> Ja lähetin viestejä eri SMTP-[br]ohjelmistoilla,

9:59:59.000,9:59:59.000
sisältäen sähköpostipalveluita Gmail, Outlook, GMX

9:59:59.000,9:59:59.000
ja lisäksi sähköpostiohjelmistoja kuten Postfix,[br]Exim, Microsoft Exchange Server ja niin edelleen.

9:59:59.000,9:59:59.000
Vastaanottavalla puolella tutkin, että mitkä[br]vääristä sekvensseistä menee itse asiassa läpi.

9:59:59.000,9:59:59.000
Voinko lähettää komennon <LF>.<LF> lähtevän palvelimen [br]kautta?

9:59:59.000,9:59:59.000
Ja useimmissa tapauksissa se ei toiminut.

9:59:59.000,9:59:59.000
<LF>.<LF> on usein suodatettu tai poistettu[br]alkuperäisestä viestistä.

9:59:59.000,9:59:59.000
Mutta jossain tapauksissa se menee läpi muuttumattomana.

9:59:59.000,9:59:59.000
Tämä oli tilanne GMX:n kohdalla. Lähetin sähköpostin[br]GMX:stä analyysipalvelimelleni

9:59:59.000,9:59:59.000
ja <LF>.<CR><LF> merkkejä ei poistettu.

9:59:59.000,9:59:59.000
Seuraavaksi tein proof-of-concept:n, jossa on[br]väärennetty datan lopetussekvenssi

9:59:59.000,9:59:59.000
ja sen jälkeen toinen sähköpostiviesti.

9:59:59.000,9:59:59.000
Jos tämä proof-of-concept toimii,

9:59:59.000,9:59:59.000
meidän pitäisi saada kaksi viestiä [br]vastaanottajan puolella.

9:59:59.000,9:59:59.000
Lähetin tämän kaiken Gmailiin.

9:59:59.000,9:59:59.000
Ja Gmail oli sitä mieltä, [br]että "tämä ei ei ole datan lopetussekvenssi".

9:59:59.000,9:59:59.000
Ja sen näkee siitä, että datan lopetussekvenssin[br]jälkeen kaikki on edelleen tulkittu viestin dataksi.

9:59:59.000,9:59:59.000
Mutta joissain tapauksissä tämä itse asiassa toimi.

9:59:59.000,9:59:59.000
Tämä oli ensimmäinen onnistunut [br]SMTP Smuggling tapaus, GMX:stä Fastmail:iin.

9:59:59.000,9:59:59.000
Me näemme, että se toimii. Meillä on ensin [br]viesti käyttäjältä user@gmx.net

9:59:59.000,9:59:59.000
ja toinen viesti käyttäjältä admin@gmx.net,

9:59:59.000,9:59:59.000
jotka läpäisevät SPF ja DMARC tarkistukset,[br]koska ne tulevat GMX:n palvelimelta.

9:59:59.000,9:59:59.000
[Applodeja]

9:59:59.000,9:59:59.000
Minä olin, että "tämä on aivan sairasta!"

9:59:59.000,9:59:59.000
Ajattelin, että meillä on tämä toinen viesti [br]ja siinä voi olla mitä tahansa.

9:59:59.000,9:59:59.000
Kuten lähettäjän osoite voi olla mitä vaan.

9:59:59.000,9:59:59.000
Joten miksi en kokeilisi muita domaineja,[br]jotka osoittavat GMX:n palvelimeen?

9:59:59.000,9:59:59.000
Sitten analysoin SPF tietueen ja tajusin...

9:59:59.000,9:59:59.000
Tässä on GMX:n SPF-tietue, mutta se on hyvin[br]samankaltainen web.de:n tietueen, joka puolestaan

9:59:59.000,9:59:59.000
on hyvin samankaltainen Ionoksen tietueen kanssa.

9:59:59.000,9:59:59.000
Ja jeah, tilanne on nyt se, että tällä me voimme[br]väärentää 1.35 miljoonaa domainia.

9:59:59.000,9:59:59.000
Jos ette tiedä mikä Ionos on, niin se on superiso [br]hosting- ja sähköpostipalveluiden tarjoaja.

9:59:59.000,9:59:59.000
Ja heillä on nämä 1.35 miljoonaa domainia[br]kytketty tähän.

9:59:59.000,9:59:59.000
Joten, minun täytyi tietenkin kokeilla tätä.

9:59:59.000,9:59:59.000
Tässä on sähköposti osoitteesta admin@web.de

9:59:59.000,9:59:59.000
Nyt kysymys on tietysti, että toimiiko[br]tämä kaikkialla?

9:59:59.000,9:59:59.000
Kuten sanoin, niin tämä palvelimilla,[br]jotka tulkitsevat lopetussekvenssit

9:59:59.000,9:59:59.000
tavalla, joka ei ole RFC:n mukainen,[br]kuten .

9:59:59.000,9:59:59.000
Voimme siis väärentää 1.35 miljoonaa domainia.

9:59:59.000,9:59:59.000
Joten pohjimmiltaan meillä on 1.4 miljoonaa Postifix instansia[br]ja 150 tuhatta Sendmail instanssia.

9:59:59.000,9:59:59.000
Ja tämä toimii, koska ne tulkitsevat...

9:59:59.000,9:59:59.000
[puhuja sekoilee sanoissaan]

9:59:59.000,9:59:59.000
Ne tulkitsevat <LF>.<CR><LF>, sekoilen itsekin sanoissani,[br]lopetussekvensiksi.

9:59:59.000,9:59:59.000
Ja olin, että OK, tämä on aika vakavaa.

9:59:59.000,9:59:59.000
Mutta tässä on muutakin.

9:59:59.000,9:59:59.000
Katsoin outlook.comia myös ja Outlook[br]palautti todella oudon virheilmoituksen

9:59:59.000,9:59:59.000
koska siinä on, että pelkät rivinvaihdot[br]eivät ole sallittuja.

9:59:59.000,9:59:59.000
Olin siinä kohtaa, että pahus, ne tietää[br]mitä olen tekemässä.

9:59:59.000,9:59:59.000
[Yleisöän naurua]

9:59:59.000,9:59:59.000
Siksi analysoin sen tarkemmin, ette pysty[br]minua tuolla pelottelemaan.

9:59:59.000,9:59:59.000
Joten löysin, että <LF>.<CR><LF> [br]on mahdollinen täällä.

9:59:59.000,9:59:59.000
[Yleisön applodeja]

9:59:59.000,9:59:59.000
Jeah, pidetään vähän hauskaa.

9:59:59.000,9:59:59.000
Tässä kohtaa en ollut varma, että[br]olenko tulossa hulluksi

9:59:59.000,9:59:59.000
vai toimiiko tämä todella.

9:59:59.000,9:59:59.000
Joten tarvitsin jonkinlaisen tarkistuksen.

9:59:59.000,9:59:59.000
Ja niinpä lähetin sähköpostin[br]osoitteesta admin@outlook.com

9:59:59.000,9:59:59.000
yhdelle kollegoistani. Idea oli siinä,[br]että jos he reagoivat tähän,

9:59:59.000,9:59:59.000
se toimii, muutoin olen tullut hulluksi.

9:59:59.000,9:59:59.000
Joten....

9:59:59.000,9:59:59.000
[Yleisön naurua]

9:59:59.000,9:59:59.000
Ja ehkä nyt hieman kansainvälisempi esimerkki,[br]koska tämä on todella itävaltalainen, luulen.

9:59:59.000,9:59:59.000
Luulen, että ymmärrätte tämän, vaikka ette[br]puhu saksaa.

9:59:59.000,9:59:59.000
Ja nyt olette, okei, voimme lähettää[br]tekstipohjaisia, väärennettyjä sähköposteja

9:59:59.000,9:59:59.000
mutta ette pysty huijaamaan tällä ketään

9:59:59.000,9:59:59.000
Mutta juttu on siinä, että voimme ujuttaa [br]periaatteessa mitä tahansa, HTML mukaan luettuna

9:59:59.000,9:59:59.000
Tässä lähetin viestin, kalasteluviestin, [br]epätavallisesta kirjautumisesta

9:59:59.000,9:59:59.000
osoitteesta no-reply@outlook.com

9:59:59.000,9:59:59.000
todelliselta outlook.com palvelimelta itselleni.

9:59:59.000,9:59:59.000
Ja se vain meni läpi.

9:59:59.000,9:59:59.000
Mutta mitä tämä mahdollistaa?

9:59:59.000,9:59:59.000
Pohdiskelin, että voimme väärentää[br]outlook.comin, mutta mitä muuta voimme tehdä tällä?

9:59:59.000,9:59:59.000
Katsoin SPF tietuetta ja se oli outo, [br]oudosti tuttu. koska tämä ei ole

9:59:59.000,9:59:59.000
pelkästään outlook.comin SPF tietue

9:59:59.000,9:59:59.000
vaan miljoonien muiden domainien SPF tietue.

9:59:59.000,9:59:59.000
Sen vuoksi, koska tämä Exchange Online[br]palvelun SPF tietue.

9:59:59.000,9:59:59.000
Outlook.com lähettää sähköpostit Exchange Online[br]infrastruktuurin kautta,

9:59:59.000,9:59:59.000
joten voimme itse asiassa väärentää ne kaikki.

9:59:59.000,9:59:59.000
Minun piti kokeilla tätä taas.

9:59:59.000,9:59:59.000
Tämä toimi ainoastaan teknisesti,[br]en saanut palkan korotusta.

9:59:59.000,9:59:59.000
Mikä vaikutus tällä on?

9:59:59.000,9:59:59.000
Voimme väärentää miljoonia domaineja, [br]mutta ketkä hyväksyvät nämä sähköpostit?

9:59:59.000,9:59:59.000
Jälleen Postfix ja Sendmail, mutta vain ne[br]instanssit, jotka eivät hyväksy BDAT komentoa.

9:59:59.000,9:59:59.000
BDAT on vaihtoehtoinen datakomennolle

9:59:59.000,9:59:59.000
ja jos sitä tuetaan, tämä ei toimi.

9:59:59.000,9:59:59.000
Se oli ulospäin suuntautuva ujutus,[br]joka on yksi osa tätä.

9:59:59.000,9:59:59.000
Sitten on myös sisäänpäin tuleva[br]SMTP ujutus.

9:59:59.000,9:59:59.000
Ulospäin suuntautuvassa ongelma oli[br]lähettävä palvelin

9:59:59.000,9:59:59.000
koska palvelin epäonnistui tai ei tehokkaasti[br]suodattanut väärennettyä datan lopetusekvenssiä

9:59:59.000,9:59:59.000
kuten <LF>.<CR><LF> Microsoftinh ja [br]GMX palveluissa.

9:59:59.000,9:59:59.000
Sitten on lisäksi sisäänpäin tuleva SMTP ujutus.

9:59:59.000,9:59:59.000
Tämä tapahtuu, kun on vastaanottava palvelin, [br]joka tulkitsee sellaisen villin datan lopetussekvenssin,

9:59:59.000,9:59:59.000
josta lähettävällä palvelimella ei ole hajuakaan [br]suodattaa pois.

9:59:59.000,9:59:59.000
Löysin tällaisen Cisco Securesta, tietysti, Email Cloud Gateway:sta

9:59:59.000,9:59:59.000
Mitä he tekevät on, ett'ähe siivoavat viestin ja <CR> merkki[br]korvataan  merkeillä.

9:59:59.000,9:59:59.000
Joten itse asiassa, <CR>.<CR> merkkien tulkinta[br]palauttaa datan lopetussekvenssin.

9:59:59.000,9:59:59.000
[Yleisön applodeja]

9:59:59.000,9:59:59.000
Ongelma on nyt siis tietenkin se, että <CR>.<CR> [br]ei suodateta ollenkaan pois.

9:59:59.000,9:59:59.000
On palveluita, jotka sen tekevät, mutta meillä[br]on jälleen Exchange Online, iCloud, Sendmail, Postix

9:59:59.000,9:59:59.000
ja monia muita, jotka päästävät tämän läpi.

9:59:59.000,9:59:59.000
Tavallaan se käy järkeen, koska en hoksaisi [br]sitä itsekään.

9:59:59.000,9:59:59.000
Joten, minun täytyi kokeilla tätä jälleen.

9:59:59.000,9:59:59.000
Valitettavasti, tai teknisesti, se toimi jälleen,

9:59:59.000,9:59:59.000
mutta en saanut en saanut yhtään Applen laitetta.

9:59:59.000,9:59:59.000
Ei sillä, että olisin halunnut muutenkaan.

9:59:59.000,9:59:59.000
Mikä vaikutus tällä on?

9:59:59.000,9:59:59.000
Pohjimmiltaan voimme väärentään vielä [br]enemmän domaineja kuin edellä.

9:59:59.000,9:59:59.000
Meillä on Exchange Online, meillä on iCloud,

9:59:59.000,9:59:59.000
meillä on Postfix ja Sendmail.

9:59:59.000,9:59:59.000
Ja voimme väärentää yrityksiä, joilla on[br]vara tähän - aika isoja yrityksiä tässä.

9:59:59.000,9:59:59.000
Tämä pitää sisällää yli 40 tuhatta muuta domainia.

9:59:59.000,9:59:59.000
Ja se on vain ne, jotka on hostattu pilvessä.

9:59:59.000,9:59:59.000
Lisäksi on on-prem instanssit, mutta en pystynyt[br]käymään niitä läpi.

9:59:59.000,9:59:59.000
Ja nyt osuuteen, joka on luultavasti mielenkiintoisin teille,[br]tai ainakin osalle teistä.

9:59:59.000,9:59:59.000
Vastuullinen julkaisu.

9:59:59.000,9:59:59.000
Puhtaasti teknisesti, koskien lähettäviä ja [br]vastaanottavia palvelimia, kenen vika tämä on?

9:59:59.000,9:59:59.000
Meillä on vastaanottavia palvelimia, joiden ei [br]koskaan oleteta tulkitsevan mitään muita

9:59:59.000,9:59:59.000
datan lopetussekvenssejä kuin <CR><LF>.<CR><LF>,[br]ainkin RFC:n mukaan.

9:59:59.000,9:59:59.000
Sitten meillä on lähettäviä palvelimia, joiden [br]ei oleteta lähettävän  ja  merkkejä

9:59:59.000,9:59:59.000
toisistaan riippumatta.

9:59:59.000,9:59:59.000
Joten lopulta tämän on kaikkien vika.

9:59:59.000,9:59:59.000
Lähetimme tämän tiedon GMX:lle.

9:59:59.000,9:59:59.000
He olivat superkiitollisia ja ilmoittivat[br]korjaavansa asian saman tien.

9:59:59.000,9:59:59.000
10 päivää myöhemmin he korjasivat tämän.

9:59:59.000,9:59:59.000
He pyysivät meitä tarkastamaan uudelleen ja [br]tarkastimme, että he todella korjasivat sen.

9:59:59.000,9:59:59.000
He maksoivat meille pienen palkkion.

9:59:59.000,9:59:59.000
Ha laittoivat meidät jopa heidän[br]Bug Bounty Hall of Fame:en.

9:59:59.000,9:59:59.000
Kaiken kaikkiaan se oli 10/10 kokemus.

9:59:59.000,9:59:59.000
[Applodeja]

9:59:59.000,9:59:59.000
Aion lähettää heille tallenteen teidän applodeista. Kiitos!

9:59:59.000,9:59:59.000
Tuntui melkein sille, että meidän olisi pitänyt[br]maksaa palkkio heille.

9:59:59.000,9:59:59.000
Tästä eteenpäin mennäänkin sitten alamäkeä.

9:59:59.000,9:59:59.000
Meillä on Microsoft. Microsoft oli sitä mieltä,[br]että tämä on kohtuullisen riskin haavoittuvuus.

9:59:59.000,9:59:59.000
En tiedä, ehkä heillä on suurempi kala kiikarissa,[br]mutta joka tapauksessa.

9:59:59.000,9:59:59.000
Lähetimme tiedot heille ja kolme kuukautta[br]myöhemmin he sulkivat tapauksen ja sanoivat,

9:59:59.000,9:59:59.000
että kaikki on korjattu, ei palkkiota ja niin edelleen.

9:59:59.000,9:59:59.000
Tässä kohtaa olin saanut jo mitä halusin.

9:59:59.000,9:59:59.000
Ja se on sähköpostin saaminen osoitteesta[br]admin@microsoft.com

9:59:59.000,9:59:59.000
Ja sitten Ciscoon.

9:59:59.000,9:59:59.000
Ciscon mielestä tämä ei ollut haavoittuvuus,

9:59:59.000,9:59:59.000
vaan dokumentoitu ja konfiguroitava ominaisuus.

9:59:59.000,9:59:59.000
Me olimme sitä mieltä, että onpa outo[br]ominaisuus,

9:59:59.000,9:59:59.000
koska voimme väärentää sähköposteja sillä.

9:59:59.000,9:59:59.000
Sanoimme, että kertokaa edes asiakkaillenne[br]tästä ominaisuudesta,

9:59:59.000,9:59:59.000
joka ei välttämättä ole paras oletustoiminallisuus.

9:59:59.000,9:59:59.000
He sanoivat "Ei".

9:59:59.000,9:59:59.000
Me olimme siinä, että meillä on tämä[br]suuri SMTP Smuggling ongelma.

9:59:59.000,9:59:59.000
Ja Cisco ei halua tehdä mitään, Microsoft[br]oli haavoittuvainen.

9:59:59.000,9:59:59.000
Me veimme tämän tapauksen CERT/CC:lle.

9:59:59.000,9:59:59.000
Niille, jotka eivät tiedä, CERT/CC koordinoi [br]ja käsittelee näitä suuria haavoittuvuuksia,

9:59:59.000,9:59:59.000
joilla voi olla maailmanlaajuisia vaikutuksia.

9:59:59.000,9:59:59.000
Me lähetimme tiedot heille ja he itse asiassa[br]hyväksyivät tapauksen.

9:59:59.000,9:59:59.000
Sitten olemme tässä Vince portaalissa.

9:59:59.000,9:59:59.000
Joka on periaatteessa iso chat-huone, jossa [br]14 toimittajaa.

9:59:59.000,9:59:59.000
Siellä on Microsoft, SendMail, Cisco, Google

9:59:59.000,9:59:59.000
Ja sitten voimme alkaa puhumaan haavoittuvuudesta

9:59:59.000,9:59:59.000
Ensimmäisessä keskustelussa Cisco sanoo[br]edelleen, että kyseessä ei ole haavoittuvuus.

9:59:59.000,9:59:59.000
Tiedättehän, se ei ole bugi, vaan ominaisuus.

9:59:59.000,9:59:59.000
Noh, joka tapauksessa se ei ole bugi heidän[br]mielestään.

9:59:59.000,9:59:59.000
Ja sitten CERT/CC on sitä mieltä, että[br]kyseessä ei ole haavoittuvuus, jostain syystä.

9:59:59.000,9:59:59.000
Kuinkas yleinen SMTP ujutusongelma?

9:59:59.000,9:59:59.000
Entäs Postfixin ja Sendmailin RFC:stä eriävät[br]tulkinnat datan lopetussekvenssistä?[br]

9:59:59.000,9:59:59.000
Ensinnäkin, Sendmail oli tässä Vince portaalissa[br]alusta alkaen.

9:59:59.000,9:59:59.000
He saivat kaikki PoC:t, viestit, kaiken.

9:59:59.000,9:59:59.000
Ja he eivät sanoneet mitään.

9:59:59.000,9:59:59.000
Entäpä Postfix? He ovat 10 kertaa suurempi.

9:59:59.000,9:59:59.000
CERT/CC oli... en tiedä miksi he eivät[br]lisänneet heitä tapaukseen suoraan.

9:59:59.000,9:59:59.000
Mutta CERT/CC lähetti heille sähköpostin, mutta[br]unohti mainita SMTP ujutuksen.

9:59:59.000,9:59:59.000
Luulimme siis, että he kertoivat Postfixille,. Sendmailia[br]ei nähtävästi kiinnostanut. CERT/CC on Ciscon puolella asiassa.

9:59:59.000,9:59:59.000
Me olimme, että Cisco on taatusti haavoittuvainen,[br]olimme varmistaneet sen.

9:59:59.000,9:59:59.000
Joten haluaisimme julkistaa tämän blogissa.

9:59:59.000,9:59:59.000
Ja tästä ongelmat vasta alkoivatkin.

9:59:59.000,9:59:59.000
Kerroimme, että haluaisimme julkaista tästä[br]blogikirjoituksen ja varoittaisimme Ciscon asiakkaita

9:59:59.000,9:59:59.000
tästä haavoittuvuudesta.

9:59:59.000,9:59:59.000
CERT/CC oli sitä mieltä, että "Antaa mennä vaan![br]Lähettäkää meille linkki kirjoitukseen, kun se on julkaistu"

9:59:59.000,9:59:59.000
Päätimme edetä ja tulimme avanneeksi Pandoran[br]laatikon, koska nyt 1.6 miljoonaan Postfix ja Sendmail

9:59:59.000,9:59:59.000
instanssia ovat haavoittuvina internetissä.

9:59:59.000,9:59:59.000
Ja se tarkoittaa, että jos tapahtuu ulospäin suuntautuva[br]SMTP ujuttelu, niin voit hyväksikäyttää Postfixiä ja Sendmailia yhä.

9:59:59.000,9:59:59.000
Tarkoittaako tämä, ettei SEC Consultissa ole yhtään vikaa?

9:59:59.000,9:59:59.000
Totta kai SEC Consultissa on vikaa.

9:59:59.000,9:59:59.000
Julkaisimme blogikirjoituksen olettaen, että[br]vaikutus olisi pienempi kuin se todellisuudessa oli

9:59:59.000,9:59:59.000
perustuen keskesteluihin CERT/CC:n kanssa ja [br]VINCE:ssä muutenkin.

9:59:59.000,9:59:59.000
Ja jos olisimme vain tuplavarmistaneet Postfixin[br]kanssa, että julkaisu ei ole ongelma, tätä ei olisi tapahtunut,

9:59:59.000,9:59:59.000
koska he ovat järkkymättämiä, että tämä on ongelma.

9:59:59.000,9:59:59.000
Yhteenveto, mitä tämä tarkoittaa?

9:59:59.000,9:59:59.000
Korjatkaa Postfix palvelimenne! Löydätte lisätietoja[br]Postfixin nettisivuilta.

9:59:59.000,9:59:59.000
Lisäksi korjatkaa Cisco palvelimenne. Voitte löytää[br]lisätietoja siitä SEC Consult:n blogista.

9:59:59.000,9:59:59.000
[Yleisön naurua ja aplodit]

9:59:59.000,9:59:59.000
Lopuksi, tässäkin pilvessä on jonkinlainen hopeareunus.

9:59:59.000,9:59:59.000
Nyt Postfix on suoraan mukana VINCE tapauksessa

9:59:59.000,9:59:59.000
ja he ovat jo antaneet suuren panoksen.

9:59:59.000,9:59:59.000
Emme työnnä päätämme pensaaseen ja yritä[br]aktiivisesti sulkea Pandoran lipasta jälleen.

9:59:59.000,9:59:59.000
Ja mitä se tarkoittaa? Lisää tutkimusta SMTP ujuttelusta

9:59:59.000,9:59:59.000
Tarkoitan, että pyysin CERT/CC:tä katsomaan tätä [br]tarkemmin, niin, se ei päättynyt kovin hyvin.

9:59:59.000,9:59:59.000
Lisää blogikirjoituksia, lisää tutkimusta ja [br]ennen kaikkea lisää toimijoita VINCE tapaukseen.

9:59:59.000,9:59:59.000
Yritämme saada kaiken korjattua ja olemme pahoillamme,[br]että tämä tapahtui ylipäätään.

9:59:59.000,9:59:59.000
Lopuksi jotain, jonka kaikki tiedätte. Älkää[br]luottako sähköposteihinn sokeasti, erityisesti tällä hetkellä.

9:59:59.000,9:59:59.000
Kiitos.