WEBVTT

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

00:00:05.372 --> 00:00:13.612
[Musiikkia]

00:00:14.212 --> 00:00:18.212
OK. Seuraavaksi puhuu Timo Longin,

00:00:19.402 --> 00:00:22.212
joka tunnetaan myös nimellä Timo Login.

00:00:22.324 --> 00:00:27.264
Hän tietoturvakonsultti ja tutkija. Hän tulee puhumaan uudesta tekniikasta

00:00:27.578 --> 00:00:29.778
nimeltään SMTP Smuggling,

00:00:29.943 --> 00:00:32.343
jolla voidaan väärentää sähköposteja

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

00:00:34.317 --> 00:00:37.207
Kiitos. Annetaan Timolle applodit.

00:00:37.641 --> 00:00:41.641
[Applodeja]

00:00:43.181 --> 00:00:45.111
Kiitos esittelystä.

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

00:00:49.811 --> 00:00:53.801
tämän katastrofaalisen haavoittuvuuden julkaisemisesta.

00:00:54.784 --> 00:01:00.734
Erityisesti pahoittelut Wietselle ja Viktorille korjausten jälkikorjauksesta

00:01:01.328 --> 00:01:05.418
sekä kaikille järjestelmävalvojille ympäri maailman,

00:01:05.701 --> 00:01:08.721
jotka ovat joutuneet asentamaan korjauksia joululoman aikana.

00:01:09.070 --> 00:01:11.790
Ja lisäksi, joka tapauksessa,

00:01:12.284 --> 00:01:16.284
suuret kiitokset Wietselle ja Viktorille

00:01:16.342 --> 00:01:20.072
heidän sitoutumisestaan.

00:01:20.094 --> 00:01:22.344
Ja lisäksi suuret kiitokset yhteisölle

00:01:22.391 --> 00:01:25.373
tämän ongelman viemisestä julkaisujärjestelmiin ja niin edelleen.

00:01:25.563 --> 00:01:27.843
Ja kaikille... Okei...

00:01:28.332 --> 00:01:32.882
[Applodeja]

00:01:35.495 --> 00:01:37.175
Ja kaikille niille,

00:01:37.307 --> 00:01:39.277
joilla ei ole mitään hajua tästä.

00:01:39.349 --> 00:01:41.729
Joten minäpä autan teidät samalle sivulle.

00:01:41.835 --> 00:01:43.845
Noin vuosi sitten olin juuri

00:01:43.876 --> 00:01:46.756
lopettanut tutkimukseni DNS:n parissa.

00:01:46.804 --> 00:01:49.274
ja etsin uutta tutkimuskohdetta,

00:01:49.414 --> 00:01:52.328
kun löysin todennäköisesti helpoimman

00:01:52.423 --> 00:01:54.543
tavan hakkeroida yrityksen

00:01:54.672 --> 00:01:56.772
ja kaikki tämä vain yhdellä

00:01:56.823 --> 00:01:59.053
yksinkertaisella Google-haulla.

00:01:59.053 --> 00:02:01.073
[Yleisön naurua]

00:02:01.211 --> 00:02:03.921
Ja tämä saattaa kuulostaa tyhmälle,

00:02:04.025 --> 00:02:06.275
mutta tämä johdatti minut suuntaan,

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

00:02:09.517 --> 00:02:12.637
Ja se on, että tietojen kalastelu on edelleen

00:02:12.656 --> 00:02:15.566
numero 1 ensipääsyvektori yritykseen

00:02:15.645 --> 00:02:17.535
ja sitten minulla välähti:

00:02:17.622 --> 00:02:19.472
Miksen tutkisi SMTP:tä,

00:02:19.556 --> 00:02:21.236
simple mail transfer protocol:aa

00:02:21.330 --> 00:02:23.714
jota käytetään miljardien sähköpostien

00:02:23.757 --> 00:02:26.235
lähettämiseen joka päivä ympäri maailman

00:02:26.315 --> 00:02:28.375
kuten on tehty viimeisen 40 vuoden ajan.

00:02:28.410 --> 00:02:30.780
Joten matkani eteni DNS:stä SMTP:hen

00:02:30.780 --> 00:02:32.760
ja tänään esittelen uuden

00:02:32.773 --> 00:02:34.963
SMTP Smuggling -tekniikan

00:02:35.009 --> 00:02:37.389
sähköpostien väärentämiseksi.

00:02:37.471 --> 00:02:39.771
Kuka olenkaan? OIen Timo Longin

00:02:39.832 --> 00:02:41.674
ja työskentelen tietoturvakonsulttina

00:02:41.674 --> 00:02:43.375
SEC Consult -yhtiössä ja

00:02:43.375 --> 00:02:45.245
päivisin teen penetraatiotestausta

00:02:45.245 --> 00:02:47.535
ja öisin teen haavoittuvuustutkimusta.

00:02:47.565 --> 00:02:50.485
Ja viimeisen kolmen vuoden aikana olen

00:02:50.533 --> 00:02:53.369
tutkinut paljon DNS-haavoittuvuuksia.

00:02:53.369 --> 00:02:56.049
Ja olen julkaissut paljon blogikirjoituksia ja työkaluja.

00:02:56.257 --> 00:02:59.007
Ja minun täytyi siirtyä eteenpäin.

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

00:03:05.093 --> 00:03:06.913
se oli... dildoista.

00:03:07.393 --> 00:03:08.883
[Yleisön naurua]

00:03:09.121 --> 00:03:12.091
Ja tiedän, että joudun tuottamaan osalle

00:03:12.184 --> 00:03:13.644
teistä pettymyksen,

00:03:13.644 --> 00:03:15.390
mutta tämä esitys ei kerro

00:03:15.390 --> 00:03:17.510
ihmiseen penetroitumisesta.

99:59:59.999 --> 99:59:59.999
Esitys kertoo tunkeutumisesta SMTP-protokollan muurien läpi.

99:59:59.999 --> 99:59:59.999
Joten nähdäksemme miten tämä toimii

99:59:59.999 --> 99:59:59.999
on meidän ensin ymmärrettävä

99:59:59.999 --> 99:59:59.999
miten sähköpostien lähetys yleensäkin toimii.

99:59:59.999 --> 99:59:59.999
Joten tässä meillä on melko yksinkertainen sähköposti-infrastuktuuri.

99:59:59.999 --> 99:59:59.999
Meillä on sähköpostikäyttäjäagentti,

99:59:59.999 --> 99:59:59.999
kuten Thunderbird, ja Thunderbird haluaa lähettää sähköpostin

99:59:59.999 --> 99:59:59.999
esimerkiksi käyttäjänä user@outlook.com.

99:59:59.999 --> 99:59:59.999
Joten jos haluamme lähettää sähköpostin tällä tavalla

99:59:59.999 --> 99:59:59.999
meidän täytyy ensin tunnistautua

99:59:59.999 --> 99:59:59.999
Outlook mail transfer agentille tai

99:59:59.999 --> 99:59:59.999
ulospäin menevälle SMTP palvelimelle.

99:59:59.999 --> 99:59:59.999
Ja kun olemme tunnistautuneet,

99:59:59.999 --> 99:59:59.999
voimme lähettää sähköpostin käyttäjänä user@outlook.com.

99:59:59.999 --> 99:59:59.999
Ja vain käyttäjänä user@outlook.com.

99:59:59.999 --> 99:59:59.999
Tämän jälkeen viesti siirretään vastaanottajan

99:59:59.999 --> 99:59:59.999
SMTP-palvelimelle ja tämä palvelin

99:59:59.999 --> 99:59:59.999
tarkistaa viestin aitouden.

99:59:59.999 --> 99:59:59.999
Ja kaikkein yleisen tapa tehdä tämä on SPF.

99:59:59.999 --> 99:59:59.999
Vastaanottava SMTP-palvelin saa SPF-tietueen

99:59:59.999 --> 99:59:59.999
DNS-palvelun kautta outlook.com osoitteelle.

99:59:59.999 --> 99:59:59.999
Ja tarkistaa sen jälkeen, että tämä IP-osoite

99:59:59.999 --> 99:59:59.999
ja IP-alue on sallittu lähettää sähköpostiviestejä

99:59:59.999 --> 99:59:59.999
outlook.com osoitteelle.

99:59:59.999 --> 99:59:59.999
Tässä tapauksessa todellinen Outlook SMTP-palvelin

99:59:59.999 --> 99:59:59.999
tai ulospäin lähtevä SMTP-palvelin lähetti viestin,

99:59:59.999 --> 99:59:59.999
vastaanottava SMTP-palvelin

99:59:59.999 --> 99:59:59.999
hyväksyy viestin.

99:59:59.999 --> 99:59:59.999
Ja nyt luonnollisesti tässä on erittäin

99:59:59.999 --> 99:59:59.999
mielenkiintoinen kysymys.

99:59:59.999 --> 99:59:59.999
Ja kysymys on: onko hyökkääjän mahdollista

99:59:59.999 --> 99:59:59.999
lähettää sähköpostiviesti

99:59:59.999 --> 99:59:59.999
esimerkiksi osoitteesta admin@outlook.com tai

99:59:59.999 --> 99:59:59.999
väärennetystä sähköpostiosoitteesta?

99:59:59.999 --> 99:59:59.999
Tätä me selvitämme tänään

99:59:59.999 --> 99:59:59.999
ja se on enemmän tai vähemmän

99:59:59.999 --> 99:59:59.999
tämän tutkimuksen tavoitteista.

99:59:59.999 --> 99:59:59.999
En tiedä oletteko huomanneet,

99:59:59.999 --> 99:59:59.999
mutta näiden palvelimien värit

99:59:59.999 --> 99:59:59.999
muistuttavat minusta Paavo Pesusieneä

99:59:59.999 --> 99:59:59.999
ja Patrik Tähtöstä.

99:59:59.999 --> 99:59:59.999
Ja sen vuoksi kutsumme niitä niiksi.

99:59:59.999 --> 99:59:59.999
Tutkimuksen yleinen tavoite ja

99:59:59.999 --> 99:59:59.999
tutkimuksen peruste oli löytää

99:59:59.999 --> 99:59:59.999
tapa väärentää sähköposteja.

99:59:59.999 --> 99:59:59.999
Ja ajattelin, että miksi en ottaisi haavoittuvuuksia

99:59:59.999 --> 99:59:59.999
muista tekstipohjaisista protokollista,

99:59:59.999 --> 99:59:59.999
kuten HTTP:stä, ja soveltaisi niitä SMTP:hen.

99:59:59.999 --> 99:59:59.999
Ja oli yksi HTTP haavoittuvuus, joka sopi kuvaan

99:59:59.999 --> 99:59:59.999
ja se oli HTTP-pyynnön käpelöinti.

99:59:59.999 --> 99:59:59.999
Tässä meillä on taas Paavo ja Patrik,

99:59:59.999 --> 99:59:59.999
mutta tällä kertaa HTTP-maailmassa.

NOTE Paragraph

99:59:59.999 --> 99:59:59.999
Joten, mitä tässä tapahuu? Paavo Pesusieni saa 
POST-tyyppisen pyynnön internetin yli

99:59:59.999 --> 99:59:59.999
Mielenkiintoista tässä pyynnössä on se, 
että siinä on kaksi otsikkoa

99:59:59.999 --> 99:59:59.999
kuinka käsitellä POST-pyynnön data.

99:59:59.999 --> 99:59:59.999
Siinä on Content-Length -otsikko, jonka arvona 
43 tavua.

99:59:59.999 --> 99:59:59.999
Ja siinä on myös Transfer-Encoding -otsikko.

99:59:59.999 --> 99:59:59.999
Nyt Paavo Pesusienen täytyy päättää,
miten käsittelen pyynnön ja Paavo päättää

99:59:59.999 --> 99:59:59.999
käyttää Content-Length otsikkoa, koska se on
43 tavua.

99:59:59.999 --> 99:59:59.999
Joten kaikki punaisella kehystetty data
on välitetty Patrikille.

99:59:59.999 --> 99:59:59.999
Patrikilla ei ole mitään hajua mitä tehdä - pitäisikö
minun tulkita Content-Lenth otsikkoa vai

99:59:59.999 --> 99:59:59.999
Transfer-Encoding -otsikko? Patrik päättää
tulkita Transfer-Encoding otsikkoa ja

99:59:59.999 --> 99:59:59.999
nyt meillä on eriävät tulkinnat:

99:59:59.999 --> 99:59:59.999
Paavo Pesusieni käyttää Content-Length -otsikkoa
ja Patrik Tähtönen käyttää Transfer-Encoding -otsikkoa.

99:59:59.999 --> 99:59:59.999
Ja koska Transfer-Encoding on määritetty "chunked" ("paloiteltu") ja
ja ensimmäinen pala on 0,

99:59:59.999 --> 99:59:59.999
on loput Paavo Pesusienen lähettämästä datasta 
tulkittu toiseksi pyynnöksi.

99:59:59.999 --> 99:59:59.999
Itse asiassa tämä tarkoittaa, että Paavo näkee
yhden pyynnön ja Patrik kaksi pyyntöä.

99:59:59.999 --> 99:59:59.999
Ja toinen pyyntö voidaan kohdistaa mielivaltaiseen
resurssipolkuun, kuten "Admin",

99:59:59.999 --> 99:59:59.999
joka tässä esimerkissä on avoin vain sisäisesti
palvelimella.

99:59:59.999 --> 99:59:59.999
Joka on tietenkin ongelma.

99:59:59.999 --> 99:59:59.999
Joten ajattelin, että miksi en ottaisi
näitä tulkintaeroja

99:59:59.999 --> 99:59:59.999
ja laittaisi niitä SMTP:hen.

99:59:59.999 --> 99:59:59.999
Ymmärtääksemme... tai ainakin päästäksemme
lähemmäs ymmärrystä miten tämä toimii,

99:59:59.999 --> 99:59:59.999
täytyy meidän katsoa ensin itse SMTP
protokollaa.

99:59:59.999 --> 99:59:59.999
Joten, SMTP näyttää kuta kuinkin tältä.

99:59:59.999 --> 99:59:59.999
Meillä on kaksi komponenttia: SMTP komennot
punaisella ja sinisellä viestin data.

99:59:59.999 --> 99:59:59.999
Lähettääksemme viestin, meidän tulee ensin
lähettää SMTP komennot:

99:59:59.999 --> 99:59:59.999
Meidän pitää esitellä itsemme, kertoa lähettäjän
osoite, yksi tai useampi vastaanottajan osoite ja

99:59:59.999 --> 99:59:59.999
sitten lähetämme "data" komennon 
kertoaksemme vastaanottavalle SMTP-palvelimelle

99:59:59.999 --> 99:59:59.999
että olemme nyt vastaanottamassa varsinaista
viestin dataa.

99:59:59.999 --> 99:59:59.999
Ja sitten lähetämme viestin datan: määrittelemme
lähettäjän osoitteen uudelleen, vastaanottajan osoitteen
ja viestin aiheen.


99:59:59.999 --> 99:59:59.999
Ja sitten tulee viestin leipäteksti.

99:59:59.999 --> 99:59:59.999
Ja kun jossain vaiheessa haluamme
lopettaa viestin datan lähettämisen,

99:59:59.999 --> 99:59:59.999
meidän tulee lähettää jotain. jota kutsumme
datan lopetussekvensiksi.

99:59:59.999 --> 99:59:59.999
Se on "<paluu rivin alkuun><rivinvaihto> piste <paluu rivin alkuun><rivinvaihto>" 
[kääntäjän kommentti: jatkossa .]

99:59:59.999 --> 99:59:59.999
Tässä vaiheessa ajattelin, että ehkä voisimme
hämätä tällä jotenkin SMTP-palvelinten toteutuksia.

99:59:59.999 --> 99:59:59.999
Ajatus oli siis, että meillä on jälleen Paavo Pesusieni
ja lähetämme sähköpostin Paavo Pesusienelle [SIC].

99:59:59.999 --> 99:59:59.999
Ja tämä sähköposti sisältää jotain
todella outoa, jotain joka näyttää

99:59:59.999 --> 99:59:59.999
lopetussekvensille, mutta se ei ole sitä.

99:59:59.999 --> 99:59:59.999
Koska se ei ole yhdenmukainen RFC:n kanssa, joku 
voisi virheellisesti tulkita sen datan lopetussekvensiksi.

99:59:59.999 --> 99:59:59.999
Joten Paavo Pesusieni katsoo tätä ja ajattelee
ettei tämä ole RFC:stä, en tulkitse tätä
"end-of-data" sekvensiksi

99:59:59.999 --> 99:59:59.999
Ja seuraavaksi... tai viestin data siihen saakka,
kunnes varsinainen datan lopetussekvenssi tulee.

99:59:59.999 --> 99:59:59.999
Sitten Paavo Pesusieni lähettää viestin Patrikille

99:59:59.999 --> 99:59:59.999
Ja Patrik on "Jeah, en välitä mistään RFC:stä ja
ja tulkitsen väärän datan lopetussekvenssi

99:59:59.999 --> 99:59:59.999
varsinaiseksi datan lopetusmerkiksi."

99:59:59.999 --> 99:59:59.999
Ja ongelmaksi tässä tulee, että kaikki väärin 
tulkitun lopetussekvenssin tulkitaan SMPT-komennoiksi

99:59:59.999 --> 99:59:59.999
Ja nyt hyökkääjänä voimme luoda SMTP-komentoja,
jotka lähettävät toisen sähköpostiviestin.

99:59:59.999 --> 99:59:59.999
Vaikka Paavo Pesusieni näki yhden ison
sähköpostiviestin, Patrik näkee kaksi pienempää viestiä.

99:59:59.999 --> 99:59:59.999
Ja ongelma on se, että toinen viesti voi sisältää
mielivaltaisia SMTP-komentoja.

99:59:59.999 --> 99:59:59.999
Kuten, että viesti tulee osoitteesta admin@outlook.com
tai mitä tahansa.

99:59:59.999 --> 99:59:59.999
Näin ainakin teoriassa.

99:59:59.999 --> 99:59:59.999
Nähdäkseni toimiiko tämä todella.

99:59:59.999 --> 99:59:59.999
Tutkin muutamia SMTP-palvelinten 
toteutuksia yksinkertaisesti

99:59:59.999 --> 99:59:59.999
ottamalla niihin yhteyttä telnet:llä tai
netcat:lla.

99:59:59.999 --> 99:59:59.999
Kun tein tämän, se näytti aluksi RFC:n mukaiselta.

99:59:59.999 --> 99:59:59.999
Kun lähetät datakomennon, palvelin pyytää
lopettamaan datan lähettämisen . merkeillä.

99:59:59.999 --> 99:59:59.999
Sitten löysin myös palvelimia, jotka sanoivat:
"lähetä minulla rivi, jossa on vain piste"

99:59:59.999 --> 99:59:59.999
Ja tämä asia riippuu paljon käytettävästä 
käyttöjärjestelmästä.

99:59:59.999 --> 99:59:59.999
Windows:ssa tämä voi olla <CR><LF>.<CR><LF>
ja se voi olla .

99:59:59.999 --> 99:59:59.999
Siinä kohtaa ajattelin, että tässä voisi
olla jotain.

99:59:59.999 --> 99:59:59.999
Ja kokeilin jotain.

99:59:59.999 --> 99:59:59.999
Ensimmäiseksi kokeilin työntää <CR>-, <LF>- ja piste-
merkkejä Paavo Pesusienen kautta.

99:59:59.999 --> 99:59:59.999
Joten kirjoitin SMTP analyysisovelluksen, joka
lähettää virheellisiä data lopetussekvenssejä,

99:59:59.999 --> 99:59:59.999
kuten <LF>.<LF> Ja lähetin viestejä eri SMTP-
ohjelmistoilla,

99:59:59.999 --> 99:59:59.999
sisältäen sähköpostipalveluita Gmail, Outlook, GMX

99:59:59.999 --> 99:59:59.999
ja lisäksi sähköpostiohjelmistoja kuten Postfix,
Exim, Microsoft Exchange Server ja niin edelleen.

99:59:59.999 --> 99:59:59.999
Vastaanottavalla puolella tutkin, että mitkä
vääristä sekvensseistä menee itse asiassa läpi.

99:59:59.999 --> 99:59:59.999
Voinko lähettää komennon <LF>.<LF> lähtevän palvelimen 
kautta?

99:59:59.999 --> 99:59:59.999
Ja useimmissa tapauksissa se ei toiminut.

99:59:59.999 --> 99:59:59.999
<LF>.<LF> on usein suodatettu tai poistettu
alkuperäisestä viestistä.

99:59:59.999 --> 99:59:59.999
Mutta jossain tapauksissa se menee läpi muuttumattomana.

99:59:59.999 --> 99:59:59.999
Tämä oli tilanne GMX:n kohdalla. Lähetin sähköpostin
GMX:stä analyysipalvelimelleni

99:59:59.999 --> 99:59:59.999
ja <LF>.<CR><LF> merkkejä ei poistettu.

99:59:59.999 --> 99:59:59.999
Seuraavaksi tein proof-of-concept:n, jossa on
väärennetty datan lopetussekvenssi

99:59:59.999 --> 99:59:59.999
ja sen jälkeen toinen sähköpostiviesti.

99:59:59.999 --> 99:59:59.999
Jos tämä proof-of-concept toimii,

99:59:59.999 --> 99:59:59.999
meidän pitäisi saada kaksi viestiä 
vastaanottajan puolella.

99:59:59.999 --> 99:59:59.999
Lähetin tämän kaiken Gmailiin.

99:59:59.999 --> 99:59:59.999
Ja Gmail oli sitä mieltä, 
että "tämä ei ei ole datan lopetussekvenssi".

99:59:59.999 --> 99:59:59.999
Ja sen näkee siitä, että datan lopetussekvenssin
jälkeen kaikki on edelleen tulkittu viestin dataksi.

99:59:59.999 --> 99:59:59.999
Mutta joissain tapauksissä tämä itse asiassa toimi.

99:59:59.999 --> 99:59:59.999
Tämä oli ensimmäinen onnistunut 
SMTP Smuggling tapaus, GMX:stä Fastmail:iin.

99:59:59.999 --> 99:59:59.999
Me näemme, että se toimii. Meillä on ensin 
viesti käyttäjältä user@gmx.net

99:59:59.999 --> 99:59:59.999
ja toinen viesti käyttäjältä admin@gmx.net,

99:59:59.999 --> 99:59:59.999
jotka läpäisevät SPF ja DMARC tarkistukset,
koska ne tulevat GMX:n palvelimelta.

99:59:59.999 --> 99:59:59.999
[Applodeja]

99:59:59.999 --> 99:59:59.999
Minä olin, että "tämä on aivan sairasta!"

99:59:59.999 --> 99:59:59.999
Ajattelin, että meillä on tämä toinen viesti 
ja siinä voi olla mitä tahansa.

99:59:59.999 --> 99:59:59.999
Kuten lähettäjän osoite voi olla mitä vaan.

99:59:59.999 --> 99:59:59.999
Joten miksi en kokeilisi muita domaineja,
jotka osoittavat GMX:n palvelimeen?

99:59:59.999 --> 99:59:59.999
Sitten analysoin SPF tietueen ja tajusin...

99:59:59.999 --> 99:59:59.999
Tässä on GMX:n SPF-tietue, mutta se on hyvin
samankaltainen web.de:n tietueen, joka puolestaan

99:59:59.999 --> 99:59:59.999
on hyvin samankaltainen Ionoksen tietueen kanssa.

99:59:59.999 --> 99:59:59.999
Ja jeah, tilanne on nyt se, että tällä me voimme
väärentää 1.35 miljoonaa domainia.

99:59:59.999 --> 99:59:59.999
Jos ette tiedä mikä Ionos on, niin se on superiso 
hosting- ja sähköpostipalveluiden tarjoaja.

99:59:59.999 --> 99:59:59.999
Ja heillä on nämä 1.35 miljoonaa domainia
kytketty tähän.

99:59:59.999 --> 99:59:59.999
Joten, minun täytyi tietenkin kokeilla tätä.

99:59:59.999 --> 99:59:59.999
Tässä on sähköposti osoitteesta admin@web.de

99:59:59.999 --> 99:59:59.999
Nyt kysymys on tietysti, että toimiiko
tämä kaikkialla?

99:59:59.999 --> 99:59:59.999
Kuten sanoin, niin tämä palvelimilla,
jotka tulkitsevat lopetussekvenssit

99:59:59.999 --> 99:59:59.999
tavalla, joka ei ole RFC:n mukainen,
kuten .

99:59:59.999 --> 99:59:59.999
Voimme siis väärentää 1.35 miljoonaa domainia.

99:59:59.999 --> 99:59:59.999
Joten pohjimmiltaan meillä on 1.4 miljoonaa Postifix instansia
ja 150 tuhatta Sendmail instanssia.

99:59:59.999 --> 99:59:59.999
Ja tämä toimii, koska ne tulkitsevat...

99:59:59.999 --> 99:59:59.999
[puhuja sekoilee sanoissaan]

99:59:59.999 --> 99:59:59.999
Ne tulkitsevat <LF>.<CR><LF>, sekoilen itsekin sanoissani,
lopetussekvensiksi.

99:59:59.999 --> 99:59:59.999
Ja olin, että OK, tämä on aika vakavaa.

99:59:59.999 --> 99:59:59.999
Mutta tässä on muutakin.

99:59:59.999 --> 99:59:59.999
Katsoin outlook.comia myös ja Outlook
palautti todella oudon virheilmoituksen

99:59:59.999 --> 99:59:59.999
koska siinä on, että pelkät rivinvaihdot
eivät ole sallittuja.

99:59:59.999 --> 99:59:59.999
Olin siinä kohtaa, että pahus, ne tietää
mitä olen tekemässä.

99:59:59.999 --> 99:59:59.999
[Yleisöän naurua]

99:59:59.999 --> 99:59:59.999
Siksi analysoin sen tarkemmin, ette pysty
minua tuolla pelottelemaan.

99:59:59.999 --> 99:59:59.999
Joten löysin, että <LF>.<CR><LF> 
on mahdollinen täällä.

99:59:59.999 --> 99:59:59.999
[Yleisön applodeja]

99:59:59.999 --> 99:59:59.999
Jeah, pidetään vähän hauskaa.

99:59:59.999 --> 99:59:59.999
Tässä kohtaa en ollut varma, että
olenko tulossa hulluksi

99:59:59.999 --> 99:59:59.999
vai toimiiko tämä todella.

99:59:59.999 --> 99:59:59.999
Joten tarvitsin jonkinlaisen tarkistuksen.

99:59:59.999 --> 99:59:59.999
Ja niinpä lähetin sähköpostin
osoitteesta admin@outlook.com

99:59:59.999 --> 99:59:59.999
yhdelle kollegoistani. Idea oli siinä,
että jos he reagoivat tähän,

99:59:59.999 --> 99:59:59.999
se toimii, muutoin olen tullut hulluksi.

99:59:59.999 --> 99:59:59.999
Joten....

99:59:59.999 --> 99:59:59.999
[Yleisön naurua]

99:59:59.999 --> 99:59:59.999
Ja ehkä nyt hieman kansainvälisempi esimerkki,
koska tämä on todella itävaltalainen, luulen.

99:59:59.999 --> 99:59:59.999
Luulen, että ymmärrätte tämän, vaikka ette
puhu saksaa.

99:59:59.999 --> 99:59:59.999
Ja nyt olette, okei, voimme lähettää
tekstipohjaisia, väärennettyjä sähköposteja

99:59:59.999 --> 99:59:59.999
mutta ette pysty huijaamaan tällä ketään

99:59:59.999 --> 99:59:59.999
Mutta juttu on siinä, että voimme ujuttaa 
periaatteessa mitä tahansa, HTML mukaan luettuna

99:59:59.999 --> 99:59:59.999
Tässä lähetin viestin, kalasteluviestin, 
epätavallisesta kirjautumisesta

99:59:59.999 --> 99:59:59.999
osoitteesta no-reply@outlook.com

99:59:59.999 --> 99:59:59.999
todelliselta outlook.com palvelimelta itselleni.

99:59:59.999 --> 99:59:59.999
Ja se vain meni läpi.

99:59:59.999 --> 99:59:59.999
Mutta mitä tämä mahdollistaa?

99:59:59.999 --> 99:59:59.999
Pohdiskelin, että voimme väärentää
outlook.comin, mutta mitä muuta voimme tehdä tällä?

99:59:59.999 --> 99:59:59.999
Katsoin SPF tietuetta ja se oli outo, 
oudosti tuttu. koska tämä ei ole

99:59:59.999 --> 99:59:59.999
pelkästään outlook.comin SPF tietue

99:59:59.999 --> 99:59:59.999
vaan miljoonien muiden domainien SPF tietue.

99:59:59.999 --> 99:59:59.999
Sen vuoksi, koska tämä Exchange Online
palvelun SPF tietue.

99:59:59.999 --> 99:59:59.999
Outlook.com lähettää sähköpostit Exchange Online
infrastruktuurin kautta,

99:59:59.999 --> 99:59:59.999
joten voimme itse asiassa väärentää ne kaikki.

99:59:59.999 --> 99:59:59.999
Minun piti kokeilla tätä taas.

99:59:59.999 --> 99:59:59.999
Tämä toimi ainoastaan teknisesti,
en saanut palkan korotusta.

99:59:59.999 --> 99:59:59.999
Mikä vaikutus tällä on?

99:59:59.999 --> 99:59:59.999
Voimme väärentää miljoonia domaineja, 
mutta ketkä hyväksyvät nämä sähköpostit?

99:59:59.999 --> 99:59:59.999
Jälleen Postfix ja Sendmail, mutta vain ne
instanssit, jotka eivät hyväksy BDAT komentoa.

99:59:59.999 --> 99:59:59.999
BDAT on vaihtoehtoinen datakomennolle

99:59:59.999 --> 99:59:59.999
ja jos sitä tuetaan, tämä ei toimi.

99:59:59.999 --> 99:59:59.999
Se oli ulospäin suuntautuva ujutus,
joka on yksi osa tätä.

99:59:59.999 --> 99:59:59.999
Sitten on myös sisäänpäin tuleva
SMTP ujutus.

99:59:59.999 --> 99:59:59.999
Ulospäin suuntautuvassa ongelma oli
lähettävä palvelin

99:59:59.999 --> 99:59:59.999
koska palvelin epäonnistui tai ei tehokkaasti
suodattanut väärennettyä datan lopetusekvenssiä

99:59:59.999 --> 99:59:59.999
kuten <LF>.<CR><LF> Microsoftinh ja 
GMX palveluissa.

99:59:59.999 --> 99:59:59.999
Sitten on lisäksi sisäänpäin tuleva SMTP ujutus.

99:59:59.999 --> 99:59:59.999
Tämä tapahtuu, kun on vastaanottava palvelin, 
joka tulkitsee sellaisen villin datan lopetussekvenssin,

99:59:59.999 --> 99:59:59.999
josta lähettävällä palvelimella ei ole hajuakaan 
suodattaa pois.

99:59:59.999 --> 99:59:59.999
Löysin tällaisen Cisco Securesta, tietysti, Email Cloud Gateway:sta

99:59:59.999 --> 99:59:59.999
Mitä he tekevät on, ett'ähe siivoavat viestin ja <CR> merkki
korvataan  merkeillä.

99:59:59.999 --> 99:59:59.999
Joten itse asiassa, <CR>.<CR> merkkien tulkinta
palauttaa datan lopetussekvenssin.

99:59:59.999 --> 99:59:59.999
[Yleisön applodeja]

99:59:59.999 --> 99:59:59.999
Ongelma on nyt siis tietenkin se, että <CR>.<CR> 
ei suodateta ollenkaan pois.

99:59:59.999 --> 99:59:59.999
On palveluita, jotka sen tekevät, mutta meillä
on jälleen Exchange Online, iCloud, Sendmail, Postix

99:59:59.999 --> 99:59:59.999
ja monia muita, jotka päästävät tämän läpi.

99:59:59.999 --> 99:59:59.999
Tavallaan se käy järkeen, koska en hoksaisi 
sitä itsekään.

99:59:59.999 --> 99:59:59.999
Joten, minun täytyi kokeilla tätä jälleen.

99:59:59.999 --> 99:59:59.999
Valitettavasti, tai teknisesti, se toimi jälleen,

99:59:59.999 --> 99:59:59.999
mutta en saanut en saanut yhtään Applen laitetta.

99:59:59.999 --> 99:59:59.999
Ei sillä, että olisin halunnut muutenkaan.

99:59:59.999 --> 99:59:59.999
Mikä vaikutus tällä on?

99:59:59.999 --> 99:59:59.999
Pohjimmiltaan voimme väärentään vielä 
enemmän domaineja kuin edellä.

99:59:59.999 --> 99:59:59.999
Meillä on Exchange Online, meillä on iCloud,

99:59:59.999 --> 99:59:59.999
meillä on Postfix ja Sendmail.

99:59:59.999 --> 99:59:59.999
Ja voimme väärentää yrityksiä, joilla on
vara tähän - aika isoja yrityksiä tässä.

99:59:59.999 --> 99:59:59.999
Tämä pitää sisällää yli 40 tuhatta muuta domainia.

99:59:59.999 --> 99:59:59.999
Ja se on vain ne, jotka on hostattu pilvessä.

99:59:59.999 --> 99:59:59.999
Lisäksi on on-prem instanssit, mutta en pystynyt
käymään niitä läpi.

99:59:59.999 --> 99:59:59.999
Ja nyt osuuteen, joka on luultavasti mielenkiintoisin teille,
tai ainakin osalle teistä.

99:59:59.999 --> 99:59:59.999
Vastuullinen julkaisu.

99:59:59.999 --> 99:59:59.999
Puhtaasti teknisesti, koskien lähettäviä ja 
vastaanottavia palvelimia, kenen vika tämä on?

99:59:59.999 --> 99:59:59.999
Meillä on vastaanottavia palvelimia, joiden ei 
koskaan oleteta tulkitsevan mitään muita

99:59:59.999 --> 99:59:59.999
datan lopetussekvenssejä kuin <CR><LF>.<CR><LF>,
ainkin RFC:n mukaan.

99:59:59.999 --> 99:59:59.999
Sitten meillä on lähettäviä palvelimia, joiden 
ei oleteta lähettävän  ja  merkkejä

99:59:59.999 --> 99:59:59.999
toisistaan riippumatta.

99:59:59.999 --> 99:59:59.999
Joten lopulta tämän on kaikkien vika.

99:59:59.999 --> 99:59:59.999
Lähetimme tämän tiedon GMX:lle.

99:59:59.999 --> 99:59:59.999
He olivat superkiitollisia ja ilmoittivat
korjaavansa asian saman tien.

99:59:59.999 --> 99:59:59.999
10 päivää myöhemmin he korjasivat tämän.

99:59:59.999 --> 99:59:59.999
He pyysivät meitä tarkastamaan uudelleen ja 
tarkastimme, että he todella korjasivat sen.

99:59:59.999 --> 99:59:59.999
He maksoivat meille pienen palkkion.

99:59:59.999 --> 99:59:59.999
Ha laittoivat meidät jopa heidän
Bug Bounty Hall of Fame:en.

99:59:59.999 --> 99:59:59.999
Kaiken kaikkiaan se oli 10/10 kokemus.

99:59:59.999 --> 99:59:59.999
[Applodeja]

99:59:59.999 --> 99:59:59.999
Aion lähettää heille tallenteen teidän applodeista. Kiitos!

99:59:59.999 --> 99:59:59.999
Tuntui melkein sille, että meidän olisi pitänyt
maksaa palkkio heille.

99:59:59.999 --> 99:59:59.999
Tästä eteenpäin mennäänkin sitten alamäkeä.

99:59:59.999 --> 99:59:59.999
Meillä on Microsoft. Microsoft oli sitä mieltä,
että tämä on kohtuullisen riskin haavoittuvuus.

99:59:59.999 --> 99:59:59.999
En tiedä, ehkä heillä on suurempi kala kiikarissa,
mutta joka tapauksessa.

99:59:59.999 --> 99:59:59.999
Lähetimme tiedot heille ja kolme kuukautta
myöhemmin he sulkivat tapauksen ja sanoivat,

99:59:59.999 --> 99:59:59.999
että kaikki on korjattu, ei palkkiota ja niin edelleen.

99:59:59.999 --> 99:59:59.999
Tässä kohtaa olin saanut jo mitä halusin.

99:59:59.999 --> 99:59:59.999
Ja se on sähköpostin saaminen osoitteesta
admin@microsoft.com

99:59:59.999 --> 99:59:59.999
Ja sitten Ciscoon.

99:59:59.999 --> 99:59:59.999
Ciscon mielestä tämä ei ollut haavoittuvuus,

99:59:59.999 --> 99:59:59.999
vaan dokumentoitu ja konfiguroitava ominaisuus.

99:59:59.999 --> 99:59:59.999
Me olimme sitä mieltä, että onpa outo
ominaisuus,

99:59:59.999 --> 99:59:59.999
koska voimme väärentää sähköposteja sillä.

99:59:59.999 --> 99:59:59.999
Sanoimme, että kertokaa edes asiakkaillenne
tästä ominaisuudesta,

99:59:59.999 --> 99:59:59.999
joka ei välttämättä ole paras oletustoiminallisuus.

99:59:59.999 --> 99:59:59.999
He sanoivat "Ei".

99:59:59.999 --> 99:59:59.999
Me olimme siinä, että meillä on tämä
suuri SMTP Smuggling ongelma.

99:59:59.999 --> 99:59:59.999
Ja Cisco ei halua tehdä mitään, Microsoft
oli haavoittuvainen.

99:59:59.999 --> 99:59:59.999
Me veimme tämän tapauksen CERT/CC:lle.

99:59:59.999 --> 99:59:59.999
Niille, jotka eivät tiedä, CERT/CC koordinoi 
ja käsittelee näitä suuria haavoittuvuuksia,

99:59:59.999 --> 99:59:59.999
joilla voi olla maailmanlaajuisia vaikutuksia.

99:59:59.999 --> 99:59:59.999
Me lähetimme tiedot heille ja he itse asiassa
hyväksyivät tapauksen.

99:59:59.999 --> 99:59:59.999
Sitten olemme tässä Vince portaalissa.

99:59:59.999 --> 99:59:59.999
Joka on periaatteessa iso chat-huone, jossa 
14 toimittajaa.

99:59:59.999 --> 99:59:59.999
Siellä on Microsoft, SendMail, Cisco, Google

99:59:59.999 --> 99:59:59.999
Ja sitten voimme alkaa puhumaan haavoittuvuudesta

99:59:59.999 --> 99:59:59.999
Ensimmäisessä keskustelussa Cisco sanoo
edelleen, että kyseessä ei ole haavoittuvuus.

99:59:59.999 --> 99:59:59.999
Tiedättehän, se ei ole bugi, vaan ominaisuus.

99:59:59.999 --> 99:59:59.999
Noh, joka tapauksessa se ei ole bugi heidän
mielestään.

99:59:59.999 --> 99:59:59.999
Ja sitten CERT/CC on sitä mieltä, että
kyseessä ei ole haavoittuvuus, jostain syystä.

99:59:59.999 --> 99:59:59.999
Kuinkas yleinen SMTP ujutusongelma?

99:59:59.999 --> 99:59:59.999
Entäs Postfixin ja Sendmailin RFC:stä eriävät
tulkinnat datan lopetussekvenssistä?


99:59:59.999 --> 99:59:59.999
Ensinnäkin, Sendmail oli tässä Vince portaalissa
alusta alkaen.

99:59:59.999 --> 99:59:59.999
He saivat kaikki PoC:t, viestit, kaiken.

99:59:59.999 --> 99:59:59.999
Ja he eivät sanoneet mitään.

99:59:59.999 --> 99:59:59.999
Entäpä Postfix? He ovat 10 kertaa suurempi.

99:59:59.999 --> 99:59:59.999
CERT/CC oli... en tiedä miksi he eivät
lisänneet heitä tapaukseen suoraan.

99:59:59.999 --> 99:59:59.999
Mutta CERT/CC lähetti heille sähköpostin, mutta
unohti mainita SMTP ujutuksen.

99:59:59.999 --> 99:59:59.999
Luulimme siis, että he kertoivat Postfixille,. Sendmailia
ei nähtävästi kiinnostanut. CERT/CC on Ciscon puolella asiassa.

99:59:59.999 --> 99:59:59.999
Me olimme, että Cisco on taatusti haavoittuvainen,
olimme varmistaneet sen.

99:59:59.999 --> 99:59:59.999
Joten haluaisimme julkistaa tämän blogissa.

99:59:59.999 --> 99:59:59.999
Ja tästä ongelmat vasta alkoivatkin.

99:59:59.999 --> 99:59:59.999
Kerroimme, että haluaisimme julkaista tästä
blogikirjoituksen ja varoittaisimme Ciscon asiakkaita

99:59:59.999 --> 99:59:59.999
tästä haavoittuvuudesta.

99:59:59.999 --> 99:59:59.999
CERT/CC oli sitä mieltä, että "Antaa mennä vaan!
Lähettäkää meille linkki kirjoitukseen, kun se on julkaistu"

99:59:59.999 --> 99:59:59.999
Päätimme edetä ja tulimme avanneeksi Pandoran
laatikon, koska nyt 1.6 miljoonaan Postfix ja Sendmail

99:59:59.999 --> 99:59:59.999
instanssia ovat haavoittuvina internetissä.

99:59:59.999 --> 99:59:59.999
Ja se tarkoittaa, että jos tapahtuu ulospäin suuntautuva
SMTP ujuttelu, niin voit hyväksikäyttää Postfixiä ja Sendmailia yhä.

99:59:59.999 --> 99:59:59.999
Tarkoittaako tämä, ettei SEC Consultissa ole yhtään vikaa?

99:59:59.999 --> 99:59:59.999
Totta kai SEC Consultissa on vikaa.

99:59:59.999 --> 99:59:59.999
Julkaisimme blogikirjoituksen olettaen, että
vaikutus olisi pienempi kuin se todellisuudessa oli

99:59:59.999 --> 99:59:59.999
perustuen keskesteluihin CERT/CC:n kanssa ja 
VINCE:ssä muutenkin.

99:59:59.999 --> 99:59:59.999
Ja jos olisimme vain tuplavarmistaneet Postfixin
kanssa, että julkaisu ei ole ongelma, tätä ei olisi tapahtunut,

99:59:59.999 --> 99:59:59.999
koska he ovat järkkymättämiä, että tämä on ongelma.

99:59:59.999 --> 99:59:59.999
Yhteenveto, mitä tämä tarkoittaa?

99:59:59.999 --> 99:59:59.999
Korjatkaa Postfix palvelimenne! Löydätte lisätietoja
Postfixin nettisivuilta.

99:59:59.999 --> 99:59:59.999
Lisäksi korjatkaa Cisco palvelimenne. Voitte löytää
lisätietoja siitä SEC Consult:n blogista.

99:59:59.999 --> 99:59:59.999
[Yleisön naurua ja aplodit]

99:59:59.999 --> 99:59:59.999
Lopuksi, tässäkin pilvessä on jonkinlainen hopeareunus.

99:59:59.999 --> 99:59:59.999
Nyt Postfix on suoraan mukana VINCE tapauksessa

99:59:59.999 --> 99:59:59.999
ja he ovat jo antaneet suuren panoksen.

99:59:59.999 --> 99:59:59.999
Emme työnnä päätämme pensaaseen ja yritä
aktiivisesti sulkea Pandoran lipasta jälleen.

99:59:59.999 --> 99:59:59.999
Ja mitä se tarkoittaa? Lisää tutkimusta SMTP ujuttelusta

99:59:59.999 --> 99:59:59.999
Tarkoitan, että pyysin CERT/CC:tä katsomaan tätä 
tarkemmin, niin, se ei päättynyt kovin hyvin.

99:59:59.999 --> 99:59:59.999
Lisää blogikirjoituksia, lisää tutkimusta ja 
ennen kaikkea lisää toimijoita VINCE tapaukseen.

99:59:59.999 --> 99:59:59.999
Yritämme saada kaiken korjattua ja olemme pahoillamme,
että tämä tapahtui ylipäätään.

99:59:59.999 --> 99:59:59.999
Lopuksi jotain, jonka kaikki tiedätte. Älkää
luottako sähköposteihinn sokeasti, erityisesti tällä hetkellä.

99:59:59.999 --> 99:59:59.999
Kiitos.

99:59:59.999 --> 99:59:59.999
[Aplodeja]

99:59:59.999 --> 99:59:59.999
Hienoa, mennään kysymyksiin.

99:59:59.999 --> 99:59:59.999
Ole hyvä.

99:59:59.999 --> 99:59:59.999
Hei, minulla on yksi lyhyt kysymys CERT/CC asiasta.

99:59:59.999 --> 99:59:59.999
Oliko tämä kommunikoitu sähköpostilla?

99:59:59.999 --> 99:59:59.999
Ja etkö olisi voinut lähettää viestin viestin 
Ciscon CDO:na?

99:59:59.999 --> 99:59:59.999
Kyllä, olisimme voineet tehdä sen ja luoda 
jonkinlaisen kolmiodraamaan

99:59:59.999 --> 99:59:59.999
Bill Gatesin, Elon Muskin ja jonkun muun välille.

99:59:59.999 --> 99:59:59.999
Mutta valitettavasti emme nähneet tätä sähköpostia.

99:59:59.999 --> 99:59:59.999
Näimme sen jälkeen päin, mutta se oli valitettavasti
liian myöhäistä.

99:59:59.999 --> 99:59:59.999
Hei, kiitos teille. Arvostan työtänne.

99:59:59.999 --> 99:59:59.999
Voisitko kertoa hieman aikajanasta?

99:59:59.999 --> 99:59:59.999
Koska löysitte tämän ensimmäisen kerran?

99:59:59.999 --> 99:59:59.999
Aloitin tutkimuksen kesäkuussa kuluvana vuonna

99:59:59.999 --> 99:59:59.999
Minulla oli 10 päivän projekti SEC Consultilla.

99:59:59.999 --> 99:59:59.999
Olin sitä mieltä, että 10 päivää ei riitä, joten
aloitin 10 päivää aiemmin.

99:59:59.999 --> 99:59:59.999
Sitten löysin SMTP ujuttelun kuudentena päivänä

99:59:59.999 --> 99:59:59.999
Sitten asia eteni kertomalla GMX:lle, Outlookille
tai Microsoftille ja Ciscolle

99:59:59.999 --> 99:59:59.999
koska heillä oli vakavat SMTP ujuttelutapaukset, 
koskien sekä lähtevää ja saapuvaa.

99:59:59.999 --> 99:59:59.999
Sitten jatkoimme ja kerroimme CERT/CC:lle, koska
tämä vaikutti olevan laajempi ongelma maailmanlaajuisesti.

99:59:59.999 --> 99:59:59.999
Aikataulumielessä, minulla ei ole sitä tässä nyt,
mutta se on SEC Consultin blogikirjoituksessa.

99:59:59.999 --> 99:59:59.999
Onko joku tietty päivämäärä, jonka haluat tietää?

99:59:59.999 --> 99:59:59.999
Ei, ei. Käyn lukemassa blogikirjoituksen. Kiitos.

99:59:59.999 --> 99:59:59.999
Hei, kiitos hyvästä puheesta täällä.

99:59:59.999 --> 99:59:59.999
Haluaisin kysyä, että on mitään evidenssiä

99:59:59.999 --> 99:59:59.999
tai epäilyksiä, että tätä olisi jo käytetty?

99:59:59.999 --> 99:59:59.999
Tämä näyttää melko yksinkertaiselta
haavoittuvuudelta hyödyntää.

99:59:59.999 --> 99:59:59.999
Voisin kuvitella, että sitä on jo hyödynnetty.

99:59:59.999 --> 99:59:59.999
Jeah, sain joitain kommentteja Reddit postaukseeni

99:59:59.999 --> 99:59:59.999
että tämä on supervanha,
mutta asia on...

99:59:59.999 --> 99:59:59.999
Kohtalainen haavoittuvuus

99:59:59.999 --> 99:59:59.999
Jeah, todennäköisesti

99:59:59.999 --> 99:59:59.999
Ei, en tosiaankaan tiedä.

99:59:59.999 --> 99:59:59.999
Kävin läpi paljon tutkimuksia, mutta niissä
ei ollut mitään.

99:59:59.999 --> 99:59:59.999
Siksi kutsun tätä uudeksi haavoittuvuudeksi.

99:59:59.999 --> 99:59:59.999
Translated by Mikko Heikkinen (ITKST56 course assignment at JYU.FI)