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 GMX:n SPF-tietue, mutta se on hyvin samankaltainen web.de:n tietueen, joka puolestaan 208 99:59:59,999 --> 99:59:59,999 on hyvin samankaltainen Ionoksen tietueen kanssa. 209 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. 210 99:59:59,999 --> 99:59:59,999 Jos ette tiedä mikä Ionos on, niin se on superiso hosting- ja sähköpostipalveluiden tarjoaja. 211 99:59:59,999 --> 99:59:59,999 Ja heillä on nämä 1.35 miljoonaa domainia kytketty tähän. 212 99:59:59,999 --> 99:59:59,999 Joten, minun täytyi tietenkin kokeilla tätä. 213 99:59:59,999 --> 99:59:59,999 Tässä on sähköposti osoitteesta admin@web.de 214 99:59:59,999 --> 99:59:59,999 Nyt kysymys on tietysti, että toimiiko tämä kaikkialla? 215 99:59:59,999 --> 99:59:59,999 Kuten sanoin, niin tämä palvelimilla, jotka tulkitsevat lopetussekvenssit 216 99:59:59,999 --> 99:59:59,999 tavalla, joka ei ole RFC:n mukainen, kuten . 217 99:59:59,999 --> 99:59:59,999 Voimme siis väärentää 1.35 miljoonaa domainia. 218 99:59:59,999 --> 99:59:59,999 Joten pohjimmiltaan meillä on 1.4 miljoonaa Postifix instansia ja 150 tuhatta Sendmail instanssia. 219 99:59:59,999 --> 99:59:59,999 Ja tämä toimii, koska ne tulkitsevat... 220 99:59:59,999 --> 99:59:59,999 [puhuja sekoilee sanoissaan] 221 99:59:59,999 --> 99:59:59,999 Ne tulkitsevat ., sekoilen itsekin sanoissani, lopetussekvensiksi. 222 99:59:59,999 --> 99:59:59,999 Ja olin, että OK, tämä on aika vakavaa. 223 99:59:59,999 --> 99:59:59,999 Mutta tässä on muutakin. 224 99:59:59,999 --> 99:59:59,999 Katsoin outlook.comia myös ja Outlook palautti todella oudon virheilmoituksen 225 99:59:59,999 --> 99:59:59,999 koska siinä on, että pelkät rivinvaihdot eivät ole sallittuja. 226 99:59:59,999 --> 99:59:59,999 Olin siinä kohtaa, että pahus, ne tietää mitä olen tekemässä. 227 99:59:59,999 --> 99:59:59,999 [Yleisöän naurua] 228 99:59:59,999 --> 99:59:59,999 Siksi analysoin sen tarkemmin, ette pysty minua tuolla pelottelemaan. 229 99:59:59,999 --> 99:59:59,999 Joten löysin, että . on mahdollinen täällä. 230 99:59:59,999 --> 99:59:59,999 [Yleisön applodeja] 231 99:59:59,999 --> 99:59:59,999 Jeah, pidetään vähän hauskaa. 232 99:59:59,999 --> 99:59:59,999 Tässä kohtaa en ollut varma, että olenko tulossa hulluksi 233 99:59:59,999 --> 99:59:59,999 vai toimiiko tämä todella. 234 99:59:59,999 --> 99:59:59,999 Joten tarvitsin jonkinlaisen tarkistuksen. 235 99:59:59,999 --> 99:59:59,999 Ja niinpä lähetin sähköpostin osoitteesta admin@outlook.com 236 99:59:59,999 --> 99:59:59,999 yhdelle kollegoistani. Idea oli siinä, että jos he reagoivat tähän, 237 99:59:59,999 --> 99:59:59,999 se toimii, muutoin olen tullut hulluksi. 238 99:59:59,999 --> 99:59:59,999 Joten.... 239 99:59:59,999 --> 99:59:59,999 [Yleisön naurua] 240 99:59:59,999 --> 99:59:59,999 Ja ehkä nyt hieman kansainvälisempi esimerkki, koska tämä on todella itävaltalainen, luulen. 241 99:59:59,999 --> 99:59:59,999 Luulen, että ymmärrätte tämän, vaikka ette puhu saksaa. 242 99:59:59,999 --> 99:59:59,999 Ja nyt olette, okei, voimme lähettää tekstipohjaisia, väärennettyjä sähköposteja 243 99:59:59,999 --> 99:59:59,999 mutta ette pysty huijaamaan tällä ketään 244 99:59:59,999 --> 99:59:59,999 Mutta juttu on siinä, että voimme ujuttaa periaatteessa mitä tahansa, HTML mukaan luettuna 245 99:59:59,999 --> 99:59:59,999 Tässä lähetin viestin, kalasteluviestin, epätavallisesta kirjautumisesta 246 99:59:59,999 --> 99:59:59,999 osoitteesta no-reply@outlook.com 247 99:59:59,999 --> 99:59:59,999 todelliselta outlook.com palvelimelta itselleni. 248 99:59:59,999 --> 99:59:59,999 Ja se vain meni läpi. 249 99:59:59,999 --> 99:59:59,999 Mutta mitä tämä mahdollistaa? 250 99:59:59,999 --> 99:59:59,999 Pohdiskelin, että voimme väärentää outlook.comin, mutta mitä muuta voimme tehdä tällä? 251 99:59:59,999 --> 99:59:59,999 Katsoin SPF tietuetta ja se oli outo, oudosti tuttu. koska tämä ei ole 252 99:59:59,999 --> 99:59:59,999 pelkästään outlook.comin SPF tietue 253 99:59:59,999 --> 99:59:59,999 vaan miljoonien muiden domainien SPF tietue. 254 99:59:59,999 --> 99:59:59,999 Sen vuoksi, koska tämä Exchange Online palvelun SPF tietue. 255 99:59:59,999 --> 99:59:59,999 Outlook.com lähettää sähköpostit Exchange Online infrastruktuurin kautta, 256 99:59:59,999 --> 99:59:59,999 joten voimme itse asiassa väärentää ne kaikki. 257 99:59:59,999 --> 99:59:59,999 Minun piti kokeilla tätä taas. 258 99:59:59,999 --> 99:59:59,999 Tämä toimi ainoastaan teknisesti, en saanut palkan korotusta. 259 99:59:59,999 --> 99:59:59,999 Mikä vaikutus tällä on? 260 99:59:59,999 --> 99:59:59,999 Voimme väärentää miljoonia domaineja, mutta ketkä hyväksyvät nämä sähköpostit? 261 99:59:59,999 --> 99:59:59,999 Jälleen Postfix ja Sendmail, mutta vain ne instanssit, jotka eivät hyväksy BDAT komentoa. 262 99:59:59,999 --> 99:59:59,999 BDAT on vaihtoehtoinen datakomennolle 263 99:59:59,999 --> 99:59:59,999 ja jos sitä tuetaan, tämä ei toimi. 264 99:59:59,999 --> 99:59:59,999 Se oli ulospäin suuntautuva ujutus, joka on yksi osa tätä. 265 99:59:59,999 --> 99:59:59,999 Sitten on myös sisäänpäin tuleva SMTP ujutus. 266 99:59:59,999 --> 99:59:59,999 Ulospäin suuntautuvassa ongelma oli lähettävä palvelin 267 99:59:59,999 --> 99:59:59,999 koska palvelin epäonnistui tai ei tehokkaasti suodattanut väärennettyä datan lopetusekvenssiä 268 99:59:59,999 --> 99:59:59,999 kuten . Microsoftinh ja GMX palveluissa. 269 99:59:59,999 --> 99:59:59,999 Sitten on lisäksi sisäänpäin tuleva SMTP ujutus. 270 99:59:59,999 --> 99:59:59,999 Tämä tapahtuu, kun on vastaanottava palvelin, joka tulkitsee sellaisen villin datan lopetussekvenssin, 271 99:59:59,999 --> 99:59:59,999 josta lähettävällä palvelimella ei ole hajuakaan suodattaa pois. 272 99:59:59,999 --> 99:59:59,999 Löysin tällaisen Cisco Securesta, tietysti, Email Cloud Gateway:sta 273 99:59:59,999 --> 99:59:59,999 Mitä he tekevät on, ett'ähe siivoavat viestin ja merkki korvataan merkeillä. 274 99:59:59,999 --> 99:59:59,999 Joten itse asiassa, . merkkien tulkinta palauttaa datan lopetussekvenssin. 275 99:59:59,999 --> 99:59:59,999 [Yleisön applodeja] 276 99:59:59,999 --> 99:59:59,999 Ongelma on nyt siis tietenkin se, että . ei suodateta ollenkaan pois. 277 99:59:59,999 --> 99:59:59,999 On palveluita, jotka sen tekevät, mutta meillä on jälleen Exchange Online, iCloud, Sendmail, Postix 278 99:59:59,999 --> 99:59:59,999 ja monia muita, jotka päästävät tämän läpi. 279 99:59:59,999 --> 99:59:59,999 Tavallaan se käy järkeen, koska en hoksaisi sitä itsekään. 280 99:59:59,999 --> 99:59:59,999 Joten, minun täytyi kokeilla tätä jälleen. 281 99:59:59,999 --> 99:59:59,999 Valitettavasti, tai teknisesti, se toimi jälleen, 282 99:59:59,999 --> 99:59:59,999 mutta en saanut en saanut yhtään Applen laitetta. 283 99:59:59,999 --> 99:59:59,999 Ei sillä, että olisin halunnut muutenkaan. 284 99:59:59,999 --> 99:59:59,999 Mikä vaikutus tällä on? 285 99:59:59,999 --> 99:59:59,999 Pohjimmiltaan voimme väärentään vielä enemmän domaineja kuin edellä. 286 99:59:59,999 --> 99:59:59,999 Meillä on Exchange Online, meillä on iCloud, 287 99:59:59,999 --> 99:59:59,999 meillä on Postfix ja Sendmail. 288 99:59:59,999 --> 99:59:59,999 Ja voimme väärentää yrityksiä, joilla on vara tähän - aika isoja yrityksiä tässä. 289 99:59:59,999 --> 99:59:59,999 Tämä pitää sisällää yli 40 tuhatta muuta domainia. 290 99:59:59,999 --> 99:59:59,999 Ja se on vain ne, jotka on hostattu pilvessä. 291 99:59:59,999 --> 99:59:59,999 Lisäksi on on-prem instanssit, mutta en pystynyt käymään niitä läpi. 292 99:59:59,999 --> 99:59:59,999 Ja nyt osuuteen, joka on luultavasti mielenkiintoisin teille, tai ainakin osalle teistä. 293 99:59:59,999 --> 99:59:59,999 Vastuullinen julkaisu. 294 99:59:59,999 --> 99:59:59,999 Puhtaasti teknisesti, koskien lähettäviä ja vastaanottavia palvelimia, kenen vika tämä on? 295 99:59:59,999 --> 99:59:59,999 Meillä on vastaanottavia palvelimia, joiden ei koskaan oleteta tulkitsevan mitään muita 296 99:59:59,999 --> 99:59:59,999 datan lopetussekvenssejä kuin ., ainkin RFC:n mukaan. 297 99:59:59,999 --> 99:59:59,999 Sitten meillä on lähettäviä palvelimia, joiden ei oleteta lähettävän ja merkkejä 298 99:59:59,999 --> 99:59:59,999 toisistaan riippumatta. 299 99:59:59,999 --> 99:59:59,999 Joten lopulta tämän on kaikkien vika. 300 99:59:59,999 --> 99:59:59,999 Lähetimme tämän tiedon GMX:lle. 301 99:59:59,999 --> 99:59:59,999 He olivat superkiitollisia ja ilmoittivat korjaavansa asian saman tien. 302 99:59:59,999 --> 99:59:59,999 10 päivää myöhemmin he korjasivat tämän. 303 99:59:59,999 --> 99:59:59,999 He pyysivät meitä tarkastamaan uudelleen ja tarkastimme, että he todella korjasivat sen. 304 99:59:59,999 --> 99:59:59,999 He maksoivat meille pienen palkkion. 305 99:59:59,999 --> 99:59:59,999 Ha laittoivat meidät jopa heidän Bug Bounty Hall of Fame:en. 306 99:59:59,999 --> 99:59:59,999 Kaiken kaikkiaan se oli 10/10 kokemus. 307 99:59:59,999 --> 99:59:59,999 [Applodeja] 308 99:59:59,999 --> 99:59:59,999 Aion lähettää heille tallenteen teidän applodeista. Kiitos! 309 99:59:59,999 --> 99:59:59,999 Tuntui melkein sille, että meidän olisi pitänyt maksaa palkkio heille. 310 99:59:59,999 --> 99:59:59,999 Tästä eteenpäin mennäänkin sitten alamäkeä. 311 99:59:59,999 --> 99:59:59,999 Meillä on Microsoft. Microsoft oli sitä mieltä, että tämä on kohtuullisen riskin haavoittuvuus. 312 99:59:59,999 --> 99:59:59,999 En tiedä, ehkä heillä on suurempi kala kiikarissa, mutta joka tapauksessa. 313 99:59:59,999 --> 99:59:59,999 Lähetimme tiedot heille ja kolme kuukautta myöhemmin he sulkivat tapauksen ja sanoivat, 314 99:59:59,999 --> 99:59:59,999 että kaikki on korjattu, ei palkkiota ja niin edelleen. 315 99:59:59,999 --> 99:59:59,999 Tässä kohtaa olin saanut jo mitä halusin. 316 99:59:59,999 --> 99:59:59,999 Ja se on sähköpostin saaminen osoitteesta admin@microsoft.com 317 99:59:59,999 --> 99:59:59,999 Ja sitten Ciscoon. 318 99:59:59,999 --> 99:59:59,999 Ciscon mielestä tämä ei ollut haavoittuvuus, 319 99:59:59,999 --> 99:59:59,999 vaan dokumentoitu ja konfiguroitava ominaisuus. 320 99:59:59,999 --> 99:59:59,999 Me olimme sitä mieltä, että onpa outo ominaisuus, 321 99:59:59,999 --> 99:59:59,999 koska voimme väärentää sähköposteja sillä. 322 99:59:59,999 --> 99:59:59,999 Sanoimme, että kertokaa edes asiakkaillenne tästä ominaisuudesta, 323 99:59:59,999 --> 99:59:59,999 joka ei välttämättä ole paras oletustoiminallisuus. 324 99:59:59,999 --> 99:59:59,999 He sanoivat "Ei". 325 99:59:59,999 --> 99:59:59,999 Me olimme siinä, että meillä on tämä suuri SMTP Smuggling ongelma. 326 99:59:59,999 --> 99:59:59,999 Ja Cisco ei halua tehdä mitään, Microsoft oli haavoittuvainen. 327 99:59:59,999 --> 99:59:59,999 Me veimme tämän tapauksen CERT/CC:lle. 328 99:59:59,999 --> 99:59:59,999 Niille, jotka eivät tiedä, CERT/CC koordinoi ja käsittelee näitä suuria haavoittuvuuksia, 329 99:59:59,999 --> 99:59:59,999 joilla voi olla maailmanlaajuisia vaikutuksia. 330 99:59:59,999 --> 99:59:59,999 Me lähetimme tiedot heille ja he itse asiassa hyväksyivät tapauksen. 331 99:59:59,999 --> 99:59:59,999 Sitten olemme tässä Vince portaalissa. 332 99:59:59,999 --> 99:59:59,999 Joka on periaatteessa iso chat-huone, jossa 14 toimittajaa. 333 99:59:59,999 --> 99:59:59,999 Siellä on Microsoft, SendMail, Cisco, Google 334 99:59:59,999 --> 99:59:59,999 Ja sitten voimme alkaa puhumaan haavoittuvuudesta 335 99:59:59,999 --> 99:59:59,999 Ensimmäisessä keskustelussa Cisco sanoo edelleen, että kyseessä ei ole haavoittuvuus. 336 99:59:59,999 --> 99:59:59,999 Tiedättehän, se ei ole bugi, vaan ominaisuus. 337 99:59:59,999 --> 99:59:59,999 Noh, joka tapauksessa se ei ole bugi heidän mielestään. 338 99:59:59,999 --> 99:59:59,999 Ja sitten CERT/CC on sitä mieltä, että kyseessä ei ole haavoittuvuus, jostain syystä. 339 99:59:59,999 --> 99:59:59,999 Kuinkas yleinen SMTP ujutusongelma? 340 99:59:59,999 --> 99:59:59,999 Entäs Postfixin ja Sendmailin RFC:stä eriävät tulkinnat datan lopetussekvenssistä? 341 99:59:59,999 --> 99:59:59,999 Ensinnäkin, Sendmail oli tässä Vince portaalissa alusta alkaen. 342 99:59:59,999 --> 99:59:59,999 He saivat kaikki PoC:t, viestit, kaiken. 343 99:59:59,999 --> 99:59:59,999 Ja he eivät sanoneet mitään. 344 99:59:59,999 --> 99:59:59,999 Entäpä Postfix? He ovat 10 kertaa suurempi. 345 99:59:59,999 --> 99:59:59,999 CERT/CC oli... en tiedä miksi he eivät lisänneet heitä tapaukseen suoraan. 346 99:59:59,999 --> 99:59:59,999 Mutta CERT/CC lähetti heille sähköpostin, mutta unohti mainita SMTP ujutuksen. 347 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. 348 99:59:59,999 --> 99:59:59,999 Me olimme, että Cisco on taatusti haavoittuvainen, olimme varmistaneet sen. 349 99:59:59,999 --> 99:59:59,999 Joten haluaisimme julkistaa tämän blogissa. 350 99:59:59,999 --> 99:59:59,999 Ja tästä ongelmat vasta alkoivatkin. 351 99:59:59,999 --> 99:59:59,999 Kerroimme, että haluaisimme julkaista tästä blogikirjoituksen ja varoittaisimme Ciscon asiakkaita 352 99:59:59,999 --> 99:59:59,999 tästä haavoittuvuudesta. 353 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" 354 99:59:59,999 --> 99:59:59,999 Päätimme edetä ja tulimme avanneeksi Pandoran laatikon, koska nyt 1.6 miljoonaan Postfix ja Sendmail 355 99:59:59,999 --> 99:59:59,999 instanssia ovat haavoittuvina internetissä. 356 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ä. 357 99:59:59,999 --> 99:59:59,999 Tarkoittaako tämä, ettei SEC Consultissa ole yhtään vikaa? 358 99:59:59,999 --> 99:59:59,999 Totta kai SEC Consultissa on vikaa. 359 99:59:59,999 --> 99:59:59,999 Julkaisimme blogikirjoituksen olettaen, että vaikutus olisi pienempi kuin se todellisuudessa oli 360 99:59:59,999 --> 99:59:59,999 perustuen keskesteluihin CERT/CC:n kanssa ja VINCE:ssä muutenkin. 361 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, 362 99:59:59,999 --> 99:59:59,999 koska he ovat järkkymättämiä, että tämä on ongelma. 363 99:59:59,999 --> 99:59:59,999 Yhteenveto, mitä tämä tarkoittaa? 364 99:59:59,999 --> 99:59:59,999 Korjatkaa Postfix palvelimenne! Löydätte lisätietoja Postfixin nettisivuilta. 365 99:59:59,999 --> 99:59:59,999 Lisäksi korjatkaa Cisco palvelimenne. Voitte löytää lisätietoja siitä SEC Consult:n blogista. 366 99:59:59,999 --> 99:59:59,999 [Yleisön naurua ja aplodit] 367 99:59:59,999 --> 99:59:59,999 Lopuksi, tässäkin pilvessä on jonkinlainen hopeareunus. 368 99:59:59,999 --> 99:59:59,999 Nyt Postfix on suoraan mukana VINCE tapauksessa 369 99:59:59,999 --> 99:59:59,999 ja he ovat jo antaneet suuren panoksen. 370 99:59:59,999 --> 99:59:59,999 Emme työnnä päätämme pensaaseen ja yritä aktiivisesti sulkea Pandoran lipasta jälleen. 371 99:59:59,999 --> 99:59:59,999 Ja mitä se tarkoittaa? Lisää tutkimusta SMTP ujuttelusta 372 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. 373 99:59:59,999 --> 99:59:59,999 Lisää blogikirjoituksia, lisää tutkimusta ja ennen kaikkea lisää toimijoita VINCE tapaukseen. 374 99:59:59,999 --> 99:59:59,999 Yritämme saada kaiken korjattua ja olemme pahoillamme, että tämä tapahtui ylipäätään. 375 99:59:59,999 --> 99:59:59,999 Lopuksi jotain, jonka kaikki tiedätte. Älkää luottako sähköposteihinn sokeasti, erityisesti tällä hetkellä. 376 99:59:59,999 --> 99:59:59,999 Kiitos. 377 99:59:59,999 --> 99:59:59,999 [Aplodeja] 378 99:59:59,999 --> 99:59:59,999 Hienoa, mennään kysymyksiin. 379 99:59:59,999 --> 99:59:59,999 Ole hyvä. 380 99:59:59,999 --> 99:59:59,999 Hei, minulla on yksi lyhyt kysymys CERT/CC asiasta. 381 99:59:59,999 --> 99:59:59,999 Oliko tämä kommunikoitu sähköpostilla? 382 99:59:59,999 --> 99:59:59,999 Ja etkö olisi voinut lähettää viestin viestin Ciscon CDO:na? 383 99:59:59,999 --> 99:59:59,999 Kyllä, olisimme voineet tehdä sen ja luoda jonkinlaisen kolmiodraamaan 384 99:59:59,999 --> 99:59:59,999 Bill Gatesin, Elon Muskin ja jonkun muun välille. 385 99:59:59,999 --> 99:59:59,999 Mutta valitettavasti emme nähneet tätä sähköpostia. 386 99:59:59,999 --> 99:59:59,999 Näimme sen jälkeen päin, mutta se oli valitettavasti liian myöhäistä.