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 Postfixin korjaamisesta.

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:15.954
suuret kiitokset Wietselle ja Viktorille

0:01:16.032,0:01:18.312
heidän sitoutumisestaan.

0:01:18.334,0:01:20.354
Ja lisäksi suuret kiitokset yhteisölle

0:01:20.411,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:36.905
Ja kaikille niille,

0:01:37.007,0:01:39.067
joilla ei ole mitään hajua tästä.

0:01:39.129,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:45.956
lopettanut tutkimukseni DNS:n parissa.

0:01:45.956,0:01:48.564
ja etsin uutta tutkimuskohdetta,

0:01:48.564,0:01:51.908
kun löysin todennäköisesti helpoimman

0:01:51.908,0:01:53.583
tavan hakkeroida yrityksen

0:01:53.583,0:01:55.562
ja kaikki tämä vain yhdellä

0:01:55.562,0:01:58.073
yksinkertaisella Google-haulla.

0:01:58.173,0:02:00.913
[Yleisön naurua]

0:02:00.913,0:02:03.571
Ja tämä saattaa kuulostaa tyhmälle,

0:02:03.585,0:02:05.735
mutta tämä johdatti minut suuntaan,

0:02:05.735,0:02:08.005
jonka jo tiesin, mutta en ollut ymmärtänyt.

0:02:08.005,0:02:11.125
Ja se on, että tietojen kalastelu on edelleen

0:02:11.166,0:02:14.076
numero 1 ensipääsyvektori yritykseen

0:02:14.400,0:02:16.290
ja sitten minulla välähti:

0:02:16.382,0:02:18.232
Miksen tutkisi SMTP:tä,

0:02:18.456,0:02:20.136
simple mail transfer protocol:aa

0:02:20.400,0:02:23.264
jota käytetään miljardien sähköpostien

0:02:23.357,0:02:25.435
lähettämiseen joka päivä ympäri maailman

0:02:25.455,0:02:27.215
kuten on tehty viimeisen 40 vuoden ajan.

0:02:27.285,0:02:29.815
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.329
sähköpostien väärentämiseksi.

0:02:37.329,0:02:39.689
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:14.920
mutta tämä esitys ei kerro

0:03:14.920,0:03:17.098
ihmiseen penetroitumisesta.

0:03:17.833,0:03:21.833
Esitys kertoo tunkeutumisesta SMTP-protokollan muurien läpi.

0:03:22.014,0:03:24.790
Joten nähdäksemme miten tämä toimii

0:03:24.790,0:03:26.646
on meidän ensin ymmärrettävä

0:03:26.646,0:03:29.017
miten sähköpostien lähetys yleensäkin toimii.

0:03:29.017,0:03:32.570
Joten tässä meillä on melko yksinkertainen sähköposti-infrastuktuuri.

0:03:32.604,0:03:34.864
Meillä on sähköpostikäyttäjäagentti,

0:03:34.864,0:03:38.484
kuten Thunderbird, ja Thunderbird haluaa lähettää sähköpostin

0:03:38.494,0:03:41.684
esimerkiksi käyttäjänä user@outlook.com.

0:03:41.684,0:03:44.344
Joten jos haluamme lähettää sähköpostin tällä tavalla

0:03:44.344,0:03:46.938
meidän täytyy ensin tunnistautua

0:03:46.938,0:03:49.637
Outlook mail transfer agentille tai

0:03:49.637,0:03:52.389
ulospäin menevälle SMTP palvelimelle.

0:03:52.407,0:03:54.877
Ja kun olemme tunnistautuneet,

0:03:54.877,0:03:59.134
voimme lähettää sähköpostin käyttäjänä user@outlook.com.

0:03:59.134,0:04:02.227
Ja vain käyttäjänä user@outlook.com.

0:04:02.227,0:04:05.697
Tämän jälkeen viesti siirretään vastaanottajan

0:04:05.807,0:04:08.977
SMTP-palvelimelle ja tämä palvelin

0:04:08.977,0:04:12.977
tarkistaa viestin aitouden.

0:04:12.977,0:04:16.977
Ja kaikkein yleisen tapa tehdä tämä on SPF.

0:04:16.997,0:04:20.997
Vastaanottava SMTP-palvelin saa SPF-tietueen

0:04:21.007,0:04:24.267
DNS-palvelun kautta outlook.com osoitteelle.

0:04:24.267,0:04:27.357
Ja tarkistaa sen jälkeen, että tämä IP-osoite

0:04:27.357,0:04:30.467
ja IP-alue on sallittu lähettää sähköpostiviestejä

0:04:30.467,0:04:31.807
outlook.com osoitteelle.

0:04:31.807,0:04:36.437
Tässä tapauksessa todellinen Outlook SMTP-palvelin

0:04:36.437,0:04:38.606
tai ulospäin lähtevä SMTP-palvelin lähetti viestin,

0:04:38.687,0:04:40.907
vastaanottava SMTP-palvelin

0:04:40.907,0:04:42.367
hyväksyy viestin.

0:04:42.367,0:04:44.907
Ja nyt luonnollisesti tässä on erittäin

0:04:44.907,0:04:46.307
mielenkiintoinen kysymys.

0:04:46.307,0:04:49.637
Ja kysymys on: onko hyökkääjän mahdollista

0:04:49.637,0:04:51.827
lähettää sähköpostiviesti

0:04:51.827,0:04:54.587
esimerkiksi osoitteesta admin@outlook.com tai

0:04:54.587,0:04:56.557
väärennetystä sähköpostiosoitteesta?

0:04:56.647,0:04:58.797
Tätä me selvitämme tänään

0:04:58.797,0:05:01.107
ja se on enemmän tai vähemmän

0:05:01.107,0:05:03.507
tämän tutkimuksen tavoitteista.

0:05:03.507,0:05:04.948
En tiedä oletteko huomanneet,

0:05:04.948,0:05:07.227
mutta näiden palvelimien värit

0:05:07.227,0:05:10.267
muistuttavat minusta Paavo Pesusieneä

0:05:10.267,0:05:11.937
ja Patrik Tähtöstä.

0:05:11.937,0:05:15.087
Ja sen vuoksi kutsumme niitä niiksi.

0:05:17.380,0:05:20.277
Tutkimuksen yleinen tavoite ja

0:05:20.277,0:05:23.417
tutkimuksen peruste oli löytää

0:05:23.417,0:05:24.657
tapa väärentää sähköposteja.

0:05:24.657,0:05:28.157
Ja ajattelin, että miksi en ottaisi haavoittuvuuksia

0:05:28.157,0:05:30.337
muista tekstipohjaisista protokollista,

0:05:30.337,0:05:34.347
kuten HTTP:stä, ja soveltaisi niitä SMTP:hen.

0:05:35.892,0:05:40.431
Ja oli yksi HTTP haavoittuvuus, joka sopi kuvaan

0:05:40.431,0:05:43.077
ja se oli HTTP-pyynnön käpelöinti.

0:05:43.077,0:05:48.157
Tässä meillä on taas Paavo ja Patrik,

0:05:48.157,0:05:50.737
mutta tällä kertaa HTTP-maailmassa.

0:05:50.737,0:05:57.610
Joten, mitä tässä tapahtuu? Paavo Pesusieni saa [br]POST-tyyppisen pyynnön internetin yli

0:05:57.610,0:06:04.687
Mielenkiintoista tässä pyynnössä on se, [br]että siinä on kaksi otsikkoa

0:06:04.687,0:06:08.627
kuinka käsitellä POST-pyynnön data.

0:06:08.647,0:06:11.547
Siinä on Content-Length -otsikko, jonka arvona [br]on 43 tavua.

0:06:11.547,0:06:14.617
Ja siinä on myös Transfer-Encoding -otsikko.

0:06:14.617,0:06:19.647
Nyt Paavo Pesusienen täytyy päättää,[br]miten käsittelen pyynnön ja Paavo päättää

0:06:19.647,0:06:25.047
käyttää Content-Length otsikkoa, koska se on[br]43 tavua.

0:06:25.477,0:06:29.477
Joten kaikki punaisella kehystetty data[br]on välitetty Patrikille.

0:06:29.477,0:06:35.187
Patrikilla ei ole mitään hajua mitä tehdä - pitäisikö[br]minun tulkita Content-Lenth otsikkoa vai

0:06:35.187,0:06:39.897
Transfer-Encoding -otsikko? Patrik päättää[br]tulkita Transfer-Encoding otsikkoa ja

0:06:39.897,0:06:41.896
nyt meillä on eriävät tulkinnat:

0:06:41.896,0:06:48.506
Paavo Pesusieni käyttää Content-Length -otsikkoa[br]ja Patrik Tähtönen käyttää Transfer-Encoding -otsikkoa.

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

0:06:52.606,0:06:58.256
on loput Paavo Pesusienen lähettämästä datasta [br]tulkittu toiseksi pyynnöksi.

0:06:58.546,0:07:04.486
Itse asiassa tämä tarkoittaa, että Paavo näkee[br]yhden pyynnön ja Patrik kaksi pyyntöä.

0:07:04.627,0:07:10.037
Ja toinen pyyntö voidaan kohdistaa mielivaltaiseen[br]resurssipolkuun, kuten "Admin",

0:07:10.297,0:07:14.118
joka tässä esimerkissä on avoin vain sisäisesti[br]palvelimella.

0:07:14.297,0:07:16.407
Joka on tietenkin ongelma.

0:07:16.407,0:07:20.047
Joten ajattelin, että miksi en ottaisi[br]näitä tulkintaeroja

0:07:20.047,0:07:21.477
ja laittaisi niitä SMTP:hen.

0:07:21.477,0:07:27.507
Ymmärtääksemme... tai ainakin päästäksemme[br]lähemmäs ymmärrystä miten tämä toimii,

0:07:27.507,0:07:31.097
täytyy meidän katsoa ensin itse SMTP[br]protokollaa.

0:07:31.097,0:07:34.377
Joten, SMTP näyttää kuta kuinkin tältä.

0:07:34.377,0:07:40.167
Meillä on kaksi komponenttia: SMTP komennot[br]punaisella ja sinisellä viestin data.

0:07:40.957,0:07:47.077
Lähettääksemme viestin, meidän tulee ensin[br]lähettää SMTP komennot:

0:07:47.637,0:07:53.167
Meidän pitää esitellä itsemme, kertoa lähettäjän[br]osoite, yksi tai useampi vastaanottajan osoite ja

0:07:53.167,0:07:59.347
sitten lähetämme "data" komennon [br]kertoaksemme vastaanottavalle SMTP-palvelimelle

0:08:00.428,0:08:03.127
että olemme nyt vastaanottamassa varsinaista[br]viestin dataa.

0:08:04.017,0:08:12.107
Ja sitten lähetämme viestin datan: määrittelemme[br]lähettäjän osoitteen uudelleen, vastaanottajan osoitteen[br]ja viestin aiheen.[br]

0:08:12.467,0:08:14.507
Ja sitten tulee viestin leipäteksti.

0:08:14.507,0:08:17.987
Ja kun jossain vaiheessa haluamme[br]lopettaa viestin datan lähettämisen,

0:08:17.987,0:08:21.987
meidän tulee lähettää jotain, jota kutsumme[br]datan lopetussekvensiksi.

0:08:22.247,0:08:27.397
Se on "<paluu rivin alkuun><rivinvaihto> piste <paluu rivin alkuun><rivinvaihto>" [br][kääntäjän kommentti: jatkossa .]

0:08:28.657,0:08:36.577
Tässä vaiheessa ajattelin, että ehkä voisimme[br]hämätä tällä jotenkin SMTP-palvelinten toteutuksia.

0:08:37.667,0:08:43.717
Ajatus oli siis, että meillä on jälleen Paavo Pesusieni[br]ja lähetämme sähköpostin Paavo Pesusienelle [SIC].

0:08:45.507,0:08:48.847
Ja tämä sähköposti sisältää jotain[br]todella outoa, jotain joka näyttää

0:08:48.847,0:08:54.147
lopetussekvensille, mutta se ei ole sitä.

0:08:54.297,0:08:59.807
Koska se ei ole yhdenmukainen RFC:n kanssa, joku [br]voisi virheellisesti tulkita sen datan lopetussekvensiksi.

0:08:59.807,0:09:05.947
Joten Paavo Pesusieni katsoo tätä ja ajattelee[br]ettei tämä ole RFC:stä, en tulkitse tätä[br]"end-of-data" sekvensiksi

0:09:07.387,0:09:15.830
Ja seuraavaksi... tai viestin data siihen saakka,[br]kunnes varsinainen datan lopetussekvenssi tulee.

0:09:16.257,0:09:18.594
Sitten Paavo Pesusieni lähettää viestin Patrikille

0:09:19.057,0:09:26.402
Ja Patrik on "Jeah, en välitä mistään RFC:stä ja[br]ja tulkitsen väärän datan lopetussekvenssi

0:09:26.497,0:09:29.647
varsinaiseksi datan lopetusmerkiksi."

0:09:29.947,0:09:36.907
Ja ongelmaksi tässä tulee, että kaikki väärin [br]tulkitun lopetussekvenssin tulkitaan SMTP-komennoiksi

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

0:09:44.737,0:09:51.377
Vaikka Paavo Pesusieni näki yhden ison[br]sähköpostiviestin, Patrik näkee kaksi pienempää viestiä.

0:09:51.477,0:09:56.258
Ja ongelma on se, että toinen viesti voi sisältää[br]mielivaltaisia SMTP-komentoja.

0:09:56.358,0:10:00.508
Kuten, että viesti tulee osoitteesta admin@outlook.com[br]tai mitä tahansa.

0:10:01.697,0:10:05.447
Näin ainakin teoriassa.

0:10:05.687,0:10:07.887
Nähdäkseni toimiiko tämä todella.

0:10:09.067,0:10:13.557
Tutkin muutamia SMTP-palvelinten [br]toteutuksia yksinkertaisesti

0:10:13.587,0:10:17.077
ottamalla niihin yhteyttä telnet:llä tai[br]netcat:lla.

0:10:18.679,0:10:23.919
Kun tein tämän, se näytti aluksi RFC:n mukaiselta.

0:10:23.979,0:10:32.189
Kun lähetät datakomennon, palvelin pyytää[br]lopettamaan datan lähettämisen . merkeillä.

0:10:32.649,0:10:38.749
Sitten löysin myös palvelimia, jotka sanoivat:[br]"lähetä minulla rivi, jossa on vain piste"

0:10:39.005,0:10:45.625
Ja tämä asia riippuu paljon käytettävästä [br]käyttöjärjestelmästä.

0:10:45.914,0:10:54.314
Windows:ssa tämä voi olla <CR><LF>.<CR><LF>[br]ja Linuxissa se voi olla .

0:10:54.819,0:11:00.059
Siinä kohtaa ajattelin, että tässä voisi[br]olla jotain.

0:11:00.669,0:11:02.059
Ja kokeilin jotain.

0:11:02.062,0:11:11.552
Ensimmäiseksi kokeilin työntää <CR>-, <LF>- ja piste-[br]merkkejä Paavo Pesusienen kautta.

0:11:11.794,0:11:18.744
Joten kirjoitin SMTP analyysisovelluksen, joka[br]lähettää sähköposteja, joissa on virheellisiä data lopetussekvenssejä,

0:11:19.041,0:11:23.631
kuten <LF>.<LF> Ja lähetin viestejä eri SMTP-[br]ohjelmistoilla,

0:11:24.043,0:11:29.203
sisältäen sähköpostipalveluita Gmail, Outlook, GMX

0:11:29.383,0:11:35.193
ja lisäksi sähköpostiohjelmistoja kuten Postfix,[br]Exim, Microsoft Exchange Server ja niin edelleen.

0:11:36.500,0:11:44.420
Vastaanottavalla puolella tutkin, että mitkä[br]vääristä sekvensseistä menee itse asiassa läpi.

0:11:44.644,0:11:50.924
Voinko lähettää komennon <LF>.<LF> lähtevän palvelimen [br]kautta?

0:11:51.211,0:11:53.986
Ja useimmissa tapauksissa se ei toiminut.

0:11:54.326,0:11:58.956
<LF>.<LF> on usein suodatettu tai poistettu[br]alkuperäisestä viestistä.

0:11:59.298,0:12:05.318
Mutta jossain tapauksissa se menee läpi muuttumattomana.

0:12:05.539,0:12:12.319
Tämä oli tilanne GMX:n kohdalla. Lähetin sähköpostin[br]GMX:stä analyysipalvelimelleni

0:12:12.499,0:12:16.499
ja <LF>.<CR><LF> merkkejä ei poistettu.

0:12:16.732,0:12:23.562
Seuraavaksi tein proof-of-concept:n, jossa on[br]ensin viesti

0:12:23.703,0:12:26.403
ja sitten väärennetty datan lopetussekvenssi

0:12:26.505,0:12:30.405
ja sen jälkeen SMTP komentoja ja data [br]toiselle sähköpostiviestille.

0:12:30.589,0:12:33.149
Jos tämä proof-of-concept toimii,

0:12:33.363,0:12:37.393
meidän pitäisi saada kaksi viestiä [br]vastaanottajan puolella.

0:12:37.625,0:12:40.135
Lähetin tämän kaiken Gmailiin.

0:12:40.265,0:12:43.275
Ja Gmail oli sitä mieltä, [br]että "tämä ei ei ole datan lopetussekvenssi".

0:12:43.703,0:12:49.353
Ja sen näkee siitä, että datan lopetussekvenssin[br]jälkeen kaikki on edelleen tulkittu viestin dataksi.

0:12:49.984,0:12:54.244
Mutta joissain tapauksissä tämä itse asiassa toimi.

0:12:54.389,0:13:01.204
Tämä oli ensimmäinen onnistunut [br]SMTP Smuggling tapaus, GMX:stä Fastmail:iin.

0:13:01.481,0:13:06.611
Me näemme, että se toimii. Meillä on ensin [br]viesti käyttäjältä user@gmx.net

0:13:06.772,0:13:11.312
ja toinen viesti käyttäjältä admin@gmx.net,

0:13:11.451,0:13:18.151
jotka läpäisevät SPF ja DMARC tarkistukset,[br]koska ne tulevat todelliselta GMX:n palvelimelta.

0:13:18.639,0:13:26.119
[Applodeja]

0:13:28.313,0:13:31.873
Minä olin, että "tämä on aivan sairasta!"

0:13:34.762,0:13:37.942
Ajattelin, että meillä on tämä toinen viesti [br]ja siinä voi olla mitä tahansa.

0:13:38.128,0:13:40.228
Kuten lähettäjän osoite voi olla mitä vaan.

0:13:40.356,0:13:46.718
Joten miksi en kokeilisi muita domaineja,[br]jotka osoittavat GMX:n palvelimeen?

0:13:47.160,0:13:50.260
Sitten analysoin SPF tietueen ja tajusin...

0:13:50.582,0:13:59.642
Tässä on GMX:n SPF-tietue, mutta se on hyvin[br]samankaltainen web.de:n tietueen, joka puolestaan

0:13:59.791,0:14:03.121
on hyvin samankaltainen Ionoksen tietueen kanssa.

0:14:03.296,0:14:08.086
Ja tilanne on nyt se, että tällä me voimme[br]väärentää 1.35 miljoonaa domainia tällä.

0:14:09.031,0:14:15.631
Jos ette tiedä mikä Ionos on, niin se on superiso [br]hosting- ja sähköpostipalveluiden tarjoaja.

0:14:15.774,0:14:20.414
Ja heillä on nämä 1.35 miljoonaa domainia[br]kytketty tähän.

0:14:20.581,0:14:24.461
Joten, minun täytyi tietenkin kokeilla tätä.

0:14:24.993,0:14:28.773
Tässä on sähköposti osoitteesta admin@web.de

0:14:28.918,0:14:32.787
Nyt kysymys on tietysti, että toimiiko[br]tämä kaikkialla?

0:14:33.058,0:14:38.398
Kuten sanoin, niin tämä toimii vain palvelimilla,[br]jotka tulkitsevat lopetussekvenssit

0:14:38.752,0:14:42.672
tavalla, joka ei ole RFC:n mukainen,[br]kuten .

0:14:42.943,0:14:46.833
Voimme siis väärentää 1.35 miljoonaa domainia.

0:14:47.043,0:14:56.293
Joten pohjimmiltaan meillä on 1.4 miljoonaa Postifix instansia[br]ja 150 tuhatta Sendmail instanssia.

0:14:56.712,0:14:59.832
Ja tämä toimii, koska ne tulkitsevat...

0:15:00.194,0:15:02.044
[puhuja sekoilee sanoissaan]

0:15:02.571,0:15:06.676
Ne tulkitsevat <LF>.<CR><LF>, sekoilen itsekin sanoissani,[br]lopetussekvensiksi.

0:15:07.026,0:15:10.146
Ja olin, että OK, tämä on aika vakavaa.

0:15:10.502,0:15:12.692
Mutta tässä on muutakin.

0:15:12.864,0:15:18.314
Katsoin outlook.comia myös ja Outlook[br]palautti todella oudon virheilmoituksen

0:15:18.693,0:15:22.933
koska siinä on, että pelkät rivinvaihdot[br]eivät ole sallittuja.

0:15:23.329,0:15:26.869
Olin siinä kohtaa, että pahus, ne tietää[br]mitä olen tekemässä.

0:15:26.913,0:15:29.390
[Yleisöän naurua]

0:15:29.790,0:15:33.710
Siksi analysoin sen tarkemmin, ette pysty[br]minua tuolla pelottelemaan.

0:15:34.406,0:15:39.526
Joten löysin, että <LF>.<CR><LF> [br]on mahdollinen täällä.

0:15:39.772,0:15:44.052
[Yleisön applodeja]

0:15:49.043,0:15:51.663
Jeah, pidetään vähän hauskaa.

0:15:51.734,0:15:54.774
Tässä kohtaa en ollut varma, että[br]olenko tulossa hulluksi

0:15:54.912,0:15:57.002
vai toimiiko tämä todella.

0:15:57.341,0:15:59.771
Joten tarvitsin jonkinlaisen tarkistuksen.

0:15:59.937,0:16:02.607
Ja niinpä lähetin sähköpostin[br]osoitteesta admin@outlook.com

0:16:02.882,0:16:07.232
muutamille kollegoilleni. Idea oli siinä,[br]että jos he reagoivat tähän,

0:16:07.646,0:16:08.746
se toimii.

0:16:09.035,0:16:10.935
Muutoin olen tullut hulluksi.

0:16:11.101,0:16:13.341
Joten....

0:16:13.859,0:16:17.359
[Yleisön naurua]

0:16:17.561,0:16:23.211
Ja ehkä nyt hieman kansainvälisempi esimerkki,[br]koska tämä on todella itävaltalainen, luulen.

0:16:30.657,0:16:34.257
Luulen, että ymmärrätte tämän, vaikka ette[br]puhu saksaa.

0:16:35.321,0:16:39.701
Ja nyt olette, okei, voimme lähettää[br]tekstipohjaisia, väärennettyjä sähköposteja

0:16:40.048,0:16:42.598
mutta ette pysty huijaamaan tällä ketään

0:16:42.776,0:16:45.866
Mutta juttu on siinä, että voimme ujuttaa [br]periaatteessa mitä tahansa,

0:16:45.986,0:16:46.986
HTML:ää mukaan luettuna

0:16:47.856,0:16:53.628
Tässä lähetin viestin, kalasteluviestin, [br]epätavallisesta kirjautumisesta

0:16:53.968,0:16:58.138
osoitteesta no-reply@outlook.com[br]todelliselta outlook.com palvelimelta

0:16:59.005,0:17:00.329
itselleni.

0:17:00.469,0:17:02.509
Ja se vain meni läpi.

0:17:04.622,0:17:08.342
Mutta jälleen, mitä tämä mahdollistaa?

0:17:09.085,0:17:13.085
Pohdiskelin, että voimme väärentää outlook.comin,

0:17:13.454,0:17:16.167
mutta mitä muuta voimme tehdä tällä?

0:17:16.192,0:17:22.552
Katsoin SPF tietuetta ja se oli outo, [br]oudosti tuttu.

0:17:22.792,0:17:26.792
Koska tämä ei ole pelkästään outlook.comin SPF tietue

0:17:26.985,0:17:31.105
vaan miljoonien muiden domainien SPF tietue.

0:17:31.537,0:17:37.777
Sen vuoksi, koska tämä Exchange Online[br]palvelun SPF tietue.

0:17:39.297,0:17:44.707
Outlook.com lähettää sähköpostit Exchange Online[br]infrastruktuurin kautta,

0:17:45.262,0:17:49.202
joten voimme itse asiassa väärentää ne kaikki.

0:17:49.423,0:17:53.313
Minun piti kokeilla tätä taas.

0:18:06.726,0:18:10.936
Tämä toimi ainoastaan teknisesti,[br]en saanut palkan korotusta.

0:18:13.664,0:18:15.244
Mikä vaikutus tällä on?

0:18:15.295,0:18:20.087
Voimme väärentää miljoonia domaineja, [br]mutta ketkä hyväksyvät nämä sähköpostit?

0:18:20.325,0:18:27.375
Jälleen Postfix ja Sendmail, mutta vain ne[br]instanssit, jotka eivät hyväksy BDAT komentoa.

0:18:27.899,0:18:31.079
BDAT on vaihtoehtoinen datakomennolle

0:18:31.269,0:18:33.899
ja jos sitä tuetaan, tämä ei toimi.

0:18:35.777,0:18:38.827
Se oli ulospäin SMTP suuntautuva ujutus,

0:18:39.081,0:18:40.511
joka on yksi osa tätä.

0:18:40.610,0:18:44.073
Sitten on myös sisäänpäin tuleva[br]SMTP ujutus.

0:18:44.198,0:18:48.391
Ulospäin suuntautuvassa ongelma oli[br]lähettävä palvelin

0:18:48.687,0:18:56.071
koska palvelin epäonnistui tai ei tehokkaasti[br]suodattanut väärennettyä datan lopetussekvenssiä

0:18:56.164,0:19:01.804
kuten <LF>.<CR><LF> Microsoftin ja [br]GMX palveluissa.

0:19:02.808,0:19:05.288
Sitten on lisäksi sisäänpäin tuleva SMTP ujutus.

0:19:05.377,0:19:11.827
Tämä tapahtuu, kun on vastaanottava palvelin, [br]joka tulkitsee sellaisen villin datan lopetussekvenssin,

0:19:12.307,0:19:17.217
josta lähettävällä palvelimella ei ole hajuakaan [br]suodattaa pois.

0:19:17.779,0:19:25.129
Löysin tällaisen Cisco Securesta, tietysti, Email Cloud Gateway:sta

0:19:27.090,0:19:37.632
Mitä he tekevät on se, että he siivoavat viestin ja <CR> merkki[br]korvataan merkeillä.

0:19:38.048,0:19:44.008
Joten itse asiassa, <CR>.<CR> merkkien tulkinta[br]palauttaa datan lopetussekvenssin.

0:19:47.277,0:19:51.277
[Yleisön applodeja]

0:19:54.955,0:20:02.625
Ongelma on nyt siis tietenkin se, että <CR>.<CR> [br]ei suodateta ollenkaan pois.

0:20:02.652,0:20:08.542
On palveluita, jotka sen tekevät, mutta meillä[br]on jälleen Exchange Online, iCloud, Sendmail, Postix

0:20:08.725,0:20:11.800
ja monia muita, jotka päästävät tämän läpi.

0:20:11.990,0:20:16.530
Tavallaan se käy järkeen, koska en hoksaisi [br]sitä itsekään.

0:20:16.940,0:20:20.650
Joten, minun täytyi kokeilla tätä jälleen.

0:20:22.240,0:20:25.420
Valitettavasti, tai teknisesti, se toimi jälleen,

0:20:25.574,0:20:28.348
mutta en saanut en saanut yhtään Applen laitetta.

0:20:28.418,0:20:31.458
Ei sillä, että olisin halunnut muutenkaan.

0:20:35.025,0:20:36.015
Mikä vaikutus tällä on?

0:20:36.091,0:20:40.111
Pohjimmiltaan voimme väärentään vielä [br]enemmän domaineja kuin edellä.

0:20:40.236,0:20:43.636
Meillä on Exchange Online, meillä on iCloud,

0:20:43.818,0:20:46.272
meillä on Postfix ja Sendmail.

0:20:46.372,0:20:50.322
Ja voimme väärentää yrityksiä, joilla on[br]vara tähän.

0:20:51.480,0:20:53.678
Aika isoja yrityksiä tässä.

0:20:54.138,0:20:58.008
Tämä pitää sisällää yli 40 tuhatta muuta domainia.

0:20:58.150,0:21:01.020
Ja se on vain ne, jotka on hostattu pilvessä.

0:21:01.192,0:21:05.062
Lisäksi on on-prem instanssit, mutta en pystynyt[br]käymään niitä läpi.

0:21:06.998,0:21:12.609
Ja nyt osuuteen, joka on luultavasti mielenkiintoisin teille,[br]tai ainakin osalle teistä.

0:21:13.240,0:21:15.300
Vastuullinen julkaisu.

0:21:15.620,0:21:22.620
Puhtaasti teknisesti, koskien lähettäviä ja [br]vastaanottavia palvelimia, kenen vika tämä on?

0:21:22.811,0:21:27.891
Meillä on vastaanottavia palvelimia, joiden ei [br]koskaan oleteta tulkitsevan mitään muita

0:21:28.056,0:21:33.616
datan lopetussekvenssejä kuin <CR><LF>.<CR><LF>,[br]ainakin RFC:n mukaan.

0:21:34.216,0:21:40.266
Sitten meillä on lähettäviä palvelimia, joiden [br]ei oleteta lähettävän ja merkkejä

0:21:40.428,0:21:42.178
toisistaan riippumatta.

0:21:42.263,0:21:44.263
Joten periaatteessa tämä on kaikkien vika.

0:21:44.292,0:21:46.072
Lähetimme tiedot GMX:lle.

0:21:46.132,0:21:50.500
He olivat superkiitollisia ja ilmoittivat[br]korjaavansa asian saman tien.

0:21:50.600,0:21:53.680
10 päivää myöhemmin he korjasivat tämän.

0:21:53.792,0:21:57.939
He pyysivät meitä tarkastamaan uudelleen ja [br]tarkastimme, että he todella korjasivat sen.

0:21:58.089,0:22:00.779
He maksoivat meille pienen palkkion.

0:22:00.858,0:22:03.678
Ha laittoivat meidät jopa heidän[br]Bug Bounty Hall of Fame:en.

0:22:03.813,0:22:07.673
Kaiken kaikkiaan se oli 10/10 kokemus.

0:22:07.956,0:22:11.956
[Applodeja]

0:22:15.782,0:22:19.692
Aion lähettää heille tallenteen teidän applodeista. Kiitos!

0:22:19.751,0:22:24.191
Tuntui melkein sille, että meidän olisi pitänyt[br]maksaa palkkio heille.

0:22:25.219,0:22:29.069
Tästä eteenpäin mennäänkin sitten alamäkeä.

0:22:29.398,0:22:35.108
Meillä on Microsoft. Microsoft oli sitä mieltä,[br]että tämä on kohtuullisen riskin haavoittuvuus.

0:22:39.079,0:22:43.079
En tiedä, ehkä heillä on suurempi kala kiikarissa,[br]mutta joka tapauksessa.

0:22:46.132,0:22:50.132
Lähetimme tiedot heille ja kolme kuukautta[br]myöhemmin he sulkivat tapauksen ja sanoivat,

0:22:50.281,0:22:54.221
että kaikki on korjattu, ei palkkiota ja niin edelleen.

0:22:54.328,0:22:58.328
Tässä kohtaa olin saanut jo mitä halusin.

0:22:58.527,0:23:02.527
Ja se on sähköpostin saaminen osoitteesta[br]admin@microsoft.com

0:23:05.310,0:23:07.895
Ja sitten Ciscoon.

0:23:07.952,0:23:11.052
Ciscon mielestä tämä ei ollut haavoittuvuus,

0:23:11.206,0:23:14.766
vaan dokumentoitu ja konfiguroitava ominaisuus.

0:23:26.741,0:23:29.961
Me olimme sitä mieltä, että onpa outo[br]ominaisuus,

0:23:30.901,0:23:34.481
koska voimme väärentää sähköposteja sillä.

0:23:35.540,0:23:39.540
Sanoimme, että kertokaa edes asiakkaillenne[br]tästä ominaisuudesta,

0:23:39.667,0:23:43.547
joka ei välttämättä ole paras oletustoiminallisuus.

0:23:45.471,0:23:49.651
He sanoivat "Ei".

0:23:50.318,0:23:54.618
Me olimme siinä, että meillä on tämä[br]suuri SMTP Smuggling ongelma.

0:23:54.738,0:23:59.248
Ja Cisco ei halua tehdä mitään, Microsoft[br]oli haavoittuvainen siihen aikaan.

0:23:59.490,0:24:03.097
Me veimme tämän tapauksen CERT/CC:lle.

0:24:03.289,0:24:09.079
Niille, jotka eivät tiedä, CERT/CC koordinoi [br]ja käsittelee näitä suuria haavoittuvuuksia,

0:24:09.187,0:24:12.107
joilla voi olla maailmanlaajuisia vaikutuksia.

0:24:12.157,0:24:16.097
Me lähetimme tiedot heille ja he itse asiassa[br]hyväksyivät tapauksen.

0:24:16.273,0:24:19.543
Sitten olemme tässä Vince portaalissa.

0:24:19.664,0:24:23.004
Joka on periaatteessa iso chat-huone, jossa [br]on 14 toimittajaa.

0:24:23.138,0:24:27.208
Siellä on SendMail, Microsoft, Cisco, Google

0:24:28.415,0:24:31.645
Ja sitten voimme alkaa puhumaan haavoittuvuudesta

0:24:31.824,0:24:36.427
Ensimmäisessä keskustelussa Cisco sanoo[br]edelleen, että kyseessä ei ole haavoittuvuus.

0:24:36.877,0:24:40.697
Tiedättehän, se ei ole bugi, vaan ominaisuus.

0:24:40.890,0:24:44.120
Noh, joka tapauksessa se ei ole haavoittuvuus heidän[br]mielestään.

0:24:44.228,0:24:48.868
Ja sitten CERT/CC on sitä mieltä, että[br]kyseessä ei ole haavoittuvuus, jostain syystä.

0:24:49.246,0:24:54.126
OK. Entäs yleinen SMTP ujutusongelma?

0:24:54.310,0:24:59.536
Entäs Postfixin ja Sendmailin RFC:stä eriävät[br]tulkinnat datan lopetussekvenssistä?[br]

0:25:01.636,0:25:05.636
Ensinnäkin, Sendmail oli tässä Vince portaalissa[br]alusta alkaen.

0:25:05.846,0:25:10.942
He saivat kaikki PoC:t, viestit, kaiken.

0:25:11.372,0:25:15.372
Ja he eivät sanoneet mitään.

0:25:16.299,0:25:19.589
Entäpä Postfix? He ovat 10 kertaa suurempi.

0:25:20.366,0:25:25.387
CERT/CC oli... en tiedä miksi he eivät[br]lisänneet heitä tapaukseen suoraan.

0:25:25.457,0:25:31.053
Mutta CERT/CC lähetti heille sähköpostin, mutta[br]unohti mainita SMTP ujutuksen.

0:25:31.263,0:25:36.799
Luulimme siis, että he kertoivat Postfixille.

0:25:37.178,0:25:40.198
Sendmailia ei nähtävästi kiinnostanut.

0:25:40.299,0:25:43.139
CERT/CC on Ciscon puolella asiassa.

0:25:44.416,0:25:49.927
Me olimme, että Cisco on taatusti haavoittuvainen,[br]olimme varmistaneet sen.

0:25:50.147,0:25:52.887
Joten haluaisimme julkistaa tämän blogissa.

0:25:52.988,0:25:55.758
Ja tästä ongelmat vasta alkoivatkin.

0:25:55.980,0:26:00.062
Kerroimme, että haluaisimme julkaista tästä[br]blogikirjoituksen

0:26:00.148,0:26:03.962
ja varoittaisimme Ciscon asiakkaita [br]tästä ominaisuudesta.

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

0:26:13.849,0:26:18.971
Päätimme edetä ja tulimme avanneeksi Pandoran[br]laatikon,

0:26:19.381,0:26:24.081
koska nyt 1.6 miljoonaan Postfix ja Sendmail

0:26:24.349,0:26:27.279
instanssia ovat haavoittuvina internetissä.

0:26:27.366,0:26:30.886
Ja se tarkoittaa, että jos tapahtuu ulospäin suuntautuva[br]SMTP ujuttelu,

0:26:31.004,0:26:35.004
niin voit hyväksikäyttää Postfixiä ja Sendmailia yhä.

0:26:35.912,0:26:38.968
Tarkoittaako tämä, ettei SEC Consultissa ole yhtään vikaa?

0:26:39.098,0:26:41.168
Totta kai SEC Consultissa on vikaa.

0:26:41.231,0:26:47.388
Julkaisimme blogikirjoituksen olettaen, että[br]vaikutus olisi pienempi kuin se todellisuudessa oli

0:26:47.515,0:26:51.895
perustuen keskesteluihin CERT/CC:n kanssa ja [br]VINCE:ssä muutenkin.

0:26:52.095,0:26:59.770
Ja jos olisimme vain tuplavarmistaneet Postfixin[br]kanssa, että julkaisu ei ole ongelma, tätä ei olisi tapahtunut,

0:26:59.990,0:27:04.580
koska he ovat järkkymättämiä, että tämä on ongelma.

0:27:06.265,0:27:08.385
Yhteenveto, mitä tämä tarkoittaa?

0:27:08.493,0:27:13.578
Korjatkaa Postfix palvelimenne! Löydätte lisätietoja[br]Postfixin nettisivuilta.

0:27:13.748,0:27:19.458
Lisäksi korjatkaa Cisco palvelimenne. Voitte löytää[br]lisätietoja siitä SEC Consult:n blogista.

0:27:19.868,0:27:23.868
[Yleisön naurua ja aplodit]

0:27:31.288,0:27:35.288
Lopuksi, tässäkin pilvessä on jonkinlainen hopeareunus.

0:27:35.853,0:27:39.853
Nyt Postfix on suoraan mukana VINCE tapauksessa

0:27:40.002,0:27:42.378
ja he ovat jo antaneet suuren panoksen.

0:27:42.598,0:27:47.215
Emme työnnä päätämme pensaaseen ja yritä[br]aktiivisesti sulkea Pandoran lipasta jälleen.

0:27:47.985,0:27:53.735
Ja mitä se tarkoittaa? Lisää tutkimusta SMTP ujuttelusta

0:27:53.868,0:27:59.179
Tarkoitan, että pyysin CERT/CC:tä katsomaan tätä [br]tarkemmin, niin, se ei päättynyt kovin hyvin.

0:27:59.287,0:28:07.337
Lisää blogikirjoituksia, lisää tutkimusta ja [br]ennen kaikkea lisää toimijoita VINCE tapaukseen.

0:28:07.433,0:28:13.003
Yritämme saada kaiken korjattua ja olemme pahoillamme,[br]että tämä tapahtui ylipäätään.

0:28:14.635,0:28:25.980
Lopuksi jotain, jonka kaikki tiedätte. Älkää[br]luottako sähköposteihinn sokeasti, erityisesti tällä hetkellä.

0:28:27.057,0:28:28.877
Kiitos.

0:28:29.278,0:28:33.278
[Aplodeja]

0:28:45.933,0:28:48.623
Hienoa, kiitos. Mennään kysymyksiin.

0:28:49.040,0:28:50.780
Ole hyvä.

0:28:50.907,0:28:55.217
Hei, minulla on yksi lyhyt kysymys CERT/CC asiasta.

0:28:55.501,0:28:58.501
Oliko tämä kommunikoitu sähköpostilla?

0:28:58.577,0:29:03.007
Ja etkö olisi voinut lähettää viestin [br]Ciscon CDO:na?

0:29:04.083,0:29:08.373
Kyllä, olisimme voineet tehdä sen ja luoda [br]jonkinlaisen kolmiodraamaan

0:29:08.648,0:29:12.838
Bill Gatesin, Elon Muskin ja jonkun muun välille.

0:29:14.718,0:29:18.588
Mutta valitettavasti emme nähneet tätä sähköpostia.

0:29:18.867,0:29:22.897
Näimme sen jälkeen päin, mutta se oli valitettavasti[br]liian myöhäistä.

0:29:26.053,0:29:28.733
Hei, kiitos teille. Arvostan työtänne.

0:29:29.031,0:29:33.031
Voisitko kertoa hieman aikajanasta?

0:29:33.187,0:29:36.827
Koska löysitte tämän ensimmäisen kerran?

0:29:37.057,0:29:41.497
Aloitin tutkimuksen kesäkuussa kuluvana vuonna

0:29:41.659,0:29:45.569
Minulla oli 10 päivän projekti SEC Consultilla.

0:29:45.797,0:29:50.567
Olin sitä mieltä, että 10 päivää ei riitä, joten[br]aloitin 10 päivää aiemmin.

0:29:51.372,0:29:55.272
Sitten löysin SMTP ujuttelun kuudentena päivänä

0:29:55.672,0:30:03.942
Sitten asia eteni kertomalla GMX:lle, Outlookille[br]tai Microsoftille ja Ciscolle

0:30:04.095,0:30:08.325
koska heillä oli vakavat SMTP ujuttelutapaukset, [br]koskien sekä lähtevää ja saapuvaa.

0:30:08.628,0:30:14.992
Sitten jatkoimme ja kerroimme CERT/CC:lle, koska[br]tämä vaikutti olevan laajempi ongelma maailmanlaajuisesti.

0:30:15.512,0:30:20.862
Aikataulumielessä, minulla ei ole sitä tässä nyt,[br]mutta se on SEC Consultin blogikirjoituksessa.

0:30:23.808,0:30:26.781
Onko joku tietty päivämäärä, jonka haluat tietää?

0:30:26.991,0:30:29.451
Ei, ei. Käyn lukemassa blogikirjoituksen. Kiitos.

0:30:32.952,0:30:37.342
Hei, kiitos hyvästä puheesta täällä.

0:30:37.754,0:30:41.334
Haluaisin kysyä, että on mitään evidenssiä

0:30:41.573,0:30:45.013
tai epäilyksiä, että tätä olisi jo käytetty?

0:30:45.483,0:30:51.123
Tämä näyttää melko yksinkertaiselta[br]haavoittuvuudelta hyödyntää.

0:30:51.350,0:30:54.510
Voisin kuvitella, että sitä on jo hyödynnetty.

0:30:54.677,0:30:58.807
Jeah, sain joitain kommentteja Reddit postaukseeni

0:30:58.925,0:31:02.855
että tämä on supervanha,[br]mutta asia on...

0:31:03.585,0:31:05.705
Kohtalainen haavoittuvuus

0:31:06.054,0:31:07.184
Jeah, todennäköisesti

0:31:07.385,0:31:10.035
Ei, en tosiaankaan tiedä.

9:59:59.000,9:59:59.000
Kävin läpi paljon tutkimuksia, mutta niissä[br]ei ollut mitään.

9:59:59.000,9:59:59.000
Siksi kutsun tätä uudeksi haavoittuvuudeksi.

9:59:59.000,9:59:59.000
Translated by Mikko Heikkinen (ITKST56 course assignment at JYU.FI)