1 00:00:00,310 --> 00:00:04,830 Translated by Mikko Heikkinen (ITKST56 course assignment at JYU.FI) 2 00:00:05,372 --> 00:00:13,612 [Musiikkia] 3 00:00:14,212 --> 00:00:18,212 OK. Seuraavaksi puhuu Timo Longin, 4 00:00:19,402 --> 00:00:22,212 joka tunnetaan myös nimellä Timo Login. 5 00:00:22,324 --> 00:00:27,264 Hän tietoturvakonsultti ja tutkija. Hän tulee puhumaan uudesta tekniikasta 6 00:00:27,578 --> 00:00:29,778 nimeltään SMTP Smuggling, 7 00:00:29,943 --> 00:00:32,343 jolla voidaan väärentää sähköposteja 8 00:00:32,426 --> 00:00:34,276 ja hyväksikäyttää eräitä eniten käytettyjä palveluita internetissä. 9 00:00:34,317 --> 00:00:37,207 Kiitos. Annetaan Timolle applodit. 10 00:00:37,641 --> 00:00:41,641 [Applodeja] 11 00:00:43,181 --> 00:00:45,111 Kiitos esittelystä. 12 00:00:45,111 --> 00:00:49,811 Ensinnäkin, pulskat pahoittelut omasta ja SEC Consult:n puolesta 13 00:00:49,811 --> 00:00:53,801 tämän katastrofaalisen haavoittuvuuden julkaisemisesta. 14 00:00:54,784 --> 00:01:00,734 Erityisesti pahoittelut Wietselle ja Viktorille korjausten jälkikorjauksesta 15 00:01:01,328 --> 00:01:05,418 sekä kaikille järjestelmävalvojille ympäri maailman, 16 00:01:05,701 --> 00:01:08,721 jotka ovat joutuneet asentamaan korjauksia joululoman aikana. 17 00:01:09,070 --> 00:01:11,790 Ja lisäksi, joka tapauksessa, 18 00:01:12,284 --> 00:01:16,284 suuret kiitokset Wietselle ja Viktorille 19 00:01:16,342 --> 00:01:20,072 heidän sitoutumisestaan. 20 00:01:20,094 --> 00:01:22,344 Ja lisäksi suuret kiitokset yhteisölle 21 00:01:22,391 --> 00:01:25,373 tämän ongelman viemisestä julkaisujärjestelmiin ja niin edelleen. 22 00:01:25,563 --> 00:01:27,843 Ja kaikille... Okei... 23 00:01:28,332 --> 00:01:32,882 [Applodeja] 24 00:01:35,495 --> 00:01:37,175 Ja kaikille niille, 25 00:01:37,307 --> 00:01:39,277 joilla ei ole mitään hajua tästä. 26 00:01:39,349 --> 00:01:41,729 Joten minäpä autan teidät samalle sivulle. 27 00:01:41,835 --> 00:01:43,845 Noin vuosi sitten olin juuri 28 00:01:43,876 --> 00:01:46,756 lopettanut tutkimukseni DNS:n parissa. 29 00:01:46,804 --> 00:01:49,274 ja etsin uutta tutkimuskohdetta, 30 00:01:49,414 --> 00:01:52,328 kun löysin todennäköisesti helpoimman 31 00:01:52,423 --> 00:01:54,543 tavan hakkeroida yrityksen 32 00:01:54,672 --> 00:01:56,772 ja kaikki tämä vain yhdellä 33 00:01:56,823 --> 00:01:59,053 yksinkertaisella Google-haulla. 34 00:01:59,053 --> 00:02:01,073 [Yleisön naurua] 35 00:02:01,211 --> 00:02:03,921 Ja tämä saattaa kuulostaa tyhmälle, 36 00:02:04,025 --> 00:02:06,275 mutta tämä johdatti minut suuntaan, 37 00:02:06,295 --> 00:02:09,405 jonka jo tiesin, mutta en ollut ymmärtänyt. 38 00:02:09,517 --> 00:02:12,637 Ja se on, että tietojen kalastelu on edelleen 39 00:02:12,656 --> 00:02:15,566 numero 1 ensipääsyvektori yritykseen 40 00:02:15,645 --> 00:02:17,535 ja sitten minulla välähti: 41 00:02:17,622 --> 00:02:19,472 Miksen tutkisi SMTP:tä, 42 00:02:19,556 --> 00:02:21,236 simple mail transfer protocol:aa 43 00:02:21,330 --> 00:02:23,714 jota käytetään miljardien sähköpostien 44 00:02:23,757 --> 00:02:26,235 lähettämiseen joka päivä ympäri maailman 45 00:02:26,315 --> 00:02:28,375 kuten on tehty viimeisen 40 vuoden ajan. 46 00:02:28,410 --> 00:02:30,780 Joten matkani eteni DNS:stä SMTP:hen 47 00:02:30,780 --> 00:02:32,760 ja tänään esittelen uuden 48 00:02:32,773 --> 00:02:34,963 SMTP Smuggling -tekniikan 49 00:02:35,009 --> 00:02:37,389 sähköpostien väärentämiseksi. 50 00:02:37,471 --> 00:02:39,771 Kuka olenkaan? OIen Timo Longin 51 00:02:39,832 --> 00:02:41,674 ja työskentelen tietoturvakonsulttina 52 00:02:41,674 --> 00:02:43,375 SEC Consult -yhtiössä ja 53 00:02:43,375 --> 00:02:45,245 päivisin teen penetraatiotestausta 54 00:02:45,245 --> 00:02:47,535 ja öisin teen haavoittuvuustutkimusta. 55 00:02:47,565 --> 00:02:50,485 Ja viimeisen kolmen vuoden aikana olen 56 00:02:50,533 --> 00:02:53,369 tutkinut paljon DNS-haavoittuvuuksia. 57 00:02:53,369 --> 00:02:56,049 Ja olen julkaissut paljon blogikirjoituksia ja työkaluja. 58 00:02:56,257 --> 00:02:59,007 Ja minun täytyi siirtyä eteenpäin. 59 00:02:59,207 --> 00:03:03,207 Edellisen kerran, kun joku SEC Consult:sta puhui CCC:ssä... 60 00:03:05,093 --> 00:03:06,913 se oli... dildoista. 61 00:03:07,393 --> 00:03:08,883 [Yleisön naurua] 62 00:03:09,121 --> 00:03:12,091 Ja tiedän, että joudun tuottamaan osalle 63 00:03:12,184 --> 00:03:13,644 teistä pettymyksen, 64 00:03:13,644 --> 00:03:15,390 mutta tämä esitys ei kerro 65 00:03:15,390 --> 00:03:17,510 ihmiseen penetroitumisesta. 66 99:59:59,999 --> 99:59:59,999 Esitys kertoo tunkeutumisesta SMTP-protokollan muurien läpi. 67 99:59:59,999 --> 99:59:59,999 Joten nähdäksemme miten tämä toimii 68 99:59:59,999 --> 99:59:59,999 on meidän ensin ymmärrettävä 69 99:59:59,999 --> 99:59:59,999 miten sähköpostien lähetys yleensäkin toimii. 70 99:59:59,999 --> 99:59:59,999 Joten tässä meillä on melko yksinkertainen sähköposti-infrastuktuuri. 71 99:59:59,999 --> 99:59:59,999 Meillä on sähköpostikäyttäjäagentti, 72 99:59:59,999 --> 99:59:59,999 kuten Thunderbird, ja Thunderbird haluaa lähettää sähköpostin 73 99:59:59,999 --> 99:59:59,999 esimerkiksi käyttäjänä user@outlook.com. 74 99:59:59,999 --> 99:59:59,999 Joten jos haluamme lähettää sähköpostin tällä tavalla 75 99:59:59,999 --> 99:59:59,999 meidän täytyy ensin tunnistautua 76 99:59:59,999 --> 99:59:59,999 Outlook mail transfer agentille tai 77 99:59:59,999 --> 99:59:59,999 ulospäin menevälle SMTP palvelimelle. 78 99:59:59,999 --> 99:59:59,999 Ja kun olemme tunnistautuneet, 79 99:59:59,999 --> 99:59:59,999 voimme lähettää sähköpostin käyttäjänä user@outlook.com. 80 99:59:59,999 --> 99:59:59,999 Ja vain käyttäjänä user@outlook.com. 81 99:59:59,999 --> 99:59:59,999 Tämän jälkeen viesti siirretään vastaanottajan 82 99:59:59,999 --> 99:59:59,999 SMTP-palvelimelle ja tämä palvelin 83 99:59:59,999 --> 99:59:59,999 tarkistaa viestin aitouden. 84 99:59:59,999 --> 99:59:59,999 Ja kaikkein yleisen tapa tehdä tämä on SPF. 85 99:59:59,999 --> 99:59:59,999 Vastaanottava SMTP-palvelin saa SPF-tietueen 86 99:59:59,999 --> 99:59:59,999 DNS-palvelun kautta outlook.com osoitteelle. 87 99:59:59,999 --> 99:59:59,999 Ja tarkistaa sen jälkeen, että tämä IP-osoite 88 99:59:59,999 --> 99:59:59,999 ja IP-alue on sallittu lähettää sähköpostiviestejä 89 99:59:59,999 --> 99:59:59,999 outlook.com osoitteelle. 90 99:59:59,999 --> 99:59:59,999 Tässä tapauksessa todellinen Outlook SMTP-palvelin 91 99:59:59,999 --> 99:59:59,999 tai ulospäin lähtevä SMTP-palvelin lähetti viestin, 92 99:59:59,999 --> 99:59:59,999 vastaanottava SMTP-palvelin 93 99:59:59,999 --> 99:59:59,999 hyväksyy viestin. 94 99:59:59,999 --> 99:59:59,999 Ja nyt luonnollisesti tässä on erittäin 95 99:59:59,999 --> 99:59:59,999 mielenkiintoinen kysymys. 96 99:59:59,999 --> 99:59:59,999 Ja kysymys on: onko hyökkääjän mahdollista 97 99:59:59,999 --> 99:59:59,999 lähettää sähköpostiviesti 98 99:59:59,999 --> 99:59:59,999 esimerkiksi osoitteesta admin@outlook.com tai 99 99:59:59,999 --> 99:59:59,999 väärennetystä sähköpostiosoitteesta? 100 99:59:59,999 --> 99:59:59,999 Tätä me selvitämme tänään 101 99:59:59,999 --> 99:59:59,999 ja se on enemmän tai vähemmän 102 99:59:59,999 --> 99:59:59,999 tämän tutkimuksen tavoitteista. 103 99:59:59,999 --> 99:59:59,999 En tiedä oletteko huomanneet, 104 99:59:59,999 --> 99:59:59,999 mutta näiden palvelimien värit 105 99:59:59,999 --> 99:59:59,999 muistuttavat minusta Paavo Pesusieneä 106 99:59:59,999 --> 99:59:59,999 ja Patrik Tähtöstä. 107 99:59:59,999 --> 99:59:59,999 Ja sen vuoksi kutsumme niitä niiksi. 108 99:59:59,999 --> 99:59:59,999 Tutkimuksen yleinen tavoite ja 109 99:59:59,999 --> 99:59:59,999 tutkimuksen peruste oli löytää 110 99:59:59,999 --> 99:59:59,999 tapa väärentää sähköposteja. 111 99:59:59,999 --> 99:59:59,999 Ja ajattelin, että miksi en ottaisi haavoittuvuuksia 112 99:59:59,999 --> 99:59:59,999 muista tekstipohjaisista protokollista, 113 99:59:59,999 --> 99:59:59,999 kuten HTTP:stä, ja soveltaisi niitä SMTP:hen. 114 99:59:59,999 --> 99:59:59,999 Ja oli yksi HTTP haavoittuvuus, joka sopi kuvaan 115 99:59:59,999 --> 99:59:59,999 ja se oli HTTP-pyynnön käpelöinti. 116 99:59:59,999 --> 99:59:59,999 Tässä meillä on taas Paavo ja Patrik, 117 99:59:59,999 --> 99:59:59,999 mutta tällä kertaa HTTP-maailmassa. 118 99:59:59,999 --> 99:59:59,999 Joten, mitä tässä tapahuu? Paavo Pesusieni saa POST-tyyppisen pyynnön internetin yli 119 99:59:59,999 --> 99:59:59,999 Mielenkiintoista tässä pyynnössä on se, että siinä on kaksi otsikkoa 120 99:59:59,999 --> 99:59:59,999 kuinka käsitellä POST-pyynnön data. 121 99:59:59,999 --> 99:59:59,999 Siinä on Content-Length -otsikko, jonka arvona 43 tavua. 122 99:59:59,999 --> 99:59:59,999 Ja siinä on myös Transfer-Encoding -otsikko. 123 99:59:59,999 --> 99:59:59,999 Nyt Paavo Pesusienen täytyy päättää, miten käsittelen pyynnön ja Paavo päättää 124 99:59:59,999 --> 99:59:59,999 käyttää Content-Length otsikkoa, koska se on 43 tavua. 125 99:59:59,999 --> 99:59:59,999 Joten kaikki punaisella kehystetty data on välitetty Patrikille. 126 99:59:59,999 --> 99:59:59,999 Patrikilla ei ole mitään hajua mitä tehdä - pitäisikö minun tulkita Content-Lenth otsikkoa vai 127 99:59:59,999 --> 99:59:59,999 Transfer-Encoding -otsikko? Patrik päättää tulkita Transfer-Encoding otsikkoa ja 128 99:59:59,999 --> 99:59:59,999 nyt meillä on eriävät tulkinnat: 129 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. 130 99:59:59,999 --> 99:59:59,999 Ja koska Transfer-Encoding on määritetty "chunked" ("paloiteltu") ja ja ensimmäinen pala on 0, 131 99:59:59,999 --> 99:59:59,999 on loput Paavo Pesusienen lähettämästä datasta tulkittu toiseksi pyynnöksi. 132 99:59:59,999 --> 99:59:59,999 Itse asiassa tämä tarkoittaa, että Paavo näkee yhden pyynnön ja Patrik kaksi pyyntöä. 133 99:59:59,999 --> 99:59:59,999 Ja toinen pyyntö voidaan kohdistaa mielivaltaiseen resurssipolkuun, kuten "Admin", 134 99:59:59,999 --> 99:59:59,999 joka tässä esimerkissä on avoin vain sisäisesti palvelimella. 135 99:59:59,999 --> 99:59:59,999 Joka on tietenkin ongelma. 136 99:59:59,999 --> 99:59:59,999 Joten ajattelin, että miksi en ottaisi näitä tulkintaeroja 137 99:59:59,999 --> 99:59:59,999 ja laittaisi niitä SMTP:hen. 138 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, 139 99:59:59,999 --> 99:59:59,999 täytyy meidän katsoa ensin itse SMTP protokollaa. 140 99:59:59,999 --> 99:59:59,999 Joten, SMTP näyttää kuta kuinkin tältä. 141 99:59:59,999 --> 99:59:59,999 Meillä on kaksi komponenttia: SMTP komennot punaisella ja sinisellä viestin data. 142 99:59:59,999 --> 99:59:59,999 Lähettääksemme viestin, meidän tulee ensin lähettää SMTP komennot: 143 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 144 99:59:59,999 --> 99:59:59,999 sitten lähetämme "data" komennon kertoaksemme vastaanottavalle SMTP-palvelimelle 145 99:59:59,999 --> 99:59:59,999 että olemme nyt vastaanottamassa varsinaista viestin dataa. 146 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. 147 99:59:59,999 --> 99:59:59,999 Ja sitten tulee viestin leipäteksti. 148 99:59:59,999 --> 99:59:59,999 Ja kun jossain vaiheessa haluamme lopettaa viestin datan lähettämisen, 149 99:59:59,999 --> 99:59:59,999 meidän tulee lähettää jotain. jota kutsumme datan lopetussekvensiksi. 150 99:59:59,999 --> 99:59:59,999 Se on " piste " [kääntäjän kommentti: jatkossa .] 151 99:59:59,999 --> 99:59:59,999 Tässä vaiheessa ajattelin, että ehkä voisimme hämätä tällä jotenkin SMTP-palvelinten toteutuksia. 152 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]. 153 99:59:59,999 --> 99:59:59,999 Ja tämä sähköposti sisältää jotain todella outoa, jotain joka näyttää 154 99:59:59,999 --> 99:59:59,999 lopetussekvensille, mutta se ei ole sitä. 155 99:59:59,999 --> 99:59:59,999 Koska se ei ole yhdenmukainen RFC:n kanssa, joku voisi virheellisesti tulkita sen datan lopetussekvensiksi. 156 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 157 99:59:59,999 --> 99:59:59,999 Ja seuraavaksi... tai viestin data siihen saakka, kunnes varsinainen datan lopetussekvenssi tulee. 158 99:59:59,999 --> 99:59:59,999 Sitten Paavo Pesusieni lähettää viestin Patrikille 159 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 160 99:59:59,999 --> 99:59:59,999 varsinaiseksi datan lopetusmerkiksi." 161 99:59:59,999 --> 99:59:59,999 Ja ongelmaksi tässä tulee, että kaikki väärin tulkitun lopetussekvenssin tulkitaan SMPT-komennoiksi 162 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. 163 99:59:59,999 --> 99:59:59,999 Vaikka Paavo Pesusieni näki yhden ison sähköpostiviestin, Patrik näkee kaksi pienempää viestiä. 164 99:59:59,999 --> 99:59:59,999 Ja ongelma on se, että toinen viesti voi sisältää mielivaltaisia SMTP-komentoja. 165 99:59:59,999 --> 99:59:59,999 Kuten, että viesti tulee osoitteesta admin@outlook.com tai mitä tahansa. 166 99:59:59,999 --> 99:59:59,999 Näin ainakin teoriassa. 167 99:59:59,999 --> 99:59:59,999 Nähdäkseni toimiiko tämä todella. 168 99:59:59,999 --> 99:59:59,999 Tutkin muutamia SMTP-palvelinten toteutuksia yksinkertaisesti 169 99:59:59,999 --> 99:59:59,999 ottamalla niihin yhteyttä telnet:llä tai netcat:lla. 170 99:59:59,999 --> 99:59:59,999 Kun tein tämän, se näytti aluksi RFC:n mukaiselta. 171 99:59:59,999 --> 99:59:59,999 Kun lähetät datakomennon, palvelin pyytää lopettamaan datan lähettämisen . merkeillä. 172 99:59:59,999 --> 99:59:59,999 Sitten löysin myös palvelimia, jotka sanoivat: "lähetä minulla rivi, jossa on vain piste" 173 99:59:59,999 --> 99:59:59,999 Ja tämä asia riippuu paljon käytettävästä käyttöjärjestelmästä. 174 99:59:59,999 --> 99:59:59,999 Windows:ssa tämä voi olla . ja se voi olla . 175 99:59:59,999 --> 99:59:59,999 Siinä kohtaa ajattelin, että tässä voisi olla jotain. 176 99:59:59,999 --> 99:59:59,999 Ja kokeilin jotain. 177 99:59:59,999 --> 99:59:59,999 Ensimmäiseksi kokeilin työntää -, - ja piste- merkkejä Paavo Pesusienen kautta. 178 99:59:59,999 --> 99:59:59,999 Joten kirjoitin SMTP analyysisovelluksen, joka lähettää virheellisiä data lopetussekvenssejä, 179 99:59:59,999 --> 99:59:59,999 kuten . Ja lähetin viestejä eri SMTP- ohjelmistoilla, 180 99:59:59,999 --> 99:59:59,999 sisältäen sähköpostipalveluita Gmail, Outlook, GMX 181 99:59:59,999 --> 99:59:59,999 ja lisäksi sähköpostiohjelmistoja kuten Postfix, Exim, Microsoft Exchange Server ja niin edelleen. 182 99:59:59,999 --> 99:59:59,999 Vastaanottavalla puolella tutkin, että mitkä vääristä sekvensseistä menee itse asiassa läpi. 183 99:59:59,999 --> 99:59:59,999 Voinko lähettää komennon . lähtevän palvelimen kautta? 184 99:59:59,999 --> 99:59:59,999 Ja useimmissa tapauksissa se ei toiminut. 185 99:59:59,999 --> 99:59:59,999 . on usein suodatettu tai poistettu alkuperäisestä viestistä. 186 99:59:59,999 --> 99:59:59,999 Mutta jossain tapauksissa se menee läpi muuttumattomana. 187 99:59:59,999 --> 99:59:59,999 Tämä oli tilanne GMX:n kohdalla. Lähetin sähköpostin GMX:stä analyysipalvelimelleni 188 99:59:59,999 --> 99:59:59,999 ja . merkkejä ei poistettu. 189 99:59:59,999 --> 99:59:59,999 Seuraavaksi tein proof-of-concept:n, jossa on väärennetty datan lopetussekvenssi 190 99:59:59,999 --> 99:59:59,999 ja sen jälkeen toinen sähköpostiviesti. 191 99:59:59,999 --> 99:59:59,999 Jos tämä proof-of-concept toimii, 192 99:59:59,999 --> 99:59:59,999 meidän pitäisi saada kaksi viestiä vastaanottajan puolella. 193 99:59:59,999 --> 99:59:59,999 Lähetin tämän kaiken Gmailiin. 194 99:59:59,999 --> 99:59:59,999 Ja Gmail oli sitä mieltä, että "tämä ei ei ole datan lopetussekvenssi". 195 99:59:59,999 --> 99:59:59,999 Ja sen näkee siitä, että datan lopetussekvenssin jälkeen kaikki on edelleen tulkittu viestin dataksi. 196 99:59:59,999 --> 99:59:59,999 Mutta joissain tapauksissä tämä itse asiassa toimi. 197 99:59:59,999 --> 99:59:59,999 Tämä oli ensimmäinen onnistunut SMTP Smuggling tapaus, GMX:stä Fastmail:iin. 198 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 199 99:59:59,999 --> 99:59:59,999 ja toinen viesti käyttäjältä admin@gmx.net, 200 99:59:59,999 --> 99:59:59,999 jotka läpäisevät SPF ja DMARC tarkistukset, koska ne tulevat GMX:n palvelimelta. 201 99:59:59,999 --> 99:59:59,999 [Applodeja] 202 99:59:59,999 --> 99:59:59,999 Minä olin, että "tämä on aivan sairasta!" 203 99:59:59,999 --> 99:59:59,999 Ajattelin, että meillä on tämä toinen viesti ja siinä voi olla mitä tahansa. 204 99:59:59,999 --> 99:59:59,999 Kuten lähettäjän osoite voi olla mitä vaan. 205 99:59:59,999 --> 99:59:59,999 Joten miksi en kokeilisi muita domaineja, jotka osoittavat GMX:n palvelimeen? 206 99:59:59,999 --> 99:59:59,999 Sitten analysoin SPF tietueen ja tajusin... 207 99:59:59,999 --> 99:59:59,999 Tässä on