WEBVTT

00:00:01.000 --> 00:00:05.000
Translated by Lauri Lyytinen
(ITKST56 course assignment at JYU.FI)

00:00:05.000 --> 00:00:19.500
♪ (36C3 intromusiikki) ♪

00:00:19.500 --> 00:00:26.220
Juontaja: Seuraavan esityksen aihe on 
käytännön välimuistihyökkäykset verkossa

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

00:00:33.960 --> 00:00:42.640
ensimmäinen laatuaan. Hän on tutkimuksen
pääkirjoittaja ja hänen esityksensä

00:00:42.640 --> 00:00:47.470
tulee olemaan suurenmoinen! Meille on
luvattu huonoja sanaleikkejä kissoista ja

00:00:47.470 --> 00:00:52.750
odotan niitä sinulta. Annetaan iso käsi
Michael Kurthille!

00:00:52.750 --> 00:00:58.690
(taputusta)

00:00:58.690 --> 00:01:03.800
Michael: Hei kaikille ja paljon kiitoksia
kun pääsitte kuuntelemaan esitystäni.

00:01:03.800 --> 00:01:08.780
Nimeni on Michael ja haluan jakaa kansanne
tutkimuksemme, jonka toteuttamisen

00:01:08.780 --> 00:01:15.659
mahdollisti mahtava VUSec group osana
Pro gradu -tutkimustani. Hieman itsestäni.

00:01:15.659 --> 00:01:20.260
Suoritin tietotekniikan maisteriopintojani
ETH Zürichin ja pystyin tekemään graduni

00:01:20.260 --> 00:01:27.869
Amsterdamissa. Nykyään työskentelen
turvallisuusanalyytikkona infoGuardilla.

00:01:27.869 --> 00:01:33.450
Tässä näette ihmiset, jotka oikeasti
mahdollistivat tämän tutkimuksen.

00:01:33.450 --> 00:01:37.869
He ovat esimiehiäni ja tutkimus-
kollegoitani, jotka tukivat minua

00:01:37.869 --> 00:01:43.500
koko ajan ja panostivat aikaa ja vaivaa
tutkimukseen. Joten he ovat oikeat

00:01:43.500 --> 00:01:50.990
rokkistarat tämän tutkimuksen taustalla.
Mutta aloitetaanpa välimuistiyökkäyksistä.

00:01:50.990 --> 00:01:56.850
Tapa tunnettiin paikallisesti suoritet-
tavan koodin hyökkäyksenä. Esimerkiksi

00:01:56.850 --> 00:02:03.679
vasemmalla näkyvässä virtuaaliympäristössä
on kaksi virtuaalikonetta, jotka jakavat

00:02:03.679 --> 00:02:10.270
laitteiston. Eli ne jakavat aikapaikat 
CPU:n ja välimuistin osalta. Siksi

00:02:10.270 --> 00:02:18.120
VM2 käyttävä hyökkääjä voi suorittaa 
välimuistihyökkäyksen VM1 vastaan. Samoin

00:02:18.120 --> 00:02:23.100
myös JavaScriptillä. Haitallinen skripti
syötetään selaimelle, joka sitten

00:02:23.100 --> 00:02:28.030
suorittaa sen. Koska se jakaa resursseja
koneen kanssa se voi myös

00:02:28.030 --> 00:02:33.330
hyökätä muihin prosesseihin. 
Tämä JavaScript tapa luo tunteen

00:02:33.330 --> 00:02:39.340
verkon yli tapahtuvasta toiminnasta, eikö?
Mutta se vaatii skriptin suorittamisen

00:02:39.340 --> 00:02:46.170
koneellasi ollakseen oikeasti onnistunut.
Joten halusimme kehittää tätä ja toteuttaa

00:02:46.170 --> 00:02:54.060
oikean välimuistihyökkäyksen verkon yli.
Tässä perusasetelmassa asiakas käyttää SSH

00:02:54.060 --> 00:03:00.790
yhteyttä palvelimeen ja meillä on kolmas,
hyökkääjän käyttämä kone. Kuten tulen

00:03:00.790 --> 00:03:08.360
tänään todistamaan, voimme murtaa tämän 
SSH-istunnon luottamuksen käyttämällä

00:03:08.360 --> 00:03:13.269
kolmatta konetta ilman haitallista koodia
tai ohjelman suorittamista asiakkaalla

00:03:13.269 --> 00:03:20.540
tai palvelimella. Lisäksi palvelimen
CPU:lla ei ole mitään tekemistä tämän

00:03:20.540 --> 00:03:25.390
välimuistihyökkäyksen kanssa. Joten se
vain on, eikä huomaa, kun siltä vuotaa

00:03:25.390 --> 00:03:34.689
salaisuuksia. Katsotaanpa hieman tarkemmin.
Tässä meillä on kiva kissa suorittamassa

00:03:34.689 --> 00:03:41.409
SSH-istuntoa palvelimen kanssa ja aina, 
kun kissa painaa nappia yksi paketti

00:03:41.409 --> 00:03:49.700
lähtee palvelimelle. Tämä toteutuu aina
interaktiivisessa SSH-istunnossa. Kuten

00:03:49.700 --> 00:03:56.530
nimikin kertoo, se luo interaktiivisuuden
tunteen. Kun kurkkaamme hieman

00:03:56.530 --> 00:04:01.459
konepellin alle nähdäksemme mitä palveli-
mella tapahtuu, huomamme näiden pakettien

00:04:01.459 --> 00:04:06.950
oikeasti aktivoivan viimeisen tason 
välimuistia (LLC). Tästä lisää hieman

00:04:06.950 --> 00:04:13.349
myöhemmin. Nyt hyökkääjä toteuttaa saman-
aikaisen välimuistihyökkäyksen LLC:een

00:04:13.349 --> 00:04:19.340
vain lähettämällä verkkoliikennepaketteja.
Ja näin voimme oikeasti vuotaa

00:04:19.340 --> 00:04:28.020
saapumisajat yksittäisistä SSH-paketeista.
Nyt varmaan kysyt itseltäsi miten

00:04:28.020 --> 00:04:36.800
SSH-pakettien saapumisajat vaikuttavat
SSH-istunnon luottamuksellisuuteen. No,

00:04:36.800 --> 00:04:43.210
ihmisillä on omintakeisia tapoja kirjoit-
taa. Ja tässä näemme esimerkin käyttäjän

00:04:43.210 --> 00:04:50.460
kirjoittaessa sanaa "because". Huomamme,
että E:n painallus B:n jälkeen on nopeampi

00:04:50.460 --> 00:04:56.870
kuin esimerkiksi C A:n jälkeen. Tämä
voidaan yleistää ja sitä voidaan käyttää

00:04:56.870 --> 00:05:03.960
tilastollisessa analyysissä. Näillä orans-
seilla pisteillä, jos saamme mallinnettua

00:05:03.960 --> 00:05:10.530
saapumisajat moitteettomasti — ja mitä
moitteeton tarkoittaa: voimme mallintaa

00:05:10.530 --> 00:05:16.270
tarkat ajat, kun käyttäjä näppäili —,
voimme toteuttaa tämän tilastollisen

00:05:16.270 --> 00:05:22.690
analyysin saapumisien välisistä ajoista.
Ja näin voimme vuotaa mitä olit

00:05:22.690 --> 00:05:29.809
kirjoittamassa yksityisessä SSH-istunnossa.
Kuulostaa pelottavalta ja futuristiselta,

00:05:29.809 --> 00:05:36.580
mutta minä selkeytän asian esityksen 
aikana. Hyvä! Haluan tuoda yhden seikan

00:05:36.580 --> 00:05:42.730
esille heti näin alussa: Kuten on tapana
ja kirjoittamien helpottamiseksi

00:05:42.730 --> 00:05:48.180
tutkimukselle annetaan nimi. Ja jos olette
seuranneet InfoSecin twitteriä tarkasti,

00:05:48.180 --> 00:05:53.930
tunnistatte varmaan mistä olen puhumassa.
Koska meidän tapauksessa nimesimme

00:05:53.930 --> 00:06:00.740
tutkimuksen NetCAT:ksi. Tämä oli tietenkin
sanaleikki. Tässä NetCAT tarkoittaa

00:06:00.740 --> 00:06:08.560
"Network Cache Attack" ja se oli tietenkin
huumoria, joka voi joskus kostautua.

00:06:08.560 --> 00:06:17.830
Ja tässä tapauksessa se kostautui pahasti.
Näin saimme aikaan hieman twitter-draamaa

00:06:17.830 --> 00:06:24.400
viime syyskuussa. Yksi tykätyimmistä 
twiiteistä tutkimukseen liittyen oli

00:06:24.400 --> 00:06:32.889
Jakelta. Nämä esitykset ovat hyviä, koska 
tällaiset twiitit voidaan henkilöidä ja

00:06:32.889 --> 00:06:42.599
kyllä: Minä olen tämä idiootti. Korjataanpa
tämä! Intel tunnusti työmme palkitsemalla

00:06:42.599 --> 00:06:48.720
ja lisäksi CVE-numerolla, joten nykyään
voimme vain käyttää CVE-numeroa. Tai,

00:06:48.720 --> 00:06:54.479
jos se on hankalaa, twitter draaman 
aikana joku lähetti meille tällaisen

00:06:54.479 --> 00:06:59.800
kivan pienen vaihtoehtoisen nimen ja
lisäsi logon, josta minä jopa pidän.

00:06:59.800 --> 00:07:09.240
Sen nimi on NeoCAT. Jokatapuksessa,
opimme läksymme nimeämisjutusta.

00:07:09.240 --> 00:07:15.250
Siirrytäänpä eteenpäin. Palataan tutkimuk-
semme varsinaisesti kiinnostavimpiin

00:07:15.250 --> 00:07:22.460
asioihin! Nopea hahmottelu: 
Aion ensin kertoa taustoista eli

00:07:22.460 --> 00:07:28.240
välimuistihyökkäykset yleisesti. Sitten 
DDIO ja RDMA, tärkeät teknologiat joita

00:07:28.240 --> 00:07:34.330
hyväksikäytimme verkon yli tapahtuvassa
hyökkäyksessä. Sitten itse hyökkäys ja kuinka

00:07:34.330 --> 00:07:42.190
käänteisesti suunnittelimme DDIO:n, 
päästä-päähän hyökkäys ja pieni demo.

00:07:42.190 --> 00:07:47.050
Välimuistihyökkäykset perustuvat mikro-
arkkitehtuurin tilan havainnointiin, jonka

00:07:47.050 --> 00:07:53.160
pitäisi säilyä salassa ohjelmistolta. Tämä
onnistuu pakottamalla jaetut resurssit

00:07:53.160 --> 00:07:59.759
vuotamaan tietoa. Analogiana voidaan pitää
kassakaapin murtamista stetoskoopilla,

00:07:59.759 --> 00:08:06.300
jossa jaettuna resurssina on ilma, 
joka välittää lukosta tulevat äänet

00:08:06.300 --> 00:08:11.990
kun sitä käsitellään. Tämä tapahtuu
jokseenkin samalla tavalla

00:08:11.990 --> 00:08:21.949
tietokoneissa. Mutta, nyt vain välimuis-
tissa. Välimuisti ratkaisee pahatkin

00:08:21.949 --> 00:08:28.389
viiveongelmat keskusmuistista ladattaessa,
eikö? Nämä tekevät karkeasti neljänneksen

00:08:28.389 --> 00:08:34.320
kaikista komennoista. Ja välimuistin avulla
voimme käyttää uudelleen datan ja käyttää

00:08:34.320 --> 00:08:41.980
paikkatietoa ohjelmissa. Moderneissa CPU:issa
on yleensä 3-kerroksinen välimuistihierarkia:

00:08:41.980 --> 00:08:47.041
L1 on jaettu datan ja komentoväli-
muistin kanssa. L2, ja sitten L3, joka

00:08:47.041 --> 00:08:54.290
on jaettu ytimien kesken. Jos käsiteltävä
data on jo ladattu välimuistiin, se

00:08:54.290 --> 00:08:58.780
aiheuttaa välimuistiosuman. Jos data
pitää ladata keskusmuistista, sitä pidetään

00:08:58.780 --> 00:09:06.290
välimuistihutina. Joten, miten saame 
oikeasti tietää milloin tapahtuu osuma tai

00:09:06.290 --> 00:09:11.549
huti? Koska emme voi lukea dataa 
suoraan välimuistista. Voimme tehdä

00:09:11.549 --> 00:09:15.700
tämän esimerkiksi alustamalla ja 
tutkaamalla. Se on tunnettu tekniikka, jota

00:09:15.700 --> 00:09:20.980
käytimme verkkoympäristössä. 
Haluan pikaisesti kertoa siitä, mitä

00:09:20.980 --> 00:09:26.430
tässä tapahtuu. Alustamisen ja tutkaamisen 
ensimmäisessä vaiheessa hyökkääjä saattaa

00:09:26.430 --> 00:09:33.860
välimuistin tunnettuun tilaan. Periaat-
teessa alustaa välimuistin. Se täyttää sen

00:09:33.860 --> 00:09:42.310
omalla datallaan, jonka jälkeen hyökkääjä
odottaa uhrin toimia. Viimeinen vaihe on

00:09:42.310 --> 00:09:49.040
tutkaaminen, joka tekee alustamisen 
uudelleen, mutta tällä kertaa mittaa

00:09:49.040 --> 00:09:56.260
kirjautumisajat. Nopeat osumat tar-
koittavat ettei välimuistia oltu muutettu

00:09:56.260 --> 00:10:02.750
välissä. Ja hutiosumat tuottavat, 
kuten nyt tiedämme, että uhri

00:10:02.750 --> 00:10:10.270
on todella käyttänyt yhtä välimuistiriviä
alustuksen ja tutkaamisen välissä.

00:10:10.270 --> 00:10:15.750
Mitä voimme siis tehdä näillä osumilla ja
hutiosumilla? Voimme analysoida niitä!

00:10:15.750 --> 00:10:21.410
Tämä aikatieto kertoo meille paljon
uhrin käyttäytymisestä ja ohjelmista.

00:10:21.410 --> 00:10:28.519
Perustuen pelkästään osumiin ja huteihin
voimme— tai tutkijat pystyivät —vuotamaan

00:10:28.519 --> 00:10:35.829
salausavaimistoja, arvaamaan nettisaitteja
tai muistin sisältöä. Näin siis SPECTRE:llä

00:10:35.829 --> 00:10:42.260
ja MELTDOWN:lla. Katsotaanpa kuinka oike-
astaan saamme toteutettua hyökkäyksen

00:10:42.260 --> 00:10:50.550
verkon yli! Toinen tärkeistä teknologioista
on DDIO. Mutta ensin haluan kertoa DMA:sta

00:10:50.550 --> 00:10:55.420
koska se on kuin sen edeltäjä. 
DMA on periaatteessa teknologia, joka

00:10:55.420 --> 00:11:02.010
sallii PCIe-laitteen, kuten esimerkiksi
verkkokortin, vaikuttaa suoraan

00:11:02.010 --> 00:11:08.519
keskusmuistiin ilman CPU:n keskeytystä.
Joten esimerkiksi, jos paketti on

00:11:08.519 --> 00:11:14.339
vastaanotettu, PCIe-laite vain laittaa
sen keskusmuistiin ja sitten, kun

00:11:14.339 --> 00:11:19.110
ohjelma tai sovellus haluaa käyttää dataa,
silloin se voi hakea sen keskusmuistista.

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

00:11:27.089 --> 00:11:33.110
laittaa suoraan dataa viimeisen tasan
välimuistiin. Tämä on hienoa, sillä nyt

00:11:33.110 --> 00:11:38.620
kun sovellus työskentelee datan kanssa,
sen ei tarvitse tehdä kallisarvoista hakua

00:11:38.620 --> 00:11:43.910
keskusmuistista vaan se voi suoraan
työstää dataa — tai noutaa sen —

00:11:43.910 --> 00:11:52.010
LLC:sta. DDIO tarkoittaa "Data Direct
I/O Technology" ja se on käytössä

00:11:52.010 --> 00:11:58.560
kaikissa Intelin palvelintason prosesso-
rissa vuodesta 2012 lähtien. Se on päällä

00:11:58.560 --> 00:12:04.069
oletuksena ja läpinäkyvä ajureille ja 
käyttöjärjestelmille. Arvaan ettei monikaan

00:12:04.069 --> 00:12:09.279
edes huomannut, että jokin muuttui kone-
pellin alla. Muutos oli kuitenkin hyvin

00:12:09.279 --> 00:12:17.100
merkittävä. Miksi oikeastaan DDIO:ta
tarvitaan? Se on käytössä suorituskyvyn

00:12:17.100 --> 00:12:23.489
takia. Tässä meillä on kiva Intelin 
tutkimus, joka alimpana osoittaa

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

00:12:29.090 --> 00:12:35.750
Ja meillä on läpimenoajat niille.
Kuten voitte nähdä tässä tumman sinisellä

00:12:35.750 --> 00:12:42.850
että ilman DDIO:ta se pysäyttää 
skaalautuvuuden 4 NIC:n jälkeen.

00:12:42.850 --> 00:12:47.890
Vaaleansinisellä voimme nähdä että skaalau-
tuvuus jatkuu verkkokortteja lisättäessä.

00:12:47.890 --> 00:12:56.770
Niinpä DDIO on rakennettu erityisesti
verkkosovellusten skaalautuvuudeksi. Toinen

00:12:56.770 --> 00:13:02.250
teknologia, jota hyväksikäytämme on RDMA.
Se tarkoittaa "Remote Direct Memory Access"

00:13:02.250 --> 00:13:08.750
ja se pohjimmiltaan purkaa 
siirtokerroksen tehtävät piirilevylle.

00:13:08.750 --> 00:13:15.390
Se on periaatteessa Kernelin ohitus. Eikä
siinä ole CPU käyttöä, jolloin ohjelmisto

00:13:15.390 --> 00:13:23.520
voi käyttää etänä muistia ilman, että
kuluttaa CPU aikaa palvelimella.

00:13:23.520 --> 00:13:28.329
Toin tähän lyhyen kuvauksen RDMA:sta
tarkasteltavaksi. Tässä vasemmalla meillä

00:13:28.329 --> 00:13:34.230
on toiminnon aloittaja ja oikealla meillä
on kohdepalvelin. Muistialue

00:13:34.230 --> 00:13:39.670
määräytyy palvelimen avauksessa ja tästä
eteen päin ohjelmistot voivat tehdä

00:13:39.670 --> 00:13:44.490
tiedonsiirtoa ilman vaikutusta verkko-
ohjelmistopinoon. Eli nyt on tehty

00:13:44.490 --> 00:13:52.779
TCP/IP pino kokonaisuudessaan. Yksipuoli-
sissa RDMA operaatioissa sallitaan myös

00:13:52.779 --> 00:13:59.740
toiminnon aloittajan lukea ja kirjoittaa
mielivaltaisiin kohtiin määrätyssä tilassa

00:13:59.740 --> 00:14:06.880
kohteessa. Lainaan nyt lausuntoa 
eräältä markkinajohtajalta näistä korkean

00:14:06.880 --> 00:14:12.900
suorituskyvyn käärmeistä: "Lisäksi, 
välimuisti etä-CPU:ssa ei täyty

00:14:12.900 --> 00:14:20.639
käytetyllä muistisisällöllä." No, tämä
ei pidä enää paikkaansa DDIO:n kohdalta ja

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"?

00:14:28.540 --> 00:14:33.749
Voin kertoa, että RDMA on yksi niistä
teknologioista joista et kuule

00:14:33.749 --> 00:14:38.780
kovinkaan usein, mutta ovat oikeasti laa-
jassa käytössä datakeskusten backendissa

00:14:38.780 --> 00:14:45.509
ja pilvi-infrastruktuurissa. Joten voit
saada omat RDMA infrastruktuuriksi

00:14:45.509 --> 00:14:52.550
julkisesta pilvestä, kuten Azurelta, 
Oraclelta, Huaweilta tai AliBabalta. Myös

00:14:52.550 --> 00:14:59.230
muistiprotokollat kuten SMB ja NFS voivat
tukea RDMA:ta. Muita ohjelmistoja ovat

00:14:59.230 --> 00:15:07.320
Suurtehotietokoneet, Big Data, kone-
oppiminen, datakeskukset, pilvi ja muut.

00:15:07.320 --> 00:15:12.810
Mennäänpä tarkemmin tutkimuksen sisältöön
ja siihen, kuinka hyväksikäytimme näitä

00:15:12.810 --> 00:15:19.339
kahta teknologiaa. Tiedämme nyt, että
meillä on verkolle avoin jaettu resurssi

00:15:19.339 --> 00:15:26.291
DDIO:n ansiosta ja RDMA antaa meillä tar-
vittavat luku- ja kirjoitusoikeudet tehdäksemme

00:15:26.291 --> 00:15:34.310
välimuistihyökkäyksen verkon yli. Mutta
ensin meidän täytyy selkeyttää pari asiaa.

00:15:34.310 --> 00:15:39.320
Tietenkin teimme monia kokeita ja 
testasimme laajasti DDIO porttia

00:15:39.320 --> 00:15:44.630
ymmärtääksemme sen salat. Mutta tässä
toin mukanani kaksi isoa kysymystä,

00:15:44.630 --> 00:15:50.420
joihin meidän on vastattava. Ensinnäkin
tietysti, voimmeko erottaa välimuistin

00:15:50.420 --> 00:15:57.860
osumat ja hutiosumat verkon yli? Meillä
on edelleen verkkoviive ja pakettijonotus

00:15:57.860 --> 00:16:04.020
ja niin edelleen. Olisiko todella mahdol-
lista saada ajoitus oikein? Se on kuitenkin

00:16:04.020 --> 00:16:09.040
ehdoton vaatimus avatakseen sivukanavan.
Ja niinpä toinen kysymys on sitten:

00:16:09.040 --> 00:16:14.240
Voimmeko oikeasti päästä käsiksi LLC:hen?
Tämä liittyy ennemminkin

00:16:14.240 --> 00:16:20.589
hyökkäyspintaan kuin itse hyökkäykseen.
Niinpä ensimmäiseen kysymykseen voimme

00:16:20.589 --> 00:16:26.640
vastata tällä yksinkertaisella kokeella:
Vasemmalla meillä on erittäin pieni koodin

00:16:26.640 --> 00:16:33.180
palanen. Meillä on ajastettu RDMA luku
tiettyyn offsettiin. Sitten kirjoitamme

00:16:33.180 --> 00:16:41.850
siihen offsettiin ja luemme sen uudelleen
samasta offsetista. Kuten näette, kun

00:16:41.850 --> 00:16:46.040
teemme tämän vaikka 50 000 kertaa useisiin
eri offsetteihin, voimme selkeästi

00:16:46.040 --> 00:16:52.000
erottaa kaksi eri jakaumaa. 
Sininen vastaa dataa, joka oli

00:16:52.000 --> 00:16:58.149
haettu muistista ja oranssi on 
dataa, joka oli haettu LLC:sta

00:16:58.149 --> 00:17:03.250
verkon yli. Voimme myös nähdä verkon
vaikutukset toimintaan.

00:17:03.250 --> 00:17:09.820
Esimerkiksi, voimme nähdä pitkät hännät,
jotka liittyvät joihinkin paketteihin, jotka

00:17:09.820 --> 00:17:16.430
hidastuivat verkossa tai olivat jonossa.
Sivuhuomautuksena kaikille sivukanava

00:17:16.430 --> 00:17:23.280
asiantuntijoille: Tarvitsemme todella 
kirjoitusoikeuden, koska DDIO luku ei

00:17:23.280 --> 00:17:30.290
kohdenna mitään LLC:hen. Periaatteessa
tämä on perusta jonka avulla

00:17:30.290 --> 00:17:36.030
suoritamme alustamisen ja tutkaamisen
verkon yli. Tarvitsemme kuitenkin vielä

00:17:36.030 --> 00:17:40.500
todellisen kohteen profiilin rakenta-
miseksi. Katsotaanpa millainen

00:17:40.500 --> 00:17:46.350
hyökkäyspinta meillä onkaan. Tämä tuokin
meidät kysymykseen: voimmeko päästä

00:17:46.350 --> 00:17:51.470
täysin LLC:hen sisälle? 
Epäonneksemme näin ei tapahdu.

00:17:51.470 --> 00:17:58.930
DDIO:ssa kohdennukset on rajoitettu
kahteen kohtaan. Tässä esimerkissä 20:stä.

00:17:58.930 --> 00:18:08.080
Joten noin 10%. Eikä se ole määritetty
kohta, jota CPU käyttää. Meillä olisi

00:18:08.080 --> 00:18:16.610
pääsy vain 10 prosenttiin CPU:n toimin- 
noista välimustin viimeisellä tasolla.

00:18:16.610 --> 00:18:22.560
Tämäei toiminut kovin hyvinensimmäisenä 
hyökkäyksenä. Mutta hyvä uutinen on, että

00:18:22.560 --> 00:18:31.760
muut PCIe-laitteet—kuten vaikkapa toinen
verkkokortti—käyttävät samoja kahta

00:18:31.760 --> 00:18:38.780
välimuistin kohtaa. Ja niinpä meillä
on 100% näkyvyys mitä muut PCIe-laitteet

00:18:38.780 --> 00:18:48.690
tekevät välimuistissa. Katsotaanpa päästä-
päähän hyökkäystä! Kuten jo mainitsin

00:18:48.690 --> 00:18:54.050
aiemmin, meillä on asiakkaan ja palvelimen
perusjärjestely. Ja meillä on kone,

00:18:54.050 --> 00:19:01.470
jota me, hyökkääjänä, hallitsemme.
Niinpä asiakas vain lähettää tämän

00:19:01.470 --> 00:19:06.770
paketin normaalisti ethernet NIC:nä ja 
siellä on myös toinen NIC liitettynä

00:19:06.770 --> 00:19:15.410
palvelimeen, mikä sallii hyökkääjän 
suorittaa RDMA-operaatioita. Tiedämme myös

00:19:15.410 --> 00:19:19.960
että kaikki paketit... tai kaikki näppäin-
painallukset, jotka käyttäjä tekee,

00:19:19.960 --> 00:19:25.540
lähtevät yksittäisinä paketteina, jotka
aktivoituvat alimman tason välimuistissa

00:19:25.540 --> 00:19:33.750
DDIO:n läpi. Mutta miten voimme nyt saada
näiden pakettien tuloajat? Koska

00:19:33.750 --> 00:19:39.420
niistä me olemme kiinnostuneita! Nyt 
meidän on katsottava tarkemmin miten

00:19:39.420 --> 00:19:46.830
tämä verkkoliikenne pakettien saapuminen
oikein toimii. IP pinossa on rengaspuskuri,

00:19:46.830 --> 00:19:52.960
joka periaatteessa suorittaa
asynkronisia operaatioita

00:19:52.960 --> 00:20:01.720
laitteiston- eli NIC:N- ja CPU:n välissä.
Kun paketti saapuu, se sijoittaa paketin

00:20:01.720 --> 00:20:07.530
rengaspuskurin ensimmäiseen paikkaan. 
Oikealla näette näkymän hyökkääjän

00:20:07.530 --> 00:20:13.700
näkökulmasta, joka voi vain seurata väli-
muistin toimintaa. Näemme, että muistirivi

00:20:13.700 --> 00:20:18.930
ensimmäisessä paikassa syttyy. Näemme siis
toimintaa siinä. Voisi olla myös välimuistin

00:20:18.930 --> 00:20:24.750
rivillä 2, tätä... emme tiedä mille riville
tämä oikeastaan ilmestyy. Mutta,

00:20:24.750 --> 00:20:29.200
tärkeintä on: Mitä tapahtuu
toiselle paketille? Sillä toinen

00:20:29.200 --> 00:20:35.380
paketti sytyttää myös yhden muistiriveistä,
mutta toisen tällä kertaa. Se on oikeastaan

00:20:35.380 --> 00:20:41.760
seuraava rivi ensimmäiseen pakettiin ver-
rattuna. Jos teemme tämän kolmannelle

00:20:41.760 --> 00:20:51.310
ja neljännelle paketille, huomamme, että
meillä on kaunis porraskuvio. Nyt voimme

00:20:51.310 --> 00:20:56.940
nähdä ennustettavan kaavan, jota voimme 
hyväksikäyttää saadaksemme tietoa pakettien

00:20:56.940 --> 00:21:04.290
saapuessa. Ja tämä vain siksi, että 
rengaspuskuri on varattu tavalla,

00:21:04.290 --> 00:21:10.300
joka ei kiellä itseään, eikö? Se ei kiellä
kun toinen paketti saapuu. Se ei

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ä

NOTE Paragraph

00:21:16.660 --> 00:21:22.260
koska nyt voimme muodostaa laadukkaan pro-
fiilin. Katsotaan elävän elämän esimerkki.

00:21:22.260 --> 00:21:28.010
Tässä on välimuistin toiminta kun se vas-
taanottaa jatkuvia pingejä. Voitte nähdä

00:21:28.010 --> 00:21:34.750
hienon porraskuvion ja näette myös, että
rengaspuskuri uudelleenkäyttää paikkoja

00:21:34.750 --> 00:21:40.650
koska se on rengas. Nyt on 
tärkeää tietää, että rengaspuskuri

00:21:40.650 --> 00:21:48.940
ei pidä datasisältöä vaan ainoastaan
datakuvauksen. Ja se käytetään uudelleen

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ä.

00:21:55.520 --> 00:22:00.000
Koska muutenhan tämä olisi 
selvä peli ja voisimme edetä sillä.

00:22:00.000 --> 00:22:05.780
Koska käyttäjä kirjoittaa, meillä on 
enemmän viivettä pakettien välillä.

00:22:05.780 --> 00:22:11.470
Yleisesti ottaen emme voi tietää milloin
käyttäjä näppäilee, joten täytyy profiloida

00:22:11.470 --> 00:22:16.060
jatkuvasti saadaksemme ajoitukset kohdil-
leen. Joten, meidän rakennettava hieman

00:22:16.060 --> 00:22:23.880
kehittyneempi järjestely. Se on periaat-
tessa kaksi-vaiheinen järjestely, joka

00:22:23.880 --> 00:22:31.520
koostuu verkkotrackerista, joka vain 
seuraa useita välimuistirivejä

00:22:31.520 --> 00:22:37.990
jatkuvasti. Ja kun se huomaa 
tietyn muistirivin tulevan

00:22:37.990 --> 00:22:44.300
aktiiviseksi, se siirtää sen ikkunan 
eteenpäin seuraavaan kohtaan, jossa

00:22:44.300 --> 00:22:50.260
se arvaa aktivoinnin tapahtuvan. Tämä
onnistuu, koska meillä on etu nopeudessa.

00:22:50.260 --> 00:22:57.090
Meidän on profiloitava paljon nopeammin
kuin SSH-istunnon verkkopaketit saapuvat.

00:22:57.090 --> 00:23:00.710
Tässä vasemmalla voitte nähdä
kuvituksen siitä, mitä

00:23:00.710 --> 00:23:07.260
verkkotrackeri tekee. Se vain profiloi
tätä ikkunaa, joka näkyy punaisella.

00:23:07.260 --> 00:23:15.030
Jos katsotte tarkasti, voitte nähdä
kirkkaamman kohdan keskellä, joka

00:23:15.030 --> 00:23:19.690
tarkoittaa saapuneitta verkkopaketteja.
Voitte myös nähdä, että siellä on paljon

00:23:19.690 --> 00:23:27.280
kohinaa mukana ja siksi emme 
voi suoraan saada pakettien

00:23:27.280 --> 00:23:35.250
saapumisaikoja siitä. Siksi tarvitsemme 
toisen vaiheen. Offline poimijan.

00:23:35.250 --> 00:23:40.590
Offline poimija vastaa todennäköisimpien
tapahtumien laskennasta, joissa tekijänä

00:23:40.590 --> 00:23:46.010
on käyttäjän SSH-paketti. Se käyttää
verkkotrackerin keräämää dataa ja

00:23:46.010 --> 00:23:52.451
rengaspuskurin ennustettavuutta.
Sitten se esittää pakettien

00:23:52.451 --> 00:23:59.380
saapumisien väliajat eri sanoille 
kuten tässä oikealla. Hienoa. Nyt

00:23:59.380 --> 00:24:04.900
olemme jälleen tilanteessa, jossa meillä
on pelkät saapumisajat muttei sanoja,

00:24:04.900 --> 00:24:10.040
joita me tarvitsemme rikkoaksemme 
SSH-istunnon luottamuksellisuuden.

00:24:10.040 --> 00:24:19.260
Kuten totesin aiemmin, käyttäjillä tai 
oikeastaan ihmisillä on omalaatuinen

00:24:19.260 --> 00:24:27.330
kirjoitustapa. Ja sen avulla me onnis-
tuimme tilastollisessa hyökkäyksessä.

00:24:27.330 --> 00:24:33.060
Lähemmin tarkasteltuna käytämme kone-
oppimista ja kartoitusta käyttäjien

00:24:33.060 --> 00:24:39.340
kirjotustyylien ja oikeiden sanojen välillä.
Lopulta voimme todeta ne kaksi sanaa,

00:24:39.340 --> 00:24:48.090
jotka kirjoitit SSH-istunnossasi. Käytimme
20:tä kohdehenkilöä, jotka kirjoittivat

00:24:48.090 --> 00:24:55.830
vapaasti ja käsikirjoituksen mukaan ja
saimme 4574 uniikkia sanaa. Ja jokainen

00:24:55.830 --> 00:25:01.230
niistä edusti pistettä moniulotteisessa
tilassa. Ja käytimme todella

00:25:01.230 --> 00:25:06.431
yksinkertaista koneoppimistekniikkaa, kuten
"k-nearest neighbour" algoritmia, joka

00:25:06.431 --> 00:25:11.960
luokittelee mittauksia Euklidisen tilan
kannalta muihin sanoihin.

00:25:11.960 --> 00:25:17.550
Syy, miksi käytimme hyvin yksinkertaista
koneoppialgoritmia oli se,

00:25:17.550 --> 00:25:21.330
että halusimme vain todistaa, että 
signaalin, jota yritimme ottaa talteen

00:25:21.330 --> 00:25:26.590
välimuistista olisi oikeasti kyllin vahva
hyökkäyksen toteuttamiseksi. Emme halunneet

00:25:26.590 --> 00:25:32.910
yleisesti parantaa tällaista käyttäjien ja
kirjoittamiskäytöksen välistä kartoitusta.

00:25:32.910 --> 00:25:40.050
Katsotaanpa miten tämä onnistui!
Eli aluksi, tässä vasemmalla

00:25:40.050 --> 00:25:47.090
näette meidän käyttäneen luokittelua
puhtaalle näppäilydatalle. Tarkoittaa, että

00:25:47.090 --> 00:25:52.880
käytimme vain kirjoituksen aikana lähetet-
tyä signaalia. Eli kun painalluksia tehtiin

00:25:52.880 --> 00:25:58.900
paikallisella näppäimistöllä. Tämä antaa
täydellistä ja tarkkaa aikadataa. Voimme

00:25:58.900 --> 00:26:02.450
nähdä, että tämä on aika vaikeaa
käyttää. Tarkkuudeksi saamme

00:26:02.450 --> 00:26:09.500
karkeasti 35%. Mutta, jos katsomme kor-
keinta 10:tä prosenttia, joka tarkoittaa,

00:26:09.500 --> 00:26:15.580
että hyökkääjä arvaa kymmenen sanaa ja
oikea sana kuuluu joukkoon, sitten sen

00:26:15.580 --> 00:26:22.930
todetaan olevan tarkka. Ja kymmenellä
parhaalla arvauksella saamme tarkkuudeksi

00:26:22.930 --> 00:26:30.750
58%. Tämä on vain puhdasta näppäily-
dataa. Sitten käytimme samaa dataa ja

00:26:30.750 --> 00:26:35.730
samaa luokittelua verkon yli tulevaan
signaaliin. Tämä ei tietenkään ole yhtä

00:26:35.730 --> 00:26:43.840
tarkkaa, koska siinä on kohinaa ja voimme
lisätä tai kadottaa näppäinpainalluksia.

00:26:43.840 --> 00:26:54.610
Tarkkuus on karkeasti 11% vähemmän ja
parhaan 10:n tarkkuus karkeasti 60%.

00:26:54.610 --> 00:27:00.851
Kun käytimme yksinkertaista koneoppimista,
useita koehenkilöitä ja suhteellisen

00:27:00.851 --> 00:27:07.600
laajaa sanakirjastoa, uskomme pystyvämme
todistamaan, että signaali on kyllin vahva

00:27:07.600 --> 00:27:15.470
toteuttaaksemme hyökkäyksen. Tietenkin
haluamme nähdä tämän nyt toiminnassa,

00:27:15.470 --> 00:27:21.030
eikö? Koska olen hieman hermostunut täällä
lavalla, en näytä livedemoa koska se

00:27:21.030 --> 00:27:27.630
vaatisi, että kirjoittaisin itse ja se 
varmaankin sekoittaisi minua ja

00:27:27.630 --> 00:27:34.060
tietenkin koneoppimismallia.
Siksipä toin mukanani videon.

00:27:34.060 --> 00:27:39.890
Tässä oikealla näette uhrin.
Se aloittaa kohta

00:27:39.890 --> 00:27:45.480
SSH-istunnon. Ja vasemmalla puolella
näette hyökkääjän.

00:27:45.480 --> 00:27:51.260
Alalaidassa näätte verkkotrakkerin ja 
ylälaidassa näätte poimijan,

00:27:51.260 --> 00:27:58.080
sekä toivottavasti ennustetut sanat. Nyt 
uhri aloittaa SSH-istunnon

00:27:58.080 --> 00:28:04.720
palvelimeen nimeltä "father". Ja hyök-
kääjä, joka käyttää konetta "son"

00:28:04.720 --> 00:28:10.590
aloittaa hyökkäyksen. Näitte, että profi-
loimme rengaspuskurin kohdan ja nyt

00:28:10.590 --> 00:28:19.790
uhri alkaa kirjoittaa. Ja koska tällä jär-
jestelyllä kestää hieman käsitellä sanat

00:28:19.790 --> 00:28:24.350
ja tehdä oikea ennustus, näette kohta,
että pikkuhiljaa sanat alkavat

00:28:24.350 --> 00:28:41.600
muodostumaan oikeaan -toivottavasti 
oikeaan- järjestykseen. Kuten näette, voimme

00:28:41.600 --> 00:28:48.010
arvata oikeat sanat verkon yli vain
lähettämällä verkkopaketteja

00:28:48.010 --> 00:28:53.620
samaan palvelimeen. Ja näin saamme 
tärkeän informaation kun sen

00:28:53.620 --> 00:29:05.450
SSH- paketit saapuvat.
(aplodeja)

00:29:05.450 --> 00:29:10.330
Nyt varmaan kysyt itseltäsi: Miten tältä
hyökkäykseltä suojaudutaan? Noh,

00:29:10.330 --> 00:29:16.860
onneksi tämä koskee vain palvelintason
prosessoreja, eli ei asiakkaita tai muita.

00:29:16.860 --> 00:29:22.960
Mutta meidän mielestämme oikea suo-
jautuminen tällä hetkellä on DDIO:n poistaminen

00:29:22.960 --> 00:29:30.260
tai ettei käytä RDMA:ta. Molemmat vaikuttavat
suorituskykyyn paljonkin. DDIO:n kohdalla

00:29:30.260 --> 00:29:37.130
puhutaan karkeasti 10-18% vähemmän suori-
tuskykyä riippuen tietenkin ohjelmistosta.

00:29:37.130 --> 00:29:42.640
Ja, jos päätät olla käyttämättä RDMA:ta,
joudut varmaankin uudelleenkirjoittamaan

00:29:42.640 --> 00:29:50.500
koko ohjelmasi. Intel kertoi asian hieman
toisin tiedoksiannon julkaisussaan.

00:29:50.500 --> 00:30:00.430
Lukekaapa itse! "Epäluotettavan verkon"
määritelmä voi varmaankin

00:30:00.430 --> 00:30:10.250
olla hieman kyseenalainen. No joo.
Sillä mennään. Olen todella ylpeä,

00:30:10.250 --> 00:30:17.420
että meidät hyväksyttiin Security and 
Privacy 2020:een. Myös Intel tunnusti

00:30:17.420 --> 00:30:22.540
löydöksemme, julkistustilaisuus oli 
syyskuussa, ja saimme myös rahapalkinnon.

00:30:22.540 --> 00:30:26.950
(yksittäinen huuto katsomossa)

00:30:26.950 --> 00:30:29.640
(naurua)
Oheislaitteiden lisääntynyt suorituskyky on

00:30:29.640 --> 00:30:36.550
pakottanut Intelin asettamaan LLC:n
nopeisiin I/O polkuihin prosessoreissa.

00:30:36.550 --> 00:30:43.250
Ja näin on paljastunut yhä enemmän
mikroarkkitehtuurikomponentteja, joiden

00:30:43.250 --> 00:30:51.631
tunnistamme vaikuttavan suoraan turvalli-
suuteen. Tutkimuksemme on ensimmäinen

00:30:51.631 --> 00:30:55.730
DDIO sivukanavahaavoittuvuus, mutta uskom-
me raapaisseemme tässä vain pintaa.

00:30:55.730 --> 00:31:03.320
Muistakaa, että niihin liittyy monia PCIe-
laitteita! Joten siellä voi olla

00:31:03.320 --> 00:31:10.900
muistilaitteita - voitaisiin profiloida
välimuistin toimintaa muistilaitteissa!

00:31:10.900 --> 00:31:20.419
On olemassa jopa GPUDirect, joka
antaa pääsyn GPU:n välimuistiin.

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ää

00:31:25.740 --> 00:31:33.090
eli pysykää kuulolla! Totean enää 
vain, että iso kiitos kaikille

00:31:33.090 --> 00:31:38.480
ja tietenkin kaikille vapaaehtoisille
täällä konferenssissa. Kiitos!

00:31:38.480 --> 00:31:46.970
(aplodeja)

00:31:46.970 --> 00:31:52.740
Juontaja: Kiitos, Michael! Meillä on aikaa
kysymyksille. Eli voitte muodostaa jonoa

00:31:52.740 --> 00:31:58.220
mikrofoneille. Ja näenkin jonkun
mikrofonilla seitsemän!

00:31:58.220 --> 00:32:02.720
Kysymys: Kiitos esityksestä! Minulla
on kysymys - kun työskentelen

00:32:02.720 --> 00:32:08.920
verkon yli SSH:ta käyttämällä, en 
kovinkaan usein käytä noin helppoja sanoja,

00:32:08.920 --> 00:32:13.750
mutta yleensä se on jotain omituisempaa,
kuten valuuttamerkkejä, viivoja ja jotain.

00:32:13.750 --> 00:32:18.120
Oletteko tutkineet myös sitä?
Michael: No, veikkaan ... Tarkoitan

00:32:18.120 --> 00:32:22.230
tietenkin mitä olisimme halunneet näyttää,
oli se, että miten vuodetaan salasanoja,

00:32:22.230 --> 00:32:27.720
eikö? Jos kirjottaisit vaikka "sudo".
Salasanojen kohdalla kyseessä

00:32:27.720 --> 00:32:35.620
on omanlaisensa dynamiikka. Painat
näppäintä... kirjoitat salasanan eri tavoin

00:32:35.620 --> 00:32:40.470
kuin normaalisti avainsanoja. Ja sitten se
muuttuu vaikeammaksi, kun halutaan

00:32:40.470 --> 00:32:45.870
tutkia laajemmin kuinka käyttäjät kirjoit-
tavat salasanoja, täytyy joko kysyä

00:32:45.870 --> 00:32:51.030
heidän oikeita salasanoja -joka ei ole
kovin eettistä- tai opettaa heille erilaisia

00:32:51.030 --> 00:32:57.600
salasanoja. Ja sekin on vaikeaa, koska
he voivat omaksua erilaisen tyylin

00:32:57.600 --> 00:33:03.180
kuinka kirjoittavat salasanoja ennemmin
kuin ne olisivat oikeita salasanoja.

00:33:03.180 --> 00:33:09.580
Ja tietenkin sama olisi kyseessä yleisesti
komentojen kohdalla, eikä meillä ollut

00:33:09.580 --> 00:33:13.050
käytössä sanavarastoa totuttaaksemme
sellaista hyökkäystä.

00:33:13.050 --> 00:33:18.880
Juontaja: Kiitos! Mikrofoni yksi!
K: Terve. Kiitos esityksestä! Haluaisin

00:33:18.880 --> 00:33:27.180
kysyä: Alkuperäinen SSH-aikoja käsittelevä
tutkimus on vuodelta 2001?

00:33:27.180 --> 00:33:31.270
Michael: Kyllä, totta. Todellakin!
K: Onko sinulla käsitystä miksi ei ole

00:33:31.270 --> 00:33:37.650
kiertotapaa SSH-asiakkaan puolella
lisäämällä "pehmustetta" tai satunnaista

00:33:37.650 --> 00:33:41.980
viivettä tai jotain vastaavaa? Tiedätkö
miksi tällaista ei ole toteutettu?

00:33:41.980 --> 00:33:46.260
Onko se jonkin teknisen rajoitteen takia
vai mikä on kyseessä?

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ä

00:33:52.752 --> 00:33:59.360
jonkun viiveen tai jonkun muun suhteen. 
En ole varma, onko kyse vain

00:33:59.360 --> 00:34:04.580
vaihtokaupasta SSH-istunnon inter-
aktiivisuudessa vai onko jotain

00:34:04.580 --> 00:34:09.450
todellista syytä tälle. Mutta tiedän, 
että on usein kovin vaikeaa

00:34:09.450 --> 00:34:15.649
lisätä keinotekoisia paketteja väliin.
Koska, jos ei ole satunnaista

00:34:15.649 --> 00:34:21.389
ollenkaan, ei voitaisi edes suodattaa
lisättyjä paketteja, jotka lisättiin

00:34:21.389 --> 00:34:27.289
SSH:n toimesta. Mitään muita syytä en
tiedä, miksi he eivät sopeutuneet,

00:34:27.289 --> 00:34:34.770
tai miksi he eivät tutkineet tätä.
Juontaja: Kiitos! Mikrofoni neljä.

00:34:34.770 --> 00:34:42.389
K: Kuinka paljon nojaatte kirjoittajien
taitoihin? Mielestäni käyttäjän, kenen

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,

00:34:49.220 --> 00:34:56.520
ei ole mitään oikeaa kirjoitusmallia.

00:34:56.520 --> 00:35:01.900
Michael: Me oikeastaan luotamme täysin
siihen, että mallin on oltava pelkistettävä.

00:35:01.900 --> 00:35:06.640
Kuten sanoin: Käytimme vain hyvin yksin-
kertaista koneoppimisalgoritmia joka vain

00:35:06.640 --> 00:35:11.820
katselee edellisen sanan Euklidista 
etäisyyttä verrattuna uuteen sanaan

00:35:11.820 --> 00:35:17.260
tai uuteen saapumisaikaan, joka 
huomattiin. Jos se on täysin

00:35:17.260 --> 00:35:24.440
eriävä, tarkkuus laskee.
Juontaja: Kiitos! Mikrofoni kahdeksan!

00:35:24.440 --> 00:35:29.120
K: Jatkokysymyksenä edelliseen. Eikö 
tämä tee siitä kohdistetun hyökkäyksen,

00:35:29.120 --> 00:35:33.220
koska täytyy opettaa koneoppimis-
algoritmi tarkasti sille henkilölle,

00:35:33.220 --> 00:35:40.340
jolta data halutaan vuotaa?
Michael: Kyllä. Tavoitteemme

00:35:40.340 --> 00:35:47.410
tutkimukselle ei ollut muodostaa
seuraavan luokan koneoppimistunnistusta

00:35:47.410 --> 00:35:53.510
eri kirjoitustavoille. Me käytimme 
tosiasiallisesti informaatiota, jota

00:35:53.510 --> 00:36:01.310
käyttäjä kirjoitti, jotta profilointi 
muodostuisi oikein. Uskon silti, että

00:36:01.310 --> 00:36:06.540
voidaan ehkä yleistää. Toinen tutkimus 
osoittaa, että voidaan luokitella

00:36:06.540 --> 00:36:12.740
käyttäjät eri tyylisiin kirjoittajiin ja 
jos muistan oikein, he keksivät, että

00:36:12.740 --> 00:36:20.260
voidaan jokainen henkilö voidaan
luokitella 7:ään eri luokkaan.

00:36:20.260 --> 00:36:26.800
Tiedän myös, että on olemassa verkko-
trakkereita, jotka seuraavat kirjoitustyyliäsi

00:36:26.800 --> 00:36:34.530
uudelleen identifioidakseen sinut. Tavoitteena
vain tarjota sinulle kohdistettuja mainoksia.

00:36:34.530 --> 00:36:41.400
Mutta silti, tarkoitan, että emme halunneet
mennä niin syvälle kehittääksemme

00:36:41.400 --> 00:36:45.550
tätä koko juttua.
Juontaja: Kiitos! Ja otamme

00:36:45.550 --> 00:36:49.470
seuraavan kysymyksen Internetin puolelta.
Signal angel: Kokeilitteko tätä koskaan

00:36:49.470 --> 00:36:56.240
korkean viiveen verkossa kuten internetissä?
Michael: Tietenkin tukeudumme - sanotaan

00:36:56.240 --> 00:37:02.740
vaikka- jatkuvaan viiveeseen. Koska muuten
se periaatteessa pilaisi aikautetun

00:37:02.740 --> 00:37:09.290
hyökkäyksemme. Kuten puhuimme RDMA:sta, 
sitä käytetään datakeskuksissa. Testasimme

00:37:09.290 --> 00:37:15.940
myös datakeskusmaisia topologioita. 
Se tekisi tästä luultavasti

00:37:15.940 --> 00:37:20.620
kovinkin haasteellista, joka tarkoittaa
että pitäisi tehdä paljon toistoja, joka

00:37:20.620 --> 00:37:25.510
on oikeastaan huono asia, koska emme voi 
sanoa käyttäjille: "voisitteko kirjoittaa sen

00:37:25.510 --> 00:37:32.730
uudelleen koska se on profiloitava uudelleen",
eikö? Joten vastaus on: Ei.

00:37:32.730 --> 00:37:39.520
Juontaja: Kiitos! Mikki yksi, kiitos.
K: Jos uhri liittää jotain

00:37:39.520 --> 00:37:44.760
SSH-istuntoon. Voitaisiinko hyökkäys
toteuttaa silloin onnistuneesti?

00:37:44.760 --> 00:37:51.200
Michael: Ei. Jos liität jonkin jutun,
se lähetetään tunnuksena

00:37:51.200 --> 00:37:54.310
kun painetaan enter.
K: Okei, kiitos!

00:37:54.310 --> 00:37:59.920
Juontaja: Kiitos! Enkelit kertovat, että
mikrofonin kuusi takana on henkilö, jota

00:37:59.920 --> 00:38:03.020
en ollenkaan voi nähdä
valaistuksen takia.

00:38:03.020 --> 00:38:08.410
K: Jos ymmärsin oikein, hyökkääjä
voi nähdä, että jokin paketti saapui

00:38:08.410 --> 00:38:13.490
heidän NIC:iin. Jos menossa on toinenkin
SSH-istunto samaan aikaan kohteena

00:38:13.490 --> 00:38:18.210
olevassa koneessa, häiritseekö
se hyökkäystä?

00:38:18.210 --> 00:38:23.910
Michael: Kyllä, täysin! Edes SSH-pakettien
erottaminen normaalista

00:38:23.910 --> 00:38:31.840
verkkopaketeista on haastavaa. Joten
käytämme tässä heuristiikkaa, koska

00:38:31.840 --> 00:38:37.505
SSH-paketteja lähtee aina kaksi
peräkkäin. Eli ei vain yksi,

00:38:37.505 --> 00:38:43.800
vaan kaksi. Jätin tämän kohdan pois yksin-
kertaistaakseni esitystä. Tukeudumme myös

00:38:43.800 --> 00:38:48.990
tällaiseen heuristiikkaan suodattaaksemme
SSH-paketteja. Ja jos olisi toinenkin

00:38:48.990 --> 00:38:54.850
SSH-istunto, voisin kuvitella, että se 
onnistuisi ollenkaan... eli emme voi

00:38:54.850 --> 00:39:05.140
erottaa kumman SSH-istunto oli kyseessä.
Juontaja: Kiitos. Mikki seitsemän taas!

00:39:05.140 --> 00:39:11.760
K: Mainitsit, että käytitte aina kahta
yhdistäjää, kuten- mitä ne olivatkaan? NIC?

00:39:11.760 --> 00:39:15.970
Michael: Kyllä, juuri niin.
K: Täytyykö niiden olla kaksi eri osaa?

00:39:15.970 --> 00:39:21.210
Voisivatko ne olla sama? Vai miten se toimii?
Michael: Järjestelyssämme käytimme yhtä

00:39:21.210 --> 00:39:27.461
NIC:iä, joka kykeni tekemään RDMA:ta. 
Meidän tapauksessa, se oli Fabric eli

00:39:27.461 --> 00:39:31.950
IinfiniBand. Ja toinen niistä oli tavallinen
ethernet-yhteys.

00:39:31.950 --> 00:39:36.910
K: Mutta voisivatko ne olla samassa tai
voisiko molemmat olla InfiniBand esimerkiksi?

00:39:36.910 --> 00:39:43.400
Michael: Kyllä. Tarkoitan, että
InfiniBand ei käytä rengaspuskuria

00:39:43.400 --> 00:39:49.720
joten meidän tulisi keksiä jokin toinen
seuraamistapa jotta saisimme sen.

00:39:49.720 --> 00:39:54.020
Siitä voisi muodostua vieläkin
monimutkaisempaa, koska se ohittaa

00:39:54.020 --> 00:39:58.730
Kernelin. Mutta, jos olisi olemassa 
ennustettava kaava, voisimme ehkä tehdä sen.

00:39:58.730 --> 00:40:03.730
Juontaja: Kiitos. Mikki yksi?

00:40:03.730 --> 00:40:08.840
K: Terve taas! Haluaisin kysyä, tiedän 
ettei pääkohteenne ollut

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?

00:40:13.710 --> 00:40:20.050
Kuten, jos teette tosi elämän simulaation
ettekä valmisteltua?

00:40:20.050 --> 00:40:23.190
Kuinka iso ongelma se voisi olla?
Mitä uskoisit, mikä on

00:40:23.190 --> 00:40:27.170
tämän alan huippu? Miltä tällainen
riski tuntuu?

00:40:27.170 --> 00:40:30.300
Michael: Viittaa ilmeisesti vain
näppäinhyökkäykseen, eikö?

00:40:30.300 --> 00:40:34.330
K: Aikautushyökkäykseen. SSH aikoihin. Ei 
välttämättä välimuistiin liittyvään.

00:40:34.330 --> 00:40:40.500
Michael: Alkuperäinen tutkimus on
ollut esillä vuodesta 2001.

00:40:40.500 --> 00:40:45.900
Ja sen jälkeen moni tutkija on osoittanut,
näppäinhyökkäyksen mahdolliseksi

00:40:45.900 --> 00:40:52.180
erilaisissa skenaarioissa, esimerkiksi
JavaScripti on yksi. Se on

00:40:52.180 --> 00:40:56.820
aina hieman haastavaa arvioida, koska
eri tutkijat käyttävät erilaisia

00:40:56.820 --> 00:41:03.340
datasettejä, joten niitä ei voida vertailla.
Yleisesti ottaen, olemme käyttäneet

00:41:03.340 --> 00:41:09.400
Melko suurta sanavarastoa ja se toimi
silti. Ei kovin tarkasti, mutta se

00:41:09.400 --> 00:41:15.910
toimi silti. Joten, kyllä. Luulen, että
se on mahdollista. Mutta ollakseen oikea

00:41:15.910 --> 00:41:21.210
hyökkäys, jossa hyökkääjä tavoittelee
korkeaa tarkkuutta, tarvittaisiin varmaankin

00:41:21.210 --> 00:41:25.950
paljon dataa ja siltikin kehittyneempiä
tekniikoita. Joita on kuitenkin olemassa.

00:41:25.950 --> 00:41:29.970
On olemassa pari erilaista koneoppimis-
tekniikkaa, joita voitaisiin käyttää,

00:41:29.970 --> 00:41:34.180
joilla on eri hyödyt ja haitat.
K: Kiitos.

00:41:34.180 --> 00:41:39.750
Juontaja: Kiitos! Naiset ja herrat!
Mies, joka nimesi hyökkäyksen

00:41:39.750 --> 00:41:44.737
"netCAT": Michael Kurth! Annetaan hänelle
isot aplodit, olkaa hyvä!

00:41:44.737 --> 00:41:58.042
(aplodeja)
Michael: Kiitos paljon!

00:41:57.048 --> 00:42:01.400
♪ (36C3 outromusiikki) ♪

00:42:01.400 --> 00:42:05.530
Translated by Lauri Lyytinen
(ITKST56 course assignment at JYU.FI)

00:42:05.530 --> 00:42:16.000
Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!