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äsytapa 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 suurenomoinen! 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 grup osana
Pro gradu -tutkimustani. Hieman itsetä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 tunnettin 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 pavelimen
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 moittettomasti — 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
kirjoittamssa yksityisessä SSH-istunnossa.
Kuuolstaa 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
tutkimuskelle annetaan nimi. Ja jos olette
seuranneet InfoSecin twitteriä tarkasti,

54
00:05:48,180 --> 00:05:53,930
tunnistatte varmaan mistä olen puhumassa.
Koska miedä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 himean 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 tukimuk-
semme varsinaisesti kiinnostavimpiin

66
00:07:15,250 --> 00:07:22,460
asioihin! Nopea hamottelu: 
Aion ensin kertoa taustoista eli

67
00:07:22,460 --> 00:07:28,240
välimuistihyökkäykset yleisesti. Sitten 
DDIO ja RDMA, tärketä 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 pakottamlla 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 jeattuna 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 keskusmistista 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
paikaktietoa ohjelmissa. Moderneissa CPU:issa
on yleensä 3-kerroksinen välimusitihierarkia:

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
aiheittaa 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 teknikka, jota

85
00:09:15,700 --> 00:09:20,980
käytimme verkkoympäsristössä. 
Haluan paikaisesti 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
keksusmuistista 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 skaalutuvuudeksi. 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 infastruktuurisi

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
mustiprotokollat 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 jeattu 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 vekon 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, voimem 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 viiemisellä 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
kahtavä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? Koksa

180
00:19:33,750 --> 00:19:39,420
niistä me olemme kiinostuneita! 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 nette 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
nistä 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


233
00:25:11,960 --> 00:25:17,550


234
00:25:17,550 --> 00:25:21,330


235
00:25:21,330 --> 00:25:26,590


236
00:25:26,590 --> 00:25:32,910


237
00:25:32,910 --> 00:25:40,050


238
00:25:40,050 --> 00:25:47,090


239
00:25:47,090 --> 00:25:52,880


240
00:25:52,880 --> 00:25:58,900


241
00:25:58,900 --> 00:26:02,450


242
00:26:02,450 --> 00:26:09,500


243
00:26:09,500 --> 00:26:15,580


244
00:26:15,580 --> 00:26:22,930


245
00:26:22,930 --> 00:26:30,750


246
00:26:30,750 --> 00:26:35,730


247
00:26:35,730 --> 00:26:43,840


248
00:26:43,840 --> 00:26:54,610


249
00:26:54,610 --> 00:27:00,851


250
00:27:00,851 --> 00:27:07,600


251
00:27:07,600 --> 00:27:15,470


252
00:27:15,470 --> 00:27:21,030


253
00:27:21,030 --> 00:27:27,630


254
00:27:27,630 --> 00:27:34,060


255
00:27:34,060 --> 00:27:39,890


256
00:27:39,890 --> 00:27:45,480


257
00:27:45,480 --> 00:27:51,260


258
00:27:51,260 --> 00:27:58,080


259
00:27:58,080 --> 00:28:04,720


260
00:28:04,720 --> 00:28:10,590


261
00:28:10,590 --> 00:28:19,790


262
00:28:19,790 --> 00:28:24,350


263
00:28:24,350 --> 00:28:41,600


264
00:28:41,600 --> 00:28:48,010


265
00:28:48,010 --> 00:28:53,620


266
00:28:53,620 --> 00:29:05,450


267
00:29:05,450 --> 00:29:10,330


268
00:29:10,330 --> 00:29:16,860


269
00:29:16,860 --> 00:29:22,960


270
00:29:22,960 --> 00:29:30,260


271
00:29:30,260 --> 00:29:37,130


272
00:29:37,130 --> 00:29:42,640


273
00:29:42,640 --> 00:29:50,500


274
00:29:50,500 --> 00:30:00,430


275
00:30:00,430 --> 00:30:10,250


276
00:30:10,250 --> 00:30:17,420


277
00:30:17,420 --> 00:30:22,540


278
00:30:22,540 --> 00:30:26,950


279
00:30:26,950 --> 00:30:29,640


280
00:30:29,640 --> 00:30:36,550


281
00:30:36,550 --> 00:30:43,250


282
00:30:43,250 --> 00:30:51,631


283
00:30:51,631 --> 00:30:55,730


284
00:30:55,730 --> 00:31:03,320


285
00:31:03,320 --> 00:31:10,900


286
00:31:10,900 --> 00:31:20,419


287
00:31:20,419 --> 00:31:25,740


288
00:31:25,740 --> 00:31:33,090


289
00:31:33,090 --> 00:31:38,480


290
00:31:38,480 --> 00:31:46,970


291
00:31:46,970 --> 00:31:52,740


292
00:31:52,740 --> 00:31:58,220


293
00:31:58,220 --> 00:32:02,720


294
00:32:02,720 --> 00:32:08,920


295
00:32:08,920 --> 00:32:13,750


296
00:32:13,750 --> 00:32:18,120


297
00:32:18,120 --> 00:32:22,230


298
00:32:22,230 --> 00:32:27,720


299
00:32:27,720 --> 00:32:35,620


300
00:32:35,620 --> 00:32:40,470


301
00:32:40,470 --> 00:32:45,870


302
00:32:45,870 --> 00:32:51,030


303
00:32:51,030 --> 00:32:57,600


304
00:32:57,600 --> 00:33:03,180


305
00:33:03,180 --> 00:33:09,580


306
00:33:09,580 --> 00:33:13,050


307
00:33:13,050 --> 00:33:18,880


308
00:33:18,880 --> 00:33:27,180


309
00:33:27,180 --> 00:33:31,270


310
00:33:31,270 --> 00:33:37,650


311
00:33:37,650 --> 00:33:41,980


312
00:33:41,980 --> 00:33:46,260


313
00:33:46,260 --> 00:33:52,752


314
00:33:52,752 --> 00:33:59,360


315
00:33:59,360 --> 00:34:04,580


316
00:34:04,580 --> 00:34:09,450


317
00:34:09,450 --> 00:34:15,649


318
00:34:15,649 --> 00:34:21,389


319
00:34:21,389 --> 00:34:27,289


320
00:34:27,289 --> 00:34:34,770


321
00:34:34,770 --> 00:34:42,389


322
00:34:42,389 --> 00:34:49,220


323
00:34:49,220 --> 00:34:56,520


324
00:34:56,520 --> 00:35:01,900


325
00:35:01,900 --> 00:35:06,640


326
00:35:06,640 --> 00:35:11,820


327
00:35:11,820 --> 00:35:17,260


328
00:35:17,260 --> 00:35:24,440


329
00:35:24,440 --> 00:35:29,120


330
00:35:29,120 --> 00:35:33,220


331
00:35:33,220 --> 00:35:40,340


332
00:35:40,340 --> 00:35:47,410


333
00:35:47,410 --> 00:35:53,510


334
00:35:53,510 --> 00:36:01,310


335
00:36:01,310 --> 00:36:06,540


336
00:36:06,540 --> 00:36:12,740


337
00:36:12,740 --> 00:36:20,260


338
00:36:20,260 --> 00:36:26,800


339
00:36:26,800 --> 00:36:34,530


340
00:36:34,530 --> 00:36:41,400


341
00:36:41,400 --> 00:36:45,550


342
00:36:45,550 --> 00:36:49,470


343
00:36:49,470 --> 00:36:56,240


344
00:36:56,240 --> 00:37:02,740


345
00:37:02,740 --> 00:37:09,290


346
00:37:09,290 --> 00:37:15,940


347
00:37:15,940 --> 00:37:20,620


348
00:37:20,620 --> 00:37:25,510


349
00:37:25,510 --> 00:37:32,730


350
00:37:32,730 --> 00:37:39,520


351
00:37:39,520 --> 00:37:44,760


352
00:37:44,760 --> 00:37:51,200


353
00:37:51,200 --> 00:37:54,310


354
00:37:54,310 --> 00:37:59,920


355
00:37:59,920 --> 00:38:03,020


356
00:38:03,020 --> 00:38:08,410


357
00:38:08,410 --> 00:38:13,490


358
00:38:13,490 --> 00:38:18,210


359
00:38:18,210 --> 00:38:23,910


360
00:38:23,910 --> 00:38:31,840


361
00:38:31,840 --> 00:38:37,505


362
00:38:37,505 --> 00:38:43,800


363
00:38:43,800 --> 00:38:48,990


364
00:38:48,990 --> 00:38:54,850


365
00:38:54,850 --> 00:39:05,140


366
00:39:05,140 --> 00:39:11,760


367
00:39:11,760 --> 00:39:15,970


368
00:39:15,970 --> 00:39:21,210


369
00:39:21,210 --> 00:39:27,461


370
00:39:27,461 --> 00:39:31,950


371
00:39:31,950 --> 00:39:36,910


372
00:39:36,910 --> 00:39:43,400


373
00:39:43,400 --> 00:39:49,720


374
00:39:49,720 --> 00:39:54,020


375
00:39:54,020 --> 00:39:58,730


376
00:39:58,730 --> 00:40:03,730


377
00:40:03,730 --> 00:40:08,840


378
00:40:08,840 --> 00:40:13,710


379
00:40:13,710 --> 00:40:20,050


380
00:40:20,050 --> 00:40:23,190


381
00:40:23,190 --> 00:40:27,170


382
00:40:27,170 --> 00:40:30,300


383
00:40:30,300 --> 00:40:34,330


384
00:40:34,330 --> 00:40:40,500


385
00:40:40,500 --> 00:40:45,900


386
00:40:45,900 --> 00:40:52,180


387
00:40:52,180 --> 00:40:56,820


388
00:40:56,820 --> 00:41:03,340


389
00:41:03,340 --> 00:41:09,400


390
00:41:09,400 --> 00:41:15,910


391
00:41:15,910 --> 00:41:21,210


392
00:41:21,210 --> 00:41:25,950


393
00:41:25,950 --> 00:41:29,970


394
00:41:29,970 --> 00:41:34,180


395
00:41:34,180 --> 00:41:39,750


396
00:41:39,750 --> 00:41:44,737


397
00:41:44,737 --> 00:41:58,042


398
00:41:57,048 --> 00:42:01,400


399
00:42:01,400 --> 00:42:16,000