1
00:00:00,000 --> 00:00:01,000
Translated by Esa Lammi
(KYBS2004 course assignment at JYU.FI)

2
00:00:01,000 --> 00:00:19,480
♪ 36c3 intromusiikki ♪

3
00:00:19,480 --> 00:00:25,090
Herald: Seuraavaksi kuulemme kuinka murretaan
PDF, murretaan salaus ja allekirjoitukset

4
00:00:25,090 --> 00:00:32,910
Puhujina Fabian Ising ja Vladislav
Mladenov. Heidän puheensa hyväksyttiin CCS

5
00:00:32,910 --> 00:00:37,750
tänä vuonna Lontoossa ja he pitivät sen
marraskuussa. Se tulee tutkimuksesta joka

6
00:00:37,750 --> 00:00:43,660
periaatteessa tuotti kaksi erilaista paperia
ja se on ollut... Ihmiset maailmanlaajuisesti

7
00:00:43,660 --> 00:00:47,540
ovat olleet kiinnostuneita mitä on ollut
meneillään. Antakaa heille suuret

8
00:00:47,540 --> 00:00:51,758
aplodit ja toivottakaa heidät
tervetulleiksi lavalle.

9
00:00:51,758 --> 00:00:59,150
Aplodeja

10
00:00:59,150 --> 00:01:11,590
Vladi: Eli kuulette minut? Yeah. Loistavaa.
OK. Nyt näette kalvot. Minun nimeni on

11
00:01:11,590 --> 00:01:15,220
Vladislav Mladenov, tai vain Vladi jos
sinulla on jotain kysymyksiä minulle ja

12
00:01:15,220 --> 00:01:20,670
tässä on Fabian. Ja meidän annetaan tänään
puhua kuinka murretaan PDFn turvallisuus

13
00:01:20,670 --> 00:01:28,230
tai tarkemmin kuinka murretaan kryptografiset
operaatiot PDF tiedostoissa. Me olemme

14
00:01:28,230 --> 00:01:36,590
suuri ryhmä Bochumin yliopistosta,
Muenster and Hackmanit GmbH:sta

15
00:01:36,590 --> 00:01:46,159
Ja kuten mainitsin. Puhumme kryptografiasta
ja PDF tiedostoista. Toimiiko se?

16
00:01:46,159 --> 00:01:57,720
Fabian: Okei. OK. Kokeillaan uudelleen.
Okei.

17
00:01:57,720 --> 00:02:02,070
Vladi: Loistavaa. Tämä esitys koostuu
kahdesta osasta. Ensimmäinen osa on

18
00:02:02,070 --> 00:02:07,829
digitaalisesti allekirjoitetuista PDF tiedostoista
ja kuinka voimme tunnistaa ne. Jos avaamme ne

19
00:02:07,829 --> 00:02:16,230
näemme informaation, että tiedosto on
allekirjoitettu ja että kaikki varmistus

20
00:02:16,230 --> 00:02:20,690
proseduurit ovat oikein. Ja lisää informaatiota
signature validation panelista

21
00:02:20,690 --> 00:02:27,220
ja tietoa kuka on allekirjoittanut tämän
tiedoston. Tämä on ensimmäinen osa

22
00:02:27,220 --> 00:02:35,660
esitystä ja minä esitän sen. Ja toinen
osa käsittelee PDF salattuja

23
00:02:35,660 --> 00:02:41,280
tiedostoja ja kuinka voimme tunnistaa
sellaiset tiedostot. Jos koitat avata sellaisen

24
00:02:41,280 --> 00:02:47,080
tiedoston, ensimmäinen asia jonka näet on
salasana kysely. Ja kun olet antanut oikean

25
00:02:47,080 --> 00:02:51,800
salasanan, tiedosto puretaan ja voit lukea
sisällön tästä tiedostosta.

26
00:02:51,800 --> 00:02:57,720
Jos avaat sen Adobella, täydentävää 
tietoa siitä

27
00:02:57,720 --> 00:03:04,420
onko tiedosto suojattu vai ei esitetään.
Ja tämä on toinen osa meidän

28
00:03:04,420 --> 00:03:11,650
esitystä, ja Fabian puhuu: Kuinka voimme
murtaa PDF salauksen?, Joten ennen kuin

29
00:03:11,650 --> 00:03:19,450
aloitamme hyökkäämään allekirjoituksiin tai
salaukseen, tarvitsemme vähän pohjatietoa.

30
00:03:19,450 --> 00:03:22,700
Ja kuuden kalvon jälkeen olette asiantuntijoita
PDF tiedostoista ja ymmärrätte

31
00:03:22,700 --> 00:03:28,820
niistä aivan kaiken. Mutta se on ehkä
hieman tylsää. Joten olkaa kärsivällisiä:

32
00:03:28,820 --> 00:03:34,830
Sitä on vain kuusi kalvoa. Ja ensimmäinen on
melko helppo. PDF tiedostot ovat.. Ensimmäinen

33
00:03:34,830 --> 00:03:42,250
määrittely oli 1993 ja miltei alusta
alkaen PDF kryptografiset operaatiot

34
00:03:42,250 --> 00:03:48,920
kuten allekirjoitus ja salaus olivat siinä.
Viimeisin versio on PDF 2.0 ja se

35
00:03:48,920 --> 00:03:57,610
julkaistiin 2017. Ja Adoben mukaan 1,6
miljardia tiedostoa on webissa ja

36
00:03:57,610 --> 00:04:06,140
mahdollisesti enemmän on webin ulkopuolella.
Joten periaatteessa PDF tiedostot ovat kaikkialla.

37
00:04:06,140 --> 00:04:11,790
Ja tämä on se syy miksi harkitsimme tätä
aihetta ja yritimme löytää tai analysoida

38
00:04:11,790 --> 00:04:19,730
näiden ominaisuuksien turvallisuutta. jos 
meillä on hyvin yksinkertainen tiedosto ja

39
00:04:19,730 --> 00:04:25,390
avaamme sen Adobe Readerilla, näemme ensin,
tietenkin sisällön. "Hello world" tässä

40
00:04:25,390 --> 00:04:32,060
tapauksessa ja lisää informaatiota tässä
sivussa ja kuinka monta

41
00:04:32,060 --> 00:04:39,630
sivua tässä dokumentissa on. Mutta mitä
tapahtuisi jos emme käyttäisi PDF lukijaa ja

42
00:04:39,630 --> 00:04:48,210
käyttäisimme vain jotain tekstieditoria.
käytämme Notepad++:aa avaamiseen ja

43
00:04:48,210 --> 00:04:56,400
myöhemmin tiedoston manipulointiin. Eli 
zoomaan tähän. Ja emmäisenä näemme, että

44
00:04:56,400 --> 00:05:04,500
voimme lukea sitä. Ehkä se on vähän, vähän 
hassua. Ja voimme silti saada jotain

45
00:05:04,500 --> 00:05:10,910
informaatiota tästä tiedostosta. Esimerkiksi
jotain tietoa sivuista. Ja tässä

46
00:05:10,910 --> 00:05:19,740
näet informaation, että PDF tiedosto koostuu
yhdestä sivusta, mutta kiinnostavampaa

47
00:05:19,740 --> 00:05:27,350
on, että näemme sisällön koko tiedostosta
itsestään. Eli opimme tässä, että

48
00:05:27,350 --> 00:05:34,960
voimme käyttää yksinkertaista tekstieditoria 
näyttämään ja muokkaamaan PDF tiedostoja.

49
00:05:34,960 --> 00:05:43,900
Ja hyökkäyksissämme käytämme vain tätä
tekstieditoria. Eli mennään yksityiskohtiin.

50
00:05:43,900 --> 00:05:51,560
Kuinka PDF tiedostot on strukturoitu ja
kuinka ne prosessoidaan. PDF tiedostot

51
00:05:51,560 --> 00:05:59,170
koostuvat 4 osasta: header, body ja body on
tärkein osa PDF tiedostoja. Body sisältää

52
00:05:59,170 --> 00:06:03,820
kaiken tiedon, joka esitetään käyttäjälle.
Ja kaksi muuta osaa ovat: Xref osio ja

53
00:06:03,820 --> 00:06:11,490
trailer. Erittäin tärkeä asia PDF
prosessoinnissa on, ettei niitä

54
00:06:11,490 --> 00:06:18,020
käsitellä ylhäältä alas vaan alhaalta ylös.
Joten ensimmäinen

55
00:06:18,020 --> 00:06:23,700
asia, jonka PDF lukija analysoi
tai prosessoi on traileri. Eli aletaan

56
00:06:23,700 --> 00:06:28,981
tekemään sitä. Mikä informaatio aloittaa
tämän trailerin? periaatteessa siinä on

57
00:06:28,981 --> 00:06:35,540
kaksi tärkeää tietoa. Ensimmäisellä
puolella tämä on se informaatio

58
00:06:35,540 --> 00:06:41,410
mikä on tämän PDF tiedoston juurielementti?
Mikä on ensimmäinen objekti joka

59
00:06:41,410 --> 00:06:47,860
prosessoidaan? Ja toinen tärkeä tieto on
mistä xref osio alkaa.

60
00:06:47,860 --> 00:06:54,000
Se on vain tavu offset, joka osoittaa XRef
osion sijainnin PDF tiedostossa.

61
00:06:54,000 --> 00:07:00,201
Eli tämä osoitin, kuten mainittu aiemmin
osoittaa XREF osioon

62
00:07:00,201 --> 00:07:05,710
Mutta mistä XRef osiossa on kyse? XRef
osio on luettelo osoittamaan

63
00:07:05,710 --> 00:07:11,180
tai sisältämään tiedon minne objektit,
jotka määritellään body:ssa on sijoitettu

64
00:07:11,180 --> 00:07:18,741
tai tavu sijainnit tähän objektiin. Eli 
kuinka voimme lukea tätä outoa XRef

65
00:07:18,741 --> 00:07:25,540
osiota? Ensimmäinen tieto jonka puramme on
että ensimmäinen objekti, joka määritellään

66
00:07:25,540 --> 00:07:34,610
tässä, on objekti jolla on ID 0 ja meillä on
5 lisä elementtiä tai objektia jotka on

67
00:07:34,610 --> 00:07:41,090
määritelty. Eli ensimmäinen objekti on tässä.
Ensimmäinen luku on tavu sijainti

68
00:07:41,090 --> 00:07:46,610
tiedostossa. Toinen on en versionumero. Ja 
viimeinen merkki kertoo, onko

69
00:07:46,610 --> 00:07:53,200
objektia käytössä vai ei. Eli luettaessa
sitä, tätä XREF osiota lukiessa saamme

70
00:07:53,200 --> 00:08:00,590
tietoa, että objekti, jonka ID on 0 on
sijainnissa tavu osoite 0 eikä se ole

71
00:08:00,590 --> 00:08:08,650
käytössä. Eli objekti, jonka id on 1 on
sijainnissa 9 ja niin edelleen. Joten

72
00:08:08,650 --> 00:08:18,370
objektille IDlla 4 ja objektinumero tulee
vain laskemalla se: 0, 1, 2, 3 ja 4

73
00:08:18,370 --> 00:08:29,430
Eli objekti IDlla 4 löydetään sijainnista
offset 184 ja se on käytössä. Toisin sanoen

74
00:08:29,430 --> 00:08:35,449
PDF lukija tietää mistä mikin objekti 
löytyy ja se voi esittää sen kunnolla

75
00:08:35,449 --> 00:08:42,329
ja prosessoida sen. Nyt tulee tärkein osa:
Body, ja mainitsin, että

76
00:08:42,329 --> 00:08:48,810
body osassa on kaikki sisältö, joka 
esitetään käyttälle sisällytettynä.

77
00:08:48,810 --> 00:08:58,220
Eli katsotaanpa. Objekti 4 0 on tämä ja 
kuten voit nähdä, se sisältää sanan

78
00:08:58,220 --> 00:09:04,870
"Hello World!". Muut objektit on ovat
mukana myös. Eli jokainen osoitin osoittaa

79
00:09:04,870 --> 00:09:10,119
täsmälleen jokaisen objektin alku
sijaintiin. Ja kuinka luemme tätä objektia?

80
00:09:10,119 --> 00:09:15,910
Katsohan, meillä on objekti joka alkaa ID
numerolla, sitten generaatio

81
00:09:15,910 --> 00:09:24,999
numero ja sana "obj". Eli nyt tiedät
mistä objekti alkaa ja mihin

82
00:09:24,999 --> 00:09:32,259
se loppuu. Nyt kuinka me voimme prosessoida
tämän body:n? Kuten mainitsin aiemmin,

83
00:09:32,259 --> 00:09:40,970
trailerissa on tieto juuri elementistä ja
tämä elementti oli ID numerolla 1

84
00:09:40,970 --> 00:09:48,769
ja generaationumerolla 0. Eli me alamme nyt
lukemaan dokumenttia tästä ja meillä on

85
00:09:48,769 --> 00:09:55,910
katalogi ja viittaukset joihinkin sivuihin.
Sivut ovat vain kuvaus kaikista sivuista

86
00:09:55,910 --> 00:10:02,889
jotka ovat mukana tiedostossa. Ja voimme
nähdä tässä, että meillä on tämä numerointi

87
00:10:02,889 --> 00:10:09,779
kunhan, tai meillä on vain yksi sivu ja
viittaus sivuobjektiin, joka sisältää

88
00:10:09,779 --> 00:10:15,170
kokonaisuudessaan tiedon sivun
kirjoituksesta. Jos meillä on

89
00:10:15,170 --> 00:10:22,230
useita sivuja, sitten meillä on monia
elementtejä. Sitten meillä on yksi sivu.

90
00:10:22,230 --> 00:10:29,850
Ja tässä meillä on sisältö, joka on viittaus
merkkijonoon, jonka jo näimme.

91
00:10:29,850 --> 00:10:35,139
Hienoa. Jos ymmärsit tämän, sitten tiedät
kaiken tai lähes kaiken PDF

92
00:10:35,139 --> 00:10:39,360
tiedostoista. Nyt voit vain ottaa editorisi
ja avata sellaisia tiedostoja ja analysoida

93
00:10:39,360 --> 00:10:50,310
niitä. Sitten tarvitsemme yhden ominaisuuden.
Unohdin viimeisen osan. Yksinkertaisimman osan.

94
00:10:50,310 --> 00:10:56,129
Headeri. Sen pitäisi olla vain yksi rivi,
joka kertoo mitä versiota käytetään. Esim.

95
00:10:56,129 --> 00:11:04,779
Meidän tapauksessa, 1.4. Viimeisessä Adoben
versiossa tässä sanotaan 2.0. Nyt tarvitsemme

96
00:11:04,779 --> 00:11:13,699
ominaisuuden nimeltä "Incremental Update".
Ja kutsun tätä ominaisuutta -Tiedättekö tämän

97
00:11:13,699 --> 00:11:19,629
ominaisuuden korostamaan jotain PDF
tiedostossa tai lisätä muistilappuja.

98
00:11:19,629 --> 00:11:24,119
Teknisesti sitä kutsutaan nimellä "Incremental 
Update" Minä kutsun sitä arvioinniksi gradu

99
00:11:24,119 --> 00:11:30,680
tai kanditöissä oppilailleni, sillä tämä on
tapa jolla toimin. Minä luen tekstin

100
00:11:30,680 --> 00:11:38,100
ja korostan jotain ja tallennan
tiedon, jonka lisään siihen.

101
00:11:38,100 --> 00:11:46,970
Teknisesti muistilapun lisäämällä. Tämä
lisä informaatio liitetään tiedoston lopun

102
00:11:46,970 --> 00:11:53,160
jälkeen. Eli meillä on boby päivitys
joka sisältää juuri tiedon

103
00:11:53,160 --> 00:12:01,369
informaation lisäyksestä, uudet objektit
ja, tietenkin, uuden XREF osion ja

104
00:12:01,369 --> 00:12:15,610
uuden trailerin, joka osoittaa tähän uuteen
objektiin. Okei, olemme valmiita. Liittyen

105
00:12:15,610 --> 00:12:23,860
tähän osittaiseen päivitykseen, näimme että
sitä pääasiassa käytettiin lappuihin ja korostuksiin.

106
00:12:23,860 --> 00:12:29,679
Mutta havaitsimme jotain todella tärkeää,
koska osittaisessa päivityksessä voimme

107
00:12:29,679 --> 00:12:36,930
uudelleen määritellä nykyisiä objekteja, 
esimerkiksi, voimme uudellen määritellä

108
00:12:36,930 --> 00:12:45,730
objektin ID:lla 4 ja luoda uuden sisällön.
Eli näin korvaamme sanan "Hello World!"

109
00:12:45,730 --> 00:12:51,699
toisella lauseella ja tietenkin Xref osio
ja traileri osoittavat tähän uuteen

110
00:12:51,699 --> 00:13:00,100
objektiin. Eli tämä on hyvin tärkeää.
Osittaisen päivityksen kanssa emme ole

111
00:13:00,100 --> 00:13:06,220
rajoittuneita vain korostuksiin tai muisti-
lappuihin. Voimme uudelleenmäärittää

112
00:13:06,220 --> 00:13:14,399
nykyistä sisältöä ja ehkä tarvitsemme tätä
hyökkäyksissä joita näytämme. Eli puhutaanpa

113
00:13:14,399 --> 00:13:23,339
PDF allekirjoituksista. Ensin meidän pitää 
erottaa elektroninen allekijoitus digitaalisesta

114
00:13:23,339 --> 00:13:28,699
allekirjoituksesta. Elektroninen allekirjoitus.
Teknisestä näkökulmasta, se on vain kuva.

115
00:13:28,699 --> 00:13:36,369
Minä vain kirjoitin sen PC:llani ja laitoin
sen tiedostoon. Siinä ei ole kryptografista

116
00:13:36,369 --> 00:13:40,890
suojausta. Se voisin olla minä makaamassa
rannalla tekemässä jotain. Kryptologiselta

117
00:13:40,890 --> 00:13:45,509
kannalta se on aivan sama. Se ei tarjoa 
mitään turvaa, mitään kryptologista turvaa.

118
00:13:45,509 --> 00:13:52,739
Mistä puhumme tässä ovat digitaalisesti
allekirjoitetut tiedostot, eli jos avaat

119
00:13:52,739 --> 00:14:00,290
sellaisen tiedoston, sinulla on enemmän
tietoa liittyen allekirjoitusten varmistamiseen

120
00:14:00,290 --> 00:14:08,309
ja kuka on allekirjoittanut tämän PDF tiedoston. 
Eli kuten aiemmin mainitsin, tämä esitys

121
00:14:08,309 --> 00:14:16,689
keskittyy vain näihin digitaalisesti 
allekirjoitettuihin PDF tiedostoihin. Miten ?

122
00:14:16,689 --> 00:14:22,879
Minkälainen prosessi on digitaalisesti 
allekirjoitetuissa PDF tiedostoissa. Kuvittele

123
00:14:22,879 --> 00:14:28,639
meillä on tämä abstrakti kuvaus PDF tiedos-
toista. Meillä on header, boxy, xref osa ja

124
00:14:28,639 --> 00:14:35,480
traileri. Haluamme allekrjoittaa sen. Mitä
tapahtuu on, että otamme PDFn ja osittaisen

125
00:14:35,480 --> 00:14:41,899
päivityksen kautta lisäämme informaation
siihen liittyen. Siinä on uusi katalogi ja

126
00:14:41,899 --> 00:14:46,379
vielä tärkeämpää, uusi allekirjoitus objekti
sisältäen allekirjoituksen arvon ja

127
00:14:46,379 --> 00:14:52,100
tiedon kuka allekirjoitti tämän PDF tiedoston.
Ja tietenkin, siellä on Xref osio ja

128
00:14:52,100 --> 00:14:58,970
traileri. Ja sinulle oleellista: koko 
tiedosto on nyt suojattu PDF

129
00:14:58,970 --> 00:15:06,860
allekirjoituksella. Eli tämän alueen
manipuloinnin ei pitäisi olla mahdollista. Eihän?

130
00:15:06,860 --> 00:15:15,879
Yeah, puhutaanpa tästä: Miksi se ei ole
mahdollista ja miten voimme rikkoa sen?

131
00:15:15,879 --> 00:15:21,370
Ensiksi tarvitsemme hyökkäys skenaarion. Mitä
haluamme saavuttaa hyökkääjänä. Oletimme

132
00:15:21,370 --> 00:15:27,839
tutkimuksessa, että hyökkääjällä on hallussa
tämä allekirjoitettu PDF. Tämä voisi olla vanha

133
00:15:27,839 --> 00:15:35,989
sopimus, kuitti, tai meidän tapauksessa
lasku Amazonilta. Ja jos me avaamme tämän

134
00:15:35,989 --> 00:15:41,440
tiedoston, allekirjoitus on oikea. Eli 
kaikki on vihreää. Varoituksia ei näytetä ja

135
00:15:41,440 --> 00:15:48,329
kaiki on hyvin. Mitä koitimme tehdä, oli
ottaa tämä tiedosto, manipuloida sitä jotenkin

136
00:15:48,329 --> 00:15:56,319
ja lähettää se uhrille. Ja nyt uhri odottaa
saavansa digitaalisesti allekirjoitetun

137
00:15:56,319 --> 00:16:01,779
PDF tiedoston, eli vain digitaalisen alle-
kirjoituksen poistaminen on hyvin tavallinen

138
00:16:01,779 --> 00:16:07,600
skenaario ja emme harkinneet sitä, koska
se on tavallinen. Me harkitsimme, että uhri

139
00:16:07,600 --> 00:16:13,240
odottaa näkevänsä, että siinä on digitaalinen
allekirjoitus ja että se on oikea. Eli varoituksia

140
00:16:13,240 --> 00:16:20,420
ei esitetä ja koko vasen laita on täysin
kuin tavallisessa toiminnassa.

141
00:16:20,420 --> 00:16:28,109
Mutta toisessa laidassa, sisältö on vaihdettu,
eli me manipuloimme

142
00:16:28,109 --> 00:16:33,790
kuittia ja vaihdoimme sen toiseen sisältöön.
Kysymys on, kuinka voimme tehdä sen

143
00:16:33,790 --> 00:16:41,079
tekniseltä kannalta? Ja tässä loimme kolme
hyökkäystä: Osittainen tallennus hyökkäys,

144
00:16:41,079 --> 00:16:45,929
allekirjoituksen kääriminen ja yleinen
allekirjoituksen väärenys. Ja nyt esittelen

145
00:16:45,929 --> 00:16:51,209
tekniikat ja kuinka nämä hyökkäykset
toimivat. Ensimmäinen hyökkäys on

146
00:16:51,209 --> 00:16:56,839
osittainen tallkennus hyökkäys. Eli kuten
mainitsin aiemmin, osittaisen tallenuksen

147
00:16:56,839 --> 00:17:06,439
tai osittaisen päivityksen kautta, voimme
lisätä, poistaa ja jopa uudelleenmäärittää

148
00:17:06,439 --> 00:17:14,650
nykyisiä objekteja ja allekirjoitus pysyy 
eheänä. Miksi näin tapahtuu ?

149
00:17:14,650 --> 00:17:21,110
Ajatelkaa taas meidän tapausta. Meillä on
header, body, Xref taulu ja trailer ja

150
00:17:21,110 --> 00:17:27,559
tiedosto on nyt allekirjoitettu ja alle-
kirjoitus suojaa vain alekkirjoitettua aluetta.

151
00:17:27,559 --> 00:17:32,600
Mitä tapahtuisi jos vain laitan muistilapun
tai korostusta? Osittainen päivitys

152
00:17:32,600 --> 00:17:39,169
tapahtuu. Jos avaan tiedoston, yleensä tämä
tapahtuu: Meillä on informaatio, että tämä

153
00:17:39,169 --> 00:17:45,799
allekirjoitus on oikea, koske se alle-
kirjoitettiin ja niin edelleen. Meidän

154
00:17:45,799 --> 00:17:53,250
ensimmäinen idea oli tehdä body päivitys,
uudelleenmäärittää sisältöä ja Xref taulua

155
00:17:53,250 --> 00:17:59,419
ja trailerissa osoitetaan uuteen sisältöön.
tämä on aika helppoa, koska se on

156
00:17:59,419 --> 00:18:04,820
sallittu toiminto PDF tiedostossa, eli me
emme sen odottaneet toimivan emmekä

157
00:18:04,820 --> 00:18:11,760
olleet niin onnistuneita. Mutta ensimmäinen
idea: Käytimme tätä hyökkäystä, me avasimme

158
00:18:11,760 --> 00:18:22,080
sen ja saimme tämän viestin. Eli se on 
aika outo viesti, sillä kokenut

159
00:18:22,080 --> 00:18:27,970
käyttäjä näkee oikean, mutta dokumentti
on päivitetty ja sinun pitäisi tietää

160
00:18:27,970 --> 00:18:33,580
mitä se oikeasti tarkoittaa. Mutta me emme
pitäneet tätä hyökkäystä onnistuneena

161
00:18:33,580 --> 00:18:41,110
koska varoitus ei ole sama tai 
allekirjoituksen validointi ei ole sama.

162
00:18:41,110 --> 00:18:50,909
Eli mitä teimme, arvioimme tätä ensimmäistä
tätä helppoa tapausta vastaan vanhempia

163
00:18:50,909 --> 00:18:56,860
lukijoita mitä meillä on ja Libre office
esimerkiksi, oli haavoittuva tälle

164
00:18:56,860 --> 00:19:01,769
helpolle hyökkäykselle. Tämä oli ainoa 
lukija, joka oli haavoittuva tätä helppoa

165
00:19:01,769 --> 00:19:07,440
versiota kohtaan. Mutta sitten kysyimme
itseltämme: Okei, muut lukijat ovat

166
00:19:07,440 --> 00:19:14,250
melko turvallisia. Mutta kuinka ne tunnistavat
nämä osittaiset päivitykset? Ja kehittäjän

167
00:19:14,250 --> 00:19:22,410
näkökulmasta, laiskin asia mitä voimme tehdä
on tarkastaa onko toinen XRef taulu ja

168
00:19:22,410 --> 00:19:28,330
traileri lisätty allekirjoituksen jälkeen.
Eli lisäsimme vain body päivitykset, mutta

169
00:19:28,330 --> 00:19:37,450
poistimme kaksi muuta osaa. Tämä ei ole
standardin mukainen PDF tiedosto. Se on

170
00:19:37,450 --> 00:19:44,789
rikki. Mutta toivoimme, että PDF lukija vain
korjaa tömön kaltaisen jutun meille ja

171
00:19:44,789 --> 00:19:51,210
että nämä lukijat ovat vikasietoisia. Ja 
olimme melko onnistuneita, koska varmistus

172
00:19:51,210 --> 00:19:56,320
logiikka toimi: Onko olemassa Xref taulua
ja traileria allekirjoituksen jälkeen?

173
00:19:56,320 --> 00:20:01,580
Ei ? Okei
Kaikki on hyvin. Allekirjoitus täsmää.

174
00:20:01,580 --> 00:20:05,450
Varoituksia ei esitetty. Mutta sitten
sovelluslogiikka näki, että osittainen

175
00:20:05,450 --> 00:20:13,580
päivitys on tehty ja korjasi sen meille
ja prosessoi nämä body päivitykset eikä

176
00:20:13,580 --> 00:20:21,159
varoituksia näytetty. Osa lukijoista vaati,
trailerin olemassaoloa. En tiedä miksi

177
00:20:21,159 --> 00:20:25,350
se oli black box testausta. Eli me vain
poistimme Xref taulun, mutta traileri

178
00:20:25,350 --> 00:20:32,030
oli siellä ja me pystyimme rikkomaan
lisää PDF lukijoita. Monimutkaisin

179
00:20:32,030 --> 00:20:38,490
versio hyökkäyksestä oli seuraava. Meillä
oli PDF lukijoita tarkastamassa, sisältääkö

180
00:20:38,490 --> 00:20:47,330
jokainen osittainen päivitys allekirjoitus
objektin. Mutta ne eivät tarkastaneet

181
00:20:47,330 --> 00:20:53,200
kattaako tämä allekirjoitus osittaisen
päivityksen. Eli me vain leikkaa-liimasimme

182
00:20:53,200 --> 00:21:01,290
allekirjoituksen joka annettiin tässä ja me
pakotimme PDF lukijan validoimaan

183
00:21:01,290 --> 00:21:10,100
allekirjoitetun sisällon kahdesti - ja silti
tekemämme body päivitykset prosessoitiin

184
00:21:10,100 --> 00:21:18,669
ja esimerkiksi, Foxit ja Master PDF olivat
haavoittuvia tämän tyyppiselle hyökkäykselle.

185
00:21:18,669 --> 00:21:24,909
Eli hyökkäyksen arviointi: Me kokeilimme
osana arviointia 22 eri

186
00:21:24,909 --> 00:21:31,050
lukijaa - muiden mukana, Adobea
eri versioina, Foxit ja niin edelleen.

187
00:21:31,050 --> 00:21:41,140
Ja kuten näette 11 - 22:sta olivat
haavoittuvia osittaiselle tallennukselle.

188
00:21:41,140 --> 00:21:47,160
Eli 50 prosenttia, ja olimme aika yllättyneitä
koska näimme, että kehittäjän näkivät, että

189
00:21:47,160 --> 00:21:51,639
osittaiset päivitykset voisivat olla 
vaarallisia allekirjoituksen validoinnille.

190
00:21:51,639 --> 00:22:01,070
Mutta pystyimme silti ohittamaan nämä 
heidän harkintansa. Meillä oli täydellinen

191
00:22:01,070 --> 00:22:07,769
keino allekirjoituksen ohittamiseen, tarkoittaen
ettei uhrilla ole keinoa tunnistaa hyökkäystä.

192
00:22:07,769 --> 00:22:14,269
Rajoitettu allekirjoituksen ohittaminen
tarkoittaa, että uhri halutessaan varmistaa

193
00:22:14,269 --> 00:22:23,470
allekirjoituksen, klikkaa yhtä - vähintään
yhtä lisäikkunaa ja haluaa juuri varmistaa

194
00:22:23,470 --> 00:22:31,520
allekirjoituksen, silloin lukija on haavoittuva.
Mutta tärkein asia on, että tiedostoa avatessa

195
00:22:31,520 --> 00:22:38,080
siinä on statusviesti, että allekirjoitus
validointi ja kaikki

196
00:22:38,080 --> 00:22:44,289
allekirjoitukset ovat oikeita. Eli tämä oli
ensimmäinen taso ja lukijat olivat

197
00:22:44,289 --> 00:22:51,390
haavoittuvia tälle. Eli puhutaampa toisesta
hyökkäyslajista. Me kutsuimme sitä

198
00:22:51,390 --> 00:22:57,970
"allekirjoituksen paketointi hyökkäykseksi"
ja tämä oli monimutkaisin 3 :sta lajista.

199
00:22:57,970 --> 00:23:04,580
Ja nyt meidän pitää mennä yksityiskohtiin,
miten PDF allekirjoitukset luodaan.

200
00:23:04,580 --> 00:23:10,450
Kuvittele, että meillä on nyt PDF tiedosto.
Meillä on headeri ja alkuperäinen dokumentti.

201
00:23:10,450 --> 00:23:15,549
Alkuperäinen dokumentti sisältää headerin,
bodyn, XRef osan ja niin edelleen.

202
00:23:15,549 --> 00:23:21,919
Ja haluamme allekirjoittaa tämän
dokumentin. Teknisesti, jälleen,

203
00:23:21,919 --> 00:23:28,700
osittainen päivitys annetaan ja meillä on 
uusi katalogi tässä. Meillä on jotain muita

204
00:23:28,700 --> 00:23:35,159
objekteja, esimerkiksi, sertifikaatteja jne.
ja allekirjoitus objekteja. Ja keskitymme

205
00:23:35,159 --> 00:23:38,720
nyt tähän allekirjoitus objektiin, koska se
on keskeinen osa hyökkäykselle jota

206
00:23:38,720 --> 00:23:45,399
suoritamme. Ja allekirjoitus objekti 
sisältää paljon informaatiota, mutta

207
00:23:45,399 --> 00:23:51,460
haluamme tätä hyökkäystä varten vain kaksi
elementtiä ovat tärkeitä. Sisältö ja tavu-alue.

208
00:23:51,460 --> 00:23:57,940
Sisältö käsittää allekirjoituksen arvon. 
Se on PKCS7 taltio sisältäen

209
00:23:57,940 --> 00:24:05,710
allekirjoituksen arvon ja sertifikaatit, 
joita käytetään allekirjoituksen validointiin

210
00:24:05,710 --> 00:24:11,299
ja tavu-alueen. Tavu-alue sisältää 4 eri
arvoa ja mihin näitä arvoja käytetään.

211
00:24:11,299 --> 00:24:23,090
Ensimmäiset kaksi, A ja B määrittävät
ensimmäisen allekirjoitetun alueen. Ja tämä

212
00:24:23,090 --> 00:24:29,159
on tästä dokumentin alusta allekirjoituksen
alkuarvoon saakka.

213
00:24:29,159 --> 00:24:35,370
Miksi tarvitsemme tätä? Koska allekirjoituksen
arvo on osa allekirjoitettua aluetta. Eli meidän

214
00:24:35,370 --> 00:24:42,780
tulee erottaa allekirjoitusarvo dokumentin
käsittelystä. Ja näin tavu-arvoa

215
00:24:42,780 --> 00:24:49,179
käytetään. Ensimmäinen osa on dokumentin
alusta kunnes allekirjoitettu

216
00:24:49,179 --> 00:24:54,629
allekirjoitusarvo alkaa ja sen jälkeen kun
allekirjoitus loppuu aina tiedoston

217
00:24:54,629 --> 00:25:04,759
lopussa on toinen alue, jonka määrittää 
kaksi lukua C ja D. Eli nyt meillä on

218
00:25:04,759 --> 00:25:13,500
kaikki suojattu, paitsi allekirjoituksen
arvo itse. Mitä halusimme kokeilla, oli

219
00:25:13,500 --> 00:25:21,889
luoda lisää tilaa hyökkäyksillemme. Eli
ajatuksena oli siirtää toista allekirjoitettua

220
00:25:21,889 --> 00:25:30,350
aluetta. Ja kuinka teimme sen? Periaatteessa
voimme vain määritellä uuden tavu alueen.

221
00:25:30,350 --> 00:25:40,240
Ja kuten näette tässä, tavu-alue osoittaa
aluetta A:sta B:hen. Eli tähän alueeseen

222
00:25:40,240 --> 00:25:46,889
emme tehneet mitään manipulointeja tässä
osassa, emmehän? Sitä ei muutettu yhtään.

223
00:25:46,889 --> 00:25:53,309
Eli se on yhä validi. Ja toinen osa, uusi
C arvo ja seuraavat D tavua

224
00:25:53,309 --> 00:26:00,169
me emme muuttaneet mitään tässä, emmehän?
Eli periaatteessa emme muuttaneet mitään

225
00:26:00,169 --> 00:26:06,750
allekirjoitetulla alueella. Ja allekirjoitus
on edelleen validi. Mutta mitä teimme,

226
00:26:06,750 --> 00:26:13,980
loimme lisää tilaa haitallisille objekteille;
joskus tarvitsemme täytettä ja

227
00:26:13,980 --> 00:26:20,960
lisä osioita osoittamaan tähän
haitalliseen objektiin. Tärkeä asia oli,

228
00:26:20,960 --> 00:26:27,559
että tämä haitallinen XREf osio, sijainti
määritetään trailerissa. Ja koska

229
00:26:27,559 --> 00:26:32,799
emme voi muokata traileria, tämä sijainti
on kiinteä. Eli tämä on ainoa rajoite

230
00:26:32,799 --> 00:26:42,880
hyökkäyksessä, mutta se toimii hienosti.
Ja kysymys on nyt: Kuinka moni

231
00:26:42,880 --> 00:26:49,730
PDF lukija on haavoittuvainen tälle
hyökkäykselle? Ja kuten näette, tämä on

232
00:26:49,730 --> 00:26:58,169
allekirjoituksen paketointi sarake. 17
22:sta sovelluksesta on haavoittuva tälle

233
00:26:58,169 --> 00:27:06,000
hyökkäykselle. Tämä oli melko odotettu tulos
koska hyökkäys oli monimutkainen, emme

234
00:27:06,000 --> 00:27:14,789
mönenkaan kehittäjän olevan tietoinen
tästä uhasta ja tämä on syy, miksi

235
00:27:14,789 --> 00:27:22,600
niin monta haavoittuvuutta oli siellä. Ja nyt
viimeinen hyökkäys luokka, yleinen

236
00:27:22,600 --> 00:27:28,580
allekirjoituksen väärentäminen. Ja kutsumme
sitä yleiseksi allekirjoituksen väärentämiseksi

237
00:27:28,580 --> 00:27:33,879
mutta suosin toisen määritelmän käyttämistä
tälle hyökkäykselle. Kutsun niitä tyhmiksi

238
00:27:33,879 --> 00:27:40,909
implementointi virheiksi. Tulemme Pentestaus
alueelta ja tiedän, että moni teistä on

239
00:27:40,909 --> 00:27:49,880
penaajia myös. Ja monella teistä on 
kokemuksia, kiinnostavia kokemuksia

240
00:27:49,880 --> 00:27:58,460
nolla-tavujen kanssa, nolla arvojen tai
joidenkin outojen arvojen kanssa. Ja tätä

241
00:27:58,460 --> 00:28:06,309
koitimme tämän tyyppisessä hyökkäyksessä.
Koitetaan tehdä tyhmiä arvoja tai poistaa

242
00:28:06,309 --> 00:28:13,100
viittauksia ja katsoa mitä tapahtuu. Katsoessa
allekirjoitusta, siinä on kaksi tärkeää

243
00:28:13,100 --> 00:28:18,389
eri elementtiä: Sisältö, jossa on alle-
kirjoituksen arvo ja tavualue

244
00:28:18,389 --> 00:28:25,220
osoittamaan mitä oikeasti on allekirjoitettu.
Eli mitä tapahtuisi, jos poistamme

245
00:28:25,220 --> 00:28:30,679
sisällön? Toivoimme, että informaatio
allekirjoituksesta olisi edelleen näytetty

246
00:28:30,679 --> 00:28:37,779
lukijassa oikeana ilman, että mitään
allekirjoitusta validoitaisiin, koska se ei

247
00:28:37,779 --> 00:28:45,169
ole mahdollista. Ja allekirjoitus arvon
poisto oli ilmeinen ajatus. Ja emme

248
00:28:45,169 --> 00:28:48,899
onnistuneet tässä hyökkäyksessä. Mutta
jatketaan muiden arvojen kanssa

249
00:28:48,899 --> 00:28:57,090
esimerkiksi, sisältö ilman arvoa tai
sisältö saman arvoinen kuin NULL tai

250
00:28:57,090 --> 00:29:04,710
nolla tavua. Ja tämän viimeisen version
kanssa meilllä oli kaksi lukijaa, jotka

251
00:29:04,710 --> 00:29:15,049
olivat haavoittuvia hyökkäykselle. Ja toinen,
toinen tapaus oli, esimerkiksi, poistamalla

252
00:29:15,049 --> 00:29:19,929
tavu-alueen. Poistamalla tämän tavu-alueen
meillä on joku allekirjoitus arvo, mutta

253
00:29:19,929 --> 00:29:29,590
emme tiedä tarkalleen mitä on allekirjoitettu.
Eli koitimme tätä hyökkäystä ja tietenkin,

254
00:29:29,590 --> 00:29:38,390
tavu-aluetta ilman arvoa tai NULL tavuilla
tai tavu-alue miinuksella tai negatiivisena,

255
00:29:38,390 --> 00:29:46,169
negatiivisilla numeroilla. Ja yleensä tämä
viimeinen kaatoi paljon lukijoita. Mutta

256
00:29:46,169 --> 00:29:51,800
mielenkiinotisinta oli, että Adobe teki
tämän virheen vain poistamalla tavu-alueen.

257
00:29:51,800 --> 00:29:56,990
Pystyimme ohittamaan koko turvallisuuden.
Emme odottaneet tätä käyttäytymistä,

258
00:29:56,990 --> 00:30:00,950
mutta se oli tyhmä implementointivirhe,
joka salli meidän tehdä mitä tahansa tässä

259
00:30:00,950 --> 00:30:08,190
dokumentissa ja kaikki exploitit, joita 
näytämme esityksessä tehtiin Adobessa tässä

260
00:30:08,190 --> 00:30:14,909
hyökkäyksessä. Eli katsoitaan tulokset tästä
hyökkäyksestä. Kuten näette, vain

261
00:30:14,909 --> 00:30:21,110
4 22:sta lukijasta olivat haavoittuvia
tälle hyökkäykselle ja vain Adobe

262
00:30:21,110 --> 00:30:26,280
rajoittamattomasti; muiden osalta, oli
rajoituksia koska jos klikkaat allekirjoitus

263
00:30:26,280 --> 00:30:32,760
validointia, silloin varoitus näytettiin.
Adoben oli helppo korjata se.

264
00:30:32,760 --> 00:30:37,540
Ja kuten näette, Adobe ei erehtynyt, tehnyt
yhtään virhettä osittaisessa tallennuksessa,

265
00:30:37,540 --> 00:30:40,820
allekirjoituksen paketoinnissa, mutta 
väitetyssä allekirjoituksen väärennyksessä

266
00:30:40,820 --> 00:30:48,169
Siellä oltiin haavoittuvia tälle hyökkäykselle.
Ja tätä toivoimme lähestymisellämme.

267
00:30:48,169 --> 00:30:56,029
Yhteenvetona, onnistuimme rikkomaan
21 22:sta PDF lukijasta. Ainoa...

268
00:30:56,029 --> 00:31:00,850
Aplodeja
Kiitos

269
00:31:00,850 --> 00:31:08,149
Aplodeja
Ainoa turvallinen PDF lukija on Adobe 9,

270
00:31:08,149 --> 00:31:12,860
joka on vanhentunut ja jossa on remote
code execution. Ainoat...

271
00:31:12,860 --> 00:31:18,039
Naurua
Ainoat käyttäjät, jotka saavat käyttää

272
00:31:18,039 --> 00:31:25,450
tai käyttävät sitä ovat Linux käyttäjät, 
sillä se on viimeinen versio saatavilla Linuxille

273
00:31:25,450 --> 00:31:31,779
ja siksi voit harkita sitä. Eli olen 
valmis puheessa PDF allekirjoituksista

274
00:31:31,779 --> 00:31:36,644
ja nyt Fabian voi puhua PDF
salauksesta. Kiitos.

275
00:31:36,644 --> 00:31:42,540
Fabian: Kyllä
Aplodeja

276
00:31:42,540 --> 00:31:46,759
OK, nyt kun olemme hoidelleet allekirjoitukset
puhutaanpa toisesta kryptografisesta

277
00:31:46,759 --> 00:31:52,759
tekijästä PDF:ssa. Ja se on salaus.
Ja osa teistä voi muistaa meidän

278
00:31:52,759 --> 00:31:58,481
PDFex haavoittuvuuden aiemmin tänä
vuonna. Se on tietenkin, hyökkäys logolla

279
00:31:58,481 --> 00:32:03,720
ja se näyttää kaksi uutta tech
tekniikkaa tähdäten PDF salaukseen jota

280
00:32:03,720 --> 00:32:08,029
ei ole koskaan kohdistettu PDF salaukseen
ennen. Eli yksi niistä oli nämä ns. suora

281
00:32:08,029 --> 00:32:12,549
exfiltrointi, jossa rikoimme kryptografian
jopa koskematta kryptografiaan.

282
00:32:12,549 --> 00:32:18,840
Eli ei salatun tekstin manipulointia tässä.
Toinen on niin kutsuttu

283
00:32:18,840 --> 00:32:24,690
muokattavat värkit. Ja ne ovat oikeasti
kohdistettuja muokkauksia dokumentin

284
00:32:24,690 --> 00:32:31,240
salattuun osaan. Mutta ensin, otetaan 
askel takaisin ja uudelleen otetaan

285
00:32:31,240 --> 00:32:39,519
muutama avainsana. Eli PDF käyttää AES. OK.
Okei, AES on hyvä. Mikään ei voi mennä pieleen.

286
00:32:39,519 --> 00:32:44,220
Eihän? Eli mennään kotiin. Salaus on hyvä.
No, tietenkään emme lopettaneet, vaan

287
00:32:44,220 --> 00:32:52,160
katsoimme tarkemmin. Eli he käyttävät CBC
toimintatilaa, eli cipher block chaining.

288
00:32:52,160 --> 00:32:58,309
Ja mikä tärkeämpää on, etteivät he käytä
mitään eheyden suojausta.

289
00:32:58,309 --> 00:33:04,120
Eli se on eheyssuojaamaton AES-CBC.
Ja saatat muistaa skenaarion

290
00:33:04,120 --> 00:33:08,909
hyökkäyksistä salattua sähköpostia vastaan,
eli vasten OpenPGPta ja S-MIMEa

291
00:33:08,909 --> 00:33:15,999
se on periaatteessa sama ongelma.
Mutta ensin kuka oikeasti käyttää PDF

292
00:33:15,999 --> 00:33:20,940
salausta? Voisit kysyä. Ensinnäkin löysimme
joidenkin paikallisten pankkien Saksassa

293
00:33:20,940 --> 00:33:26,030
käyttävän salattuja PDFia korvatakseen 
S-MIMEn tai OpenPGPn, koska heidän

294
00:33:26,030 --> 00:33:34,899
asiakkaansa eivät ehkä halua toimia, umh,
asettaa, ottaa salattua e-mailia käyttöön.

295
00:33:34,899 --> 00:33:39,740
Toiseksi, oli joitain drop-in plugineja 
sähköpostin salaukseen myös. Eli on

296
00:33:39,740 --> 00:33:44,570
joitain yrityksiä, jotka tekevät tuotteita,
jotka voit laittaa outlookiin ja voit käyttää

297
00:33:44,570 --> 00:33:51,330
salattuja PDF tiedostoja salatun
sähköpostin sijaan. Havaitsimme myös

298
00:33:51,330 --> 00:33:57,919
että jotkus skannerit ja lääketieteelliset
laitteet lähettävät salattuja PDFia e-mailina

299
00:33:57,919 --> 00:34:02,990
Eli voit asettaa salasanan siihen koneeseen
ja ne lähettävät salatun PDFn sähköpostilla

300
00:34:02,990 --> 00:34:10,369
ja sinun pitää asettaa salasana
jollain toisella tavalla. Ja viimeisenä löysimme

301
00:34:10,369 --> 00:34:14,639
että jotkut valtiolliset organisaatiot käyttävät
salattuja PDF dokumentteja, esimerkiksi,

302
00:34:14,639 --> 00:34:20,409
US Oikeusministeriö antaa lähettää, 
lähettä joitain vaatimuksia salattujen

303
00:34:20,409 --> 00:34:25,280
PDFien kautta. Enkä ole aivan varma miten
he saavat salasanan, mutta ainakin he sallivat

304
00:34:25,280 --> 00:34:30,850
sen. Joten koska olemme akatemiasta,
otetaan askel takaisin ja katsotaan

305
00:34:30,850 --> 00:34:36,860
hyökkäysmalliamme. Meillä on Alice ja
Bob. Alice haluaa lähettää dokumentin Bobille.

306
00:34:36,860 --> 00:34:42,120
Ja hän haluaa lähettä sen salaamatonta
yhteyttä pitkin tai yhteyttä, johon hän ei

307
00:34:42,120 --> 00:34:48,610
luota. Joten tietenkin hän päättää salata
sen. Toinen skenaario on, he haluavat

308
00:34:48,610 --> 00:34:53,020
ladata sen jaettuun tallennukseen. 
Esimerkiksi Dropboxiin ja toiseen jaettuun

309
00:34:53,020 --> 00:34:57,190
tallennukseen. Ja taas, he eivät luota
tallennukseen. Ja taas he käyttävät päästä-

310
00:34:57,190 --> 00:35:05,120
päähän salausta. Oletetaanpa, että tämä jaettu
tallennus on oikeasti vaarallinen tai haitallinen.

311
00:35:05,120 --> 00:35:11,420
Alice lataa, tietenkin, taas salatun
dokumentin hyökkääjälle tässä tapauksessa

312
00:35:11,420 --> 00:35:17,490
joka suorittaa kohdistettua muokkausta
siihen ja lähettää

313
00:35:17,490 --> 00:35:22,290
muokatun dokumentin takaisin Bobille,
joka ilmoisesti syöttää salasanan, koska

314
00:35:22,290 --> 00:35:26,800
hänen näkökulmasta, sitä ei voi erottaa
alkuperäisestä dokumentista

315
00:35:26,800 --> 00:35:32,880
ja alkuperäinen selkoteksti vuodetaan
takaisin hyökkääjälle, rikkoen

316
00:35:32,880 --> 00:35:39,730
luottamuksellisuuden. Eli katsotaan
ensimmäistä hyökkäystä kuinka teimme sen.

317
00:35:39,730 --> 00:35:43,410
Se on suora exfiltrointi, eli kryptauksen
rikkominen koskematta mitenkään

318
00:35:43,410 --> 00:35:51,360
kryptografiaan, kuten tykkään sanoa. Mutta
ensin, salaus, pähkinänkuoressa, PDF salaus.

319
00:35:51,360 --> 00:35:54,570
Eli olette nähneet PDF dokumentin rakenteen.
Siinä on header, jossa on

320
00:35:54,570 --> 00:35:57,280
versionumero. Siinä on body, jossa kaikki
kiinnostavat objektit asuvat. Eli siinä

321
00:35:59,990 --> 00:36:06,820
on meidän luottamuksellinen sisältö jonka
haluamme oikeastaan, no

322
00:36:06,820 --> 00:36:14,740
exfiltroida hyökkääjänä. Ja lopuksi, siinä
on Xref taulu ja traileri. Eli

323
00:36:14,740 --> 00:36:19,730
mikä muuttuu his päätämme salata tämän
dokumentin? No, oikeastaan, ei paljon mikään.

324
00:36:19,730 --> 00:36:24,080
Eli luottamuksellisen datan sijaan, tietenkin
siellä on nyt jotain salattua salatekstiä

325
00:36:24,080 --> 00:36:29,010
Okei. Ja loppu pitkälti pysyykin
samana. Ainoa asia, joka lisätään on

326
00:36:29,010 --> 00:36:36,960
uusi arvo traileriin, joka kertoo meille,
kuinka tämän datan salaus avataan uudelleen.

327
00:36:36,960 --> 00:36:43,560
Eli siinä on oikeastaan rakenne purettuna.
Ja ajattelimme:

328
00:36:43,560 --> 00:36:50,120
Miksi näin? Ja katsoimme standardia.
Eli, tämä on ote PDF

329
00:36:50,120 --> 00:36:55,940
määritelmästä ja olen korostanut 
kiinnostavat osat teille. Salaus koskee

330
00:36:55,940 --> 00:37:00,690
vain stringeja ja streameja. No, niitä
arvoja, jotka oikeastaan voivat

331
00:37:00,690 --> 00:37:07,640
sisältää mitään tekstiä dokumentissa ja 
kaikki muut objektit ovat salaamatta. Ja

332
00:37:07,640 --> 00:37:12,270
se on, koska he haluavat sallia satunnaisen
pääsyn koko dokumenttiin. Eli ei mitään

333
00:37:12,270 --> 00:37:17,600
parsintaa koko dokumentille, ennen kuin
näytetään sivu 16 salatusta dokumentista.

334
00:37:17,600 --> 00:37:24,560
No, se vaikuttaa kohtuulliselta. Mutta se
tarkoittaa myös, että koko dokumentin

335
00:37:24,560 --> 00:37:27,970
rakenne on salaamaton ja ainoastaan
stringit ja streamit ovat salattuja.

336
00:37:27,970 --> 00:37:31,380
Tämä paljastaa paljon informaatiota
hyökkääjälle jota hänellä ei varmaan

337
00:37:31,380 --> 00:37:36,420
pitäisi olla. Se on ensinnäkin sivujen 
määrä ja koko, se on määrä

338
00:37:36,420 --> 00:37:42,610
ja koko objekteilla dokumentissa ja
se käsittää myös kaikki linkit, eli

339
00:37:42,610 --> 00:37:48,120
kaikki hyperlinkit dokumentissa, jotka
ovat siinä. Ja se on paljon informaatiota

340
00:37:48,120 --> 00:37:55,260
jota hyökkääjällä ei varmaan pitäisi
olla. Eli seuraavaksi mietimme, ehkä

341
00:37:55,260 --> 00:38:01,270
voisimme tehdä jotain lisää. Voimmeko
lisätä omaa salaamatonta sisältöä. Ja

342
00:38:01,270 --> 00:38:05,910
katsoimme standardia uudelleen ja löysimme
ns. crypt filttereitä, jotka tarjoavat tarkemman

343
00:38:05,910 --> 00:38:10,750
kontrollin salaamiseen. Tämä periaatteessa
tarkoittaa, että hyökkääjänä voin muuttaa

344
00:38:10,750 --> 00:38:15,920
dokumentin sanomaan, hei, vain
stringit dokumentissa ovat salattuja ja

345
00:38:15,920 --> 00:38:21,340
streamit ovat selkokielisiä. Sitä varten
identiteetti filtteri on. En tiedä miksi he

346
00:38:21,340 --> 00:38:27,190
päättivät lisätä sen dokumenttiformaattiin,
mutta siellä se on. Se tarkoittaa, että

347
00:38:27,190 --> 00:38:31,570
he tukevat osittaista salausta ja se taas
tarkoittaa, että hyökkääjän sisältö voidaan

348
00:38:31,570 --> 00:38:36,880
sekoittaa salatun sisällön kanssa. Ja
löysimme 18 erilaista tekniikkaa tähän

349
00:38:36,880 --> 00:38:42,290
eri lukijoissa. Eli on monta tapaa tehdä
se eri lukijoissa.

350
00:38:42,290 --> 00:38:48,150
Katsotaanpa demoa. Eli meillä on tämä
dokumentti, tämä salattu dokumentti,

351
00:38:48,150 --> 00:38:54,170
me syötämme salasanan ja saamme salaisen
viestimme. Me avaamme sen taas tekstieditorilla.

352
00:38:54,170 --> 00:39:00,140
Näemme, objektissa 4 0 alhaalla täällä, siellä
on oikeasti objektin salateksti,

353
00:39:00,140 --> 00:39:06,110
eli viesti, ja näemme se on AES salattu
32 tavuisella avaimella, eli se on AES-256.

354
00:39:06,110 --> 00:39:15,670
OK, nyt päätämme lisätä uuden objektin,
joka sisältää, no, selkotekstiä.

355
00:39:15,670 --> 00:39:22,220
Ja, no, me vain lisäämme sen sisältö
jonoon dokumentissa. Me sanomme

356
00:39:22,220 --> 00:39:28,241
"näytä tämä ensimmäisellä sivulla"
tallennamme dokumentin. Avaamme sen ja

357
00:39:28,241 --> 00:39:38,300
laitamme salasanan ja, no tämä todella on
kiusallista. OK. Eli me olemme rikkoneet

358
00:39:38,300 --> 00:39:44,160
eheyden salatusta dokumentista. No, voit 
ajatella että ehkä he eivät halunneet mitään

359
00:39:44,160 --> 00:39:49,190
eheyttä salatuissa dokumenteissa. Ehkä se
on ihmisten käyttötapaus, en tiedä.

360
00:39:49,190 --> 00:39:55,060
Mutta ajattelimme, ehkä voisimme exfiltroida
selkotekstin jotenkin tätä kautta.

361
00:39:55,060 --> 00:40:00,040
Eli taas otimme askeleen takaisin ja katsoimme
PDF määritystä. Ja ensimmäinen asia jonka

362
00:40:00,040 --> 00:40:06,080
löysimme oli ns. lähetä lomake toiminto.
Ja se on periaatteessa sama kuin lomake

363
00:40:06,080 --> 00:40:10,550
web sivulla. Voit syöttää dataa. Olet
voinut nähdä tämän sopimuksessa,

364
00:40:10,550 --> 00:40:14,740
PDF sopimuksessa, minne voit laittaa nimesi
ja osoitteesi ja niin edelleen ja

365
00:40:14,740 --> 00:40:23,330
data tallennetaan sisään, sisään
stringeina ja streameina. Ja nyt

366
00:40:23,330 --> 00:40:27,760
muistakaa, että kaikki mitä on salattuna
dokumentissa. Ja tietenkin, voit

367
00:40:27,760 --> 00:40:32,101
myös lähettää kaiken tämän takaisin
hyökkääjälle, tai no, laillinen käyttötapaus,

368
00:40:32,101 --> 00:40:37,890
tietenkin, näppäintä painamalla, mutta
näppäintä painamalla on vähän laimeaa.

369
00:40:37,890 --> 00:40:42,120
Eli katsoimme taas standardia ja löysimme
ns. open action:in. Ja se on toiminto,

370
00:40:42,120 --> 00:40:47,190
esimerkiksi, lomakkeen lähettäminen, joka
voidaan suorittaa dokumenttia avatessa.

371
00:40:47,190 --> 00:40:54,980
Eli miltä tämä voisi näyttää? Tältä PDF
lomake näyttää. hyökkäys jo mukana.

372
00:40:54,980 --> 00:41:01,390
Eli meillä on URL tässä, joka on salaamaton
koska kaikki stringit tässä

373
00:41:01,390 --> 00:41:07,400
dokumentissa ovat salaamattomia, ja 
meillä on arvo objektille 2 0, jossa

374
00:41:07,400 --> 00:41:13,335
salattu data asustaa. Eli se on arvo
lomakkeen kentälle. Ja mitä

375
00:41:13,335 --> 00:41:17,120
tapahtuu hyökkääjän puolella kun heti
kun dokumentti avataan? No, saamme

376
00:41:17,120 --> 00:41:24,540
POST pyynnön, jossa on luottamuksellinen
sisältö. Pidetäänpä demo. Taas, meillä on

377
00:41:24,540 --> 00:41:30,620
tämä dokumentti. Annamme salasanan. Se on 
alkuperäinen dokumentti, jonka olette jo

378
00:41:30,620 --> 00:41:36,160
nähneet. Me avaamme sen uudelleen tekstin
lukijassa, tai tekstieditorissa, jälleen huomatkaa

379
00:41:36,160 --> 00:41:44,160
se on salattu ja päätämme muuttaa kaikki
stringit identity filtterissa. Eli salausta

380
00:41:44,160 --> 00:41:49,480
ei käytetä stringeissä tästä eteenpäin. Ja
sitten lisäämme koko blobin informaatiota

381
00:41:49,480 --> 00:41:55,940
open actioniin ja lomakkeeseen.
Eli tämä op- tämä suoritetaan

382
00:41:55,940 --> 00:42:00,350
heti kun dokumentti avataan. Siellä on
URL, p.df ja arvo

383
00:42:00,350 --> 00:42:07,540
on salattu objekti 4 0. Käynnistämme HTTP
palvelimen domainissa, jonka määritimme,

384
00:42:07,540 --> 00:42:12,970
avaamme dokumentin, annamme salasanan
taas ja heti kun avaamme dokumentin

385
00:42:12,970 --> 00:42:17,770
Adobe avuliaasti näyttää meille
varoituksen, mutta he klikaavat jo

386
00:42:17,770 --> 00:42:22,170
nappia muistamaan sen seuraavalla kerralla.
Ja jos hyväksyt sen, näet sinun

387
00:42:22,170 --> 00:42:29,390
salaisen viestin hyökkääjän palvelimella.
Ja tämä on jo aika paha sinänsä.

388
00:42:29,390 --> 00:42:36,480
OK. Sama toimii hyperlinkeillä, joten 
tietenkin linkkejä on PDF dokumenteissa,

389
00:42:36,480 --> 00:42:43,600
ja kuten Webissa, voimme määrittää base 
URLin hyperlinkeissä. Eli voimme sanoa

390
00:42:43,600 --> 00:42:49,940
kaikki URLit dokumentissa alkavat http://p.df.
Ja tietenkin voimme määritellä minkä tahansa

391
00:42:49,940 --> 00:42:57,260
objektin URLiksi. Eli mikä tahansa objekti,
jonka valmistelemme voidaan lähettää URLina,

392
00:42:57,260 --> 00:43:01,180
ja se tietenkin laukaisee GET requestin 
kun dokumentti avataan, jos määrittelit

393
00:43:01,180 --> 00:43:08,750
open actionin objektille. Eli taas aika
paha ja rikkoo luottamuksellisuuden. Ja

394
00:43:08,750 --> 00:43:16,380
tietenkin, kaikki rakastavat JavaScriptia
PDF tiedostoissa, ja se toimii hyvin. Okei.

395
00:43:16,380 --> 00:43:21,350
Puhutaanpas ciphertext hyökkäyksistä, eli
oikeista kryptologisista hyökkäyksistä, ei

396
00:43:21,350 --> 00:43:29,190
enää olla koskematta kryptoon. Voit muistaa
efail hyökkäykset OpenPGP ja S-MIMEen,

397
00:43:29,190 --> 00:43:34,160
ja niissä oli kolme edellytystä.
1: No, ciphertekstin muokattavuus.

398
00:43:34,160 --> 00:43:38,690
sitä kutsutaan muokattavaksi värkiksi, siksi
tarvitsemme ciphertekstin

399
00:43:38,690 --> 00:43:43,850
muokattavuuutta ja meillä ei ole eheyden
suojausta, se on plussaa. Sitten tarvitsemme

400
00:43:43,850 --> 00:43:48,680
jonkun tunnetun selkotekstin kohdenetuille
muokkauksille. Ja tarvitsemme exfiltrointi

401
00:43:48,680 --> 00:43:53,070
kanavan lähettämään datan takaisin 
hyökkääjälle. No, exfiltrointikanavat

402
00:43:53,070 --> 00:43:59,730
käsiteltiin jo kun meillä on hyperlinkit
ja formit. Joten voimme jo ruksata sen.

403
00:43:59,730 --> 00:44:05,800
Kiva, puhutaan vähän ciphertekstin
muokattavuudesta, mitä kutsumme värkeiksi.

404
00:44:05,800 --> 00:44:10,180
Jotkut voivat muistaa tämän Krypto 101:sta
tai miltä tahansa kryptografian luennolta

405
00:44:10,180 --> 00:44:15,290
Tämä on purkutoiminto CBC:ssa
eli Cipher Block

406
00:44:15,290 --> 00:44:24,030
Chainingissa. Ja se on periaatteessa, sinulla
on ciphertekstisi täällä ylhäällä ja selko-

407
00:44:24,030 --> 00:44:29,730
tekstisi täällä alhaalla. Ja se toimii 
yksinkertaisesti purkamalla lohkon ciphertekstiä,

408
00:44:29,730 --> 00:44:35,850
XORaamalla edellisen lohkon ciphertekstiä
siihen, ja saat selkotekstin.

409
00:44:35,850 --> 00:44:41,070
Eli mitä tapahtuu, jos koitat vaihtaa yhden
bitin ciphertekstissä, esimerkiksi, ensimmäisen

410
00:44:41,070 --> 00:44:47,530
bitin alustusvektorista? No, se
sama bitti vaihtuu myös oikeassa

411
00:44:47,530 --> 00:44:53,110
selkotekstissä. Odotas, mitä tapahtuu, jos
satut tietämään koko

412
00:44:53,110 --> 00:45:00,150
selkoteksti lohkon? No, voimme XORata sen
ensimmäiseen lohkoon ja periaatteessa

413
00:45:00,150 --> 00:45:05,890
saada kaikki nollaa, tai mitä kutsumme 
värkiksi tai tyhjän paperin, koska voimme

414
00:45:05,890 --> 00:45:14,130
kirjoittaa siihen ottamalla tunnetun selko-
tekstin ja XORaamalla sen tuloksiin. Ja näin

415
00:45:14,130 --> 00:45:18,740
voimme, esimerkiksi, rakentaa URLin itse
ciphertekstiin, tai oikeaan seuraavaan

416
00:45:18,740 --> 00:45:24,420
selkotekstiin. Mitä voimme myös tehdä näillä
värkeillä, värkkejä voidaan siirtää muualle

417
00:45:24,420 --> 00:45:28,580
dokumentissa, kloonata niitä, jolloin 
meillä voi olla useita värkkejä

418
00:45:28,580 --> 00:45:34,150
monessa kohdassa ciphertekstiä. Mutta
muistakaa, jos teette sen, sillä

419
00:45:34,150 --> 00:45:37,800
on aina lumivyöryefekti CBCssa,
eli sinulla on satunnaisia tavuja täällä

420
00:45:37,800 --> 00:45:45,590
mutta URL pysyy silti paikoillaan.
Okei. Se oli ciphertekstin muokattavuus.

421
00:45:45,590 --> 00:45:50,610
Kuten sanoin tarvitsemme vähän selkotekstiä.
Meillä pitää olla selkotekstiä. Ja PDF

422
00:45:50,610 --> 00:45:54,460
standardi on ollut avulias tähän asti, 
PDF salausta rikottaessa, joten

423
00:45:54,460 --> 00:46:02,071
kurkataan uudelleen. Ja mitä löydämme 
täältä: Oikeudet. Eli PDF dokumentissa voi

424
00:46:02,071 --> 00:46:08,040
olla eri oikeudet kirjoittajalle ja
dokumentin käyttäjälle. Tämä käytännössä

425
00:46:08,040 --> 00:46:11,020
tarkoittaa, että kirjoittaja voi muokata
dokumenttia ja käyttäjä ei voisi

426
00:46:11,020 --> 00:46:16,060
tehdä sitä. Ja tietenkin ihmiset alkoivat
muuttaa sitä- alkoivat sormeilla niitä

427
00:46:16,060 --> 00:46:20,220
arvoja, jos se oli jätetty salaamatta,
joten uusimmassa versiossa, tehtiin

428
00:46:20,220 --> 00:46:27,310
päätös, että se pitäisi salata 16 tavuisena
arvona. Eli meillä on 16 tavua. Miltä ne

429
00:46:27,310 --> 00:46:30,890
näyttävät? No, ensin, tarvitsemme tilaa 
laajennukselle. Tarvitsemme paljon

430
00:46:30,890 --> 00:46:36,100
oikeuksia. Sitten laitamme 4 tavua
itse oikeus arvolle - Se on myös selkokielisessä

431
00:46:36,100 --> 00:46:42,270
muodossa dokumentissa. Sitten tarvitsemme
yhden tavun salatulle metadatalle, ja jostain

432
00:46:42,270 --> 00:46:46,840
syystä tarvitsemme lyhenteen, "adb", jätän
teidät miettimään mitä se tarkoittaa.

433
00:46:46,840 --> 00:46:52,700
Ja lopuksi, meillä on 4 satunnaista tavua,
koska meidän täytyy täyttää 16 tavua,

434
00:46:52,700 --> 00:47:00,260
ja meiltä loppui ideat. Okei.
Otetaan tämä kaikki, salataan se, ja

435
00:47:00,260 --> 00:47:05,980
no, me tiedämme siitä paljon, ja se on
periaatteessa tunnettua selkotekstiä.

436
00:47:05,980 --> 00:47:12,940
Joka on paha. Katsotaan miltä tämä näyttää
dokumentissa. Eli, näette oikeus-arvon,

437
00:47:12,940 --> 00:47:16,410
merkkasin sen tänne alas. Se on oikeasti
laajennettu arvo, jonka olen näyttänyt

438
00:47:16,410 --> 00:47:22,750
viimeisellä kalvolla. Ja sen yläpuolella
näette puretun arvon, joka on oikeus-

439
00:47:22,750 --> 00:47:28,030
arvon sisällä, eli miinus 4 tässä kohtaa,
se on periaattessa bitti kenttä, oikealla

440
00:47:28,030 --> 00:47:33,610
näette oikean salatun sisällön, ja
avuliaasti, kaikki tämä on salattu

441
00:47:33,610 --> 00:47:37,750
koko dokumentin laajuisella avaimella
uusimmassa spesifikaation versiossa.

442
00:47:37,750 --> 00:47:43,510
Ja se tarkoittaa, että voime uudelleen
käyttää tätä selkotekstiä missä tahansa

443
00:47:43,510 --> 00:47:48,930
kohtaa dokumentissa ja voimme käyttää tätä
rakentaessa värkkejä. Yhteenvetona

444
00:47:48,930 --> 00:47:53,190
viimeisestä teille. Adobe päätti lisätä 
oikeudet PDF formaattiin ja ihmiset

445
00:47:53,190 --> 00:47:56,950
alkoivat peukaloimaan niitä. Joten he 
päättivät salata nämä oikeudet estääkseen

446
00:47:56,950 --> 00:48:06,360
peukaloinnin, ja nyt tunnettu selkoteksti
on saatavilla hyökkääjille. No niin. Eli

447
00:48:06,360 --> 00:48:14,330
siinä oli käytännössä kaikki edellytykset,
ja jälleen tehdäänpä demo. Eli jälleen

448
00:48:14,330 --> 00:48:20,180
avaamme tämän dokumentin, annamme ,
salasanan, no, heti kun Chrome päättää avata

449
00:48:20,180 --> 00:48:26,740
tämän dokumentin, annamme salasanan, se
on sama kuin aiemmin. Nyt olen

450
00:48:26,740 --> 00:48:31,630
valmistellut scriptin teille, koska en voi
tehdä tätä livenä, ja se periaatteessa

451
00:48:31,630 --> 00:48:35,400
tekee mitä sen teille kerroin tekevän. Se
ottaa tyhjiä värkkejä perms arvosta.

452
00:48:35,400 --> 00:48:39,670
Se generoi URLin siitä. Se generoi
kentän nimen, jotta se näyttää

453
00:48:39,670 --> 00:48:45,410
kivalta serverin päässä, me uudelleen
luomme tämän dokumentin ja laitamme

454
00:48:45,410 --> 00:48:50,080
lomakkeen sinne. Käynnistämme web palvelimen,
avaamme tämän muokatun dokumentin, annamme

455
00:48:50,080 --> 00:48:55,540
salasanan taas ja, no Chrome ei edes kysele.
Ja heti kun dokumentti on avattu Chromessa

456
00:48:55,540 --> 00:48:59,160
ja salasana on annettu, me saamme
meidän salaisen viestin toimitettuna

457
00:48:59,160 --> 00:49:07,080
hyökkääjälle.
Aplodeja

458
00:49:07,080 --> 00:49:13,510
Eli otimme 27 lukijaa ja havaitsimme, että
kaikki olivat haavoittuvia ainakin yhdelle

459
00:49:13,510 --> 00:49:18,390
hyökkäyksistämme. Eli osa niistä toimi
täysin ilman käyttäjän toimia kuten näimme

460
00:49:18,390 --> 00:49:22,730
Chromessa. Osa toimi käyttäjän toimien
avulla tietyissä tapauksissa, kuten näimme

461
00:49:22,730 --> 00:49:30,660
Adoben varoituksesta mutta yleisesti
kaikki näistä oli hyökättävissä jollain

462
00:49:30,660 --> 00:49:35,670
tavalla. No mitä tälle voi tehdä? No, voit
ajatella, että allekirjoitus auttaisi.

463
00:49:35,670 --> 00:49:40,250
Se on yleensä ensimmäinen seikka, jonka
käyttäjät tuovat esille. "allekirjoitus

464
00:49:40,250 --> 00:49:46,550
salatussa tiedostossa auttaa". No, ei. Ei 
oikeasti. Miksei ? No ensinnäkin rikkinäinen

465
00:49:46,550 --> 00:49:50,332
allekirjoitus ei estä avaamasta 
dokumenttia. Eli voimme silti pystyä

466
00:49:50,332 --> 00:49:54,360
exfiltroimaan heti kun salasana on annettu.
Allekirjoitukset voi poistaa, koska niitä

467
00:49:54,360 --> 00:49:57,700
ei salata. Ja kuten näitte aiemmin, ne
voidaan myös väärentää useimmissa

468
00:49:57,700 --> 00:50:02,960
lukijoissa. Allekirjoitukset eivät ole 
vastaus. Exfiltrointi kanavan sulkeminen

469
00:50:02,960 --> 00:50:08,360
ei myöskään ole vastaus, sillä ensinnäkin
se on vaikeaa. Ja kuinka edes löytäisit

470
00:50:08,360 --> 00:50:14,690
kaikki exfiltrointikanavat 800 sivuisesta
standardista? Tarkoitan, että olemme vain

471
00:50:14,690 --> 00:50:18,430
vähän raapaisseet pintaa exfiltrointi 
kanavissa. Ja poistaisimmeko tosiaan

472
00:50:18,430 --> 00:50:24,290
lomakkeet ja hyperlinkit dokumenteista. Ja
pitäisikö meidän poistaa JavaScript? OK,

473
00:50:24,290 --> 00:50:28,700
ehkä meidän pitäisi. Ja lopuksi, jos sinun
täytyy tehdä se, kysy käyttäjältä ennen

474
00:50:28,700 --> 00:50:34,300
yhteyttä web palvelimelle. Eli katsotaan
joitain valmistajien reaktioita. Apple

475
00:50:34,300 --> 00:50:38,680
päätti tehdä kuten kerroin teille: lisätä
dialogin käyttäjän varoittamiseksi ja

476
00:50:38,680 --> 00:50:44,460
näyttää koko URL salatun selkotekstin 
kanssa. Ja Google päätti lopettaa yrittämästä

477
00:50:44,460 --> 00:50:49,830
korjata rikkinäistä Chromessa. He korjasivat
automaattisen exfiltroinnin, mutta he eivät

478
00:50:49,830 --> 00:50:54,290
voi mitään standardille. Eli se on
ongelma jolle täytyy tehdä jotain

479
00:50:54,290 --> 00:51:00,230
standardissa. Ja siinä se periaatteessa oli.
Paketointihyökkäysten mitigoimiseksi meidän

480
00:51:00,230 --> 00:51:04,110
pitää poistaa osittainen salaus ja estää
pääsy salaamattomista objekteista

481
00:51:04,110 --> 00:51:08,450
salattuihin. Ja värkkihyökkäysiä vastaan,
meidän tulee käyttää autentikoivaa

482
00:51:08,450 --> 00:51:16,221
salausta, kuten AES-GCM. OK. Ja Adobe on
kertonut meille, että he eskaloivat tämän

483
00:51:16,221 --> 00:51:19,980
ISO työryhmälle, joka nykyisin vastaa
PDF standardista ja tämä otetaan

484
00:51:19,980 --> 00:51:24,710
huomioon seuraavassa versiossa.
Ja se on mielestäni voitto.

485
00:51:24,710 --> 00:51:30,950
Aplodeja

486
00:51:30,950 --> 00:51:36,330
Herald: Kiitos paljon, kundit. Se oli
todella mahtavaa. Olkaa hyvä ja

487
00:51:36,330 --> 00:51:41,290
jonottakaa mikrofoneille jos teillä on
kysyttävää, meillä on vähän aikaa Q & A:han

488
00:51:41,290 --> 00:51:45,180
Mutta mielestäni teidän tutkimus oli todella
kiinnostavaa, sillä se avasi mieleni siihen

489
00:51:45,180 --> 00:51:51,490
kuinka tätä voisi väärinkäyttää 
käytännössä? Kuten, en tiedä,

490
00:51:51,490 --> 00:51:54,760
kuten, mitä mieltä olet? Luulen, että
kun olet työskennellyt tämän parissa

491
00:51:54,760 --> 00:51:59,020
kauan, sinulla on joku ajatus, minkälaisia
ilkeyksiä voisit keksiä tämän avulla.

492
00:51:59,020 --> 00:52:02,680
Fabian: Tarkoitan, tämä on silti hyökkäys
skenaario

493
00:52:02,680 --> 00:52:08,080
joka vaatii paljon resursseja ja 
erittäin motivoituneen hyökkääjän. Eli

494
00:52:08,080 --> 00:52:13,680
tämä ei välttämättä ole tärkeä tavalliselle
käyttäjälle. Ollaan tosissaan. Suurin osa

495
00:52:13,680 --> 00:52:19,100
meistä ei ole NSAn kohteena, arvelen. Eli
tarvitset aktiivisen hyökkääjän, aktiivisen

496
00:52:19,100 --> 00:52:21,070
ihmisen keskellä toteuttaaksesi nämä
hyökkäykset.

497
00:52:21,070 --> 00:52:25,800
Herald: Hienoa, kiitos. Ja luulen, että
meillä on kysymys mikrofonilla numero

498
00:52:25,800 --> 00:52:28,850
neljä, ole hyvä.
Mikrofoni 4: Kyllä, kerroit, että seuraava

499
00:52:28,850 --> 00:52:32,700
standardin versio voisi sisältää korjauksen.
Tiedättekö kauanko kestää rakentaa

500
00:52:32,700 --> 00:52:41,450
sellainen standardi?
Fabian: No, me emme oikeastaan tiedä.

501
00:52:41,450 --> 00:52:44,640
Puhuimme Adoben kanssa ja he kertoivat
meille, että näyttävät seuraavan version

502
00:52:44,640 --> 00:52:48,950
standardista ennen sen julkaisua, mutta
meillä ei ole ajankohtaa heiltä.

503
00:52:48,950 --> 00:52:51,950
Mikrofoni 4: OK, Kiitoksia.

504
00:52:51,950 --> 00:52:57,400
Herald: Kiitoksia.
Mikrofoni numero viisi, ole hyvä.

505
00:52:57,400 --> 00:53:02,300
Mikrofoni 5: Kiitos mielenkiintoisesta 
esityksestä. Näytitte ensimmäisessä osassa

506
00:53:02,300 --> 00:53:09,140
että allekirjoituksessa on nämä neljä
numeroa tavu-avaruudessa. Ja miksi se

507
00:53:09,140 --> 00:53:15,580
siis, neljä numeroa, eivät ole osa
allekirjoitusta? Onko siihen tekninen syy?

508
00:53:15,580 --> 00:53:18,480
Koska tavu offset on ennustettava.

509
00:53:18,480 --> 00:53:24,470
Vlad: Se on! Tavu-avaruudet suojaa
allekirjoitus. Mutta me juuri määritimme

510
00:53:24,470 --> 00:53:31,710
toisen ja juuri siirsimme allekirjoitetun
varmenenttavaksi myöhemmin. Eli siinä on

511
00:53:31,710 --> 00:53:37,530
kaksi tavu-avaruutta. Mutta vain ensimmäinen,
manipuloitu, prosessoidaan.

512
00:53:37,530 --> 00:53:42,580
Mikrofoni 5: Kiitoksia
Herald: Kiitos paljon. Mikrofoni

513
00:53:42,580 --> 00:53:47,940
numero neljä, ole hyvä.
Mikrofoni 4: Oh, tämä on liian korkealla

514
00:53:47,940 --> 00:53:53,870
minulle. OK. Minulla on vastaus ja kysymys
teille. Mainitsit esityksen aikana, että

515
00:53:53,870 --> 00:53:58,690
et ole varma miten oikeusvirasto jakelee
salasanat PDF salausta varten.

516
00:53:58,690 --> 00:54:07,940
Vastaus on: Selkokielisenä, erillisessä 
sähköpostissa tai viikon

517
00:54:07,940 --> 00:54:14,300
salasanana, joka jaellaan eri
keinoin. Tämä on myös mitä

518
00:54:14,300 --> 00:54:20,370
kotimaan turvallisuuden virasto tekee,
ja armeija on vähän vähemmän tyhmä.

519
00:54:20,370 --> 00:54:27,030
Kysymyksenä: Minulla on noin puoli teraa
arkaluonteisia PDF:ia jotka haluaisin

520
00:54:27,030 --> 00:54:36,910
skannata hyökkäystänne varten ja samalla
poistovirheiden varalta. Tiedättekö mitään

521
00:54:36,910 --> 00:54:45,560
nopeaa ja toimivaa tapaa skannata dokumentteja
tämän tapaisen hyökkäyksen varalta?

522
00:54:45,560 --> 00:54:51,970
Fabian: En tiedä yhtään työkalua, mutta 
tarkoitan, skannaus värkki hyökkäyksiltä

523
00:54:51,970 --> 00:54:58,390
on oikeasti mahdollista, jos koitat tehdä
entropian tarkastusta. Eli koska uudelleen-

524
00:54:58,390 --> 00:55:01,870
käytät salatekstiä, sinulla on vähemmän
entropiaa salatekstissä, mutta se on vaikeaa.

525
00:55:01,870 --> 00:55:07,350
Suoran enxfiltroinnin havaitsemisen 
pitäisi olla mahdollista skannaamalla sanat

526
00:55:07,350 --> 00:55:12,300
kuten "identify". No sen lisäksi, 18 eri
tekniikkaa, jotka annettiin paperissa

527
00:55:12,300 --> 00:55:15,980
Mutta en tiedä mitään työkalua joka
tekisi sen automaattisesti.

528
00:55:15,980 --> 00:55:21,560
Mikrofoni 4: Kiitos.
Herald. Hienoa. Ja mikrofoni

529
00:55:21,560 --> 00:55:24,200
numero kaksi, ole hyvä.
Mikrofoni 2: Kiitos kiinnostavasta

530
00:55:24,200 --> 00:55:30,220
esityksestä. Minulla on yksi ehdotus ja
yksi kysymys mitigointi keinoista. Jos vain

531
00:55:30,220 --> 00:55:33,810
ajat PDF lukijaasi virtuaalikoneessa,
joka on palomuuritettu, eli sinun

532
00:55:33,810 --> 00:55:38,660
palomuuri ei sinun mennä ulos. Mutta
allekirjoitus väärennöksiin.

533
00:55:38,660 --> 00:55:43,020
minulla oli ajatus. En ole varma onko se
tyhmä idea, mutta harkitsitteko

534
00:55:43,020 --> 00:55:47,440
sertifikaatin väärentämistä? Koska
oletettavasti allekirjoitus on myyjän

535
00:55:47,440 --> 00:55:52,250
sertifikaatin suojaama. Sinä teet omasi,
ja allekirjoitat sillä sen. Saako se sen

536
00:55:52,250 --> 00:55:57,670
kiinni ja miten ?
Vladi: me harkitsimme sitä, mutta emme

537
00:55:57,670 --> 00:56:04,900
tässä paperissa. Oletamme, että sertifikaatti
ja koko luottamusketju tässä polussa on

538
00:56:04,900 --> 00:56:11,750
turvallinen. Se oli vain oletus keskittyä
vain hyökkäyksiin jotka olimme jo

539
00:56:11,750 --> 00:56:19,600
löytäneet. Eli, ehkä tähän tulee vielä
jatkotutkimusta toimestamme tulevina

540
00:56:19,600 --> 00:56:22,810
kuukausina ja vuosina.
Herald: Me saatamme kuulla teistä lisää

541
00:56:22,810 --> 00:56:27,890
tulevaisuudessa. Kiitos paljon. Ja nyt
kysymyksiä Internetistä, olkaa hyvä.

542
00:56:27,890 --> 00:56:34,800
Signal Angel: Minulla on kaksi kysymystä
ensimmäisestä osasta esitystä Internetistä.

543
00:56:34,800 --> 00:56:40,540
Ensiksi, mainistitte muutaman reaktion, 
mutta voitteko antaa lisää yksityiskohtia

544
00:56:40,540 --> 00:56:46,510
kokemuksistanne valmistajien kanssa kun
raportoitte nämä ongelmat?

545
00:56:46,510 --> 00:56:58,480
Vladi: Yeah. Me, ... kun ensimmäistä kertaa
aloitimme, pyysimme CERT teamia BSI:sta,

546
00:56:58,480 --> 00:57:04,790
CERT-Bund, auttamaan meitä, koska oli monia
valmistajia, joita asia koski emmekä pystyneet

547
00:57:04,790 --> 00:57:13,580
tukemaan heitä merkityksellisellä tavalla.
Joten he tukivat meitä koko matkan ajan.

548
00:57:13,580 --> 00:57:19,880
Me ensin teimme raportin, joka sisälsi
tarkan kuvauksen haavoittuvuuksista

549
00:57:19,880 --> 00:57:26,190
ja vanhoista exploiteista. Sitten jaoimme
sen BSI:lle ja he ottivat yhteyttä

550
00:57:26,190 --> 00:57:32,540
valmistajiin ja välittivät kommunikaation
ja siinä oli paljon kommunikaatiota.

551
00:57:32,540 --> 00:57:36,680
En ole varma kaikesta viestinnästä, 
vain teknisistä

552
00:57:36,680 --> 00:57:45,930
jutuista, mitä meitä pyydettiin uudelleen
kokeilemaan korjauksia ja niin edelleen.

553
00:57:45,930 --> 00:57:52,810
Eli siinä oli reaktio Adobelta, Foxit:lta ja
monet lukijat reagoivat hyökkäyksiimme ja

554
00:57:52,810 --> 00:57:58,210
ottivat yhteyttä meihin, mutta eivät kaikki.
Herald: Kiitos paljon. Valitettavasti siinä

555
00:57:58,210 --> 00:58:01,670
oli kaikki aika, mitä meillä oli
kysymyksille tänään. Luulen että te

556
00:58:01,670 --> 00:58:06,080
voisitte pyöriä tässä vielä hetken aikaa
jos jollain olisi vielä lisää kysymyksiä.

557
00:58:06,080 --> 00:58:10,930
Fabian, kiitän sinua... ja Vladislav liian
vähän. Kiitos oikein paljon.

558
00:58:10,930 --> 00:58:13,040
Se oli todella mielenkiintoista. Antakaa
heille suuret aplodit.

559
00:58:13,040 --> 00:58:14,793
Vladi: Kiitoksia sinulle.
Aplodeja

560
00:58:14,793 --> 00:58:20,299
36c3 Loppumusiikki

561
00:58:20,299 --> 00:58:43,000
Translated by Esa Lammi
(KYBS2004 course assignment at JYU.FI)