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 Postfixin korjaamisesta. 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:15,954 suuret kiitokset Wietselle ja Viktorille 19 00:01:16,032 --> 00:01:18,312 heidän sitoutumisestaan. 20 00:01:18,334 --> 00:01:20,354 Ja lisäksi suuret kiitokset yhteisölle 21 00:01:20,411 --> 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:36,905 Ja kaikille niille, 25 00:01:37,007 --> 00:01:39,067 joilla ei ole mitään hajua tästä. 26 00:01:39,129 --> 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:45,956 lopettanut tutkimukseni DNS:n parissa. 29 00:01:45,956 --> 00:01:48,564 ja etsin uutta tutkimuskohdetta, 30 00:01:48,564 --> 00:01:51,908 kun löysin todennäköisesti helpoimman 31 00:01:51,908 --> 00:01:53,583 tavan hakkeroida yrityksen 32 00:01:53,583 --> 00:01:55,562 ja kaikki tämä vain yhdellä 33 00:01:55,562 --> 00:01:58,073 yksinkertaisella Google-haulla. 34 00:01:58,173 --> 00:02:00,913 [Yleisön naurua] 35 00:02:00,913 --> 00:02:03,571 Ja tämä saattaa kuulostaa tyhmälle, 36 00:02:03,585 --> 00:02:05,735 mutta tämä johdatti minut suuntaan, 37 00:02:05,735 --> 00:02:08,005 jonka jo tiesin, mutta en ollut ymmärtänyt. 38 00:02:08,005 --> 00:02:11,125 Ja se on, että tietojen kalastelu on edelleen 39 00:02:11,166 --> 00:02:14,076 numero 1 ensipääsyvektori yritykseen 40 00:02:14,400 --> 00:02:16,290 ja sitten minulla välähti: 41 00:02:16,382 --> 00:02:18,232 Miksen tutkisi SMTP:tä, 42 00:02:18,456 --> 00:02:20,136 simple mail transfer protocol:aa 43 00:02:20,400 --> 00:02:23,264 jota käytetään miljardien sähköpostien 44 00:02:23,357 --> 00:02:25,435 lähettämiseen joka päivä ympäri maailman 45 00:02:25,455 --> 00:02:27,215 kuten on tehty viimeisen 40 vuoden ajan. 46 00:02:27,285 --> 00:02:29,815 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,329 sähköpostien väärentämiseksi. 50 00:02:37,329 --> 00:02:39,689 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:14,920 mutta tämä esitys ei kerro 65 00:03:14,920 --> 00:03:17,098 ihmiseen penetroitumisesta. 66 00:03:17,833 --> 00:03:21,833 Esitys kertoo tunkeutumisesta SMTP-protokollan muurien läpi. 67 00:03:22,014 --> 00:03:24,790 Joten nähdäksemme miten tämä toimii 68 00:03:24,790 --> 00:03:26,646 on meidän ensin ymmärrettävä 69 00:03:26,646 --> 00:03:29,017 miten sähköpostien lähetys yleensäkin toimii. 70 00:03:29,017 --> 00:03:32,570 Joten tässä meillä on melko yksinkertainen sähköposti-infrastuktuuri. 71 00:03:32,604 --> 00:03:34,864 Meillä on sähköpostikäyttäjäagentti, 72 00:03:34,864 --> 00:03:38,484 kuten Thunderbird, ja Thunderbird haluaa lähettää sähköpostin 73 00:03:38,494 --> 00:03:41,684 esimerkiksi käyttäjänä user@outlook.com. 74 00:03:41,684 --> 00:03:44,344 Joten jos haluamme lähettää sähköpostin tällä tavalla 75 00:03:44,344 --> 00:03:46,938 meidän täytyy ensin tunnistautua 76 00:03:46,938 --> 00:03:49,637 Outlook mail transfer agentille tai 77 00:03:49,637 --> 00:03:52,389 ulospäin menevälle SMTP palvelimelle. 78 00:03:52,407 --> 00:03:54,877 Ja kun olemme tunnistautuneet, 79 00:03:54,877 --> 00:03:59,134 voimme lähettää sähköpostin käyttäjänä user@outlook.com. 80 00:03:59,134 --> 00:04:02,227 Ja vain käyttäjänä user@outlook.com. 81 00:04:02,227 --> 00:04:05,697 Tämän jälkeen viesti siirretään vastaanottajan 82 00:04:05,807 --> 00:04:08,977 SMTP-palvelimelle ja tämä palvelin 83 00:04:08,977 --> 00:04:12,977 tarkistaa viestin aitouden. 84 00:04:12,977 --> 00:04:16,977 Ja kaikkein yleisen tapa tehdä tämä on SPF. 85 00:04:16,997 --> 00:04:20,997 Vastaanottava SMTP-palvelin saa SPF-tietueen 86 00:04:21,007 --> 00:04:24,267 DNS-palvelun kautta outlook.com osoitteelle. 87 00:04:24,267 --> 00:04:27,357 Ja tarkistaa sen jälkeen, että tämä IP-osoite 88 00:04:27,357 --> 00:04:30,467 ja IP-alue on sallittu lähettää sähköpostiviestejä 89 00:04:30,467 --> 00:04:31,807 outlook.com osoitteelle. 90 00:04:31,807 --> 00:04:36,437 Tässä tapauksessa todellinen Outlook SMTP-palvelin 91 00:04:36,437 --> 00:04:38,606 tai ulospäin lähtevä SMTP-palvelin lähetti viestin, 92 00:04:38,687 --> 00:04:40,907 vastaanottava SMTP-palvelin 93 00:04:40,907 --> 00:04:42,367 hyväksyy viestin. 94 00:04:42,367 --> 00:04:44,907 Ja nyt luonnollisesti tässä on erittäin 95 00:04:44,907 --> 00:04:46,307 mielenkiintoinen kysymys. 96 00:04:46,307 --> 00:04:49,637 Ja kysymys on: onko hyökkääjän mahdollista 97 00:04:49,637 --> 00:04:51,827 lähettää sähköpostiviesti 98 00:04:51,827 --> 00:04:54,587 esimerkiksi osoitteesta admin@outlook.com tai 99 00:04:54,587 --> 00:04:56,557 väärennetystä sähköpostiosoitteesta? 100 00:04:56,647 --> 00:04:58,797 Tätä me selvitämme tänään 101 00:04:58,797 --> 00:05:01,107 ja se on enemmän tai vähemmän 102 00:05:01,107 --> 00:05:03,507 tämän tutkimuksen tavoitteista. 103 00:05:03,507 --> 00:05:04,948 En tiedä oletteko huomanneet, 104 00:05:04,948 --> 00:05:07,227 mutta näiden palvelimien värit 105 00:05:07,227 --> 00:05:10,267 muistuttavat minusta Paavo Pesusieneä 106 00:05:10,267 --> 00:05:11,937 ja Patrik Tähtöstä. 107 00:05:11,937 --> 00:05:15,087 Ja sen vuoksi kutsumme niitä niiksi. 108 00:05:17,380 --> 00:05:20,277 Tutkimuksen yleinen tavoite ja 109 00:05:20,277 --> 00:05:23,417 tutkimuksen peruste oli löytää 110 00:05:23,417 --> 00:05:24,657 tapa väärentää sähköposteja. 111 00:05:24,657 --> 00:05:28,157 Ja ajattelin, että miksi en ottaisi haavoittuvuuksia 112 00:05:28,157 --> 00:05:30,337 muista tekstipohjaisista protokollista, 113 00:05:30,337 --> 00:05:34,347 kuten HTTP:stä, ja soveltaisi niitä SMTP:hen. 114 00:05:35,892 --> 00:05:40,431 Ja oli yksi HTTP haavoittuvuus, joka sopi kuvaan 115 00:05:40,431 --> 00:05:43,077 ja se oli HTTP-pyynnön käpelöinti. 116 00:05:43,077 --> 00:05:48,157 Tässä meillä on taas Paavo ja Patrik, 117 00:05:48,157 --> 00:05:50,737 mutta tällä kertaa HTTP-maailmassa. 118 00:05:50,737 --> 00:05:57,610 Joten, mitä tässä tapahtuu? Paavo Pesusieni saa POST-tyyppisen pyynnön internetin yli 119 00:05:57,610 --> 00:06:04,687 Mielenkiintoista tässä pyynnössä on se, että siinä on kaksi otsikkoa 120 00:06:04,687 --> 00:06:08,627 kuinka käsitellä POST-pyynnön data. 121 00:06:08,647 --> 00:06:11,547 Siinä on Content-Length -otsikko, jonka arvona on 43 tavua. 122 00:06:11,547 --> 00:06:14,617 Ja siinä on myös Transfer-Encoding -otsikko. 123 00:06:14,617 --> 00:06:19,647 Nyt Paavo Pesusienen täytyy päättää, miten käsittelen pyynnön ja Paavo päättää 124 00:06:19,647 --> 00:06:25,047 käyttää Content-Length otsikkoa, koska se on 43 tavua. 125 00:06:25,477 --> 00:06:29,477 Joten kaikki punaisella kehystetty data on välitetty Patrikille. 126 00:06:29,477 --> 00:06:35,187 Patrikilla ei ole mitään hajua mitä tehdä - pitäisikö minun tulkita Content-Lenth otsikkoa vai 127 00:06:35,187 --> 00:06:39,897 Transfer-Encoding -otsikko? Patrik päättää tulkita Transfer-Encoding otsikkoa ja 128 00:06:39,897 --> 00:06:41,896 nyt meillä on eriävät tulkinnat: 129 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. 130 00:06:48,506 --> 00:06:52,606 Ja koska Transfer-Encoding on määritetty "chunked" ("paloiteltu") ja ja ensimmäinen pala on 0, 131 00:06:52,606 --> 00:06:58,256 on loput Paavo Pesusienen lähettämästä datasta tulkittu toiseksi pyynnöksi. 132 00:06:58,546 --> 00:07:04,486 Itse asiassa tämä tarkoittaa, että Paavo näkee yhden pyynnön ja Patrik kaksi pyyntöä. 133 00:07:04,627 --> 00:07:10,037 Ja toinen pyyntö voidaan kohdistaa mielivaltaiseen resurssipolkuun, kuten "Admin", 134 00:07:10,297 --> 00:07:14,118 joka tässä esimerkissä on avoin vain sisäisesti palvelimella. 135 00:07:14,297 --> 00:07:16,407 Joka on tietenkin ongelma. 136 00:07:16,407 --> 00:07:20,047 Joten ajattelin, että miksi en ottaisi näitä tulkintaeroja 137 00:07:20,047 --> 00:07:21,477 ja laittaisi niitä SMTP:hen. 138 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, 139 00:07:27,507 --> 00:07:31,097 täytyy meidän katsoa ensin itse SMTP protokollaa. 140 00:07:31,097 --> 00:07:34,377 Joten, SMTP näyttää kuta kuinkin tältä. 141 00:07:34,377 --> 00:07:40,167 Meillä on kaksi komponenttia: SMTP komennot punaisella ja sinisellä viestin data. 142 00:07:40,957 --> 00:07:47,077 Lähettääksemme viestin, meidän tulee ensin lähettää SMTP komennot: 143 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 144 00:07:53,167 --> 00:07:59,347 sitten lähetämme "data" komennon kertoaksemme vastaanottavalle SMTP-palvelimelle 145 00:08:00,428 --> 00:08:03,127 että olemme nyt vastaanottamassa varsinaista viestin dataa. 146 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. 147 00:08:12,467 --> 00:08:14,507 Ja sitten tulee viestin leipäteksti. 148 00:08:14,507 --> 00:08:17,987 Ja kun jossain vaiheessa haluamme lopettaa viestin datan lähettämisen, 149 00:08:17,987 --> 00:08:21,987 meidän tulee lähettää jotain, jota kutsumme datan lopetussekvensiksi. 150 00:08:22,247 --> 00:08:27,397 Se on " piste " [kääntäjän kommentti: jatkossa .] 151 00:08:28,657 --> 00:08:36,577 Tässä vaiheessa ajattelin, että ehkä voisimme hämätä tällä jotenkin SMTP-palvelinten toteutuksia. 152 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]. 153 00:08:45,507 --> 00:08:48,847 Ja tämä sähköposti sisältää jotain todella outoa, jotain joka näyttää 154 00:08:48,847 --> 00:08:54,147 lopetussekvensille, mutta se ei ole sitä. 155 00:08:54,297 --> 00:08:59,807 Koska se ei ole yhdenmukainen RFC:n kanssa, joku voisi virheellisesti tulkita sen datan lopetussekvensiksi. 156 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 157 00:09:07,387 --> 00:09:15,830 Ja seuraavaksi... tai viestin data siihen saakka, kunnes varsinainen datan lopetussekvenssi tulee. 158 00:09:16,257 --> 00:09:18,594 Sitten Paavo Pesusieni lähettää viestin Patrikille 159 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 160 00:09:26,497 --> 00:09:29,647 varsinaiseksi datan lopetusmerkiksi." 161 00:09:29,947 --> 00:09:36,907 Ja ongelmaksi tässä tulee, että kaikki väärin tulkitun lopetussekvenssin tulkitaan SMTP-komennoiksi 162 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. 163 00:09:44,737 --> 00:09:51,377 Vaikka Paavo Pesusieni näki yhden ison sähköpostiviestin, Patrik näkee kaksi pienempää viestiä. 164 00:09:51,477 --> 00:09:56,258 Ja ongelma on se, että toinen viesti voi sisältää mielivaltaisia SMTP-komentoja. 165 00:09:56,358 --> 00:10:00,508 Kuten, että viesti tulee osoitteesta admin@outlook.com tai mitä tahansa. 166 00:10:01,697 --> 00:10:05,447 Näin ainakin teoriassa. 167 00:10:05,687 --> 00:10:07,887 Nähdäkseni toimiiko tämä todella. 168 00:10:09,067 --> 00:10:13,557 Tutkin muutamia SMTP-palvelinten toteutuksia yksinkertaisesti 169 00:10:13,587 --> 00:10:17,077 ottamalla niihin yhteyttä telnet:llä tai netcat:lla. 170 00:10:18,679 --> 00:10:23,919 Kun tein tämän, se näytti aluksi RFC:n mukaiselta. 171 00:10:23,979 --> 00:10:32,189 Kun lähetät datakomennon, palvelin pyytää lopettamaan datan lähettämisen . merkeillä. 172 00:10:32,649 --> 00:10:38,749 Sitten löysin myös palvelimia, jotka sanoivat: "lähetä minulla rivi, jossa on vain piste" 173 00:10:39,005 --> 00:10:45,625 Ja tämä asia riippuu paljon käytettävästä käyttöjärjestelmästä. 174 00:10:45,914 --> 00:10:54,314 Windows:ssa tämä voi olla . ja Linuxissa se voi olla . 175 00:10:54,819 --> 00:11:00,059 Siinä kohtaa ajattelin, että tässä voisi olla jotain. 176 00:11:00,669 --> 00:11:02,059 Ja kokeilin jotain. 177 00:11:02,062 --> 00:11:11,552 Ensimmäiseksi kokeilin työntää -, - ja piste- merkkejä Paavo Pesusienen kautta. 178 00:11:11,794 --> 00:11:18,744 Joten kirjoitin SMTP analyysisovelluksen, joka lähettää sähköposteja, joissa on virheellisiä data lopetussekvenssejä, 179 00:11:19,041 --> 00:11:23,631 kuten . Ja lähetin viestejä eri SMTP- ohjelmistoilla, 180 00:11:24,043 --> 00:11:29,203 sisältäen sähköpostipalveluita Gmail, Outlook, GMX 181 00:11:29,383 --> 00:11:35,193 ja lisäksi sähköpostiohjelmistoja kuten Postfix, Exim, Microsoft Exchange Server ja niin edelleen. 182 00:11:36,500 --> 00:11:44,420 Vastaanottavalla puolella tutkin, että mitkä vääristä sekvensseistä menee itse asiassa läpi. 183 00:11:44,644 --> 00:11:50,924 Voinko lähettää komennon . lähtevän palvelimen kautta? 184 00:11:51,211 --> 00:11:53,986 Ja useimmissa tapauksissa se ei toiminut. 185 00:11:54,326 --> 00:11:58,956 . on usein suodatettu tai poistettu alkuperäisestä viestistä. 186 00:11:59,298 --> 00:12:05,318 Mutta jossain tapauksissa se menee läpi muuttumattomana. 187 00:12:05,539 --> 00:12:12,319 Tämä oli tilanne GMX:n kohdalla. Lähetin sähköpostin GMX:stä analyysipalvelimelleni 188 00:12:12,499 --> 00:12:16,499 ja . merkkejä ei poistettu. 189 00:12:16,732 --> 00:12:23,562 Seuraavaksi tein proof-of-concept:n, jossa on ensin viesti 190 00:12:23,703 --> 00:12:26,403 ja sitten väärennetty datan lopetussekvenssi 191 00:12:26,505 --> 00:12:30,405 ja sen jälkeen SMTP komentoja ja data toiselle sähköpostiviestille. 192 00:12:30,589 --> 00:12:33,149 Jos tämä proof-of-concept toimii, 193 00:12:33,363 --> 00:12:37,393 meidän pitäisi saada kaksi viestiä vastaanottajan puolella. 194 00:12:37,625 --> 00:12:40,135 Lähetin tämän kaiken Gmailiin. 195 00:12:40,265 --> 00:12:43,275 Ja Gmail oli sitä mieltä, että "tämä ei ei ole datan lopetussekvenssi". 196 00:12:43,703 --> 00:12:49,353 Ja sen näkee siitä, että datan lopetussekvenssin jälkeen kaikki on edelleen tulkittu viestin dataksi. 197 00:12:49,984 --> 00:12:54,244 Mutta joissain tapauksissä tämä itse asiassa toimi. 198 00:12:54,389 --> 00:13:01,204 Tämä oli ensimmäinen onnistunut SMTP Smuggling tapaus, GMX:stä Fastmail:iin. 199 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 200 00:13:06,772 --> 00:13:11,312 ja toinen viesti käyttäjältä admin@gmx.net, 201 00:13:11,451 --> 00:13:18,151 jotka läpäisevät SPF ja DMARC tarkistukset, koska ne tulevat todelliselta GMX:n palvelimelta. 202 00:13:18,639 --> 00:13:26,119 [Applodeja] 203 00:13:28,313 --> 00:13:31,873 Minä olin, että "tämä on aivan sairasta!" 204 00:13:34,762 --> 00:13:37,942 Ajattelin, että meillä on tämä toinen viesti ja siinä voi olla mitä tahansa. 205 00:13:38,128 --> 00:13:40,228 Kuten lähettäjän osoite voi olla mitä vaan. 206 00:13:40,356 --> 00:13:46,718 Joten miksi en kokeilisi muita domaineja, jotka osoittavat GMX:n palvelimeen? 207 00:13:47,160 --> 00:13:50,260 Sitten analysoin SPF tietueen ja tajusin... 208 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 209 00:13:59,791 --> 00:14:03,121 on hyvin samankaltainen Ionoksen tietueen kanssa. 210 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ä. 211 00:14:09,031 --> 00:14:15,631 Jos ette tiedä mikä Ionos on, niin se on superiso hosting- ja sähköpostipalveluiden tarjoaja. 212 00:14:15,774 --> 00:14:20,414 Ja heillä on nämä 1.35 miljoonaa domainia kytketty tähän. 213 00:14:20,581 --> 00:14:24,461 Joten, minun täytyi tietenkin kokeilla tätä. 214 00:14:24,993 --> 00:14:28,773 Tässä on sähköposti osoitteesta admin@web.de 215 00:14:28,918 --> 00:14:32,787 Nyt kysymys on tietysti, että toimiiko tämä kaikkialla? 216 00:14:33,058 --> 00:14:38,398 Kuten sanoin, niin tämä toimii vain palvelimilla, jotka tulkitsevat lopetussekvenssit 217 00:14:38,752 --> 00:14:42,672 tavalla, joka ei ole RFC:n mukainen, kuten . 218 00:14:42,943 --> 00:14:46,833 Voimme siis väärentää 1.35 miljoonaa domainia. 219 00:14:47,043 --> 00:14:56,293 Joten pohjimmiltaan meillä on 1.4 miljoonaa Postifix instansia ja 150 tuhatta Sendmail instanssia. 220 00:14:56,712 --> 00:14:59,832 Ja tämä toimii, koska ne tulkitsevat... 221 00:15:00,194 --> 00:15:02,044 [puhuja sekoilee sanoissaan] 222 00:15:02,571 --> 00:15:06,676 Ne tulkitsevat ., sekoilen itsekin sanoissani, lopetussekvensiksi. 223 00:15:07,026 --> 00:15:10,146 Ja olin, että OK, tämä on aika vakavaa. 224 00:15:10,502 --> 00:15:12,692 Mutta tässä on muutakin. 225 00:15:12,864 --> 00:15:18,314 Katsoin outlook.comia myös ja Outlook palautti todella oudon virheilmoituksen 226 00:15:18,693 --> 00:15:22,933 koska siinä on, että pelkät rivinvaihdot eivät ole sallittuja. 227 00:15:23,329 --> 00:15:26,869 Olin siinä kohtaa, että pahus, ne tietää mitä olen tekemässä. 228 00:15:26,913 --> 00:15:29,390 [Yleisöän naurua] 229 00:15:29,790 --> 00:15:33,710 Siksi analysoin sen tarkemmin, ette pysty minua tuolla pelottelemaan. 230 00:15:34,406 --> 00:15:39,526 Joten löysin, että . on mahdollinen täällä. 231 00:15:39,772 --> 00:15:44,052 [Yleisön applodeja] 232 00:15:49,043 --> 00:15:51,663 Jeah, pidetään vähän hauskaa. 233 00:15:51,734 --> 00:15:54,774 Tässä kohtaa en ollut varma, että olenko tulossa hulluksi 234 00:15:54,912 --> 00:15:57,002 vai toimiiko tämä todella. 235 00:15:57,341 --> 00:15:59,771 Joten tarvitsin jonkinlaisen tarkistuksen. 236 00:15:59,937 --> 00:16:02,607 Ja niinpä lähetin sähköpostin osoitteesta admin@outlook.com 237 00:16:02,882 --> 00:16:07,232 muutamille kollegoilleni. Idea oli siinä, että jos he reagoivat tähän, 238 00:16:07,646 --> 00:16:08,746 se toimii. 239 00:16:09,035 --> 00:16:10,935 Muutoin olen tullut hulluksi. 240 00:16:11,101 --> 00:16:13,341 Joten.... 241 00:16:13,859 --> 00:16:17,359 [Yleisön naurua] 242 00:16:17,561 --> 00:16:23,211 Ja ehkä nyt hieman kansainvälisempi esimerkki, koska tämä on todella itävaltalainen, luulen. 243 00:16:30,657 --> 00:16:34,257 Luulen, että ymmärrätte tämän, vaikka ette puhu saksaa. 244 00:16:35,321 --> 00:16:39,701 Ja nyt olette, okei, voimme lähettää tekstipohjaisia, väärennettyjä sähköposteja 245 00:16:40,048 --> 00:16:42,598 mutta ette pysty huijaamaan tällä ketään 246 00:16:42,776 --> 00:16:45,866 Mutta juttu on siinä, että voimme ujuttaa periaatteessa mitä tahansa, 247 00:16:45,986 --> 00:16:46,986 HTML:ää mukaan luettuna 248 00:16:47,856 --> 00:16:53,628 Tässä lähetin viestin, kalasteluviestin, epätavallisesta kirjautumisesta 249 00:16:53,968 --> 00:16:58,138 osoitteesta no-reply@outlook.com todelliselta outlook.com palvelimelta 250 00:16:59,005 --> 00:17:00,329 itselleni. 251 00:17:00,469 --> 00:17:02,509 Ja se vain meni läpi. 252 00:17:04,622 --> 00:17:08,342 Mutta jälleen, mitä tämä mahdollistaa? 253 00:17:09,085 --> 00:17:13,085 Pohdiskelin, että voimme väärentää outlook.comin, 254 00:17:13,454 --> 00:17:16,167 mutta mitä muuta voimme tehdä tällä? 255 00:17:16,192 --> 00:17:22,552 Katsoin SPF tietuetta ja se oli outo, oudosti tuttu. 256 00:17:22,792 --> 00:17:26,792 Koska tämä ei ole pelkästään outlook.comin SPF tietue 257 00:17:26,985 --> 00:17:31,105 vaan miljoonien muiden domainien SPF tietue. 258 00:17:31,537 --> 00:17:37,777 Sen vuoksi, koska tämä Exchange Online palvelun SPF tietue. 259 00:17:39,297 --> 00:17:44,707 Outlook.com lähettää sähköpostit Exchange Online infrastruktuurin kautta, 260 00:17:45,262 --> 00:17:49,202 joten voimme itse asiassa väärentää ne kaikki. 261 00:17:49,423 --> 00:17:53,313 Minun piti kokeilla tätä taas. 262 00:18:06,726 --> 00:18:10,936 Tämä toimi ainoastaan teknisesti, en saanut palkan korotusta. 263 00:18:13,664 --> 00:18:15,244 Mikä vaikutus tällä on? 264 00:18:15,295 --> 00:18:20,087 Voimme väärentää miljoonia domaineja, mutta ketkä hyväksyvät nämä sähköpostit? 265 00:18:20,325 --> 00:18:27,375 Jälleen Postfix ja Sendmail, mutta vain ne instanssit, jotka eivät hyväksy BDAT komentoa. 266 00:18:27,899 --> 00:18:31,079 BDAT on vaihtoehtoinen datakomennolle 267 00:18:31,269 --> 00:18:33,899 ja jos sitä tuetaan, tämä ei toimi. 268 00:18:35,777 --> 00:18:38,827 Se oli ulospäin SMTP suuntautuva ujutus, 269 00:18:39,081 --> 00:18:40,511 joka on yksi osa tätä. 270 00:18:40,610 --> 00:18:44,073 Sitten on myös sisäänpäin tuleva SMTP ujutus. 271 00:18:44,198 --> 00:18:48,391 Ulospäin suuntautuvassa ongelma oli lähettävä palvelin 272 00:18:48,687 --> 00:18:56,071 koska palvelin epäonnistui tai ei tehokkaasti suodattanut väärennettyä datan lopetussekvenssiä 273 00:18:56,164 --> 00:19:01,804 kuten . Microsoftin ja GMX palveluissa. 274 00:19:02,808 --> 00:19:05,288 Sitten on lisäksi sisäänpäin tuleva SMTP ujutus. 275 00:19:05,377 --> 00:19:11,827 Tämä tapahtuu, kun on vastaanottava palvelin, joka tulkitsee sellaisen villin datan lopetussekvenssin, 276 00:19:12,307 --> 00:19:17,217 josta lähettävällä palvelimella ei ole hajuakaan suodattaa pois. 277 00:19:17,779 --> 00:19:25,129 Löysin tällaisen Cisco Securesta, tietysti, Email Cloud Gateway:sta 278 00:19:27,090 --> 00:19:37,632 Mitä he tekevät on se, että he siivoavat viestin ja merkki korvataan merkeillä. 279 00:19:38,048 --> 00:19:44,008 Joten itse asiassa, . merkkien tulkinta palauttaa datan lopetussekvenssin. 280 00:19:47,277 --> 00:19:51,277 [Yleisön applodeja] 281 00:19:54,955 --> 00:20:02,625 Ongelma on nyt siis tietenkin se, että . ei suodateta ollenkaan pois. 282 00:20:02,652 --> 00:20:08,542 On palveluita, jotka sen tekevät, mutta meillä on jälleen Exchange Online, iCloud, Sendmail, Postix 283 00:20:08,725 --> 00:20:11,800 ja monia muita, jotka päästävät tämän läpi. 284 00:20:11,990 --> 00:20:16,530 Tavallaan se käy järkeen, koska en hoksaisi sitä itsekään. 285 00:20:16,940 --> 00:20:20,650 Joten, minun täytyi kokeilla tätä jälleen. 286 00:20:22,240 --> 00:20:25,420 Valitettavasti, tai teknisesti, se toimi jälleen, 287 00:20:25,574 --> 00:20:28,348 mutta en saanut en saanut yhtään Applen laitetta. 288 00:20:28,418 --> 00:20:31,458 Ei sillä, että olisin halunnut muutenkaan. 289 00:20:35,025 --> 00:20:36,015 Mikä vaikutus tällä on? 290 00:20:36,091 --> 00:20:40,111 Pohjimmiltaan voimme väärentään vielä enemmän domaineja kuin edellä. 291 00:20:40,236 --> 00:20:43,636 Meillä on Exchange Online, meillä on iCloud, 292 00:20:43,818 --> 00:20:46,272 meillä on Postfix ja Sendmail. 293 00:20:46,372 --> 00:20:50,322 Ja voimme väärentää yrityksiä, joilla on vara tähän. 294 00:20:51,480 --> 00:20:53,678 Aika isoja yrityksiä tässä. 295 00:20:54,138 --> 00:20:58,008 Tämä pitää sisällää yli 40 tuhatta muuta domainia. 296 00:20:58,150 --> 00:21:01,020 Ja se on vain ne, jotka on hostattu pilvessä. 297 00:21:01,192 --> 00:21:05,062 Lisäksi on on-prem instanssit, mutta en pystynyt käymään niitä läpi. 298 00:21:06,998 --> 00:21:12,609 Ja nyt osuuteen, joka on luultavasti mielenkiintoisin teille, tai ainakin osalle teistä. 299 00:21:13,240 --> 00:21:15,300 Vastuullinen julkaisu. 300 00:21:15,620 --> 00:21:22,620 Puhtaasti teknisesti, koskien lähettäviä ja vastaanottavia palvelimia, kenen vika tämä on? 301 00:21:22,811 --> 00:21:27,891 Meillä on vastaanottavia palvelimia, joiden ei koskaan oleteta tulkitsevan mitään muita 302 00:21:28,056 --> 00:21:33,616 datan lopetussekvenssejä kuin ., ainakin RFC:n mukaan. 303 00:21:34,216 --> 00:21:40,266 Sitten meillä on lähettäviä palvelimia, joiden ei oleteta lähettävän ja merkkejä 304 00:21:40,428 --> 00:21:42,178 toisistaan riippumatta. 305 00:21:42,263 --> 00:21:44,263 Joten periaatteessa tämä on kaikkien vika. 306 00:21:44,292 --> 00:21:46,072 Lähetimme tiedot GMX:lle. 307 00:21:46,132 --> 00:21:50,500 He olivat superkiitollisia ja ilmoittivat korjaavansa asian saman tien. 308 00:21:50,600 --> 00:21:53,680 10 päivää myöhemmin he korjasivat tämän. 309 00:21:53,792 --> 00:21:57,939 He pyysivät meitä tarkastamaan uudelleen ja tarkastimme, että he todella korjasivat sen. 310 00:21:58,089 --> 00:22:00,779 He maksoivat meille pienen palkkion. 311 00:22:00,858 --> 00:22:03,678 Ha laittoivat meidät jopa heidän Bug Bounty Hall of Fame:en. 312 00:22:03,813 --> 00:22:07,673 Kaiken kaikkiaan se oli 10/10 kokemus. 313 00:22:07,956 --> 00:22:11,956 [Applodeja] 314 00:22:15,782 --> 00:22:19,692 Aion lähettää heille tallenteen teidän applodeista. Kiitos! 315 00:22:19,751 --> 00:22:24,191 Tuntui melkein sille, että meidän olisi pitänyt maksaa palkkio heille. 316 00:22:25,219 --> 00:22:29,069 Tästä eteenpäin mennäänkin sitten alamäkeä. 317 00:22:29,398 --> 00:22:35,108 Meillä on Microsoft. Microsoft oli sitä mieltä, että tämä on kohtuullisen riskin haavoittuvuus. 318 00:22:39,079 --> 00:22:43,079 En tiedä, ehkä heillä on suurempi kala kiikarissa, mutta joka tapauksessa. 319 00:22:46,132 --> 00:22:50,132 Lähetimme tiedot heille ja kolme kuukautta myöhemmin he sulkivat tapauksen ja sanoivat, 320 00:22:50,281 --> 00:22:54,221 että kaikki on korjattu, ei palkkiota ja niin edelleen. 321 00:22:54,328 --> 00:22:58,328 Tässä kohtaa olin saanut jo mitä halusin. 322 00:22:58,527 --> 00:23:02,527 Ja se on sähköpostin saaminen osoitteesta admin@microsoft.com 323 00:23:05,310 --> 00:23:07,895 Ja sitten Ciscoon. 324 00:23:07,952 --> 00:23:11,052 Ciscon mielestä tämä ei ollut haavoittuvuus, 325 00:23:11,206 --> 00:23:14,766 vaan dokumentoitu ja konfiguroitava ominaisuus. 326 00:23:26,741 --> 00:23:29,961 Me olimme sitä mieltä, että onpa outo ominaisuus, 327 00:23:30,901 --> 00:23:34,481 koska voimme väärentää sähköposteja sillä. 328 00:23:35,540 --> 00:23:39,540 Sanoimme, että kertokaa edes asiakkaillenne tästä ominaisuudesta, 329 00:23:39,667 --> 00:23:43,547 joka ei välttämättä ole paras oletustoiminallisuus. 330 00:23:45,471 --> 00:23:49,651 He sanoivat "Ei". 331 00:23:50,318 --> 00:23:54,618 Me olimme siinä, että meillä on tämä suuri SMTP Smuggling ongelma. 332 00:23:54,738 --> 00:23:59,248 Ja Cisco ei halua tehdä mitään, Microsoft oli haavoittuvainen siihen aikaan. 333 00:23:59,490 --> 00:24:03,097 Me veimme tämän tapauksen CERT/CC:lle. 334 00:24:03,289 --> 00:24:09,079 Niille, jotka eivät tiedä, CERT/CC koordinoi ja käsittelee näitä suuria haavoittuvuuksia, 335 00:24:09,187 --> 00:24:12,107 joilla voi olla maailmanlaajuisia vaikutuksia. 336 00:24:12,157 --> 00:24:16,097 Me lähetimme tiedot heille ja he itse asiassa hyväksyivät tapauksen. 337 00:24:16,273 --> 00:24:19,543 Sitten olemme tässä Vince portaalissa. 338 00:24:19,664 --> 00:24:23,004 Joka on periaatteessa iso chat-huone, jossa on 14 toimittajaa. 339 00:24:23,138 --> 00:24:27,208 Siellä on SendMail, Microsoft, Cisco, Google 340 00:24:28,415 --> 00:24:31,645 Ja sitten voimme alkaa puhumaan haavoittuvuudesta 341 00:24:31,824 --> 00:24:36,427 Ensimmäisessä keskustelussa Cisco sanoo edelleen, että kyseessä ei ole haavoittuvuus. 342 00:24:36,877 --> 00:24:40,697 Tiedättehän, se ei ole bugi, vaan ominaisuus. 343 00:24:40,890 --> 00:24:44,120 Noh, joka tapauksessa se ei ole haavoittuvuus heidän mielestään. 344 00:24:44,228 --> 00:24:48,868 Ja sitten CERT/CC on sitä mieltä, että kyseessä ei ole haavoittuvuus, jostain syystä. 345 00:24:49,246 --> 00:24:54,126 OK. Entäs yleinen SMTP ujutusongelma? 346 00:24:54,310 --> 00:24:59,536 Entäs Postfixin ja Sendmailin RFC:stä eriävät tulkinnat datan lopetussekvenssistä? 347 00:25:01,636 --> 00:25:05,636 Ensinnäkin, Sendmail oli tässä Vince portaalissa alusta alkaen. 348 00:25:05,846 --> 00:25:10,942 He saivat kaikki PoC:t, viestit, kaiken. 349 00:25:11,372 --> 00:25:15,372 Ja he eivät sanoneet mitään. 350 00:25:16,299 --> 00:25:19,589 Entäpä Postfix? He ovat 10 kertaa suurempi. 351 00:25:20,366 --> 00:25:25,387 CERT/CC oli... en tiedä miksi he eivät lisänneet heitä tapaukseen suoraan. 352 00:25:25,457 --> 00:25:31,053 Mutta CERT/CC lähetti heille sähköpostin, mutta unohti mainita SMTP ujutuksen. 353 00:25:31,263 --> 00:25:36,799 Luulimme siis, että he kertoivat Postfixille. 354 00:25:37,178 --> 00:25:40,198 Sendmailia ei nähtävästi kiinnostanut. 355 00:25:40,299 --> 00:25:43,139 CERT/CC on Ciscon puolella asiassa. 356 00:25:44,416 --> 00:25:49,927 Me olimme, että Cisco on taatusti haavoittuvainen, olimme varmistaneet sen. 357 00:25:50,147 --> 00:25:52,887 Joten haluaisimme julkistaa tämän blogissa. 358 00:25:52,988 --> 00:25:55,758 Ja tästä ongelmat vasta alkoivatkin. 359 00:25:55,980 --> 00:26:00,062 Kerroimme, että haluaisimme julkaista tästä blogikirjoituksen 360 00:26:00,148 --> 00:26:03,962 ja varoittaisimme Ciscon asiakkaita tästä ominaisuudesta. 361 00:26:04,082 --> 00:26:11,412 CERT/CC oli sitä mieltä, että "Antaa mennä vaan! Lähettäkää meille linkki kirjoitukseen, kun se on julkaistu" 362 00:26:13,849 --> 00:26:18,971 Päätimme edetä ja tulimme avanneeksi Pandoran laatikon, 363 00:26:19,381 --> 00:26:24,081 koska nyt 1.6 miljoonaan Postfix ja Sendmail 364 00:26:24,349 --> 00:26:27,279 instanssia ovat haavoittuvina internetissä. 365 00:26:27,366 --> 00:26:30,886 Ja se tarkoittaa, että jos tapahtuu ulospäin suuntautuva SMTP ujuttelu, 366 00:26:31,004 --> 00:26:35,004 niin voit hyväksikäyttää Postfixiä ja Sendmailia yhä. 367 00:26:35,912 --> 00:26:38,968 Tarkoittaako tämä, ettei SEC Consultissa ole yhtään vikaa? 368 00:26:39,098 --> 00:26:41,168 Totta kai SEC Consultissa on vikaa. 369 00:26:41,231 --> 00:26:47,388 Julkaisimme blogikirjoituksen olettaen, että vaikutus olisi pienempi kuin se todellisuudessa oli 370 00:26:47,515 --> 00:26:51,895 perustuen keskesteluihin CERT/CC:n kanssa ja VINCE:ssä muutenkin. 371 00:26:52,095 --> 00:26:59,770 Ja jos olisimme vain tuplavarmistaneet Postfixin kanssa, että julkaisu ei ole ongelma, tätä ei olisi tapahtunut, 372 00:26:59,990 --> 00:27:04,580 koska he ovat järkkymättämiä, että tämä on ongelma. 373 00:27:06,265 --> 00:27:08,385 Yhteenveto, mitä tämä tarkoittaa? 374 00:27:08,493 --> 00:27:13,578 Korjatkaa Postfix palvelimenne! Löydätte lisätietoja Postfixin nettisivuilta. 375 00:27:13,748 --> 00:27:19,458 Lisäksi korjatkaa Cisco palvelimenne. Voitte löytää lisätietoja siitä SEC Consult:n blogista. 376 00:27:19,868 --> 00:27:23,868 [Yleisön naurua ja aplodit] 377 00:27:31,288 --> 00:27:35,288 Lopuksi, tässäkin pilvessä on jonkinlainen hopeareunus. 378 00:27:35,853 --> 00:27:39,853 Nyt Postfix on suoraan mukana VINCE tapauksessa 379 00:27:40,002 --> 00:27:42,378 ja he ovat jo antaneet suuren panoksen. 380 00:27:42,598 --> 00:27:47,215 Emme työnnä päätämme pensaaseen ja yritä aktiivisesti sulkea Pandoran lipasta jälleen. 381 00:27:47,985 --> 00:27:53,735 Ja mitä se tarkoittaa? Lisää tutkimusta SMTP ujuttelusta 382 00:27:53,868 --> 00:27:59,179 Tarkoitan, että pyysin CERT/CC:tä katsomaan tätä tarkemmin, niin, se ei päättynyt kovin hyvin. 383 00:27:59,287 --> 00:28:07,337 Lisää blogikirjoituksia, lisää tutkimusta ja ennen kaikkea lisää toimijoita VINCE tapaukseen. 384 00:28:07,433 --> 00:28:13,003 Yritämme saada kaiken korjattua ja olemme pahoillamme, että tämä tapahtui ylipäätään. 385 00:28:14,635 --> 00:28:25,980 Lopuksi jotain, jonka kaikki tiedätte. Älkää luottako sähköposteihinn sokeasti, erityisesti tällä hetkellä. 386 00:28:27,057 --> 00:28:28,877 Kiitos. 387 00:28:29,278 --> 00:28:33,278 [Aplodeja] 388 00:28:45,933 --> 00:28:49,933 Hienoa, kiitos. Mennään kysymyksiin. 389 99:59:59,999 --> 99:59:59,999 Ole hyvä. 390 99:59:59,999 --> 99:59:59,999 Hei, minulla on yksi lyhyt kysymys CERT/CC asiasta. 391 99:59:59,999 --> 99:59:59,999 Oliko tämä kommunikoitu sähköpostilla? 392 99:59:59,999 --> 99:59:59,999 Ja etkö olisi voinut lähettää viestin viestin Ciscon CDO:na? 393 99:59:59,999 --> 99:59:59,999 Kyllä, olisimme voineet tehdä sen ja luoda jonkinlaisen kolmiodraamaan 394 99:59:59,999 --> 99:59:59,999 Bill Gatesin, Elon Muskin ja jonkun muun välille. 395 99:59:59,999 --> 99:59:59,999 Mutta valitettavasti emme nähneet tätä sähköpostia. 396 99:59:59,999 --> 99:59:59,999 Näimme sen jälkeen päin, mutta se oli valitettavasti liian myöhäistä. 397 99:59:59,999 --> 99:59:59,999 Hei, kiitos teille. Arvostan työtänne. 398 99:59:59,999 --> 99:59:59,999 Voisitko kertoa hieman aikajanasta? 399 99:59:59,999 --> 99:59:59,999 Koska löysitte tämän ensimmäisen kerran? 400 99:59:59,999 --> 99:59:59,999 Aloitin tutkimuksen kesäkuussa kuluvana vuonna 401 99:59:59,999 --> 99:59:59,999 Minulla oli 10 päivän projekti SEC Consultilla. 402 99:59:59,999 --> 99:59:59,999 Olin sitä mieltä, että 10 päivää ei riitä, joten aloitin 10 päivää aiemmin. 403 99:59:59,999 --> 99:59:59,999 Sitten löysin SMTP ujuttelun kuudentena päivänä 404 99:59:59,999 --> 99:59:59,999 Sitten asia eteni kertomalla GMX:lle, Outlookille tai Microsoftille ja Ciscolle 405 99:59:59,999 --> 99:59:59,999 koska heillä oli vakavat SMTP ujuttelutapaukset, koskien sekä lähtevää ja saapuvaa. 406 99:59:59,999 --> 99:59:59,999 Sitten jatkoimme ja kerroimme CERT/CC:lle, koska tämä vaikutti olevan laajempi ongelma maailmanlaajuisesti. 407 99:59:59,999 --> 99:59:59,999 Aikataulumielessä, minulla ei ole sitä tässä nyt, mutta se on SEC Consultin blogikirjoituksessa. 408 99:59:59,999 --> 99:59:59,999 Onko joku tietty päivämäärä, jonka haluat tietää? 409 99:59:59,999 --> 99:59:59,999 Ei, ei. Käyn lukemassa blogikirjoituksen. Kiitos. 410 99:59:59,999 --> 99:59:59,999 Hei, kiitos hyvästä puheesta täällä. 411 99:59:59,999 --> 99:59:59,999 Haluaisin kysyä, että on mitään evidenssiä 412 99:59:59,999 --> 99:59:59,999 tai epäilyksiä, että tätä olisi jo käytetty? 413 99:59:59,999 --> 99:59:59,999 Tämä näyttää melko yksinkertaiselta haavoittuvuudelta hyödyntää. 414 99:59:59,999 --> 99:59:59,999 Voisin kuvitella, että sitä on jo hyödynnetty. 415 99:59:59,999 --> 99:59:59,999 Jeah, sain joitain kommentteja Reddit postaukseeni 416 99:59:59,999 --> 99:59:59,999 että tämä on supervanha, mutta asia on... 417 99:59:59,999 --> 99:59:59,999 Kohtalainen haavoittuvuus 418 99:59:59,999 --> 99:59:59,999 Jeah, todennäköisesti 419 99:59:59,999 --> 99:59:59,999 Ei, en tosiaankaan tiedä. 420 99:59:59,999 --> 99:59:59,999 Kävin läpi paljon tutkimuksia, mutta niissä ei ollut mitään. 421 99:59:59,999 --> 99:59:59,999 Siksi kutsun tätä uudeksi haavoittuvuudeksi. 422 99:59:59,999 --> 99:59:59,999 Translated by Mikko Heikkinen (ITKST56 course assignment at JYU.FI)