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 Postfixin korjaamisesta. 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:15.954 suuret kiitokset Wietselle ja Viktorille 00:01:16.032 --> 00:01:18.312 heidän sitoutumisestaan. 00:01:18.334 --> 00:01:20.354 Ja lisäksi suuret kiitokset yhteisölle 00:01:20.411 --> 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:36.905 Ja kaikille niille, 00:01:37.007 --> 00:01:39.067 joilla ei ole mitään hajua tästä. 00:01:39.129 --> 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:45.956 lopettanut tutkimukseni DNS:n parissa. 00:01:45.956 --> 00:01:48.564 ja etsin uutta tutkimuskohdetta, 00:01:48.564 --> 00:01:51.908 kun löysin todennäköisesti helpoimman 00:01:51.908 --> 00:01:53.583 tavan hakkeroida yrityksen 00:01:53.583 --> 00:01:55.562 ja kaikki tämä vain yhdellä 00:01:55.562 --> 00:01:58.073 yksinkertaisella Google-haulla. 00:01:58.173 --> 00:02:00.913 [Yleisön naurua] 00:02:00.913 --> 00:02:03.571 Ja tämä saattaa kuulostaa tyhmälle, 00:02:03.585 --> 00:02:05.735 mutta tämä johdatti minut suuntaan, 00:02:05.735 --> 00:02:08.005 jonka jo tiesin, mutta en ollut ymmärtänyt. 00:02:08.005 --> 00:02:11.125 Ja se on, että tietojen kalastelu on edelleen 00:02:11.166 --> 00:02:14.076 numero 1 ensipääsyvektori yritykseen 00:02:14.400 --> 00:02:16.290 ja sitten minulla välähti: 00:02:16.382 --> 00:02:18.232 Miksen tutkisi SMTP:tä, 00:02:18.456 --> 00:02:20.136 simple mail transfer protocol:aa 00:02:20.400 --> 00:02:23.264 jota käytetään miljardien sähköpostien 00:02:23.357 --> 00:02:25.435 lähettämiseen joka päivä ympäri maailman 00:02:25.455 --> 00:02:27.215 kuten on tehty viimeisen 40 vuoden ajan. 00:02:27.285 --> 00:02:29.815 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.329 sähköpostien väärentämiseksi. 00:02:37.329 --> 00:02:39.689 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:14.920 mutta tämä esitys ei kerro 00:03:14.920 --> 00:03:17.098 ihmiseen penetroitumisesta. 00:03:17.833 --> 00:03:21.833 Esitys kertoo tunkeutumisesta SMTP-protokollan muurien läpi. 00:03:22.014 --> 00:03:24.790 Joten nähdäksemme miten tämä toimii 00:03:24.790 --> 00:03:26.646 on meidän ensin ymmärrettävä 00:03:26.646 --> 00:03:29.017 miten sähköpostien lähetys yleensäkin toimii. 00:03:29.017 --> 00:03:32.570 Joten tässä meillä on melko yksinkertainen sähköposti-infrastuktuuri. 00:03:32.604 --> 00:03:34.864 Meillä on sähköpostikäyttäjäagentti, 00:03:34.864 --> 00:03:38.484 kuten Thunderbird, ja Thunderbird haluaa lähettää sähköpostin 00:03:38.494 --> 00:03:41.684 esimerkiksi käyttäjänä user@outlook.com. 00:03:41.684 --> 00:03:44.344 Joten jos haluamme lähettää sähköpostin tällä tavalla 00:03:44.344 --> 00:03:46.938 meidän täytyy ensin tunnistautua 00:03:46.938 --> 00:03:49.637 Outlook mail transfer agentille tai 00:03:49.637 --> 00:03:52.389 ulospäin menevälle SMTP palvelimelle. 00:03:52.407 --> 00:03:54.877 Ja kun olemme tunnistautuneet, 00:03:54.877 --> 00:03:59.134 voimme lähettää sähköpostin käyttäjänä user@outlook.com. 00:03:59.134 --> 00:04:02.227 Ja vain käyttäjänä user@outlook.com. 00:04:02.227 --> 00:04:05.697 Tämän jälkeen viesti siirretään vastaanottajan 00:04:05.807 --> 00:04:08.977 SMTP-palvelimelle ja tämä palvelin 00:04:08.977 --> 00:04:12.977 tarkistaa viestin aitouden. 00:04:12.977 --> 00:04:16.977 Ja kaikkein yleisen tapa tehdä tämä on SPF. 00:04:16.997 --> 00:04:20.997 Vastaanottava SMTP-palvelin saa SPF-tietueen 00:04:21.007 --> 00:04:24.267 DNS-palvelun kautta outlook.com osoitteelle. 00:04:24.267 --> 00:04:27.357 Ja tarkistaa sen jälkeen, että tämä IP-osoite 00:04:27.357 --> 00:04:30.467 ja IP-alue on sallittu lähettää sähköpostiviestejä 00:04:30.467 --> 00:04:31.807 outlook.com osoitteelle. 00:04:31.807 --> 00:04:36.437 Tässä tapauksessa todellinen Outlook SMTP-palvelin 00:04:36.437 --> 00:04:38.606 tai ulospäin lähtevä SMTP-palvelin lähetti viestin, 00:04:38.687 --> 00:04:40.907 vastaanottava SMTP-palvelin 00:04:40.907 --> 00:04:42.367 hyväksyy viestin. 00:04:42.367 --> 00:04:44.907 Ja nyt luonnollisesti tässä on erittäin 00:04:44.907 --> 00:04:46.307 mielenkiintoinen kysymys. 00:04:46.307 --> 00:04:49.637 Ja kysymys on: onko hyökkääjän mahdollista 00:04:49.637 --> 00:04:51.827 lähettää sähköpostiviesti 00:04:51.827 --> 00:04:54.587 esimerkiksi osoitteesta admin@outlook.com tai 00:04:54.587 --> 00:04:56.557 väärennetystä sähköpostiosoitteesta? 00:04:56.647 --> 00:04:58.797 Tätä me selvitämme tänään 00:04:58.797 --> 00:05:01.107 ja se on enemmän tai vähemmän 00:05:01.107 --> 00:05:03.507 tämän tutkimuksen tavoitteista. 00:05:03.507 --> 00:05:04.948 En tiedä oletteko huomanneet, 00:05:04.948 --> 00:05:07.227 mutta näiden palvelimien värit 00:05:07.227 --> 00:05:10.267 muistuttavat minusta Paavo Pesusieneä 00:05:10.267 --> 00:05:11.937 ja Patrik Tähtöstä. 00:05:11.937 --> 00:05:15.087 Ja sen vuoksi kutsumme niitä niiksi. 00:05:17.380 --> 00:05:20.277 Tutkimuksen yleinen tavoite ja 00:05:20.277 --> 00:05:23.417 tutkimuksen peruste oli löytää 00:05:23.417 --> 00:05:24.657 tapa väärentää sähköposteja. 00:05:24.657 --> 00:05:28.157 Ja ajattelin, että miksi en ottaisi haavoittuvuuksia 00:05:28.157 --> 00:05:30.337 muista tekstipohjaisista protokollista, 00:05:30.337 --> 00:05:34.347 kuten HTTP:stä, ja soveltaisi niitä SMTP:hen. 00:05:35.892 --> 00:05:40.431 Ja oli yksi HTTP haavoittuvuus, joka sopi kuvaan 00:05:40.431 --> 00:05:43.077 ja se oli HTTP-pyynnön käpelöinti. 00:05:43.077 --> 00:05:48.157 Tässä meillä on taas Paavo ja Patrik, 00:05:48.157 --> 00:05:50.737 mutta tällä kertaa HTTP-maailmassa. NOTE Paragraph 00:05:50.737 --> 00:05:57.610 Joten, mitä tässä tapahtuu? Paavo Pesusieni saa POST-tyyppisen pyynnön internetin yli 00:05:57.610 --> 00:06:04.687 Mielenkiintoista tässä pyynnössä on se, että siinä on kaksi otsikkoa 00:06:04.687 --> 00:06:08.627 kuinka käsitellä POST-pyynnön data. 00:06:08.647 --> 00:06:11.547 Siinä on Content-Length -otsikko, jonka arvona on 43 tavua. 00:06:11.547 --> 00:06:14.617 Ja siinä on myös Transfer-Encoding -otsikko. 00:06:14.617 --> 00:06:19.647 Nyt Paavo Pesusienen täytyy päättää, miten käsittelen pyynnön ja Paavo päättää 00:06:19.647 --> 00:06:25.047 käyttää Content-Length otsikkoa, koska se on 43 tavua. 00:06:25.477 --> 00:06:29.477 Joten kaikki punaisella kehystetty data on välitetty Patrikille. 00:06:29.477 --> 00:06:35.187 Patrikilla ei ole mitään hajua mitä tehdä - pitäisikö minun tulkita Content-Lenth otsikkoa vai 00:06:35.187 --> 00:06:39.897 Transfer-Encoding -otsikko? Patrik päättää tulkita Transfer-Encoding otsikkoa ja 00:06:39.897 --> 00:06:41.896 nyt meillä on eriävät tulkinnat: 00:06:41.896 --> 00:06:48.506 Paavo Pesusieni käyttää Content-Length -otsikkoa ja Patrik Tähtönen käyttää Transfer-Encoding -otsikkoa. 00:06:48.506 --> 00:06:52.606 Ja koska Transfer-Encoding on määritetty "chunked" ("paloiteltu") ja ja ensimmäinen pala on 0, 00:06:52.606 --> 00:06:58.256 on loput Paavo Pesusienen lähettämästä datasta tulkittu toiseksi pyynnöksi. 00:06:58.546 --> 00:07:04.486 Itse asiassa tämä tarkoittaa, että Paavo näkee yhden pyynnön ja Patrik kaksi pyyntöä. 00:07:04.627 --> 00:07:10.037 Ja toinen pyyntö voidaan kohdistaa mielivaltaiseen resurssipolkuun, kuten "Admin", 00:07:10.297 --> 00:07:14.118 joka tässä esimerkissä on avoin vain sisäisesti palvelimella. 00:07:14.297 --> 00:07:16.407 Joka on tietenkin ongelma. 00:07:16.407 --> 00:07:20.047 Joten ajattelin, että miksi en ottaisi näitä tulkintaeroja 00:07:20.047 --> 00:07:21.477 ja laittaisi niitä SMTP:hen. 00:07:21.477 --> 00:07:27.507 Ymmärtääksemme... tai ainakin päästäksemme lähemmäs ymmärrystä miten tämä toimii, 00:07:27.507 --> 00:07:31.097 täytyy meidän katsoa ensin itse SMTP protokollaa. 00:07:31.097 --> 00:07:34.377 Joten, SMTP näyttää kuta kuinkin tältä. 00:07:34.377 --> 00:07:40.167 Meillä on kaksi komponenttia: SMTP komennot punaisella ja sinisellä viestin data. 00:07:40.957 --> 00:07:47.077 Lähettääksemme viestin, meidän tulee ensin lähettää SMTP komennot: 00:07:47.637 --> 00:07:53.167 Meidän pitää esitellä itsemme, kertoa lähettäjän osoite, yksi tai useampi vastaanottajan osoite ja 00:07:53.167 --> 00:07:59.347 sitten lähetämme "data" komennon kertoaksemme vastaanottavalle SMTP-palvelimelle 00:08:00.428 --> 00:08:03.127 että olemme nyt vastaanottamassa varsinaista viestin dataa. 00:08:04.017 --> 00:08:12.107 Ja sitten lähetämme viestin datan: määrittelemme lähettäjän osoitteen uudelleen, vastaanottajan osoitteen ja viestin aiheen. 00:08:12.467 --> 00:08:14.507 Ja sitten tulee viestin leipäteksti. 00:08:14.507 --> 00:08:17.987 Ja kun jossain vaiheessa haluamme lopettaa viestin datan lähettämisen, 00:08:17.987 --> 00:08:21.987 meidän tulee lähettää jotain, jota kutsumme datan lopetussekvensiksi. 00:08:22.247 --> 00:08:27.397 Se on "<paluu rivin alkuun><rivinvaihto> piste <paluu rivin alkuun><rivinvaihto>" [kääntäjän kommentti: jatkossa .] 00:08:28.657 --> 00:08:36.577 Tässä vaiheessa ajattelin, että ehkä voisimme hämätä tällä jotenkin SMTP-palvelinten toteutuksia. 00:08:37.667 --> 00:08:43.717 Ajatus oli siis, että meillä on jälleen Paavo Pesusieni ja lähetämme sähköpostin Paavo Pesusienelle [SIC]. 00:08:45.507 --> 00:08:48.847 Ja tämä sähköposti sisältää jotain todella outoa, jotain joka näyttää 00:08:48.847 --> 00:08:54.147 lopetussekvensille, mutta se ei ole sitä. 00:08:54.297 --> 00:08:59.807 Koska se ei ole yhdenmukainen RFC:n kanssa, joku voisi virheellisesti tulkita sen datan lopetussekvensiksi. 00:08:59.807 --> 00:09:05.947 Joten Paavo Pesusieni katsoo tätä ja ajattelee ettei tämä ole RFC:stä, en tulkitse tätä "end-of-data" sekvensiksi 00:09:07.387 --> 00:09:15.830 Ja seuraavaksi... tai viestin data siihen saakka, kunnes varsinainen datan lopetussekvenssi tulee. 00:09:16.257 --> 00:09:18.594 Sitten Paavo Pesusieni lähettää viestin Patrikille 00:09:19.057 --> 00:09:26.402 Ja Patrik on "Jeah, en välitä mistään RFC:stä ja ja tulkitsen väärän datan lopetussekvenssi 00:09:26.497 --> 00:09:29.647 varsinaiseksi datan lopetusmerkiksi." 00:09:29.947 --> 00:09:36.907 Ja ongelmaksi tässä tulee, että kaikki väärin tulkitun lopetussekvenssin tulkitaan SMTP-komennoiksi 00:09:37.417 --> 00:09:44.507 Ja nyt hyökkääjänä voimme luoda SMTP-komentoja, jotka lähettävät toisen sähköpostiviestin. 00:09:44.737 --> 00:09:51.377 Vaikka Paavo Pesusieni näki yhden ison sähköpostiviestin, Patrik näkee kaksi pienempää viestiä. 00:09:51.477 --> 00:09:56.258 Ja ongelma on se, että toinen viesti voi sisältää mielivaltaisia SMTP-komentoja. 00:09:56.358 --> 00:10:00.508 Kuten, että viesti tulee osoitteesta admin@outlook.com tai mitä tahansa. 00:10:01.697 --> 00:10:05.447 Näin ainakin teoriassa. 00:10:05.687 --> 00:10:07.887 Nähdäkseni toimiiko tämä todella. 00:10:09.067 --> 00:10:13.557 Tutkin muutamia SMTP-palvelinten toteutuksia yksinkertaisesti 00:10:13.587 --> 00:10:17.077 ottamalla niihin yhteyttä telnet:llä tai netcat:lla. 00:10:18.679 --> 00:10:23.919 Kun tein tämän, se näytti aluksi RFC:n mukaiselta. 00:10:23.979 --> 00:10:32.189 Kun lähetät datakomennon, palvelin pyytää lopettamaan datan lähettämisen . merkeillä. 00:10:32.649 --> 00:10:38.749 Sitten löysin myös palvelimia, jotka sanoivat: "lähetä minulla rivi, jossa on vain piste" 00:10:39.005 --> 00:10:45.625 Ja tämä asia riippuu paljon käytettävästä käyttöjärjestelmästä. 00:10:45.914 --> 00:10:54.314 Windows:ssa tämä voi olla <CR><LF>.<CR><LF> ja Linuxissa se voi olla . 00:10:54.819 --> 00:11:00.059 Siinä kohtaa ajattelin, että tässä voisi olla jotain. 00:11:00.669 --> 00:11:02.059 Ja kokeilin jotain. 00:11:02.062 --> 00:11:11.552 Ensimmäiseksi kokeilin työntää <CR>-, <LF>- ja piste- merkkejä Paavo Pesusienen kautta. 00:11:11.794 --> 00:11:18.744 Joten kirjoitin SMTP analyysisovelluksen, joka lähettää sähköposteja, joissa on virheellisiä data lopetussekvenssejä, 00:11:19.041 --> 00:11:23.631 kuten <LF>.<LF> Ja lähetin viestejä eri SMTP- ohjelmistoilla, 00:11:24.043 --> 00:11:29.203 sisältäen sähköpostipalveluita Gmail, Outlook, GMX 00:11:29.383 --> 00:11:35.193 ja lisäksi sähköpostiohjelmistoja kuten Postfix, Exim, Microsoft Exchange Server ja niin edelleen. 00:11:36.500 --> 00:11:44.420 Vastaanottavalla puolella tutkin, että mitkä vääristä sekvensseistä menee itse asiassa läpi. 00:11:44.644 --> 00:11:50.924 Voinko lähettää komennon <LF>.<LF> lähtevän palvelimen kautta? 00:11:51.211 --> 00:11:53.986 Ja useimmissa tapauksissa se ei toiminut. 00:11:54.326 --> 00:11:58.956 <LF>.<LF> on usein suodatettu tai poistettu alkuperäisestä viestistä. 00:11:59.298 --> 00:12:05.318 Mutta jossain tapauksissa se menee läpi muuttumattomana. 00:12:05.539 --> 00:12:12.319 Tämä oli tilanne GMX:n kohdalla. Lähetin sähköpostin GMX:stä analyysipalvelimelleni 00:12:12.499 --> 00:12:16.499 ja <LF>.<CR><LF> merkkejä ei poistettu. 00:12:16.732 --> 00:12:23.562 Seuraavaksi tein proof-of-concept:n, jossa on ensin viesti 00:12:23.703 --> 00:12:26.403 ja sitten väärennetty datan lopetussekvenssi 00:12:26.505 --> 00:12:30.405 ja sen jälkeen SMTP komentoja ja data toiselle sähköpostiviestille. 00:12:30.589 --> 00:12:33.149 Jos tämä proof-of-concept toimii, 00:12:33.363 --> 00:12:37.393 meidän pitäisi saada kaksi viestiä vastaanottajan puolella. 00:12:37.625 --> 00:12:40.135 Lähetin tämän kaiken Gmailiin. 00:12:40.265 --> 00:12:43.275 Ja Gmail oli sitä mieltä, että "tämä ei ei ole datan lopetussekvenssi". 00:12:43.703 --> 00:12:49.353 Ja sen näkee siitä, että datan lopetussekvenssin jälkeen kaikki on edelleen tulkittu viestin dataksi. 00:12:49.984 --> 00:12:54.244 Mutta joissain tapauksissä tämä itse asiassa toimi. 00:12:54.389 --> 00:13:01.204 Tämä oli ensimmäinen onnistunut SMTP Smuggling tapaus, GMX:stä Fastmail:iin. 00:13:01.481 --> 00:13:06.611 Me näemme, että se toimii. Meillä on ensin viesti käyttäjältä user@gmx.net 00:13:06.772 --> 00:13:11.312 ja toinen viesti käyttäjältä admin@gmx.net, 00:13:11.451 --> 00:13:18.151 jotka läpäisevät SPF ja DMARC tarkistukset, koska ne tulevat todelliselta GMX:n palvelimelta. 00:13:18.639 --> 00:13:26.119 [Applodeja] 00:13:28.313 --> 00:13:31.873 Minä olin, että "tämä on aivan sairasta!" 00:13:34.762 --> 00:13:37.942 Ajattelin, että meillä on tämä toinen viesti ja siinä voi olla mitä tahansa. 00:13:38.128 --> 00:13:40.228 Kuten lähettäjän osoite voi olla mitä vaan. 00:13:40.356 --> 00:13:46.718 Joten miksi en kokeilisi muita domaineja, jotka osoittavat GMX:n palvelimeen? 00:13:47.160 --> 00:13:50.260 Sitten analysoin SPF tietueen ja tajusin... 00:13:50.582 --> 00:13:59.642 Tässä on GMX:n SPF-tietue, mutta se on hyvin samankaltainen web.de:n tietueen, joka puolestaan 00:13:59.791 --> 00:14:03.121 on hyvin samankaltainen Ionoksen tietueen kanssa. 00:14:03.296 --> 00:14:08.086 Ja tilanne on nyt se, että tällä me voimme väärentää 1.35 miljoonaa domainia tällä. 00:14:09.031 --> 00:14:15.631 Jos ette tiedä mikä Ionos on, niin se on superiso hosting- ja sähköpostipalveluiden tarjoaja. 00:14:15.774 --> 00:14:20.414 Ja heillä on nämä 1.35 miljoonaa domainia kytketty tähän. 00:14:20.581 --> 00:14:24.461 Joten, minun täytyi tietenkin kokeilla tätä. 00:14:24.993 --> 00:14:28.773 Tässä on sähköposti osoitteesta admin@web.de 00:14:28.918 --> 00:14:32.787 Nyt kysymys on tietysti, että toimiiko tämä kaikkialla? 00:14:33.058 --> 00:14:38.398 Kuten sanoin, niin tämä toimii vain palvelimilla, jotka tulkitsevat lopetussekvenssit 00:14:38.752 --> 00:14:42.672 tavalla, joka ei ole RFC:n mukainen, kuten . 00:14:42.943 --> 00:14:46.833 Voimme siis väärentää 1.35 miljoonaa domainia. 00:14:47.043 --> 00:14:56.293 Joten pohjimmiltaan meillä on 1.4 miljoonaa Postifix instansia ja 150 tuhatta Sendmail instanssia. 00:14:56.712 --> 00:14:59.832 Ja tämä toimii, koska ne tulkitsevat... 00:15:00.194 --> 00:15:02.044 [puhuja sekoilee sanoissaan] 00:15:02.571 --> 00:15:06.676 Ne tulkitsevat <LF>.<CR><LF>, sekoilen itsekin sanoissani, lopetussekvensiksi. 00:15:07.026 --> 00:15:10.146 Ja olin, että OK, tämä on aika vakavaa. 00:15:10.502 --> 00:15:12.692 Mutta tässä on muutakin. 00:15:12.864 --> 00:15:18.314 Katsoin outlook.comia myös ja Outlook palautti todella oudon virheilmoituksen 00:15:18.693 --> 00:15:22.933 koska siinä on, että pelkät rivinvaihdot eivät ole sallittuja. 00:15:23.329 --> 00:15:26.869 Olin siinä kohtaa, että pahus, ne tietää mitä olen tekemässä. 00:15:26.913 --> 00:15:29.390 [Yleisöän naurua] 00:15:29.790 --> 00:15:33.710 Siksi analysoin sen tarkemmin, ette pysty minua tuolla pelottelemaan. 00:15:34.406 --> 00:15:39.526 Joten löysin, että <LF>.<CR><LF> on mahdollinen täällä. 00:15:39.772 --> 00:15:44.052 [Yleisön applodeja] 00:15:49.043 --> 00:15:51.663 Jeah, pidetään vähän hauskaa. 00:15:51.734 --> 00:15:54.774 Tässä kohtaa en ollut varma, että olenko tulossa hulluksi 00:15:54.912 --> 00:15:57.002 vai toimiiko tämä todella. 00:15:57.341 --> 00:15:59.771 Joten tarvitsin jonkinlaisen tarkistuksen. 00:15:59.937 --> 00:16:02.607 Ja niinpä lähetin sähköpostin osoitteesta admin@outlook.com 00:16:02.882 --> 00:16:07.232 muutamille kollegoilleni. Idea oli siinä, että jos he reagoivat tähän, 00:16:07.646 --> 00:16:08.746 se toimii. 00:16:09.035 --> 00:16:10.935 Muutoin olen tullut hulluksi. 00:16:11.101 --> 00:16:13.341 Joten.... 00:16:13.859 --> 00:16:17.359 [Yleisön naurua] 00:16:17.561 --> 00:16:23.211 Ja ehkä nyt hieman kansainvälisempi esimerkki, koska tämä on todella itävaltalainen, luulen. 00:16:30.657 --> 00:16:34.257 Luulen, että ymmärrätte tämän, vaikka ette puhu saksaa. 00:16:35.321 --> 00:16:39.701 Ja nyt olette, okei, voimme lähettää tekstipohjaisia, väärennettyjä sähköposteja 00:16:40.048 --> 00:16:42.598 mutta ette pysty huijaamaan tällä ketään 00:16:42.776 --> 00:16:45.866 Mutta juttu on siinä, että voimme ujuttaa periaatteessa mitä tahansa, 00:16:45.986 --> 00:16:46.986 HTML:ää mukaan luettuna 00:16:47.856 --> 00:16:53.628 Tässä lähetin viestin, kalasteluviestin, epätavallisesta kirjautumisesta 00:16:53.968 --> 00:16:58.138 osoitteesta no-reply@outlook.com todelliselta outlook.com palvelimelta 00:16:59.005 --> 00:17:00.329 itselleni. 00:17:00.469 --> 00:17:02.509 Ja se vain meni läpi. 00:17:04.622 --> 00:17:08.342 Mutta jälleen, mitä tämä mahdollistaa? 00:17:09.085 --> 00:17:13.085 Pohdiskelin, että voimme väärentää outlook.comin, 00:17:13.454 --> 00:17:16.167 mutta mitä muuta voimme tehdä tällä? 00:17:16.192 --> 00:17:22.552 Katsoin SPF tietuetta ja se oli outo, oudosti tuttu. 00:17:22.792 --> 00:17:26.792 Koska tämä ei ole pelkästään outlook.comin SPF tietue 00:17:26.985 --> 00:17:31.105 vaan miljoonien muiden domainien SPF tietue. 00:17:31.537 --> 00:17:37.777 Sen vuoksi, koska tämä Exchange Online palvelun SPF tietue. 00:17:39.297 --> 00:17:44.707 Outlook.com lähettää sähköpostit Exchange Online infrastruktuurin kautta, 00:17:45.262 --> 00:17:49.202 joten voimme itse asiassa väärentää ne kaikki. 00:17:49.423 --> 00:17:53.313 Minun piti kokeilla tätä taas. 00:18:06.726 --> 00:18:10.936 Tämä toimi ainoastaan teknisesti, en saanut palkan korotusta. 00:18:13.664 --> 00:18:15.244 Mikä vaikutus tällä on? 00:18:15.295 --> 00:18:20.087 Voimme väärentää miljoonia domaineja, mutta ketkä hyväksyvät nämä sähköpostit? 00:18:20.325 --> 00:18:27.375 Jälleen Postfix ja Sendmail, mutta vain ne instanssit, jotka eivät hyväksy BDAT komentoa. 00:18:27.899 --> 00:18:31.079 BDAT on vaihtoehtoinen datakomennolle 00:18:31.269 --> 00:18:33.899 ja jos sitä tuetaan, tämä ei toimi. 00:18:35.777 --> 00:18:38.827 Se oli ulospäin SMTP suuntautuva ujutus, 00:18:39.081 --> 00:18:40.511 joka on yksi osa tätä. 00:18:40.610 --> 00:18:44.073 Sitten on myös sisäänpäin tuleva SMTP ujutus. 00:18:44.198 --> 00:18:48.391 Ulospäin suuntautuvassa ongelma oli lähettävä palvelin 00:18:48.687 --> 00:18:56.071 koska palvelin epäonnistui tai ei tehokkaasti suodattanut väärennettyä datan lopetussekvenssiä 00:18:56.164 --> 00:19:01.804 kuten <LF>.<CR><LF> Microsoftin ja GMX palveluissa. 00:19:02.808 --> 00:19:05.288 Sitten on lisäksi sisäänpäin tuleva SMTP ujutus. 00:19:05.377 --> 00:19:11.827 Tämä tapahtuu, kun on vastaanottava palvelin, joka tulkitsee sellaisen villin datan lopetussekvenssin, 00:19:12.307 --> 00:19:17.217 josta lähettävällä palvelimella ei ole hajuakaan suodattaa pois. 00:19:17.779 --> 00:19:25.129 Löysin tällaisen Cisco Securesta, tietysti, Email Cloud Gateway:sta 00:19:27.090 --> 00:19:37.632 Mitä he tekevät on se, että he siivoavat viestin ja <CR> merkki korvataan merkeillä. 00:19:38.048 --> 00:19:44.008 Joten itse asiassa, <CR>.<CR> merkkien tulkinta palauttaa datan lopetussekvenssin. 00:19:47.277 --> 00:19:51.277 [Yleisön applodeja] 00:19:54.955 --> 00:20:02.625 Ongelma on nyt siis tietenkin se, että <CR>.<CR> ei suodateta ollenkaan pois. 00:20:02.652 --> 00:20:08.542 On palveluita, jotka sen tekevät, mutta meillä on jälleen Exchange Online, iCloud, Sendmail, Postix 00:20:08.725 --> 00:20:11.800 ja monia muita, jotka päästävät tämän läpi. 00:20:11.990 --> 00:20:16.530 Tavallaan se käy järkeen, koska en hoksaisi sitä itsekään. 00:20:16.940 --> 00:20:20.650 Joten, minun täytyi kokeilla tätä jälleen. 00:20:22.240 --> 00:20:25.420 Valitettavasti, tai teknisesti, se toimi jälleen, 00:20:25.574 --> 00:20:28.348 mutta en saanut en saanut yhtään Applen laitetta. 00:20:28.418 --> 00:20:31.458 Ei sillä, että olisin halunnut muutenkaan. 00:20:35.025 --> 00:20:36.015 Mikä vaikutus tällä on? 00:20:36.091 --> 00:20:40.111 Pohjimmiltaan voimme väärentään vielä enemmän domaineja kuin edellä. 00:20:40.236 --> 00:20:43.636 Meillä on Exchange Online, meillä on iCloud, 00:20:43.818 --> 00:20:46.272 meillä on Postfix ja Sendmail. 00:20:46.372 --> 00:20:50.322 Ja voimme väärentää yrityksiä, joilla on vara tähän. 00:20:51.480 --> 00:20:53.678 Aika isoja yrityksiä tässä. 00:20:54.138 --> 00:20:58.008 Tämä pitää sisällää yli 40 tuhatta muuta domainia. 00:20:58.150 --> 00:21:01.020 Ja se on vain ne, jotka on hostattu pilvessä. 00:21:01.192 --> 00:21:05.062 Lisäksi on on-prem instanssit, mutta en pystynyt käymään niitä läpi. 00:21:06.998 --> 00:21:12.609 Ja nyt osuuteen, joka on luultavasti mielenkiintoisin teille, tai ainakin osalle teistä. 00:21:13.240 --> 00:21:16.230 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)