Return to Video

36C3 - Practical Cache Attacks from the Network and Bad Cat Puns

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

more » « less
Video Language:
English
Duration:
42:16

Finnish subtitles

Revisions Compare revisions