1 00:00:01,000 --> 00:00:05,000 Translated by Lauri Lyytinen (ITKST56 course assignment at JYU.FI) 2 00:00:05,000 --> 00:00:19,500 ♪ (36C3 intromusiikki) ♪ 3 00:00:19,500 --> 00:00:26,220 Juontaja: Seuraavan esityksen aihe on käytännön välimuistihyökkäykset verkossa 4 00:00:26,220 --> 00:00:33,960 Puhujana on Michael Kurth. Hän tunnisti tämän hyökkäystavan. Hyökkäystapa on 5 00:00:33,960 --> 00:00:42,640 ensimmäinen laatuaan. Hän on tutkimuksen pääkirjoittaja ja hänen esityksensä 6 00:00:42,640 --> 00:00:47,470 tulee olemaan suurenmoinen! Meille on luvattu huonoja sanaleikkejä kissoista ja 7 00:00:47,470 --> 00:00:52,750 odotan niitä sinulta. Annetaan iso käsi Michael Kurthille! 8 00:00:52,750 --> 00:00:58,690 (taputusta) 9 00:00:58,690 --> 00:01:03,800 Michael: Hei kaikille ja paljon kiitoksia kun pääsitte kuuntelemaan esitystäni. 10 00:01:03,800 --> 00:01:08,780 Nimeni on Michael ja haluan jakaa kansanne tutkimuksemme, jonka toteuttamisen 11 00:01:08,780 --> 00:01:15,659 mahdollisti mahtava VUSec group osana Pro gradu -tutkimustani. Hieman itsestäni. 12 00:01:15,659 --> 00:01:20,260 Suoritin tietotekniikan maisteriopintojani ETH Zürichin ja pystyin tekemään graduni 13 00:01:20,260 --> 00:01:27,869 Amsterdamissa. Nykyään työskentelen turvallisuusanalyytikkona infoGuardilla. 14 00:01:27,869 --> 00:01:33,450 Tässä näette ihmiset, jotka oikeasti mahdollistivat tämän tutkimuksen. 15 00:01:33,450 --> 00:01:37,869 He ovat esimiehiäni ja tutkimus- kollegoitani, jotka tukivat minua 16 00:01:37,869 --> 00:01:43,500 koko ajan ja panostivat aikaa ja vaivaa tutkimukseen. Joten he ovat oikeat 17 00:01:43,500 --> 00:01:50,990 rokkistarat tämän tutkimuksen taustalla. Mutta aloitetaanpa välimuistiyökkäyksistä. 18 00:01:50,990 --> 00:01:56,850 Tapa tunnettiin paikallisesti suoritet- tavan koodin hyökkäyksenä. Esimerkiksi 19 00:01:56,850 --> 00:02:03,679 vasemmalla näkyvässä virtuaaliympäristössä on kaksi virtuaalikonetta, jotka jakavat 20 00:02:03,679 --> 00:02:10,270 laitteiston. Eli ne jakavat aikapaikat CPU:n ja välimuistin osalta. Siksi 21 00:02:10,270 --> 00:02:18,120 VM2 käyttävä hyökkääjä voi suorittaa välimuistihyökkäyksen VM1 vastaan. Samoin 22 00:02:18,120 --> 00:02:23,100 myös JavaScriptillä. Haitallinen skripti syötetään selaimelle, joka sitten 23 00:02:23,100 --> 00:02:28,030 suorittaa sen. Koska se jakaa resursseja koneen kanssa se voi myös 24 00:02:28,030 --> 00:02:33,330 hyökätä muihin prosesseihin. Tämä JavaScript tapa luo tunteen 25 00:02:33,330 --> 00:02:39,340 verkon yli tapahtuvasta toiminnasta, eikö? Mutta se vaatii skriptin suorittamisen 26 00:02:39,340 --> 00:02:46,170 koneellasi ollakseen oikeasti onnistunut. Joten halusimme kehittää tätä ja toteuttaa 27 00:02:46,170 --> 00:02:54,060 oikean välimuistihyökkäyksen verkon yli. Tässä perusasetelmassa asiakas käyttää SSH 28 00:02:54,060 --> 00:03:00,790 yhteyttä palvelimeen ja meillä on kolmas, hyökkääjän käyttämä kone. Kuten tulen 29 00:03:00,790 --> 00:03:08,360 tänään todistamaan, voimme murtaa tämän SSH-istunnon luottamuksen käyttämällä 30 00:03:08,360 --> 00:03:13,269 kolmatta konetta ilman haitallista koodia tai ohjelman suorittamista asiakkaalla 31 00:03:13,269 --> 00:03:20,540 tai palvelimella. Lisäksi palvelimen CPU:lla ei ole mitään tekemistä tämän 32 00:03:20,540 --> 00:03:25,390 välimuistihyökkäyksen kanssa. Joten se vain on, eikä huomaa, kun siltä vuotaa 33 00:03:25,390 --> 00:03:34,689 salaisuuksia. Katsotaanpa hieman tarkemmin. Tässä meillä on kiva kissa suorittamassa 34 00:03:34,689 --> 00:03:41,409 SSH-istuntoa palvelimen kanssa ja aina, kun kissa painaa nappia yksi paketti 35 00:03:41,409 --> 00:03:49,700 lähtee palvelimelle. Tämä toteutuu aina interaktiivisessa SSH-istunnossa. Kuten 36 00:03:49,700 --> 00:03:56,530 nimikin kertoo, se luo interaktiivisuuden tunteen. Kun kurkkaamme hieman 37 00:03:56,530 --> 00:04:01,459 konepellin alle nähdäksemme mitä palveli- mella tapahtuu, huomamme näiden pakettien 38 00:04:01,459 --> 00:04:06,950 oikeasti aktivoivan viimeisen tason välimuistia (LLC). Tästä lisää hieman 39 00:04:06,950 --> 00:04:13,349 myöhemmin. Nyt hyökkääjä toteuttaa saman- aikaisen välimuistihyökkäyksen LLC:een 40 00:04:13,349 --> 00:04:19,340 vain lähettämällä verkkoliikennepaketteja. Ja näin voimme oikeasti vuotaa 41 00:04:19,340 --> 00:04:28,020 saapumisajat yksittäisistä SSH-paketeista. Nyt varmaan kysyt itseltäsi miten 42 00:04:28,020 --> 00:04:36,800 SSH-pakettien saapumisajat vaikuttavat SSH-istunnon luottamuksellisuuteen. No, 43 00:04:36,800 --> 00:04:43,210 ihmisillä on omintakeisia tapoja kirjoit- taa. Ja tässä näemme esimerkin käyttäjän 44 00:04:43,210 --> 00:04:50,460 kirjoittaessa sanaa "because". Huomamme, että E:n painallus B:n jälkeen on nopeampi 45 00:04:50,460 --> 00:04:56,870 kuin esimerkiksi C A:n jälkeen. Tämä voidaan yleistää ja sitä voidaan käyttää 46 00:04:56,870 --> 00:05:03,960 tilastollisessa analyysissä. Näillä orans- seilla pisteillä, jos saamme mallinnettua 47 00:05:03,960 --> 00:05:10,530 saapumisajat moitteettomasti — ja mitä moitteeton tarkoittaa: voimme mallintaa 48 00:05:10,530 --> 00:05:16,270 tarkat ajat, kun käyttäjä näppäili —, voimme toteuttaa tämän tilastollisen 49 00:05:16,270 --> 00:05:22,690 analyysin saapumisien välisistä ajoista. Ja näin voimme vuotaa mitä olit 50 00:05:22,690 --> 00:05:29,809 kirjoittamassa yksityisessä SSH-istunnossa. Kuulostaa pelottavalta ja futuristiselta, 51 00:05:29,809 --> 00:05:36,580 mutta minä selkeytän asian esityksen aikana. Hyvä! Haluan tuoda yhden seikan 52 00:05:36,580 --> 00:05:42,730 esille heti näin alussa: Kuten on tapana ja kirjoittamien helpottamiseksi 53 00:05:42,730 --> 00:05:48,180 tutkimukselle annetaan nimi. Ja jos olette seuranneet InfoSecin twitteriä tarkasti, 54 00:05:48,180 --> 00:05:53,930 tunnistatte varmaan mistä olen puhumassa. Koska meidän tapauksessa nimesimme 55 00:05:53,930 --> 00:06:00,740 tutkimuksen NetCAT:ksi. Tämä oli tietenkin sanaleikki. Tässä NetCAT tarkoittaa 56 00:06:00,740 --> 00:06:08,560 "Network Cache Attack" ja se oli tietenkin huumoria, joka voi joskus kostautua. 57 00:06:08,560 --> 00:06:17,830 Ja tässä tapauksessa se kostautui pahasti. Näin saimme aikaan hieman twitter-draamaa 58 00:06:17,830 --> 00:06:24,400 viime syyskuussa. Yksi tykätyimmistä twiiteistä tutkimukseen liittyen oli 59 00:06:24,400 --> 00:06:32,889 Jakelta. Nämä esitykset ovat hyviä, koska tällaiset twiitit voidaan henkilöidä ja 60 00:06:32,889 --> 00:06:42,599 kyllä: Minä olen tämä idiootti. Korjataanpa tämä! Intel tunnusti työmme palkitsemalla 61 00:06:42,599 --> 00:06:48,720 ja lisäksi CVE-numerolla, joten nykyään voimme vain käyttää CVE-numeroa. Tai, 62 00:06:48,720 --> 00:06:54,479 jos se on hankalaa, twitter draaman aikana joku lähetti meille tällaisen 63 00:06:54,479 --> 00:06:59,800 kivan pienen vaihtoehtoisen nimen ja lisäsi logon, josta minä jopa pidän. 64 00:06:59,800 --> 00:07:09,240 Sen nimi on NeoCAT. Jokatapuksessa, opimme läksymme nimeämisjutusta. 65 00:07:09,240 --> 00:07:15,250 Siirrytäänpä eteenpäin. Palataan tutkimuk- semme varsinaisesti kiinnostavimpiin 66 00:07:15,250 --> 00:07:22,460 asioihin! Nopea hahmottelu: Aion ensin kertoa taustoista eli 67 00:07:22,460 --> 00:07:28,240 välimuistihyökkäykset yleisesti. Sitten DDIO ja RDMA, tärkeät teknologiat joita 68 00:07:28,240 --> 00:07:34,330 hyväksikäytimme verkon yli tapahtuvassa hyökkäyksessä. Sitten itse hyökkäys ja kuinka 69 00:07:34,330 --> 00:07:42,190 käänteisesti suunnittelimme DDIO:n, päästä-päähän hyökkäys ja pieni demo. 70 00:07:42,190 --> 00:07:47,050 Välimuistihyökkäykset perustuvat mikro- arkkitehtuurin tilan havainnointiin, jonka 71 00:07:47,050 --> 00:07:53,160 pitäisi säilyä salassa ohjelmistolta. Tämä onnistuu pakottamalla jaetut resurssit 72 00:07:53,160 --> 00:07:59,759 vuotamaan tietoa. Analogiana voidaan pitää kassakaapin murtamista stetoskoopilla, 73 00:07:59,759 --> 00:08:06,300 jossa jaettuna resurssina on ilma, joka välittää lukosta tulevat äänet 74 00:08:06,300 --> 00:08:11,990 kun sitä käsitellään. Tämä tapahtuu jokseenkin samalla tavalla 75 00:08:11,990 --> 00:08:21,949 tietokoneissa. Mutta, nyt vain välimuis- tissa. Välimuisti ratkaisee pahatkin 76 00:08:21,949 --> 00:08:28,389 viiveongelmat keskusmuistista ladattaessa, eikö? Nämä tekevät karkeasti neljänneksen 77 00:08:28,389 --> 00:08:34,320 kaikista komennoista. Ja välimuistin avulla voimme käyttää uudelleen datan ja käyttää 78 00:08:34,320 --> 00:08:41,980 paikkatietoa ohjelmissa. Moderneissa CPU:issa on yleensä 3-kerroksinen välimuistihierarkia: 79 00:08:41,980 --> 00:08:47,041 L1 on jaettu datan ja komentoväli- muistin kanssa. L2, ja sitten L3, joka 80 00:08:47,041 --> 00:08:54,290 on jaettu ytimien kesken. Jos käsiteltävä data on jo ladattu välimuistiin, se 81 00:08:54,290 --> 00:08:58,780 aiheuttaa välimuistiosuman. Jos data pitää ladata keskusmuistista, sitä pidetään 82 00:08:58,780 --> 00:09:06,290 välimuistihutina. Joten, miten saame oikeasti tietää milloin tapahtuu osuma tai 83 00:09:06,290 --> 00:09:11,549 huti? Koska emme voi lukea dataa suoraan välimuistista. Voimme tehdä 84 00:09:11,549 --> 00:09:15,700 tämän esimerkiksi alustamalla ja tutkaamalla. Se on tunnettu tekniikka, jota 85 00:09:15,700 --> 00:09:20,980 käytimme verkkoympäristössä. Haluan pikaisesti kertoa siitä, mitä 86 00:09:20,980 --> 00:09:26,430 tässä tapahtuu. Alustamisen ja tutkaamisen ensimmäisessä vaiheessa hyökkääjä saattaa 87 00:09:26,430 --> 00:09:33,860 välimuistin tunnettuun tilaan. Periaat- teessa alustaa välimuistin. Se täyttää sen 88 00:09:33,860 --> 00:09:42,310 omalla datallaan, jonka jälkeen hyökkääjä odottaa uhrin toimia. Viimeinen vaihe on 89 00:09:42,310 --> 00:09:49,040 tutkaaminen, joka tekee alustamisen uudelleen, mutta tällä kertaa mittaa 90 00:09:49,040 --> 00:09:56,260 kirjautumisajat. Nopeat osumat tar- koittavat ettei välimuistia oltu muutettu 91 00:09:56,260 --> 00:10:02,750 välissä. Ja hutiosumat tuottavat, kuten nyt tiedämme, että uhri 92 00:10:02,750 --> 00:10:10,270 on todella käyttänyt yhtä välimuistiriviä alustuksen ja tutkaamisen välissä. 93 00:10:10,270 --> 00:10:15,750 Mitä voimme siis tehdä näillä osumilla ja hutiosumilla? Voimme analysoida niitä! 94 00:10:15,750 --> 00:10:21,410 Tämä aikatieto kertoo meille paljon uhrin käyttäytymisestä ja ohjelmista. 95 00:10:21,410 --> 00:10:28,519 Perustuen pelkästään osumiin ja huteihin voimme— tai tutkijat pystyivät —vuotamaan 96 00:10:28,519 --> 00:10:35,829 salausavaimistoja, arvaamaan nettisaitteja tai muistin sisältöä. Näin siis SPECTRE:llä 97 00:10:35,829 --> 00:10:42,260 ja MELTDOWN:lla. Katsotaanpa kuinka oike- astaan saamme toteutettua hyökkäyksen 98 00:10:42,260 --> 00:10:50,550 verkon yli! Toinen tärkeistä teknologioista on DDIO. Mutta ensin haluan kertoa DMA:sta 99 00:10:50,550 --> 00:10:55,420 koska se on kuin sen edeltäjä. DMA on periaatteessa teknologia, joka 100 00:10:55,420 --> 00:11:02,010 sallii PCIe-laitteen, kuten esimerkiksi verkkokortin, vaikuttaa suoraan 101 00:11:02,010 --> 00:11:08,519 keskusmuistiin ilman CPU:n keskeytystä. Joten esimerkiksi, jos paketti on 102 00:11:08,519 --> 00:11:14,339 vastaanotettu, PCIe-laite vain laittaa sen keskusmuistiin ja sitten, kun 103 00:11:14,339 --> 00:11:19,110 ohjelma tai sovellus haluaa käyttää dataa, silloin se voi hakea sen keskusmuistista. 104 00:11:19,110 --> 00:11:27,089 Nyt DDIO:n kanssa tämä käy hieman toisella tavalla. DDIO:n avulla PCIe-laite voi 105 00:11:27,089 --> 00:11:33,110 laittaa suoraan dataa viimeisen tasan välimuistiin. Tämä on hienoa, sillä nyt 106 00:11:33,110 --> 00:11:38,620 kun sovellus työskentelee datan kanssa, sen ei tarvitse tehdä kallisarvoista hakua 107 00:11:38,620 --> 00:11:43,910 keskusmuistista vaan se voi suoraan työstää dataa — tai noutaa sen — 108 00:11:43,910 --> 00:11:52,010 LLC:sta. DDIO tarkoittaa "Data Direct I/O Technology" ja se on käytössä 109 00:11:52,010 --> 00:11:58,560 kaikissa Intelin palvelintason prosesso- rissa vuodesta 2012 lähtien. Se on päällä 110 00:11:58,560 --> 00:12:04,069 oletuksena ja läpinäkyvä ajureille ja käyttöjärjestelmille. Arvaan ettei monikaan 111 00:12:04,069 --> 00:12:09,279 edes huomannut, että jokin muuttui kone- pellin alla. Muutos oli kuitenkin hyvin 112 00:12:09,279 --> 00:12:17,100 merkittävä. Miksi oikeastaan DDIO:ta tarvitaan? Se on käytössä suorituskyvyn 113 00:12:17,100 --> 00:12:23,489 takia. Tässä meillä on kiva Intelin tutkimus, joka alimpana osoittaa 114 00:12:23,489 --> 00:12:29,090 NIC:n eriävät ajat. Tässä meillä on ase- telma, jossa on 2, 4, 6 ja 8 NIC:a 115 00:12:29,090 --> 00:12:35,750 Ja meillä on läpimenoajat niille. Kuten voitte nähdä tässä tumman sinisellä 116 00:12:35,750 --> 00:12:42,850 että ilman DDIO:ta se pysäyttää skaalautuvuuden 4 NIC:n jälkeen. 117 00:12:42,850 --> 00:12:47,890 Vaaleansinisellä voimme nähdä että skaalau- tuvuus jatkuu verkkokortteja lisättäessä. 118 00:12:47,890 --> 00:12:56,770 Niinpä DDIO on rakennettu erityisesti verkkosovellusten skaalautuvuudeksi. Toinen 119 00:12:56,770 --> 00:13:02,250 teknologia, jota hyväksikäytämme on RDMA. Se tarkoittaa "Remote Direct Memory Access" 120 00:13:02,250 --> 00:13:08,750 ja se pohjimmiltaan purkaa siirtokerroksen tehtävät piirilevylle. 121 00:13:08,750 --> 00:13:15,390 Se on periaatteessa Kernelin ohitus. Eikä siinä ole CPU käyttöä, jolloin ohjelmisto 122 00:13:15,390 --> 00:13:23,520 voi käyttää etänä muistia ilman, että kuluttaa CPU aikaa palvelimella. 123 00:13:23,520 --> 00:13:28,329 Toin tähän lyhyen kuvauksen RDMA:sta tarkasteltavaksi. Tässä vasemmalla meillä 124 00:13:28,329 --> 00:13:34,230 on toiminnon aloittaja ja oikealla meillä on kohdepalvelin. Muistialue 125 00:13:34,230 --> 00:13:39,670 määräytyy palvelimen avauksessa ja tästä eteen päin ohjelmistot voivat tehdä 126 00:13:39,670 --> 00:13:44,490 tiedonsiirtoa ilman vaikutusta verkko- ohjelmistopinoon. Eli nyt on tehty 127 00:13:44,490 --> 00:13:52,779 TCP/IP pino kokonaisuudessaan. Yksipuoli- sissa RDMA operaatioissa sallitaan myös 128 00:13:52,779 --> 00:13:59,740 toiminnon aloittajan lukea ja kirjoittaa mielivaltaisiin kohtiin määrätyssä tilassa 129 00:13:59,740 --> 00:14:06,880 kohteessa. Lainaan nyt lausuntoa eräältä markkinajohtajalta näistä korkean 130 00:14:06,880 --> 00:14:12,900 suorituskyvyn käärmeistä: "Lisäksi, välimuisti etä-CPU:ssa ei täyty 131 00:14:12,900 --> 00:14:20,639 käytetyllä muistisisällöllä." No, tämä ei pidä enää paikkaansa DDIO:n kohdalta ja 132 00:14:20,639 --> 00:14:28,540 se on juuri se johon hyökkäsimme. Saatat kysyä itseltäsi "missä RDMA:ta käytetään"? 133 00:14:28,540 --> 00:14:33,749 Voin kertoa, että RDMA on yksi niistä teknologioista joista et kuule 134 00:14:33,749 --> 00:14:38,780 kovinkaan usein, mutta ovat oikeasti laa- jassa käytössä datakeskusten backendissa 135 00:14:38,780 --> 00:14:45,509 ja pilvi-infrastruktuurissa. Joten voit saada omat RDMA infrastruktuuriksi 136 00:14:45,509 --> 00:14:52,550 julkisesta pilvestä, kuten Azurelta, Oraclelta, Huaweilta tai AliBabalta. Myös 137 00:14:52,550 --> 00:14:59,230 muistiprotokollat kuten SMB ja NFS voivat tukea RDMA:ta. Muita ohjelmistoja ovat 138 00:14:59,230 --> 00:15:07,320 Suurtehotietokoneet, Big Data, kone- oppiminen, datakeskukset, pilvi ja muut. 139 00:15:07,320 --> 00:15:12,810 Mennäänpä tarkemmin tutkimuksen sisältöön ja siihen, kuinka hyväksikäytimme näitä 140 00:15:12,810 --> 00:15:19,339 kahta teknologiaa. Tiedämme nyt, että meillä on verkolle avoin jaettu resurssi 141 00:15:19,339 --> 00:15:26,291 DDIO:n ansiosta ja RDMA antaa meillä tar- vittavat luku- ja kirjoitusoikeudet tehdäksemme 142 00:15:26,291 --> 00:15:34,310 välimuistihyökkäyksen verkon yli. Mutta ensin meidän täytyy selkeyttää pari asiaa. 143 00:15:34,310 --> 00:15:39,320 Tietenkin teimme monia kokeita ja testasimme laajasti DDIO porttia 144 00:15:39,320 --> 00:15:44,630 ymmärtääksemme sen salat. Mutta tässä toin mukanani kaksi isoa kysymystä, 145 00:15:44,630 --> 00:15:50,420 joihin meidän on vastattava. Ensinnäkin tietysti, voimmeko erottaa välimuistin 146 00:15:50,420 --> 00:15:57,860 osumat ja hutiosumat verkon yli? Meillä on edelleen verkkoviive ja pakettijonotus 147 00:15:57,860 --> 00:16:04,020 ja niin edelleen. Olisiko todella mahdol- lista saada ajoitus oikein? Se on kuitenkin 148 00:16:04,020 --> 00:16:09,040 ehdoton vaatimus avatakseen sivukanavan. Ja niinpä toinen kysymys on sitten: 149 00:16:09,040 --> 00:16:14,240 Voimmeko oikeasti päästä käsiksi LLC:hen? Tämä liittyy ennemminkin 150 00:16:14,240 --> 00:16:20,589 hyökkäyspintaan kuin itse hyökkäykseen. Niinpä ensimmäiseen kysymykseen voimme 151 00:16:20,589 --> 00:16:26,640 vastata tällä yksinkertaisella kokeella: Vasemmalla meillä on erittäin pieni koodin 152 00:16:26,640 --> 00:16:33,180 palanen. Meillä on ajastettu RDMA luku tiettyyn offsettiin. Sitten kirjoitamme 153 00:16:33,180 --> 00:16:41,850 siihen offsettiin ja luemme sen uudelleen samasta offsetista. Kuten näette, kun 154 00:16:41,850 --> 00:16:46,040 teemme tämän vaikka 50 000 kertaa useisiin eri offsetteihin, voimme selkeästi 155 00:16:46,040 --> 00:16:52,000 erottaa kaksi eri jakaumaa. Sininen vastaa dataa, joka oli 156 00:16:52,000 --> 00:16:58,149 haettu muistista ja oranssi on dataa, joka oli haettu LLC:sta 157 00:16:58,149 --> 00:17:03,250 verkon yli. Voimme myös nähdä verkon vaikutukset toimintaan. 158 00:17:03,250 --> 00:17:09,820 Esimerkiksi, voimme nähdä pitkät hännät, jotka liittyvät joihinkin paketteihin, jotka 159 00:17:09,820 --> 00:17:16,430 hidastuivat verkossa tai olivat jonossa. Sivuhuomautuksena kaikille sivukanava 160 00:17:16,430 --> 00:17:23,280 asiantuntijoille: Tarvitsemme todella kirjoitusoikeuden, koska DDIO luku ei 161 00:17:23,280 --> 00:17:30,290 kohdenna mitään LLC:hen. Periaatteessa tämä on perusta jonka avulla 162 00:17:30,290 --> 00:17:36,030 suoritamme alustamisen ja tutkaamisen verkon yli. Tarvitsemme kuitenkin vielä 163 00:17:36,030 --> 00:17:40,500 todellisen kohteen profiilin rakenta- miseksi. Katsotaanpa millainen 164 00:17:40,500 --> 00:17:46,350 hyökkäyspinta meillä onkaan. Tämä tuokin meidät kysymykseen: voimmeko päästä 165 00:17:46,350 --> 00:17:51,470 täysin LLC:hen sisälle? Epäonneksemme näin ei tapahdu. 166 00:17:51,470 --> 00:17:58,930 DDIO:ssa kohdennukset on rajoitettu kahteen kohtaan. Tässä esimerkissä 20:stä. 167 00:17:58,930 --> 00:18:08,080 Joten noin 10%. Eikä se ole määritetty kohta, jota CPU käyttää. Meillä olisi 168 00:18:08,080 --> 00:18:16,610 pääsy vain 10 prosenttiin CPU:n toimin- noista välimustin viimeisellä tasolla. 169 00:18:16,610 --> 00:18:22,560 Tämäei toiminut kovin hyvinensimmäisenä hyökkäyksenä. Mutta hyvä uutinen on, että 170 00:18:22,560 --> 00:18:31,760 muut PCIe-laitteet—kuten vaikkapa toinen verkkokortti—käyttävät samoja kahta 171 00:18:31,760 --> 00:18:38,780 välimuistin kohtaa. Ja niinpä meillä on 100% näkyvyys mitä muut PCIe-laitteet 172 00:18:38,780 --> 00:18:48,690 tekevät välimuistissa. Katsotaanpa päästä- päähän hyökkäystä! Kuten jo mainitsin 173 00:18:48,690 --> 00:18:54,050 aiemmin, meillä on asiakkaan ja palvelimen perusjärjestely. Ja meillä on kone, 174 00:18:54,050 --> 00:19:01,470 jota me, hyökkääjänä, hallitsemme. Niinpä asiakas vain lähettää tämän 175 00:19:01,470 --> 00:19:06,770 paketin normaalisti ethernet NIC:nä ja siellä on myös toinen NIC liitettynä 176 00:19:06,770 --> 00:19:15,410 palvelimeen, mikä sallii hyökkääjän suorittaa RDMA-operaatioita. Tiedämme myös 177 00:19:15,410 --> 00:19:19,960 että kaikki paketit... tai kaikki näppäin- painallukset, jotka käyttäjä tekee, 178 00:19:19,960 --> 00:19:25,540 lähtevät yksittäisinä paketteina, jotka aktivoituvat alimman tason välimuistissa 179 00:19:25,540 --> 00:19:33,750 DDIO:n läpi. Mutta miten voimme nyt saada näiden pakettien tuloajat? Koska 180 00:19:33,750 --> 00:19:39,420 niistä me olemme kiinnostuneita! Nyt meidän on katsottava tarkemmin miten 181 00:19:39,420 --> 00:19:46,830 tämä verkkoliikenne pakettien saapuminen oikein toimii. IP pinossa on rengaspuskuri, 182 00:19:46,830 --> 00:19:52,960 joka periaatteessa suorittaa asynkronisia operaatioita 183 00:19:52,960 --> 00:20:01,720 laitteiston- eli NIC:N- ja CPU:n välissä. Kun paketti saapuu, se sijoittaa paketin 184 00:20:01,720 --> 00:20:07,530 rengaspuskurin ensimmäiseen paikkaan. Oikealla näette näkymän hyökkääjän 185 00:20:07,530 --> 00:20:13,700 näkökulmasta, joka voi vain seurata väli- muistin toimintaa. Näemme, että muistirivi 186 00:20:13,700 --> 00:20:18,930 ensimmäisessä paikassa syttyy. Näemme siis toimintaa siinä. Voisi olla myös välimuistin 187 00:20:18,930 --> 00:20:24,750 rivillä 2, tätä... emme tiedä mille riville tämä oikeastaan ilmestyy. Mutta, 188 00:20:24,750 --> 00:20:29,200 tärkeintä on: Mitä tapahtuu toiselle paketille? Sillä toinen 189 00:20:29,200 --> 00:20:35,380 paketti sytyttää myös yhden muistiriveistä, mutta toisen tällä kertaa. Se on oikeastaan 190 00:20:35,380 --> 00:20:41,760 seuraava rivi ensimmäiseen pakettiin ver- rattuna. Jos teemme tämän kolmannelle 191 00:20:41,760 --> 00:20:51,310 ja neljännelle paketille, huomamme, että meillä on kaunis porraskuvio. Nyt voimme 192 00:20:51,310 --> 00:20:56,940 nähdä ennustettavan kaavan, jota voimme hyväksikäyttää saadaksemme tietoa pakettien 193 00:20:56,940 --> 00:21:04,290 saapuessa. Ja tämä vain siksi, että rengaspuskuri on varattu tavalla, 194 00:21:04,290 --> 00:21:10,300 joka ei kiellä itseään, eikö? Se ei kiellä kun toinen paketti saapuu. Se ei 195 00:21:10,300 --> 00:21:16,660 kiellä ensimmäisen paketin välimuistin si- sältöä. Tämä on huikeaa meille hyökkääjänä 196 00:21:16,660 --> 00:21:22,260 koska nyt voimme muodostaa laadukkaan pro- fiilin. Katsotaan elävän elämän esimerkki. 197 00:21:22,260 --> 00:21:28,010 Tässä on välimuistin toiminta kun se vas- taanottaa jatkuvia pingejä. Voitte nähdä 198 00:21:28,010 --> 00:21:34,750 hienon porraskuvion ja näette myös, että rengaspuskuri uudelleenkäyttää paikkoja 199 00:21:34,750 --> 00:21:40,650 koska se on rengas. Nyt on tärkeää tietää, että rengaspuskuri 200 00:21:40,650 --> 00:21:48,940 ei pidä datasisältöä vaan ainoastaan datakuvauksen. Ja se käytetään uudelleen 201 00:21:48,940 --> 00:21:55,520 Epäonneksemme kun käyttäjä näppäilee SSH:lla, kuvio ei ole yhtä kaunis kuin tämä. 202 00:21:55,520 --> 00:22:00,000 Koska muutenhan tämä olisi selvä peli ja voisimme edetä sillä. 203 00:22:00,000 --> 00:22:05,780 Koska käyttäjä kirjoittaa, meillä on enemmän viivettä pakettien välillä. 204 00:22:05,780 --> 00:22:11,470 Yleisesti ottaen emme voi tietää milloin käyttäjä näppäilee, joten täytyy profiloida 205 00:22:11,470 --> 00:22:16,060 jatkuvasti saadaksemme ajoitukset kohdil- leen. Joten, meidän rakennettava hieman 206 00:22:16,060 --> 00:22:23,880 kehittyneempi järjestely. Se on periaat- tessa kaksi-vaiheinen järjestely, joka 207 00:22:23,880 --> 00:22:31,520 koostuu verkkotrackerista, joka vain seuraa useita välimuistirivejä 208 00:22:31,520 --> 00:22:37,990 jatkuvasti. Ja kun se huomaa tietyn muistirivin tulevan 209 00:22:37,990 --> 00:22:44,300 aktiiviseksi, se siirtää sen ikkunan eteenpäin seuraavaan kohtaan, jossa 210 00:22:44,300 --> 00:22:50,260 se arvaa aktivoinnin tapahtuvan. Tämä onnistuu, koska meillä on etu nopeudessa. 211 00:22:50,260 --> 00:22:57,090 Meidän on profiloitava paljon nopeammin kuin SSH-istunnon verkkopaketit saapuvat. 212 00:22:57,090 --> 00:23:00,710 Tässä vasemmalla voitte nähdä kuvituksen siitä, mitä 213 00:23:00,710 --> 00:23:07,260 verkkotrackeri tekee. Se vain profiloi tätä ikkunaa, joka näkyy punaisella. 214 00:23:07,260 --> 00:23:15,030 Jos katsotte tarkasti, voitte nähdä kirkkaamman kohdan keskellä, joka 215 00:23:15,030 --> 00:23:19,690 tarkoittaa saapuneitta verkkopaketteja. Voitte myös nähdä, että siellä on paljon 216 00:23:19,690 --> 00:23:27,280 kohinaa mukana ja siksi emme voi suoraan saada pakettien 217 00:23:27,280 --> 00:23:35,250 saapumisaikoja siitä. Siksi tarvitsemme toisen vaiheen. Offline poimijan. 218 00:23:35,250 --> 00:23:40,590 Offline poimija vastaa todennäköisimpien tapahtumien laskennasta, joissa tekijänä 219 00:23:40,590 --> 00:23:46,010 on käyttäjän SSH-paketti. Se käyttää verkkotrackerin keräämää dataa ja 220 00:23:46,010 --> 00:23:52,451 rengaspuskurin ennustettavuutta. Sitten se esittää pakettien 221 00:23:52,451 --> 00:23:59,380 saapumisien väliajat eri sanoille kuten tässä oikealla. Hienoa. Nyt 222 00:23:59,380 --> 00:24:04,900 olemme jälleen tilanteessa, jossa meillä on pelkät saapumisajat muttei sanoja, 223 00:24:04,900 --> 00:24:10,040 joita me tarvitsemme rikkoaksemme SSH-istunnon luottamuksellisuuden. 224 00:24:10,040 --> 00:24:19,260 Kuten totesin aiemmin, käyttäjillä tai oikeastaan ihmisillä on omalaatuinen 225 00:24:19,260 --> 00:24:27,330 kirjoitustapa. Ja sen avulla me onnis- tuimme tilastollisessa hyökkäyksessä. 226 00:24:27,330 --> 00:24:33,060 Lähemmin tarkasteltuna käytämme kone- oppimista ja kartoitusta käyttäjien 227 00:24:33,060 --> 00:24:39,340 kirjotustyylien ja oikeiden sanojen välillä. Lopulta voimme todeta ne kaksi sanaa, 228 00:24:39,340 --> 00:24:48,090 jotka kirjoitit SSH-istunnossasi. Käytimme 20:tä kohdehenkilöä, jotka kirjoittivat 229 00:24:48,090 --> 00:24:55,830 vapaasti ja käsikirjoituksen mukaan ja saimme 4574 uniikkia sanaa. Ja jokainen 230 00:24:55,830 --> 00:25:01,230 niistä edusti pistettä moniulotteisessa tilassa. Ja käytimme todella 231 00:25:01,230 --> 00:25:06,431 yksinkertaista koneoppimistekniikkaa, kuten "k-nearest neighbour" algoritmia, joka 232 00:25:06,431 --> 00:25:11,960 luokittelee mittauksia Euklidisen tilan kannalta muihin sanoihin. 233 00:25:11,960 --> 00:25:17,550 Syy, miksi käytimme hyvin yksinkertaista koneoppialgoritmia oli se, 234 00:25:17,550 --> 00:25:21,330 että halusimme vain todistaa, että signaalin, jota yritimme ottaa talteen 235 00:25:21,330 --> 00:25:26,590 välimuistista olisi oikeasti kyllin vahva hyökkäyksen toteuttamiseksi. Emme halunneet 236 00:25:26,590 --> 00:25:32,910 yleisesti parantaa tällaista käyttäjien ja kirjoittamiskäytöksen välistä kartoitusta. 237 00:25:32,910 --> 00:25:40,050 Katsotaanpa miten tämä onnistui! Eli aluksi, tässä vasemmalla 238 00:25:40,050 --> 00:25:47,090 näette meidän käyttäneen luokittelua puhtaalle näppäilydatalle. Tarkoittaa, että 239 00:25:47,090 --> 00:25:52,880 käytimme vain kirjoituksen aikana lähetet- tyä signaalia. Eli kun painalluksia tehtiin 240 00:25:52,880 --> 00:25:58,900 paikallisella näppäimistöllä. Tämä antaa täydellistä ja tarkkaa aikadataa. Voimme 241 00:25:58,900 --> 00:26:02,450 nähdä, että tämä on aika vaikeaa käyttää. Tarkkuudeksi saamme 242 00:26:02,450 --> 00:26:09,500 karkeasti 35%. Mutta, jos katsomme kor- keinta 10:tä prosenttia, joka tarkoittaa, 243 00:26:09,500 --> 00:26:15,580 että hyökkääjä arvaa kymmenen sanaa ja oikea sana kuuluu joukkoon, sitten sen 244 00:26:15,580 --> 00:26:22,930 todetaan olevan tarkka. Ja kymmenellä parhaalla arvauksella saamme tarkkuudeksi 245 00:26:22,930 --> 00:26:30,750 58%. Tämä on vain puhdasta näppäily- dataa. Sitten käytimme samaa dataa ja 246 00:26:30,750 --> 00:26:35,730 samaa luokittelua verkon yli tulevaan signaaliin. Tämä ei tietenkään ole yhtä 247 00:26:35,730 --> 00:26:43,840 tarkkaa, koska siinä on kohinaa ja voimme lisätä tai kadottaa näppäinpainalluksia. 248 00:26:43,840 --> 00:26:54,610 Tarkkuus on karkeasti 11% vähemmän ja parhaan 10:n tarkkuus karkeasti 60%. 249 00:26:54,610 --> 00:27:00,851 Kun käytimme yksinkertaista koneoppimista, useita koehenkilöitä ja suhteellisen 250 00:27:00,851 --> 00:27:07,600 laajaa sanakirjastoa, uskomme pystyvämme todistamaan, että signaali on kyllin vahva 251 00:27:07,600 --> 00:27:15,470 toteuttaaksemme hyökkäyksen. Tietenkin haluamme nähdä tämän nyt toiminnassa, 252 00:27:15,470 --> 00:27:21,030 eikö? Koska olen hieman hermostunut täällä lavalla, en näytä livedemoa koska se 253 00:27:21,030 --> 00:27:27,630 vaatisi, että kirjoittaisin itse ja se varmaankin sekoittaisi minua ja 254 00:27:27,630 --> 00:27:34,060 tietenkin koneoppimismallia. Siksipä toin mukanani videon. 255 00:27:34,060 --> 00:27:39,890 Tässä oikealla näette uhrin. Se aloittaa kohta 256 00:27:39,890 --> 00:27:45,480 SSH-istunnon. Ja vasemmalla puolella näette hyökkääjän. 257 00:27:45,480 --> 00:27:51,260 Alalaidassa näätte verkkotrakkerin ja ylälaidassa näätte poimijan, 258 00:27:51,260 --> 00:27:58,080 sekä toivottavasti ennustetut sanat. Nyt uhri aloittaa SSH-istunnon 259 00:27:58,080 --> 00:28:04,720 palvelimeen nimeltä "father". Ja hyök- kääjä, joka käyttää konetta "son" 260 00:28:04,720 --> 00:28:10,590 aloittaa hyökkäyksen. Näitte, että profi- loimme rengaspuskurin kohdan ja nyt 261 00:28:10,590 --> 00:28:19,790 uhri alkaa kirjoittaa. Ja koska tällä jär- jestelyllä kestää hieman käsitellä sanat 262 00:28:19,790 --> 00:28:24,350 ja tehdä oikea ennustus, näette kohta, että pikkuhiljaa sanat alkavat 263 00:28:24,350 --> 00:28:41,600 muodostumaan oikeaan -toivottavasti oikeaan- järjestykseen. Kuten näette, voimme 264 00:28:41,600 --> 00:28:48,010 arvata oikeat sanat verkon yli vain lähettämällä verkkopaketteja 265 00:28:48,010 --> 00:28:53,620 samaan palvelimeen. Ja näin saamme tärkeän informaation kun sen 266 00:28:53,620 --> 00:29:05,450 SSH- paketit saapuvat. (aplodeja) 267 00:29:05,450 --> 00:29:10,330 Nyt varmaan kysyt itseltäsi: Miten tältä hyökkäykseltä suojaudutaan? Noh, 268 00:29:10,330 --> 00:29:16,860 onneksi tämä koskee vain palvelintason prosessoreja, eli ei asiakkaita tai muita. 269 00:29:16,860 --> 00:29:22,960 Mutta meidän mielestämme oikea suo- jautuminen tällä hetkellä on DDIO:n poistaminen 270 00:29:22,960 --> 00:29:30,260 tai ettei käytä RDMA:ta. Molemmat vaikuttavat suorituskykyyn paljonkin. DDIO:n kohdalla 271 00:29:30,260 --> 00:29:37,130 puhutaan karkeasti 10-18% vähemmän suori- tuskykyä riippuen tietenkin ohjelmistosta. 272 00:29:37,130 --> 00:29:42,640 Ja, jos päätät olla käyttämättä RDMA:ta, joudut varmaankin uudelleenkirjoittamaan 273 00:29:42,640 --> 00:29:50,500 koko ohjelmasi. Intel kertoi asian hieman toisin tiedoksiannon julkaisussaan. 274 00:29:50,500 --> 00:30:00,430 Lukekaapa itse! "Epäluotettavan verkon" määritelmä voi varmaankin 275 00:30:00,430 --> 00:30:10,250 olla hieman kyseenalainen. No joo. Sillä mennään. Olen todella ylpeä, 276 00:30:10,250 --> 00:30:17,420 että meidät hyväksyttiin Security and Privacy 2020:een. Myös Intel tunnusti 277 00:30:17,420 --> 00:30:22,540 löydöksemme, julkistustilaisuus oli syyskuussa, ja saimme myös rahapalkinnon. 278 00:30:22,540 --> 00:30:26,950 (yksittäinen huuto katsomossa) 279 00:30:26,950 --> 00:30:29,640 (naurua) Oheislaitteiden lisääntynyt suorituskyky on 280 00:30:29,640 --> 00:30:36,550 pakottanut Intelin asettamaan LLC:n nopeisiin I/O polkuihin prosessoreissa. 281 00:30:36,550 --> 00:30:43,250 Ja näin on paljastunut yhä enemmän mikroarkkitehtuurikomponentteja, joiden 282 00:30:43,250 --> 00:30:51,631 tunnistamme vaikuttavan suoraan turvalli- suuteen. Tutkimuksemme on ensimmäinen 283 00:30:51,631 --> 00:30:55,730 DDIO sivukanavahaavoittuvuus, mutta uskom- me raapaisseemme tässä vain pintaa. 284 00:30:55,730 --> 00:31:03,320 Muistakaa, että niihin liittyy monia PCIe- laitteita! Joten siellä voi olla 285 00:31:03,320 --> 00:31:10,900 muistilaitteita - voitaisiin profiloida välimuistin toimintaa muistilaitteissa! 286 00:31:10,900 --> 00:31:20,419 On olemassa jopa GPUDirect, joka antaa pääsyn GPU:n välimuistiin. 287 00:31:20,419 --> 00:31:25,740 Mutta se onkin jo toinen tarina. Eli näin. Luulen, että aiheessa on paljon löydettävää 288 00:31:25,740 --> 00:31:33,090 eli pysykää kuulolla! Totean enää vain, että iso kiitos kaikille 289 00:31:33,090 --> 00:31:38,480 ja tietenkin kaikille vapaaehtoisille täällä konferenssissa. Kiitos! 290 00:31:38,480 --> 00:31:46,970 (aplodeja) 291 00:31:46,970 --> 00:31:52,740 Juontaja: Kiitos, Michael! Meillä on aikaa kysymyksille. Eli voitte muodostaa jonoa 292 00:31:52,740 --> 00:31:58,220 mikrofoneille. Ja näenkin jonkun mikrofonilla seitsemän! 293 00:31:58,220 --> 00:32:02,720 Kysymys: Kiitos esityksestä! Minulla on kysymys - kun työskentelen 294 00:32:02,720 --> 00:32:08,920 verkon yli SSH:ta käyttämällä, en kovinkaan usein käytä noin helppoja sanoja, 295 00:32:08,920 --> 00:32:13,750 mutta yleensä se on jotain omituisempaa, kuten valuuttamerkkejä, viivoja ja jotain. 296 00:32:13,750 --> 00:32:18,120 Oletteko tutkineet myös sitä? Michael: No, veikkaan ... Tarkoitan 297 00:32:18,120 --> 00:32:22,230 tietenkin mitä olisimme halunneet näyttää, oli se, että miten vuodetaan salasanoja, 298 00:32:22,230 --> 00:32:27,720 eikö? Jos kirjottaisit vaikka "sudo". Salasanojen kohdalla kyseessä 299 00:32:27,720 --> 00:32:35,620 on omanlaisensa dynamiikka. Painat näppäintä... kirjoitat salasanan eri tavoin 300 00:32:35,620 --> 00:32:40,470 kuin normaalisti avainsanoja. Ja sitten se muuttuu vaikeammaksi, kun halutaan 301 00:32:40,470 --> 00:32:45,870 tutkia laajemmin kuinka käyttäjät kirjoit- tavat salasanoja, täytyy joko kysyä 302 00:32:45,870 --> 00:32:51,030 heidän oikeita salasanoja -joka ei ole kovin eettistä- tai opettaa heille erilaisia 303 00:32:51,030 --> 00:32:57,600 salasanoja. Ja sekin on vaikeaa, koska he voivat omaksua erilaisen tyylin 304 00:32:57,600 --> 00:33:03,180 kuinka kirjoittavat salasanoja ennemmin kuin ne olisivat oikeita salasanoja. 305 00:33:03,180 --> 00:33:09,580 Ja tietenkin sama olisi kyseessä yleisesti komentojen kohdalla, eikä meillä ollut 306 00:33:09,580 --> 00:33:13,050 käytössä sanavarastoa totuttaaksemme sellaista hyökkäystä. 307 00:33:13,050 --> 00:33:18,880 Juontaja: Kiitos! Mikrofoni yksi! K: Terve. Kiitos esityksestä! Haluaisin 308 00:33:18,880 --> 00:33:27,180 kysyä: Alkuperäinen SSH-aikoja käsittelevä tutkimus on vuodelta 2001? 309 00:33:27,180 --> 00:33:31,270 Michael: Kyllä, totta. Todellakin! K: Onko sinulla käsitystä miksi ei ole 310 00:33:31,270 --> 00:33:37,650 kiertotapaa SSH-asiakkaan puolella lisäämällä "pehmustetta" tai satunnaista 311 00:33:37,650 --> 00:33:41,980 viivettä tai jotain vastaavaa? Tiedätkö miksi tällaista ei ole toteutettu? 312 00:33:41,980 --> 00:33:46,260 Onko se jonkin teknisen rajoitteen takia vai mikä on kyseessä? 313 00:33:46,260 --> 00:33:52,752 Michael: Pelkäsimme, että 2001 ja tämän päivän välissä tapahtui jotain lisäyksiä 314 00:33:52,752 --> 00:33:59,360 jonkun viiveen tai jonkun muun suhteen. En ole varma, onko kyse vain 315 00:33:59,360 --> 00:34:04,580 vaihtokaupasta SSH-istunnon inter- aktiivisuudessa vai onko jotain 316 00:34:04,580 --> 00:34:09,450 todellista syytä tälle. Mutta tiedän, että on usein kovin vaikeaa 317 00:34:09,450 --> 00:34:15,649 lisätä keinotekoisia paketteja väliin. Koska, jos ei ole satunnaista 318 00:34:15,649 --> 00:34:21,389 ollenkaan, ei voitaisi edes suodattaa lisättyjä paketteja, jotka lisättiin 319 00:34:21,389 --> 00:34:27,289 SSH:n toimesta. Mitään muita syytä en tiedä, miksi he eivät sopeutuneet, 320 00:34:27,289 --> 00:34:34,770 tai miksi he eivät tutkineet tätä. Juontaja: Kiitos! Mikrofoni neljä. 321 00:34:34,770 --> 00:34:42,389 K: Kuinka paljon nojaatte kirjoittajien taitoihin? Mielestäni käyttäjän, kenen 322 00:34:42,389 --> 00:34:49,220 on etsittävä näppäimiä näppäimistöstä tai jonkun, joka tulee häirityksi kirjoittaessaan, 323 00:34:49,220 --> 00:34:56,520 ei ole mitään oikeaa kirjoitusmallia. 324 00:34:56,520 --> 00:35:01,900 Michael: Me oikeastaan luotamme täysin siihen, että mallin on oltava pelkistettävä. 325 00:35:01,900 --> 00:35:06,640 Kuten sanoin: Käytimme vain hyvin yksin- kertaista koneoppimisalgoritmia joka vain 326 00:35:06,640 --> 00:35:11,820 katselee edellisen sanan Euklidista etäisyyttä verrattuna uuteen sanaan 327 00:35:11,820 --> 00:35:17,260 tai uuteen saapumisaikaan, joka huomattiin. Jos se on täysin 328 00:35:17,260 --> 00:35:24,440 eriävä, tarkkuus laskee. Juontaja: Kiitos! Mikrofoni kahdeksan! 329 00:35:24,440 --> 00:35:29,120 K: Jatkokysymyksenä edelliseen. Eikö tämä tee siitä kohdistetun hyökkäyksen, 330 00:35:29,120 --> 00:35:33,220 koska täytyy opettaa koneoppimis- algoritmi tarkasti sille henkilölle, 331 00:35:33,220 --> 00:35:40,340 jolta data halutaan vuotaa? Michael: Kyllä. Tavoitteemme 332 00:35:40,340 --> 00:35:47,410 tutkimukselle ei ollut muodostaa seuraavan luokan koneoppimistunnistusta 333 00:35:47,410 --> 00:35:53,510 eri kirjoitustavoille. Me käytimme tosiasiallisesti informaatiota, jota 334 00:35:53,510 --> 00:36:01,310 käyttäjä kirjoitti, jotta profilointi muodostuisi oikein. Uskon silti, että 335 00:36:01,310 --> 00:36:06,540 voidaan ehkä yleistää. Toinen tutkimus osoittaa, että voidaan luokitella 336 00:36:06,540 --> 00:36:12,740 käyttäjät eri tyylisiin kirjoittajiin ja jos muistan oikein, he keksivät, että 337 00:36:12,740 --> 00:36:20,260 voidaan jokainen henkilö voidaan luokitella 7:ään eri luokkaan. 338 00:36:20,260 --> 00:36:26,800 Tiedän myös, että on olemassa verkko- trakkereita, jotka seuraavat kirjoitustyyliäsi 339 00:36:26,800 --> 00:36:34,530 uudelleen identifioidakseen sinut. Tavoitteena vain tarjota sinulle kohdistettuja mainoksia. 340 00:36:34,530 --> 00:36:41,400 Mutta silti, tarkoitan, että emme halunneet mennä niin syvälle kehittääksemme 341 00:36:41,400 --> 00:36:45,550 tätä koko juttua. Juontaja: Kiitos! Ja otamme 342 00:36:45,550 --> 00:36:49,470 seuraavan kysymyksen Internetin puolelta. Signal angel: Kokeilitteko tätä koskaan 343 00:36:49,470 --> 00:36:56,240 korkean viiveen verkossa kuten internetissä? Michael: Tietenkin tukeudumme - sanotaan 344 00:36:56,240 --> 00:37:02,740 vaikka- jatkuvaan viiveeseen. Koska muuten se periaatteessa pilaisi aikautetun 345 00:37:02,740 --> 00:37:09,290 hyökkäyksemme. Kuten puhuimme RDMA:sta, sitä käytetään datakeskuksissa. Testasimme 346 00:37:09,290 --> 00:37:15,940 myös datakeskusmaisia topologioita. Se tekisi tästä luultavasti 347 00:37:15,940 --> 00:37:20,620 kovinkin haasteellista, joka tarkoittaa että pitäisi tehdä paljon toistoja, joka 348 00:37:20,620 --> 00:37:25,510 on oikeastaan huono asia, koska emme voi sanoa käyttäjille: "voisitteko kirjoittaa sen 349 00:37:25,510 --> 00:37:32,730 uudelleen koska se on profiloitava uudelleen", eikö? Joten vastaus on: Ei. 350 00:37:32,730 --> 00:37:39,520 Juontaja: Kiitos! Mikki yksi, kiitos. K: Jos uhri liittää jotain 351 00:37:39,520 --> 00:37:44,760 SSH-istuntoon. Voitaisiinko hyökkäys toteuttaa silloin onnistuneesti? 352 00:37:44,760 --> 00:37:51,200 Michael: Ei. Jos liität jonkin jutun, se lähetetään tunnuksena 353 00:37:51,200 --> 00:37:54,310 kun painetaan enter. K: Okei, kiitos! 354 00:37:54,310 --> 00:37:59,920 Juontaja: Kiitos! Enkelit kertovat, että mikrofonin kuusi takana on henkilö, jota 355 00:37:59,920 --> 00:38:03,020 en ollenkaan voi nähdä valaistuksen takia. 356 00:38:03,020 --> 00:38:08,410 K: Jos ymmärsin oikein, hyökkääjä voi nähdä, että jokin paketti saapui 357 00:38:08,410 --> 00:38:13,490 heidän NIC:iin. Jos menossa on toinenkin SSH-istunto samaan aikaan kohteena 358 00:38:13,490 --> 00:38:18,210 olevassa koneessa, häiritseekö se hyökkäystä? 359 00:38:18,210 --> 00:38:23,910 Michael: Kyllä, täysin! Edes SSH-pakettien erottaminen normaalista 360 00:38:23,910 --> 00:38:31,840 verkkopaketeista on haastavaa. Joten käytämme tässä heuristiikkaa, koska 361 00:38:31,840 --> 00:38:37,505 SSH-paketteja lähtee aina kaksi peräkkäin. Eli ei vain yksi, 362 00:38:37,505 --> 00:38:43,800 vaan kaksi. Jätin tämän kohdan pois yksin- kertaistaakseni esitystä. Tukeudumme myös 363 00:38:43,800 --> 00:38:48,990 tällaiseen heuristiikkaan suodattaaksemme SSH-paketteja. Ja jos olisi toinenkin 364 00:38:48,990 --> 00:38:54,850 SSH-istunto, voisin kuvitella, että se onnistuisi ollenkaan... eli emme voi 365 00:38:54,850 --> 00:39:05,140 erottaa kumman SSH-istunto oli kyseessä. Juontaja: Kiitos. Mikki seitsemän taas! 366 00:39:05,140 --> 00:39:11,760 K: Mainitsit, että käytitte aina kahta yhdistäjää, kuten- mitä ne olivatkaan? NIC? 367 00:39:11,760 --> 00:39:15,970 Michael: Kyllä, juuri niin. K: Täytyykö niiden olla kaksi eri osaa? 368 00:39:15,970 --> 00:39:21,210 Voisivatko ne olla sama? Vai miten se toimii? Michael: Järjestelyssämme käytimme yhtä 369 00:39:21,210 --> 00:39:27,461 NIC:iä, joka kykeni tekemään RDMA:ta. Meidän tapauksessa, se oli Fabric eli 370 00:39:27,461 --> 00:39:31,950 IinfiniBand. Ja toinen niistä oli tavallinen ethernet-yhteys. 371 00:39:31,950 --> 00:39:36,910 K: Mutta voisivatko ne olla samassa tai voisiko molemmat olla InfiniBand esimerkiksi? 372 00:39:36,910 --> 00:39:43,400 Michael: Kyllä. Tarkoitan, että InfiniBand ei käytä rengaspuskuria 373 00:39:43,400 --> 00:39:49,720 joten meidän tulisi keksiä jokin toinen seuraamistapa jotta saisimme sen. 374 00:39:49,720 --> 00:39:54,020 Siitä voisi muodostua vieläkin monimutkaisempaa, koska se ohittaa 375 00:39:54,020 --> 00:39:58,730 Kernelin. Mutta, jos olisi olemassa ennustettava kaava, voisimme ehkä tehdä sen. 376 00:39:58,730 --> 00:40:03,730 Juontaja: Kiitos. Mikki yksi? 377 00:40:03,730 --> 00:40:08,840 K: Terve taas! Haluaisin kysyä, tiedän ettei pääkohteenne ollut 378 00:40:08,840 --> 00:40:13,710 tutkimuksesi, mutta onko sinulla arviota, siitä kuinka käytännöllinen tämä hyökkäys on? 379 00:40:13,710 --> 00:40:20,050 Kuten, jos teette tosi elämän simulaation ettekä valmisteltua? 380 00:40:20,050 --> 00:40:23,190 Kuinka iso ongelma se voisi olla? Mitä uskoisit, mikä on 381 00:40:23,190 --> 00:40:27,170 tämän alan huippu? Miltä tällainen riski tuntuu? 382 00:40:27,170 --> 00:40:30,300 Michael: Viittaa ilmeisesti vain näppäinhyökkäykseen, eikö? 383 00:40:30,300 --> 00:40:34,330 K: Aikautushyökkäykseen. SSH aikoihin. Ei välttämättä välimuistiin liittyvään. 384 00:40:34,330 --> 00:40:40,500 Michael: Alkuperäinen tutkimus on ollut esillä vuodesta 2001. 385 00:40:40,500 --> 00:40:45,900 Ja sen jälkeen moni tutkija on osoittanut, näppäinhyökkäyksen mahdolliseksi 386 00:40:45,900 --> 00:40:52,180 erilaisissa skenaarioissa, esimerkiksi JavaScripti on yksi. Se on 387 00:40:52,180 --> 00:40:56,820 aina hieman haastavaa arvioida, koska eri tutkijat käyttävät erilaisia 388 00:40:56,820 --> 00:41:03,340 datasettejä, joten niitä ei voida vertailla. Yleisesti ottaen, olemme käyttäneet 389 00:41:03,340 --> 00:41:09,400 Melko suurta sanavarastoa ja se toimi silti. Ei kovin tarkasti, mutta se 390 00:41:09,400 --> 00:41:15,910 toimi silti. Joten, kyllä. Luulen, että se on mahdollista. Mutta ollakseen oikea 391 00:41:15,910 --> 00:41:21,210 hyökkäys, jossa hyökkääjä tavoittelee korkeaa tarkkuutta, tarvittaisiin varmaankin 392 00:41:21,210 --> 00:41:25,950 paljon dataa ja siltikin kehittyneempiä tekniikoita. Joita on kuitenkin olemassa. 393 00:41:25,950 --> 00:41:29,970 On olemassa pari erilaista koneoppimis- tekniikkaa, joita voitaisiin käyttää, 394 00:41:29,970 --> 00:41:34,180 joilla on eri hyödyt ja haitat. K: Kiitos. 395 00:41:34,180 --> 00:41:39,750 Juontaja: Kiitos! Naiset ja herrat! Mies, joka nimesi hyökkäyksen 396 00:41:39,750 --> 00:41:44,737 "netCAT": Michael Kurth! Annetaan hänelle isot aplodit, olkaa hyvä! 397 00:41:44,737 --> 00:41:58,042 (aplodeja) Michael: Kiitos paljon! 398 00:41:57,048 --> 00:42:01,400 ♪ (36C3 outromusiikki) ♪ 399 00:42:01,400 --> 00:42:05,530 Translated by Lauri Lyytinen (ITKST56 course assignment at JYU.FI) 400 00:42:05,530 --> 00:42:16,000 Subtitles created by c3subtitles.de in the year 2021. Join, and help us!