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