0:00:00.310,0:00:04.830 Translated by Mikko Heikkinen (ITKST56 course assignment at JYU.FI) 0:00:05.372,0:00:13.612 [Musiikkia] 0:00:14.212,0:00:18.212 OK. Seuraavaksi puhuu Timo Longin, 0:00:19.402,0:00:22.212 joka tunnetaan myös nimellä Timo Login. 0:00:22.324,0:00:27.264 Hän tietoturvakonsultti ja tutkija. Hän tulee puhumaan uudesta tekniikasta 0:00:27.578,0:00:29.778 nimeltään SMTP Smuggling, 0:00:29.943,0:00:32.343 jolla voidaan väärentää sähköposteja 0:00:32.426,0:00:34.276 ja hyväksikäyttää eräitä eniten käytettyjä palveluita internetissä. 0:00:34.317,0:00:37.207 Kiitos. Annetaan Timolle applodit. 0:00:37.641,0:00:41.641 [Applodeja] 0:00:43.181,0:00:45.111 Kiitos esittelystä. 0:00:45.111,0:00:49.811 Ensinnäkin, pulskat pahoittelut omasta ja SEC Consult:n puolesta 0:00:49.811,0:00:53.801 tämän katastrofaalisen haavoittuvuuden julkaisemisesta. 0:00:54.784,0:01:00.734 Erityisesti pahoittelut Wietselle ja Viktorille Postfixin korjaamisesta. 0:01:01.328,0:01:05.418 sekä kaikille järjestelmävalvojille ympäri maailman, 0:01:05.701,0:01:08.721 jotka ovat joutuneet asentamaan korjauksia joululoman aikana. 0:01:09.070,0:01:11.790 Ja lisäksi, joka tapauksessa, 0:01:12.284,0:01:15.954 suuret kiitokset Wietselle ja Viktorille 0:01:16.032,0:01:18.312 heidän sitoutumisestaan. 0:01:18.334,0:01:20.354 Ja lisäksi suuret kiitokset yhteisölle 0:01:20.411,0:01:25.373 tämän ongelman viemisestä julkaisujärjestelmiin ja niin edelleen. 0:01:25.563,0:01:27.843 Ja kaikille... Okei... 0:01:28.332,0:01:32.882 [Applodeja] 0:01:35.495,0:01:36.905 Ja kaikille niille, 0:01:37.007,0:01:39.067 joilla ei ole mitään hajua tästä. 0:01:39.129,0:01:41.729 Joten minäpä autan teidät samalle sivulle. 0:01:41.835,0:01:43.845 Noin vuosi sitten olin juuri 0:01:43.876,0:01:45.956 lopettanut tutkimukseni DNS:n parissa. 0:01:45.956,0:01:48.564 ja etsin uutta tutkimuskohdetta, 0:01:48.564,0:01:51.908 kun löysin todennäköisesti helpoimman 0:01:51.908,0:01:53.583 tavan hakkeroida yrityksen 0:01:53.583,0:01:55.562 ja kaikki tämä vain yhdellä 0:01:55.562,0:01:58.073 yksinkertaisella Google-haulla. 0:01:58.173,0:02:00.913 [Yleisön naurua] 0:02:00.913,0:02:03.571 Ja tämä saattaa kuulostaa tyhmälle, 0:02:03.585,0:02:05.735 mutta tämä johdatti minut suuntaan, 0:02:05.735,0:02:08.005 jonka jo tiesin, mutta en ollut ymmärtänyt. 0:02:08.005,0:02:11.125 Ja se on, että tietojen kalastelu on edelleen 0:02:11.166,0:02:14.076 numero 1 ensipääsyvektori yritykseen 0:02:14.400,0:02:16.290 ja sitten minulla välähti: 0:02:16.382,0:02:18.232 Miksen tutkisi SMTP:tä, 0:02:18.456,0:02:20.136 simple mail transfer protocol:aa 0:02:20.400,0:02:23.264 jota käytetään miljardien sähköpostien 0:02:23.357,0:02:25.435 lähettämiseen joka päivä ympäri maailman 0:02:25.455,0:02:27.215 kuten on tehty viimeisen 40 vuoden ajan. 0:02:27.285,0:02:29.815 Joten matkani eteni DNS:stä SMTP:hen 0:02:30.780,0:02:32.760 ja tänään esittelen uuden 0:02:32.773,0:02:34.963 SMTP Smuggling -tekniikan 0:02:35.009,0:02:37.329 sähköpostien väärentämiseksi. 0:02:37.329,0:02:39.689 Kuka olenkaan? OIen Timo Longin 0:02:39.832,0:02:41.674 ja työskentelen tietoturvakonsulttina 0:02:41.674,0:02:43.375 SEC Consult -yhtiössä ja 0:02:43.375,0:02:45.245 päivisin teen penetraatiotestausta 0:02:45.245,0:02:47.535 ja öisin teen haavoittuvuustutkimusta. 0:02:47.565,0:02:50.485 Ja viimeisen kolmen vuoden aikana olen 0:02:50.533,0:02:53.369 tutkinut paljon DNS-haavoittuvuuksia. 0:02:53.369,0:02:56.049 Ja olen julkaissut paljon blogikirjoituksia ja työkaluja. 0:02:56.257,0:02:59.007 Ja minun täytyi siirtyä eteenpäin. 0:02:59.207,0:03:03.207 Edellisen kerran, kun joku SEC Consult:sta puhui CCC:ssä... 0:03:05.093,0:03:06.913 se oli... dildoista. 0:03:07.393,0:03:08.883 [Yleisön naurua] 0:03:09.121,0:03:12.091 Ja tiedän, että joudun tuottamaan osalle 0:03:12.184,0:03:13.644 teistä pettymyksen, 0:03:13.644,0:03:14.920 mutta tämä esitys ei kerro 0:03:14.920,0:03:17.098 ihmiseen penetroitumisesta. 0:03:17.833,0:03:21.833 Esitys kertoo tunkeutumisesta SMTP-protokollan muurien läpi. 0:03:22.014,0:03:24.790 Joten nähdäksemme miten tämä toimii 0:03:24.790,0:03:26.646 on meidän ensin ymmärrettävä 0:03:26.646,0:03:29.017 miten sähköpostien lähetys yleensäkin toimii. 0:03:29.017,0:03:32.570 Joten tässä meillä on melko yksinkertainen sähköposti-infrastuktuuri. 0:03:32.604,0:03:34.864 Meillä on sähköpostikäyttäjäagentti, 0:03:34.864,0:03:38.484 kuten Thunderbird, ja Thunderbird haluaa lähettää sähköpostin 0:03:38.494,0:03:41.684 esimerkiksi käyttäjänä user@outlook.com. 0:03:41.684,0:03:44.344 Joten jos haluamme lähettää sähköpostin tällä tavalla 0:03:44.344,0:03:46.938 meidän täytyy ensin tunnistautua 0:03:46.938,0:03:49.637 Outlook mail transfer agentille tai 0:03:49.637,0:03:52.389 ulospäin menevälle SMTP palvelimelle. 0:03:52.407,0:03:54.877 Ja kun olemme tunnistautuneet, 0:03:54.877,0:03:59.134 voimme lähettää sähköpostin käyttäjänä user@outlook.com. 0:03:59.134,0:04:02.227 Ja vain käyttäjänä user@outlook.com. 0:04:02.227,0:04:05.697 Tämän jälkeen viesti siirretään vastaanottajan 0:04:05.807,0:04:08.977 SMTP-palvelimelle ja tämä palvelin 0:04:08.977,0:04:12.977 tarkistaa viestin aitouden. 0:04:12.977,0:04:16.977 Ja kaikkein yleisen tapa tehdä tämä on SPF. 0:04:16.997,0:04:20.997 Vastaanottava SMTP-palvelin saa SPF-tietueen 0:04:21.007,0:04:24.267 DNS-palvelun kautta outlook.com osoitteelle. 0:04:24.267,0:04:27.357 Ja tarkistaa sen jälkeen, että tämä IP-osoite 0:04:27.357,0:04:30.467 ja IP-alue on sallittu lähettää sähköpostiviestejä 0:04:30.467,0:04:31.807 outlook.com osoitteelle. 0:04:31.807,0:04:36.437 Tässä tapauksessa todellinen Outlook SMTP-palvelin 0:04:36.437,0:04:38.606 tai ulospäin lähtevä SMTP-palvelin lähetti viestin, 0:04:38.687,0:04:40.907 vastaanottava SMTP-palvelin 0:04:40.907,0:04:42.367 hyväksyy viestin. 0:04:42.367,0:04:44.907 Ja nyt luonnollisesti tässä on erittäin 0:04:44.907,0:04:46.307 mielenkiintoinen kysymys. 0:04:46.307,0:04:49.637 Ja kysymys on: onko hyökkääjän mahdollista 0:04:49.637,0:04:51.827 lähettää sähköpostiviesti 0:04:51.827,0:04:54.587 esimerkiksi osoitteesta admin@outlook.com tai 0:04:54.587,0:04:56.557 väärennetystä sähköpostiosoitteesta? 0:04:56.647,0:04:58.797 Tätä me selvitämme tänään 0:04:58.797,0:05:01.107 ja se on enemmän tai vähemmän 0:05:01.107,0:05:03.507 tämän tutkimuksen tavoitteista. 0:05:03.507,0:05:04.948 En tiedä oletteko huomanneet, 0:05:04.948,0:05:07.227 mutta näiden palvelimien värit 0:05:07.227,0:05:10.267 muistuttavat minusta Paavo Pesusieneä 0:05:10.267,0:05:11.937 ja Patrik Tähtöstä. 0:05:11.937,0:05:15.087 Ja sen vuoksi kutsumme niitä niiksi. 0:05:17.380,0:05:20.277 Tutkimuksen yleinen tavoite ja 0:05:20.277,0:05:23.417 tutkimuksen peruste oli löytää 0:05:23.417,0:05:24.657 tapa väärentää sähköposteja. 0:05:24.657,0:05:28.157 Ja ajattelin, että miksi en ottaisi haavoittuvuuksia 0:05:28.157,0:05:30.337 muista tekstipohjaisista protokollista, 0:05:30.337,0:05:34.347 kuten HTTP:stä, ja soveltaisi niitä SMTP:hen. 0:05:35.892,0:05:40.431 Ja oli yksi HTTP haavoittuvuus, joka sopi kuvaan 0:05:40.431,0:05:43.077 ja se oli HTTP-pyynnön käpelöinti. 0:05:43.077,0:05:48.157 Tässä meillä on taas Paavo ja Patrik, 0:05:48.157,0:05:50.737 mutta tällä kertaa HTTP-maailmassa. 0:05:50.737,0:05:57.610 Joten, mitä tässä tapahtuu? Paavo Pesusieni saa [br]POST-tyyppisen pyynnön internetin yli 0:05:57.610,0:06:04.687 Mielenkiintoista tässä pyynnössä on se, [br]että siinä on kaksi otsikkoa 0:06:04.687,0:06:08.627 kuinka käsitellä POST-pyynnön data. 0:06:08.647,0:06:11.547 Siinä on Content-Length -otsikko, jonka arvona [br]on 43 tavua. 0:06:11.547,0:06:14.617 Ja siinä on myös Transfer-Encoding -otsikko. 0:06:14.617,0:06:19.647 Nyt Paavo Pesusienen täytyy päättää,[br]miten käsittelen pyynnön ja Paavo päättää 0:06:19.647,0:06:25.047 käyttää Content-Length otsikkoa, koska se on[br]43 tavua. 0:06:25.477,0:06:29.477 Joten kaikki punaisella kehystetty data[br]on välitetty Patrikille. 0:06:29.477,0:06:35.187 Patrikilla ei ole mitään hajua mitä tehdä - pitäisikö[br]minun tulkita Content-Lenth otsikkoa vai 0:06:35.187,0:06:39.897 Transfer-Encoding -otsikko? Patrik päättää[br]tulkita Transfer-Encoding otsikkoa ja 0:06:39.897,0:06:41.896 nyt meillä on eriävät tulkinnat: 0:06:41.896,0:06:48.506 Paavo Pesusieni käyttää Content-Length -otsikkoa[br]ja Patrik Tähtönen käyttää Transfer-Encoding -otsikkoa. 0:06:48.506,0:06:52.606 Ja koska Transfer-Encoding on määritetty "chunked" ("paloiteltu") ja[br]ja ensimmäinen pala on 0, 0:06:52.606,0:06:58.256 on loput Paavo Pesusienen lähettämästä datasta [br]tulkittu toiseksi pyynnöksi. 0:06:58.546,0:07:04.486 Itse asiassa tämä tarkoittaa, että Paavo näkee[br]yhden pyynnön ja Patrik kaksi pyyntöä. 0:07:04.627,0:07:10.037 Ja toinen pyyntö voidaan kohdistaa mielivaltaiseen[br]resurssipolkuun, kuten "Admin", 0:07:10.297,0:07:14.118 joka tässä esimerkissä on avoin vain sisäisesti[br]palvelimella. 0:07:14.297,0:07:16.407 Joka on tietenkin ongelma. 0:07:16.407,0:07:20.047 Joten ajattelin, että miksi en ottaisi[br]näitä tulkintaeroja 0:07:20.047,0:07:21.477 ja laittaisi niitä SMTP:hen. 0:07:21.477,0:07:27.507 Ymmärtääksemme... tai ainakin päästäksemme[br]lähemmäs ymmärrystä miten tämä toimii, 0:07:27.507,0:07:31.097 täytyy meidän katsoa ensin itse SMTP[br]protokollaa. 0:07:31.097,0:07:34.377 Joten, SMTP näyttää kuta kuinkin tältä. 0:07:34.377,0:07:40.167 Meillä on kaksi komponenttia: SMTP komennot[br]punaisella ja sinisellä viestin data. 0:07:40.957,0:07:47.077 Lähettääksemme viestin, meidän tulee ensin[br]lähettää SMTP komennot: 0:07:47.637,0:07:53.167 Meidän pitää esitellä itsemme, kertoa lähettäjän[br]osoite, yksi tai useampi vastaanottajan osoite ja 0:07:53.167,0:07:59.347 sitten lähetämme "data" komennon [br]kertoaksemme vastaanottavalle SMTP-palvelimelle 0:08:00.428,0:08:03.127 että olemme nyt vastaanottamassa varsinaista[br]viestin dataa. 0:08:04.017,0:08:12.107 Ja sitten lähetämme viestin datan: määrittelemme[br]lähettäjän osoitteen uudelleen, vastaanottajan osoitteen[br]ja viestin aiheen.[br] 0:08:12.467,0:08:14.507 Ja sitten tulee viestin leipäteksti. 0:08:14.507,0:08:17.987 Ja kun jossain vaiheessa haluamme[br]lopettaa viestin datan lähettämisen, 0:08:17.987,0:08:21.987 meidän tulee lähettää jotain, jota kutsumme[br]datan lopetussekvensiksi. 0:08:22.247,0:08:27.397 Se on "<paluu rivin alkuun><rivinvaihto> piste <paluu rivin alkuun><rivinvaihto>" [br][kääntäjän kommentti: jatkossa .] 0:08:28.657,0:08:36.577 Tässä vaiheessa ajattelin, että ehkä voisimme[br]hämätä tällä jotenkin SMTP-palvelinten toteutuksia. 0:08:37.667,0:08:43.717 Ajatus oli siis, että meillä on jälleen Paavo Pesusieni[br]ja lähetämme sähköpostin Paavo Pesusienelle [SIC]. 0:08:45.507,0:08:48.847 Ja tämä sähköposti sisältää jotain[br]todella outoa, jotain joka näyttää 0:08:48.847,0:08:54.147 lopetussekvensille, mutta se ei ole sitä. 0:08:54.297,0:08:59.807 Koska se ei ole yhdenmukainen RFC:n kanssa, joku [br]voisi virheellisesti tulkita sen datan lopetussekvensiksi. 0:08:59.807,0:09:05.947 Joten Paavo Pesusieni katsoo tätä ja ajattelee[br]ettei tämä ole RFC:stä, en tulkitse tätä[br]"end-of-data" sekvensiksi 0:09:07.387,0:09:13.207 Ja seuraavaksi... tai viestin data siihen saakka,[br]kunnes varsinainen datan lopetussekvenssi tulee. 0:09:13.377,0:09:14.337 Sitten Paavo Pesusieni lähettää viestin Patrikille 0:09:14.577,0:09:15.527 Ja Patrik on "Jeah, en välitä mistään RFC:stä ja[br]ja tulkitsen väärän datan lopetussekvenssi 0:09:15.527,0:09:17.187 varsinaiseksi datan lopetusmerkiksi." 0:09:17.187,0:09:18.817 Ja ongelmaksi tässä tulee, että kaikki väärin [br]tulkitun lopetussekvenssin tulkitaan SMPT-komennoiksi 0:09:18.817,0:09:20.357 Ja nyt hyökkääjänä voimme luoda SMTP-komentoja,[br]jotka lähettävät toisen sähköpostiviestin. 0:09:20.357,0:09:22.017 Vaikka Paavo Pesusieni näki yhden ison[br]sähköpostiviestin, Patrik näkee kaksi pienempää viestiä. 0:09:22.017,0:09:26.017 Ja ongelma on se, että toinen viesti voi sisältää[br]mielivaltaisia SMTP-komentoja. 0:09:31.227,0:09:33.077 Kuten, että viesti tulee osoitteesta admin@outlook.com[br]tai mitä tahansa. 0:09:33.157,0:09:34.017 Näin ainakin teoriassa. 0:09:34.017,0:09:38.017 Nähdäkseni toimiiko tämä todella. 0:09:38.017,0:09:42.017 Tutkin muutamia SMTP-palvelinten [br]toteutuksia yksinkertaisesti 0:09:42.017,0:09:46.017 ottamalla niihin yhteyttä telnet:llä tai[br]netcat:lla. 0:09:46.017,0:09:50.017 Kun tein tämän, se näytti aluksi RFC:n mukaiselta. 0:09:50.017,0:09:54.017 Kun lähetät datakomennon, palvelin pyytää[br]lopettamaan datan lähettämisen . merkeillä. 9:59:59.000,9:59:59.000 Sitten löysin myös palvelimia, jotka sanoivat:[br]"lähetä minulla rivi, jossa on vain piste" 9:59:59.000,9:59:59.000 Ja tämä asia riippuu paljon käytettävästä [br]käyttöjärjestelmästä. 9:59:59.000,9:59:59.000 Windows:ssa tämä voi olla <CR><LF>.<CR><LF>[br]ja se voi olla . 9:59:59.000,9:59:59.000 Siinä kohtaa ajattelin, että tässä voisi[br]olla jotain. 9:59:59.000,9:59:59.000 Ja kokeilin jotain. 9:59:59.000,9:59:59.000 Ensimmäiseksi kokeilin työntää <CR>-, <LF>- ja piste-[br]merkkejä Paavo Pesusienen kautta. 9:59:59.000,9:59:59.000 Joten kirjoitin SMTP analyysisovelluksen, joka[br]lähettää virheellisiä data lopetussekvenssejä, 9:59:59.000,9:59:59.000 kuten <LF>.<LF> Ja lähetin viestejä eri SMTP-[br]ohjelmistoilla, 9:59:59.000,9:59:59.000 sisältäen sähköpostipalveluita Gmail, Outlook, GMX 9:59:59.000,9:59:59.000 ja lisäksi sähköpostiohjelmistoja kuten Postfix,[br]Exim, Microsoft Exchange Server ja niin edelleen. 9:59:59.000,9:59:59.000 Vastaanottavalla puolella tutkin, että mitkä[br]vääristä sekvensseistä menee itse asiassa läpi. 9:59:59.000,9:59:59.000 Voinko lähettää komennon <LF>.<LF> lähtevän palvelimen [br]kautta? 9:59:59.000,9:59:59.000 Ja useimmissa tapauksissa se ei toiminut. 9:59:59.000,9:59:59.000 <LF>.<LF> on usein suodatettu tai poistettu[br]alkuperäisestä viestistä. 9:59:59.000,9:59:59.000 Mutta jossain tapauksissa se menee läpi muuttumattomana. 9:59:59.000,9:59:59.000 Tämä oli tilanne GMX:n kohdalla. Lähetin sähköpostin[br]GMX:stä analyysipalvelimelleni 9:59:59.000,9:59:59.000 ja <LF>.<CR><LF> merkkejä ei poistettu. 9:59:59.000,9:59:59.000 Seuraavaksi tein proof-of-concept:n, jossa on[br]väärennetty datan lopetussekvenssi 9:59:59.000,9:59:59.000 ja sen jälkeen toinen sähköpostiviesti. 9:59:59.000,9:59:59.000 Jos tämä proof-of-concept toimii, 9:59:59.000,9:59:59.000 meidän pitäisi saada kaksi viestiä [br]vastaanottajan puolella. 9:59:59.000,9:59:59.000 Lähetin tämän kaiken Gmailiin. 9:59:59.000,9:59:59.000 Ja Gmail oli sitä mieltä, [br]että "tämä ei ei ole datan lopetussekvenssi". 9:59:59.000,9:59:59.000 Ja sen näkee siitä, että datan lopetussekvenssin[br]jälkeen kaikki on edelleen tulkittu viestin dataksi. 9:59:59.000,9:59:59.000 Mutta joissain tapauksissä tämä itse asiassa toimi. 9:59:59.000,9:59:59.000 Tämä oli ensimmäinen onnistunut [br]SMTP Smuggling tapaus, GMX:stä Fastmail:iin. 9:59:59.000,9:59:59.000 Me näemme, että se toimii. Meillä on ensin [br]viesti käyttäjältä user@gmx.net 9:59:59.000,9:59:59.000 ja toinen viesti käyttäjältä admin@gmx.net, 9:59:59.000,9:59:59.000 jotka läpäisevät SPF ja DMARC tarkistukset,[br]koska ne tulevat GMX:n palvelimelta. 9:59:59.000,9:59:59.000 [Applodeja] 9:59:59.000,9:59:59.000 Minä olin, että "tämä on aivan sairasta!" 9:59:59.000,9:59:59.000 Ajattelin, että meillä on tämä toinen viesti [br]ja siinä voi olla mitä tahansa. 9:59:59.000,9:59:59.000 Kuten lähettäjän osoite voi olla mitä vaan. 9:59:59.000,9:59:59.000 Joten miksi en kokeilisi muita domaineja,[br]jotka osoittavat GMX:n palvelimeen? 9:59:59.000,9:59:59.000 Sitten analysoin SPF tietueen ja tajusin... 9:59:59.000,9:59:59.000 Tässä on GMX:n SPF-tietue, mutta se on hyvin[br]samankaltainen web.de:n tietueen, joka puolestaan 9:59:59.000,9:59:59.000 on hyvin samankaltainen Ionoksen tietueen kanssa. 9:59:59.000,9:59:59.000 Ja jeah, tilanne on nyt se, että tällä me voimme[br]väärentää 1.35 miljoonaa domainia. 9:59:59.000,9:59:59.000 Jos ette tiedä mikä Ionos on, niin se on superiso [br]hosting- ja sähköpostipalveluiden tarjoaja. 9:59:59.000,9:59:59.000 Ja heillä on nämä 1.35 miljoonaa domainia[br]kytketty tähän. 9:59:59.000,9:59:59.000 Joten, minun täytyi tietenkin kokeilla tätä. 9:59:59.000,9:59:59.000 Tässä on sähköposti osoitteesta admin@web.de 9:59:59.000,9:59:59.000 Nyt kysymys on tietysti, että toimiiko[br]tämä kaikkialla? 9:59:59.000,9:59:59.000 Kuten sanoin, niin tämä palvelimilla,[br]jotka tulkitsevat lopetussekvenssit 9:59:59.000,9:59:59.000 tavalla, joka ei ole RFC:n mukainen,[br]kuten . 9:59:59.000,9:59:59.000 Voimme siis väärentää 1.35 miljoonaa domainia. 9:59:59.000,9:59:59.000 Joten pohjimmiltaan meillä on 1.4 miljoonaa Postifix instansia[br]ja 150 tuhatta Sendmail instanssia. 9:59:59.000,9:59:59.000 Ja tämä toimii, koska ne tulkitsevat... 9:59:59.000,9:59:59.000 [puhuja sekoilee sanoissaan] 9:59:59.000,9:59:59.000 Ne tulkitsevat <LF>.<CR><LF>, sekoilen itsekin sanoissani,[br]lopetussekvensiksi. 9:59:59.000,9:59:59.000 Ja olin, että OK, tämä on aika vakavaa. 9:59:59.000,9:59:59.000 Mutta tässä on muutakin. 9:59:59.000,9:59:59.000 Katsoin outlook.comia myös ja Outlook[br]palautti todella oudon virheilmoituksen 9:59:59.000,9:59:59.000 koska siinä on, että pelkät rivinvaihdot[br]eivät ole sallittuja. 9:59:59.000,9:59:59.000 Olin siinä kohtaa, että pahus, ne tietää[br]mitä olen tekemässä. 9:59:59.000,9:59:59.000 [Yleisöän naurua] 9:59:59.000,9:59:59.000 Siksi analysoin sen tarkemmin, ette pysty[br]minua tuolla pelottelemaan. 9:59:59.000,9:59:59.000 Joten löysin, että <LF>.<CR><LF> [br]on mahdollinen täällä. 9:59:59.000,9:59:59.000 [Yleisön applodeja] 9:59:59.000,9:59:59.000 Jeah, pidetään vähän hauskaa. 9:59:59.000,9:59:59.000 Tässä kohtaa en ollut varma, että[br]olenko tulossa hulluksi 9:59:59.000,9:59:59.000 vai toimiiko tämä todella. 9:59:59.000,9:59:59.000 Joten tarvitsin jonkinlaisen tarkistuksen. 9:59:59.000,9:59:59.000 Ja niinpä lähetin sähköpostin[br]osoitteesta admin@outlook.com 9:59:59.000,9:59:59.000 yhdelle kollegoistani. Idea oli siinä,[br]että jos he reagoivat tähän, 9:59:59.000,9:59:59.000 se toimii, muutoin olen tullut hulluksi. 9:59:59.000,9:59:59.000 Joten.... 9:59:59.000,9:59:59.000 [Yleisön naurua] 9:59:59.000,9:59:59.000 Ja ehkä nyt hieman kansainvälisempi esimerkki,[br]koska tämä on todella itävaltalainen, luulen. 9:59:59.000,9:59:59.000 Luulen, että ymmärrätte tämän, vaikka ette[br]puhu saksaa. 9:59:59.000,9:59:59.000 Ja nyt olette, okei, voimme lähettää[br]tekstipohjaisia, väärennettyjä sähköposteja 9:59:59.000,9:59:59.000 mutta ette pysty huijaamaan tällä ketään 9:59:59.000,9:59:59.000 Mutta juttu on siinä, että voimme ujuttaa [br]periaatteessa mitä tahansa, HTML mukaan luettuna 9:59:59.000,9:59:59.000 Tässä lähetin viestin, kalasteluviestin, [br]epätavallisesta kirjautumisesta 9:59:59.000,9:59:59.000 osoitteesta no-reply@outlook.com 9:59:59.000,9:59:59.000 todelliselta outlook.com palvelimelta itselleni. 9:59:59.000,9:59:59.000 Ja se vain meni läpi. 9:59:59.000,9:59:59.000 Mutta mitä tämä mahdollistaa? 9:59:59.000,9:59:59.000 Pohdiskelin, että voimme väärentää[br]outlook.comin, mutta mitä muuta voimme tehdä tällä? 9:59:59.000,9:59:59.000 Katsoin SPF tietuetta ja se oli outo, [br]oudosti tuttu. koska tämä ei ole 9:59:59.000,9:59:59.000 pelkästään outlook.comin SPF tietue 9:59:59.000,9:59:59.000 vaan miljoonien muiden domainien SPF tietue. 9:59:59.000,9:59:59.000 Sen vuoksi, koska tämä Exchange Online[br]palvelun SPF tietue. 9:59:59.000,9:59:59.000 Outlook.com lähettää sähköpostit Exchange Online[br]infrastruktuurin kautta, 9:59:59.000,9:59:59.000 joten voimme itse asiassa väärentää ne kaikki. 9:59:59.000,9:59:59.000 Minun piti kokeilla tätä taas. 9:59:59.000,9:59:59.000 Tämä toimi ainoastaan teknisesti,[br]en saanut palkan korotusta. 9:59:59.000,9:59:59.000 Mikä vaikutus tällä on? 9:59:59.000,9:59:59.000 Voimme väärentää miljoonia domaineja, [br]mutta ketkä hyväksyvät nämä sähköpostit? 9:59:59.000,9:59:59.000 Jälleen Postfix ja Sendmail, mutta vain ne[br]instanssit, jotka eivät hyväksy BDAT komentoa. 9:59:59.000,9:59:59.000 BDAT on vaihtoehtoinen datakomennolle 9:59:59.000,9:59:59.000 ja jos sitä tuetaan, tämä ei toimi. 9:59:59.000,9:59:59.000 Se oli ulospäin suuntautuva ujutus,[br]joka on yksi osa tätä. 9:59:59.000,9:59:59.000 Sitten on myös sisäänpäin tuleva[br]SMTP ujutus. 9:59:59.000,9:59:59.000 Ulospäin suuntautuvassa ongelma oli[br]lähettävä palvelin 9:59:59.000,9:59:59.000 koska palvelin epäonnistui tai ei tehokkaasti[br]suodattanut väärennettyä datan lopetusekvenssiä 9:59:59.000,9:59:59.000 kuten <LF>.<CR><LF> Microsoftinh ja [br]GMX palveluissa. 9:59:59.000,9:59:59.000 Sitten on lisäksi sisäänpäin tuleva SMTP ujutus. 9:59:59.000,9:59:59.000 Tämä tapahtuu, kun on vastaanottava palvelin, [br]joka tulkitsee sellaisen villin datan lopetussekvenssin, 9:59:59.000,9:59:59.000 josta lähettävällä palvelimella ei ole hajuakaan [br]suodattaa pois. 9:59:59.000,9:59:59.000 Löysin tällaisen Cisco Securesta, tietysti, Email Cloud Gateway:sta 9:59:59.000,9:59:59.000 Mitä he tekevät on, ett'ähe siivoavat viestin ja <CR> merkki[br]korvataan merkeillä. 9:59:59.000,9:59:59.000 Joten itse asiassa, <CR>.<CR> merkkien tulkinta[br]palauttaa datan lopetussekvenssin. 9:59:59.000,9:59:59.000 [Yleisön applodeja] 9:59:59.000,9:59:59.000 Ongelma on nyt siis tietenkin se, että <CR>.<CR> [br]ei suodateta ollenkaan pois. 9:59:59.000,9:59:59.000 On palveluita, jotka sen tekevät, mutta meillä[br]on jälleen Exchange Online, iCloud, Sendmail, Postix 9:59:59.000,9:59:59.000 ja monia muita, jotka päästävät tämän läpi. 9:59:59.000,9:59:59.000 Tavallaan se käy järkeen, koska en hoksaisi [br]sitä itsekään. 9:59:59.000,9:59:59.000 Joten, minun täytyi kokeilla tätä jälleen. 9:59:59.000,9:59:59.000 Valitettavasti, tai teknisesti, se toimi jälleen, 9:59:59.000,9:59:59.000 mutta en saanut en saanut yhtään Applen laitetta. 9:59:59.000,9:59:59.000 Ei sillä, että olisin halunnut muutenkaan. 9:59:59.000,9:59:59.000 Mikä vaikutus tällä on? 9:59:59.000,9:59:59.000 Pohjimmiltaan voimme väärentään vielä [br]enemmän domaineja kuin edellä. 9:59:59.000,9:59:59.000 Meillä on Exchange Online, meillä on iCloud, 9:59:59.000,9:59:59.000 meillä on Postfix ja Sendmail. 9:59:59.000,9:59:59.000 Ja voimme väärentää yrityksiä, joilla on[br]vara tähän - aika isoja yrityksiä tässä. 9:59:59.000,9:59:59.000 Tämä pitää sisällää yli 40 tuhatta muuta domainia. 9:59:59.000,9:59:59.000 Ja se on vain ne, jotka on hostattu pilvessä. 9:59:59.000,9:59:59.000 Lisäksi on on-prem instanssit, mutta en pystynyt[br]käymään niitä läpi. 9:59:59.000,9:59:59.000 Ja nyt osuuteen, joka on luultavasti mielenkiintoisin teille,[br]tai ainakin osalle teistä. 9:59:59.000,9:59:59.000 Vastuullinen julkaisu. 9:59:59.000,9:59:59.000 Puhtaasti teknisesti, koskien lähettäviä ja [br]vastaanottavia palvelimia, kenen vika tämä on? 9:59:59.000,9:59:59.000 Meillä on vastaanottavia palvelimia, joiden ei [br]koskaan oleteta tulkitsevan mitään muita 9:59:59.000,9:59:59.000 datan lopetussekvenssejä kuin <CR><LF>.<CR><LF>,[br]ainkin RFC:n mukaan. 9:59:59.000,9:59:59.000 Sitten meillä on lähettäviä palvelimia, joiden [br]ei oleteta lähettävän ja merkkejä 9:59:59.000,9:59:59.000 toisistaan riippumatta. 9:59:59.000,9:59:59.000 Joten lopulta tämän on kaikkien vika. 9:59:59.000,9:59:59.000 Lähetimme tämän tiedon GMX:lle. 9:59:59.000,9:59:59.000 He olivat superkiitollisia ja ilmoittivat[br]korjaavansa asian saman tien. 9:59:59.000,9:59:59.000 10 päivää myöhemmin he korjasivat tämän. 9:59:59.000,9:59:59.000 He pyysivät meitä tarkastamaan uudelleen ja [br]tarkastimme, että he todella korjasivat sen. 9:59:59.000,9:59:59.000 He maksoivat meille pienen palkkion. 9:59:59.000,9:59:59.000 Ha laittoivat meidät jopa heidän[br]Bug Bounty Hall of Fame:en. 9:59:59.000,9:59:59.000 Kaiken kaikkiaan se oli 10/10 kokemus. 9:59:59.000,9:59:59.000 [Applodeja] 9:59:59.000,9:59:59.000 Aion lähettää heille tallenteen teidän applodeista. Kiitos! 9:59:59.000,9:59:59.000 Tuntui melkein sille, että meidän olisi pitänyt[br]maksaa palkkio heille. 9:59:59.000,9:59:59.000 Tästä eteenpäin mennäänkin sitten alamäkeä. 9:59:59.000,9:59:59.000 Meillä on Microsoft. Microsoft oli sitä mieltä,[br]että tämä on kohtuullisen riskin haavoittuvuus. 9:59:59.000,9:59:59.000 En tiedä, ehkä heillä on suurempi kala kiikarissa,[br]mutta joka tapauksessa. 9:59:59.000,9:59:59.000 Lähetimme tiedot heille ja kolme kuukautta[br]myöhemmin he sulkivat tapauksen ja sanoivat, 9:59:59.000,9:59:59.000 että kaikki on korjattu, ei palkkiota ja niin edelleen. 9:59:59.000,9:59:59.000 Tässä kohtaa olin saanut jo mitä halusin. 9:59:59.000,9:59:59.000 Ja se on sähköpostin saaminen osoitteesta[br]admin@microsoft.com 9:59:59.000,9:59:59.000 Ja sitten Ciscoon. 9:59:59.000,9:59:59.000 Ciscon mielestä tämä ei ollut haavoittuvuus, 9:59:59.000,9:59:59.000 vaan dokumentoitu ja konfiguroitava ominaisuus. 9:59:59.000,9:59:59.000 Me olimme sitä mieltä, että onpa outo[br]ominaisuus, 9:59:59.000,9:59:59.000 koska voimme väärentää sähköposteja sillä. 9:59:59.000,9:59:59.000 Sanoimme, että kertokaa edes asiakkaillenne[br]tästä ominaisuudesta, 9:59:59.000,9:59:59.000 joka ei välttämättä ole paras oletustoiminallisuus. 9:59:59.000,9:59:59.000 He sanoivat "Ei". 9:59:59.000,9:59:59.000 Me olimme siinä, että meillä on tämä[br]suuri SMTP Smuggling ongelma. 9:59:59.000,9:59:59.000 Ja Cisco ei halua tehdä mitään, Microsoft[br]oli haavoittuvainen. 9:59:59.000,9:59:59.000 Me veimme tämän tapauksen CERT/CC:lle. 9:59:59.000,9:59:59.000 Niille, jotka eivät tiedä, CERT/CC koordinoi [br]ja käsittelee näitä suuria haavoittuvuuksia, 9:59:59.000,9:59:59.000 joilla voi olla maailmanlaajuisia vaikutuksia. 9:59:59.000,9:59:59.000 Me lähetimme tiedot heille ja he itse asiassa[br]hyväksyivät tapauksen. 9:59:59.000,9:59:59.000 Sitten olemme tässä Vince portaalissa. 9:59:59.000,9:59:59.000 Joka on periaatteessa iso chat-huone, jossa [br]14 toimittajaa. 9:59:59.000,9:59:59.000 Siellä on Microsoft, SendMail, Cisco, Google 9:59:59.000,9:59:59.000 Ja sitten voimme alkaa puhumaan haavoittuvuudesta 9:59:59.000,9:59:59.000 Ensimmäisessä keskustelussa Cisco sanoo[br]edelleen, että kyseessä ei ole haavoittuvuus. 9:59:59.000,9:59:59.000 Tiedättehän, se ei ole bugi, vaan ominaisuus. 9:59:59.000,9:59:59.000 Noh, joka tapauksessa se ei ole bugi heidän[br]mielestään. 9:59:59.000,9:59:59.000 Ja sitten CERT/CC on sitä mieltä, että[br]kyseessä ei ole haavoittuvuus, jostain syystä. 9:59:59.000,9:59:59.000 Kuinkas yleinen SMTP ujutusongelma? 9:59:59.000,9:59:59.000 Entäs Postfixin ja Sendmailin RFC:stä eriävät[br]tulkinnat datan lopetussekvenssistä?[br] 9:59:59.000,9:59:59.000 Ensinnäkin, Sendmail oli tässä Vince portaalissa[br]alusta alkaen. 9:59:59.000,9:59:59.000 He saivat kaikki PoC:t, viestit, kaiken. 9:59:59.000,9:59:59.000 Ja he eivät sanoneet mitään. 9:59:59.000,9:59:59.000 Entäpä Postfix? He ovat 10 kertaa suurempi. 9:59:59.000,9:59:59.000 CERT/CC oli... en tiedä miksi he eivät[br]lisänneet heitä tapaukseen suoraan. 9:59:59.000,9:59:59.000 Mutta CERT/CC lähetti heille sähköpostin, mutta[br]unohti mainita SMTP ujutuksen. 9:59:59.000,9:59:59.000 Luulimme siis, että he kertoivat Postfixille,. Sendmailia[br]ei nähtävästi kiinnostanut. CERT/CC on Ciscon puolella asiassa. 9:59:59.000,9:59:59.000 Me olimme, että Cisco on taatusti haavoittuvainen,[br]olimme varmistaneet sen. 9:59:59.000,9:59:59.000 Joten haluaisimme julkistaa tämän blogissa. 9:59:59.000,9:59:59.000 Ja tästä ongelmat vasta alkoivatkin. 9:59:59.000,9:59:59.000 Kerroimme, että haluaisimme julkaista tästä[br]blogikirjoituksen ja varoittaisimme Ciscon asiakkaita 9:59:59.000,9:59:59.000 tästä haavoittuvuudesta. 9:59:59.000,9:59:59.000 CERT/CC oli sitä mieltä, että "Antaa mennä vaan![br]Lähettäkää meille linkki kirjoitukseen, kun se on julkaistu" 9:59:59.000,9:59:59.000 Päätimme edetä ja tulimme avanneeksi Pandoran[br]laatikon, koska nyt 1.6 miljoonaan Postfix ja Sendmail 9:59:59.000,9:59:59.000 instanssia ovat haavoittuvina internetissä. 9:59:59.000,9:59:59.000 Ja se tarkoittaa, että jos tapahtuu ulospäin suuntautuva[br]SMTP ujuttelu, niin voit hyväksikäyttää Postfixiä ja Sendmailia yhä. 9:59:59.000,9:59:59.000 Tarkoittaako tämä, ettei SEC Consultissa ole yhtään vikaa? 9:59:59.000,9:59:59.000 Totta kai SEC Consultissa on vikaa. 9:59:59.000,9:59:59.000 Julkaisimme blogikirjoituksen olettaen, että[br]vaikutus olisi pienempi kuin se todellisuudessa oli 9:59:59.000,9:59:59.000 perustuen keskesteluihin CERT/CC:n kanssa ja [br]VINCE:ssä muutenkin. 9:59:59.000,9:59:59.000 Ja jos olisimme vain tuplavarmistaneet Postfixin[br]kanssa, että julkaisu ei ole ongelma, tätä ei olisi tapahtunut, 9:59:59.000,9:59:59.000 koska he ovat järkkymättämiä, että tämä on ongelma. 9:59:59.000,9:59:59.000 Yhteenveto, mitä tämä tarkoittaa? 9:59:59.000,9:59:59.000 Korjatkaa Postfix palvelimenne! Löydätte lisätietoja[br]Postfixin nettisivuilta. 9:59:59.000,9:59:59.000 Lisäksi korjatkaa Cisco palvelimenne. Voitte löytää[br]lisätietoja siitä SEC Consult:n blogista. 9:59:59.000,9:59:59.000 [Yleisön naurua ja aplodit] 9:59:59.000,9:59:59.000 Lopuksi, tässäkin pilvessä on jonkinlainen hopeareunus. 9:59:59.000,9:59:59.000 Nyt Postfix on suoraan mukana VINCE tapauksessa 9:59:59.000,9:59:59.000 ja he ovat jo antaneet suuren panoksen. 9:59:59.000,9:59:59.000 Emme työnnä päätämme pensaaseen ja yritä[br]aktiivisesti sulkea Pandoran lipasta jälleen. 9:59:59.000,9:59:59.000 Ja mitä se tarkoittaa? Lisää tutkimusta SMTP ujuttelusta 9:59:59.000,9:59:59.000 Tarkoitan, että pyysin CERT/CC:tä katsomaan tätä [br]tarkemmin, niin, se ei päättynyt kovin hyvin. 9:59:59.000,9:59:59.000 Lisää blogikirjoituksia, lisää tutkimusta ja [br]ennen kaikkea lisää toimijoita VINCE tapaukseen. 9:59:59.000,9:59:59.000 Yritämme saada kaiken korjattua ja olemme pahoillamme,[br]että tämä tapahtui ylipäätään. 9:59:59.000,9:59:59.000 Lopuksi jotain, jonka kaikki tiedätte. Älkää[br]luottako sähköposteihinn sokeasti, erityisesti tällä hetkellä. 9:59:59.000,9:59:59.000 Kiitos. 9:59:59.000,9:59:59.000 [Aplodeja] 9:59:59.000,9:59:59.000 Hienoa, mennään kysymyksiin. 9:59:59.000,9:59:59.000 Ole hyvä. 9:59:59.000,9:59:59.000 Hei, minulla on yksi lyhyt kysymys CERT/CC asiasta. 9:59:59.000,9:59:59.000 Oliko tämä kommunikoitu sähköpostilla? 9:59:59.000,9:59:59.000 Ja etkö olisi voinut lähettää viestin viestin [br]Ciscon CDO:na? 9:59:59.000,9:59:59.000 Kyllä, olisimme voineet tehdä sen ja luoda [br]jonkinlaisen kolmiodraamaan 9:59:59.000,9:59:59.000 Bill Gatesin, Elon Muskin ja jonkun muun välille. 9:59:59.000,9:59:59.000 Mutta valitettavasti emme nähneet tätä sähköpostia. 9:59:59.000,9:59:59.000 Näimme sen jälkeen päin, mutta se oli valitettavasti[br]liian myöhäistä. 9:59:59.000,9:59:59.000 Hei, kiitos teille. Arvostan työtänne. 9:59:59.000,9:59:59.000 Voisitko kertoa hieman aikajanasta? 9:59:59.000,9:59:59.000 Koska löysitte tämän ensimmäisen kerran? 9:59:59.000,9:59:59.000 Aloitin tutkimuksen kesäkuussa kuluvana vuonna 9:59:59.000,9:59:59.000 Minulla oli 10 päivän projekti SEC Consultilla. 9:59:59.000,9:59:59.000 Olin sitä mieltä, että 10 päivää ei riitä, joten[br]aloitin 10 päivää aiemmin. 9:59:59.000,9:59:59.000 Sitten löysin SMTP ujuttelun kuudentena päivänä 9:59:59.000,9:59:59.000 Sitten asia eteni kertomalla GMX:lle, Outlookille[br]tai Microsoftille ja Ciscolle 9:59:59.000,9:59:59.000 koska heillä oli vakavat SMTP ujuttelutapaukset, [br]koskien sekä lähtevää ja saapuvaa. 9:59:59.000,9:59:59.000 Sitten jatkoimme ja kerroimme CERT/CC:lle, koska[br]tämä vaikutti olevan laajempi ongelma maailmanlaajuisesti. 9:59:59.000,9:59:59.000 Aikataulumielessä, minulla ei ole sitä tässä nyt,[br]mutta se on SEC Consultin blogikirjoituksessa. 9:59:59.000,9:59:59.000 Onko joku tietty päivämäärä, jonka haluat tietää? 9:59:59.000,9:59:59.000 Ei, ei. Käyn lukemassa blogikirjoituksen. Kiitos. 9:59:59.000,9:59:59.000 Hei, kiitos hyvästä puheesta täällä. 9:59:59.000,9:59:59.000 Haluaisin kysyä, että on mitään evidenssiä 9:59:59.000,9:59:59.000 tai epäilyksiä, että tätä olisi jo käytetty? 9:59:59.000,9:59:59.000 Tämä näyttää melko yksinkertaiselta[br]haavoittuvuudelta hyödyntää. 9:59:59.000,9:59:59.000 Voisin kuvitella, että sitä on jo hyödynnetty. 9:59:59.000,9:59:59.000 Jeah, sain joitain kommentteja Reddit postaukseeni 9:59:59.000,9:59:59.000 että tämä on supervanha,[br]mutta asia on... 9:59:59.000,9:59:59.000 Kohtalainen haavoittuvuus 9:59:59.000,9:59:59.000 Jeah, todennäköisesti 9:59:59.000,9:59:59.000 Ei, en tosiaankaan tiedä. 9:59:59.000,9:59:59.000 Kävin läpi paljon tutkimuksia, mutta niissä[br]ei ollut mitään. 9:59:59.000,9:59:59.000 Siksi kutsun tätä uudeksi haavoittuvuudeksi. 9:59:59.000,9:59:59.000 Translated by Mikko Heikkinen (ITKST56 course assignment at JYU.FI)