WEBVTT

00:00:00.000 --> 00:00:01.000
Translated by Esa Lammi
(KYBS2004 course assignment at JYU.FI)

00:00:01.000 --> 00:00:19.480
♪ 36c3 intromusiikki ♪

00:00:19.480 --> 00:00:25.090
Herald: Seuraavaksi kuulemme kuinka murretaan
PDF, murretaan salaus ja allekirjoitukset

00:00:25.090 --> 00:00:32.910
Puhujina Fabian Ising ja Vladislav
Mladenov. Heidän puheensa hyväksyttiin CCS

00:00:32.910 --> 00:00:37.750
tänä vuonna Lontoossa ja he pitivät sen
marraskuussa. Se tulee tutkimuksesta joka

00:00:37.750 --> 00:00:43.660
periaatteessa tuotti kaksi erilaista paperia
ja se on ollut... Ihmiset maailmanlaajuisesti

00:00:43.660 --> 00:00:47.540
ovat olleet kiinnostuneita mitä on ollut
meneillään. Antakaa heille suuret

00:00:47.540 --> 00:00:51.758
aplodit ja toivottakaa heidät
tervetulleiksi lavalle.

00:00:51.758 --> 00:00:59.150
Aplodeja

00:00:59.150 --> 00:01:11.590
Vladi: Eli kuulette minut? Yeah. Loistavaa.
OK. Nyt näette kalvot. Minun nimeni on

00:01:11.590 --> 00:01:15.220
Vladislav Mladenov, tai vain Vladi jos
sinulla on jotain kysymyksiä minulle ja

00:01:15.220 --> 00:01:20.670
tässä on Fabian. Ja meidän annetaan tänään
puhua kuinka murretaan PDFn turvallisuus

00:01:20.670 --> 00:01:28.230
tai tarkemmin kuinka murretaan kryptografiset
operaatiot PDF tiedostoissa. Me olemme

00:01:28.230 --> 00:01:36.590
suuri ryhmä Bochumin yliopistosta,
Muenster and Hackmanit GmbH:sta

00:01:36.590 --> 00:01:46.159
Ja kuten mainitsin. Puhumme kryptografiasta
ja PDF tiedostoista. Toimiiko se?

00:01:46.159 --> 00:01:57.720
Fabian: Okei. OK. Kokeillaan uudelleen.
Okei.

00:01:57.720 --> 00:02:02.070
Vladi: Loistavaa. Tämä esitys koostuu
kahdesta osasta. Ensimmäinen osa on

00:02:02.070 --> 00:02:07.829
digitaalisesti allekirjoitetuista PDF tiedostoista
ja kuinka voimme tunnistaa ne. Jos avaamme ne

00:02:07.829 --> 00:02:16.230
näemme informaation, että tiedosto on
allekirjoitettu ja että kaikki varmistus

00:02:16.230 --> 00:02:20.690
proseduurit ovat oikein. Ja lisää informaatiota
signature validation panelista

00:02:20.690 --> 00:02:27.220
ja tietoa kuka on allekirjoittanut tämän
tiedoston. Tämä on ensimmäinen osa

00:02:27.220 --> 00:02:35.660
esitystä ja minä esitän sen. Ja toinen
osa käsittelee PDF salattuja

00:02:35.660 --> 00:02:41.280
tiedostoja ja kuinka voimme tunnistaa
sellaiset tiedostot. Jos koitat avata sellaisen

00:02:41.280 --> 00:02:47.080
tiedoston, ensimmäinen asia jonka näet on
salasana kysely. Ja kun olet antanut oikean

00:02:47.080 --> 00:02:51.800
salasanan, tiedosto puretaan ja voit lukea
sisällön tästä tiedostosta.

00:02:51.800 --> 00:02:57.720
Jos avaat sen Adobella, täydentävää 
tietoa siitä

00:02:57.720 --> 00:03:04.420
onko tiedosto suojattu vai ei esitetään.
Ja tämä on toinen osa meidän

00:03:04.420 --> 00:03:11.650
esitystä, ja Fabian puhuu: Kuinka voimme
murtaa PDF salauksen?, Joten ennen kuin

00:03:11.650 --> 00:03:19.450
aloitamme hyökkäämään allekirjoituksiin tai
salaukseen, tarvitsemme vähän pohjatietoa.

00:03:19.450 --> 00:03:22.700
Ja kuuden kalvon jälkeen olette asiantuntijoita
PDF tiedostoista ja ymmärrätte

00:03:22.700 --> 00:03:28.820
niistä aivan kaiken. Mutta se on ehkä
hieman tylsää. Joten olkaa kärsivällisiä:

00:03:28.820 --> 00:03:34.830
Sitä on vain kuusi kalvoa. Ja ensimmäinen on
melko helppo. PDF tiedostot ovat.. Ensimmäinen

00:03:34.830 --> 00:03:42.250
määrittely oli 1993 ja miltei alusta
alkaen PDF kryptografiset operaatiot

00:03:42.250 --> 00:03:48.920
kuten allekirjoitus ja salaus olivat siinä.
Viimeisin versio on PDF 2.0 ja se

00:03:48.920 --> 00:03:57.610
julkaistiin 2017. Ja Adoben mukaan 1,6
miljardia tiedostoa on webissa ja

00:03:57.610 --> 00:04:06.140
mahdollisesti enemmän on webin ulkopuolella.
Joten periaatteessa PDF tiedostot ovat kaikkialla.

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

00:04:11.790 --> 00:04:19.730
näiden ominaisuuksien turvallisuutta. jos 
meillä on hyvin yksinkertainen tiedosto ja

00:04:19.730 --> 00:04:25.390
avaamme sen Adobe Readerilla, näemme ensin,
tietenkin sisällön. "Hello world" tässä

00:04:25.390 --> 00:04:32.060
tapauksessa ja lisää informaatiota tässä
sivussa ja kuinka monta

00:04:32.060 --> 00:04:39.630
sivua tässä dokumentissa on. Mutta mitä
tapahtuisi jos emme käyttäisi PDF lukijaa ja

00:04:39.630 --> 00:04:48.210
käyttäisimme vain jotain tekstieditoria.
käytämme Notepad++:aa avaamiseen ja

00:04:48.210 --> 00:04:56.400
myöhemmin tiedoston manipulointiin. Eli 
zoomaan tähän. Ja emmäisenä näemme, että

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

00:05:04.500 --> 00:05:10.910
informaatiota tästä tiedostosta. Esimerkiksi
jotain tietoa sivuista. Ja tässä

00:05:10.910 --> 00:05:19.740
näet informaation, että PDF tiedosto koostuu
yhdestä sivusta, mutta kiinnostavampaa

00:05:19.740 --> 00:05:27.350
on, että näemme sisällön koko tiedostosta
itsestään. Eli opimme tässä, että

00:05:27.350 --> 00:05:34.960
voimme käyttää yksinkertaista tekstieditoria 
näyttämään ja muokkaamaan PDF tiedostoja.

00:05:34.960 --> 00:05:43.900
Ja hyökkäyksissämme käytämme vain tätä
tekstieditoria. Eli mennään yksityiskohtiin.

00:05:43.900 --> 00:05:51.560
Kuinka PDF tiedostot on strukturoitu ja
kuinka ne prosessoidaan. PDF tiedostot

00:05:51.560 --> 00:05:59.170
koostuvat 4 osasta: header, body ja body on
tärkein osa PDF tiedostoja. Body sisältää

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

00:06:03.820 --> 00:06:11.490
trailer. Erittäin tärkeä asia PDF
prosessoinnissa on, ettei niitä

00:06:11.490 --> 00:06:18.020
käsitellä ylhäältä alas vaan alhaalta ylös.
Joten ensimmäinen

00:06:18.020 --> 00:06:23.700
asia, jonka PDF lukija analysoi
tai prosessoi on traileri. Eli aletaan

00:06:23.700 --> 00:06:28.981
tekemään sitä. Mikä informaatio aloittaa
tämän trailerin? periaatteessa siinä on

00:06:28.981 --> 00:06:35.540
kaksi tärkeää tietoa. Ensimmäisellä
puolella tämä on se informaatio

00:06:35.540 --> 00:06:41.410
mikä on tämän PDF tiedoston juurielementti?
Mikä on ensimmäinen objekti joka

00:06:41.410 --> 00:06:47.860
prosessoidaan? Ja toinen tärkeä tieto on
mistä xref osio alkaa.

00:06:47.860 --> 00:06:54.000
Se on vain tavu offset, joka osoittaa XRef
osion sijainnin PDF tiedostossa.

00:06:54.000 --> 00:07:00.201
Eli tämä osoitin, kuten mainittu aiemmin
osoittaa XREF osioon

00:07:00.201 --> 00:07:05.710
Mutta mistä XRef osiossa on kyse? XRef
osio on luettelo osoittamaan

00:07:05.710 --> 00:07:11.180
tai sisältämään tiedon minne objektit,
jotka määritellään body:ssa on sijoitettu

00:07:11.180 --> 00:07:18.741
tai tavu sijainnit tähän objektiin. Eli 
kuinka voimme lukea tätä outoa XRef

00:07:18.741 --> 00:07:25.540
osiota? Ensimmäinen tieto jonka puramme on
että ensimmäinen objekti, joka määritellään

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

00:07:34.610 --> 00:07:41.090
määritelty. Eli ensimmäinen objekti on tässä.
Ensimmäinen luku on tavu sijainti

00:07:41.090 --> 00:07:46.610
tiedostossa. Toinen on en versionumero. Ja 
viimeinen merkki kertoo, onko

00:07:46.610 --> 00:07:53.200
objektia käytössä vai ei. Eli luettaessa
sitä, tätä XREF osiota lukiessa saamme

00:07:53.200 --> 00:08:00.590
tietoa, että objekti, jonka ID on 0 on
sijainnissa tavu osoite 0 eikä se ole

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

00:08:08.650 --> 00:08:18.370
objektille IDlla 4 ja objektinumero tulee
vain laskemalla se: 0, 1, 2, 3 ja 4

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

00:08:29.430 --> 00:08:35.449
PDF lukija tietää mistä mikin objekti 
löytyy ja se voi esittää sen kunnolla

00:08:35.449 --> 00:08:42.329
ja prosessoida sen. Nyt tulee tärkein osa:
Body, ja mainitsin, että

00:08:42.329 --> 00:08:48.810
body osassa on kaikki sisältö, joka 
esitetään käyttälle sisällytettynä.

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

00:08:58.220 --> 00:09:04.870
"Hello World!". Muut objektit on ovat
mukana myös. Eli jokainen osoitin osoittaa

00:09:04.870 --> 00:09:10.119
täsmälleen jokaisen objektin alku
sijaintiin. Ja kuinka luemme tätä objektia?

00:09:10.119 --> 00:09:15.910
Katsohan, meillä on objekti joka alkaa ID
numerolla, sitten generaatio

00:09:15.910 --> 00:09:24.999
numero ja sana "obj". Eli nyt tiedät
mistä objekti alkaa ja mihin

00:09:24.999 --> 00:09:32.259
se loppuu. Nyt kuinka me voimme prosessoida
tämän body:n? Kuten mainitsin aiemmin,

00:09:32.259 --> 00:09:40.970
trailerissa on tieto juuri elementistä ja
tämä elementti oli ID numerolla 1

00:09:40.970 --> 00:09:48.769
ja generaationumerolla 0. Eli me alamme nyt
lukemaan dokumenttia tästä ja meillä on

00:09:48.769 --> 00:09:55.910
katalogi ja viittaukset joihinkin sivuihin.
Sivut ovat vain kuvaus kaikista sivuista

00:09:55.910 --> 00:10:02.889
jotka ovat mukana tiedostossa. Ja voimme
nähdä tässä, että meillä on tämä numerointi

00:10:02.889 --> 00:10:09.779
kunhan, tai meillä on vain yksi sivu ja
viittaus sivuobjektiin, joka sisältää

00:10:09.779 --> 00:10:15.170
kokonaisuudessaan tiedon sivun
kirjoituksesta. Jos meillä on

00:10:15.170 --> 00:10:22.230
useita sivuja, sitten meillä on monia
elementtejä. Sitten meillä on yksi sivu.

00:10:22.230 --> 00:10:29.850
Ja tässä meillä on sisältö, joka on viittaus
merkkijonoon, jonka jo näimme.

00:10:29.850 --> 00:10:35.139
Hienoa. Jos ymmärsit tämän, sitten tiedät
kaiken tai lähes kaiken PDF

00:10:35.139 --> 00:10:39.360
tiedostoista. Nyt voit vain ottaa editorisi
ja avata sellaisia tiedostoja ja analysoida

00:10:39.360 --> 00:10:50.310
niitä. Sitten tarvitsemme yhden ominaisuuden.
Unohdin viimeisen osan. Yksinkertaisimman osan.

00:10:50.310 --> 00:10:56.129
Headeri. Sen pitäisi olla vain yksi rivi,
joka kertoo mitä versiota käytetään. Esim.

00:10:56.129 --> 00:11:04.779
Meidän tapauksessa, 1.4. Viimeisessä Adoben
versiossa tässä sanotaan 2.0. Nyt tarvitsemme

00:11:04.779 --> 00:11:13.699
ominaisuuden nimeltä "Incremental Update".
Ja kutsun tätä ominaisuutta -Tiedättekö tämän

00:11:13.699 --> 00:11:19.629
ominaisuuden korostamaan jotain PDF
tiedostossa tai lisätä muistilappuja.

00:11:19.629 --> 00:11:24.119
Teknisesti sitä kutsutaan nimellä "Incremental 
Update" Minä kutsun sitä arvioinniksi gradu

00:11:24.119 --> 00:11:30.680
tai kanditöissä oppilailleni, sillä tämä on
tapa jolla toimin. Minä luen tekstin

00:11:30.680 --> 00:11:38.100
ja korostan jotain ja tallennan
tiedon, jonka lisään siihen.

00:11:38.100 --> 00:11:46.970
Teknisesti muistilapun lisäämällä. Tämä
lisä informaatio liitetään tiedoston lopun

00:11:46.970 --> 00:11:53.160
jälkeen. Eli meillä on boby päivitys
joka sisältää juuri tiedon

00:11:53.160 --> 00:12:01.369
informaation lisäyksestä, uudet objektit
ja, tietenkin, uuden XREF osion ja

00:12:01.369 --> 00:12:15.610
uuden trailerin, joka osoittaa tähän uuteen
objektiin. Okei, olemme valmiita. Liittyen

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.

00:12:23.860 --> 00:12:29.679
Mutta havaitsimme jotain todella tärkeää,
koska osittaisessa päivityksessä voimme

00:12:29.679 --> 00:12:36.930
uudelleen määritellä nykyisiä objekteja, 
esimerkiksi, voimme uudellen määritellä

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

00:12:45.730 --> 00:12:51.699
toisella lauseella ja tietenkin Xref osio
ja traileri osoittavat tähän uuteen

00:12:51.699 --> 00:13:00.100
objektiin. Eli tämä on hyvin tärkeää.
Osittaisen päivityksen kanssa emme ole

00:13:00.100 --> 00:13:06.220
rajoittuneita vain korostuksiin tai muisti-
lappuihin. Voimme uudelleenmäärittää

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

00:13:14.399 --> 00:13:23.339
PDF allekirjoituksista. Ensin meidän pitää 
erottaa elektroninen allekijoitus digitaalisesta

00:13:23.339 --> 00:13:28.699
allekirjoituksesta. Elektroninen allekirjoitus.
Teknisestä näkökulmasta, se on vain kuva.

00:13:28.699 --> 00:13:36.369
Minä vain kirjoitin sen PC:llani ja laitoin
sen tiedostoon. Siinä ei ole kryptografista

00:13:36.369 --> 00:13:40.890
suojausta. Se voisin olla minä makaamassa
rannalla tekemässä jotain. Kryptologiselta

00:13:40.890 --> 00:13:45.509
kannalta se on aivan sama. Se ei tarjoa 
mitään turvaa, mitään kryptologista turvaa.

00:13:45.509 --> 00:13:52.739
Mistä puhumme tässä ovat digitaalisesti
allekirjoitetut tiedostot, eli jos avaat

00:13:52.739 --> 00:14:00.290
sellaisen tiedoston, sinulla on enemmän
tietoa liittyen allekirjoitusten varmistamiseen

00:14:00.290 --> 00:14:08.309
ja kuka on allekirjoittanut tämän PDF tiedoston. 
Eli kuten aiemmin mainitsin, tämä esitys

00:14:08.309 --> 00:14:16.689
keskittyy vain näihin digitaalisesti 
allekirjoitettuihin PDF tiedostoihin. Miten ?

00:14:16.689 --> 00:14:22.879
Minkälainen prosessi on digitaalisesti 
allekirjoitetuissa PDF tiedostoissa. Kuvittele

00:14:22.879 --> 00:14:28.639
meillä on tämä abstrakti kuvaus PDF tiedos-
toista. Meillä on header, boxy, xref osa ja

00:14:28.639 --> 00:14:35.480
traileri. Haluamme allekrjoittaa sen. Mitä
tapahtuu on, että otamme PDFn ja osittaisen

00:14:35.480 --> 00:14:41.899
päivityksen kautta lisäämme informaation
siihen liittyen. Siinä on uusi katalogi ja

00:14:41.899 --> 00:14:46.379
vielä tärkeämpää, uusi allekirjoitus objekti
sisältäen allekirjoituksen arvon ja

00:14:46.379 --> 00:14:52.100
tiedon kuka allekirjoitti tämän PDF tiedoston.
Ja tietenkin, siellä on Xref osio ja

00:14:52.100 --> 00:14:58.970
traileri. Ja sinulle oleellista: koko 
tiedosto on nyt suojattu PDF

00:14:58.970 --> 00:15:06.860
allekirjoituksella. Eli tämän alueen
manipuloinnin ei pitäisi olla mahdollista. Eihän?

00:15:06.860 --> 00:15:15.879
Yeah, puhutaanpa tästä: Miksi se ei ole
mahdollista ja miten voimme rikkoa sen?

00:15:15.879 --> 00:15:21.370
Ensiksi tarvitsemme hyökkäys skenaarion. Mitä
haluamme saavuttaa hyökkääjänä. Oletimme

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

00:15:27.839 --> 00:15:35.989
sopimus, kuitti, tai meidän tapauksessa
lasku Amazonilta. Ja jos me avaamme tämän

00:15:35.989 --> 00:15:41.440
tiedoston, allekirjoitus on oikea. Eli 
kaikki on vihreää. Varoituksia ei näytetä ja

00:15:41.440 --> 00:15:48.329
kaiki on hyvin. Mitä koitimme tehdä, oli
ottaa tämä tiedosto, manipuloida sitä jotenkin

00:15:48.329 --> 00:15:56.319
ja lähettää se uhrille. Ja nyt uhri odottaa
saavansa digitaalisesti allekirjoitetun

00:15:56.319 --> 00:16:01.779
PDF tiedoston, eli vain digitaalisen alle-
kirjoituksen poistaminen on hyvin tavallinen

00:16:01.779 --> 00:16:07.600
skenaario ja emme harkinneet sitä, koska
se on tavallinen. Me harkitsimme, että uhri

00:16:07.600 --> 00:16:13.240
odottaa näkevänsä, että siinä on digitaalinen
allekirjoitus ja että se on oikea. Eli varoituksia

00:16:13.240 --> 00:16:20.420
ei esitetä ja koko vasen laita on täysin
kuin tavallisessa toiminnassa.

00:16:20.420 --> 00:16:28.109
Mutta toisessa laidassa, sisältö on vaihdettu,
eli me manipuloimme

00:16:28.109 --> 00:16:33.790
kuittia ja vaihdoimme sen toiseen sisältöön.
Kysymys on, kuinka voimme tehdä sen

00:16:33.790 --> 00:16:41.079
tekniseltä kannalta? Ja tässä loimme kolme
hyökkäystä: Osittainen tallennus hyökkäys,

00:16:41.079 --> 00:16:45.929
allekirjoituksen kääriminen ja yleinen
allekirjoituksen väärenys. Ja nyt esittelen

00:16:45.929 --> 00:16:51.209
tekniikat ja kuinka nämä hyökkäykset
toimivat. Ensimmäinen hyökkäys on

00:16:51.209 --> 00:16:56.839
osittainen tallkennus hyökkäys. Eli kuten
mainitsin aiemmin, osittaisen tallenuksen

00:16:56.839 --> 00:17:06.439
tai osittaisen päivityksen kautta, voimme
lisätä, poistaa ja jopa uudelleenmäärittää

00:17:06.439 --> 00:17:14.650
nykyisiä objekteja ja allekirjoitus pysyy 
eheänä. Miksi näin tapahtuu ?

00:17:14.650 --> 00:17:21.110
Ajatelkaa taas meidän tapausta. Meillä on
header, body, Xref taulu ja trailer ja

00:17:21.110 --> 00:17:27.559
tiedosto on nyt allekirjoitettu ja alle-
kirjoitus suojaa vain alekkirjoitettua aluetta.

00:17:27.559 --> 00:17:32.600
Mitä tapahtuisi jos vain laitan muistilapun
tai korostusta? Osittainen päivitys

00:17:32.600 --> 00:17:39.169
tapahtuu. Jos avaan tiedoston, yleensä tämä
tapahtuu: Meillä on informaatio, että tämä

00:17:39.169 --> 00:17:45.799
allekirjoitus on oikea, koske se alle-
kirjoitettiin ja niin edelleen. Meidän

00:17:45.799 --> 00:17:53.250
ensimmäinen idea oli tehdä body päivitys,
uudelleenmäärittää sisältöä ja Xref taulua

00:17:53.250 --> 00:17:59.419
ja trailerissa osoitetaan uuteen sisältöön.
tämä on aika helppoa, koska se on

00:17:59.419 --> 00:18:04.820
sallittu toiminto PDF tiedostossa, eli me
emme sen odottaneet toimivan emmekä

00:18:04.820 --> 00:18:11.760
olleet niin onnistuneita. Mutta ensimmäinen
idea: Käytimme tätä hyökkäystä, me avasimme

00:18:11.760 --> 00:18:22.080
sen ja saimme tämän viestin. Eli se on 
aika outo viesti, sillä kokenut

00:18:22.080 --> 00:18:27.970
käyttäjä näkee oikean, mutta dokumentti
on päivitetty ja sinun pitäisi tietää

00:18:27.970 --> 00:18:33.580
mitä se oikeasti tarkoittaa. Mutta me emme
pitäneet tätä hyökkäystä onnistuneena

00:18:33.580 --> 00:18:41.110
koska varoitus ei ole sama tai 
allekirjoituksen validointi ei ole sama.

00:18:41.110 --> 00:18:50.909
Eli mitä teimme, arvioimme tätä ensimmäistä
tätä helppoa tapausta vastaan vanhempia

00:18:50.909 --> 00:18:56.860
lukijoita mitä meillä on ja Libre office
esimerkiksi, oli haavoittuva tälle

00:18:56.860 --> 00:19:01.769
helpolle hyökkäykselle. Tämä oli ainoa 
lukija, joka oli haavoittuva tätä helppoa

00:19:01.769 --> 00:19:07.440
versiota kohtaan. Mutta sitten kysyimme
itseltämme: Okei, muut lukijat ovat

00:19:07.440 --> 00:19:14.250
melko turvallisia. Mutta kuinka ne tunnistavat
nämä osittaiset päivitykset? Ja kehittäjän

00:19:14.250 --> 00:19:22.410
näkökulmasta, laiskin asia mitä voimme tehdä
on tarkastaa onko toinen XRef taulu ja

00:19:22.410 --> 00:19:28.330
traileri lisätty allekirjoituksen jälkeen.
Eli lisäsimme vain body päivitykset, mutta

00:19:28.330 --> 00:19:37.450
poistimme kaksi muuta osaa. Tämä ei ole
standardin mukainen PDF tiedosto. Se on

00:19:37.450 --> 00:19:44.789
rikki. Mutta toivoimme, että PDF lukija vain
korjaa tömön kaltaisen jutun meille ja

00:19:44.789 --> 00:19:51.210
että nämä lukijat ovat vikasietoisia. Ja 
olimme melko onnistuneita, koska varmistus

00:19:51.210 --> 00:19:56.320
logiikka toimi: Onko olemassa Xref taulua
ja traileria allekirjoituksen jälkeen?

00:19:56.320 --> 00:20:01.580
Ei ? Okei
Kaikki on hyvin. Allekirjoitus täsmää.

00:20:01.580 --> 00:20:05.450
Varoituksia ei esitetty. Mutta sitten
sovelluslogiikka näki, että osittainen

00:20:05.450 --> 00:20:13.580
päivitys on tehty ja korjasi sen meille
ja prosessoi nämä body päivitykset eikä

00:20:13.580 --> 00:20:21.159
varoituksia näytetty. Osa lukijoista vaati,
trailerin olemassaoloa. En tiedä miksi

00:20:21.159 --> 00:20:25.350
se oli black box testausta. Eli me vain
poistimme Xref taulun, mutta traileri

00:20:25.350 --> 00:20:32.030
oli siellä ja me pystyimme rikkomaan
lisää PDF lukijoita. Monimutkaisin

00:20:32.030 --> 00:20:38.490
versio hyökkäyksestä oli seuraava. Meillä
oli PDF lukijoita tarkastamassa, sisältääkö

00:20:38.490 --> 00:20:47.330
jokainen osittainen päivitys allekirjoitus
objektin. Mutta ne eivät tarkastaneet

00:20:47.330 --> 00:20:53.200
kattaako tämä allekirjoitus osittaisen
päivityksen. Eli me vain leikkaa-liimasimme

00:20:53.200 --> 00:21:01.290
allekirjoituksen joka annettiin tässä ja me
pakotimme PDF lukijan validoimaan

00:21:01.290 --> 00:21:10.100
allekirjoitetun sisällon kahdesti - ja silti
tekemämme body päivitykset prosessoitiin

00:21:10.100 --> 00:21:18.669
ja esimerkiksi, Foxit ja Master PDF olivat
haavoittuvia tämän tyyppiselle hyökkäykselle.

00:21:18.669 --> 00:21:24.909
Eli hyökkäyksen arviointi: Me kokeilimme
osana arviointia 22 eri

00:21:24.909 --> 00:21:31.050
lukijaa - muiden mukana, Adobea
eri versioina, Foxit ja niin edelleen.

00:21:31.050 --> 00:21:41.140
Ja kuten näette 11 - 22:sta olivat
haavoittuvia osittaiselle tallennukselle.

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ä

00:21:47.160 --> 00:21:51.639
osittaiset päivitykset voisivat olla 
vaarallisia allekirjoituksen validoinnille.

00:21:51.639 --> 00:22:01.070
Mutta pystyimme silti ohittamaan nämä 
heidän harkintansa. Meillä oli täydellinen

00:22:01.070 --> 00:22:07.769
keino allekirjoituksen ohittamiseen, tarkoittaen
ettei uhrilla ole keinoa tunnistaa hyökkäystä.

00:22:07.769 --> 00:22:14.269
Rajoitettu allekirjoituksen ohittaminen
tarkoittaa, että uhri halutessaan varmistaa

00:22:14.269 --> 00:22:23.470
allekirjoituksen, klikkaa yhtä - vähintään
yhtä lisäikkunaa ja haluaa juuri varmistaa

00:22:23.470 --> 00:22:31.520
allekirjoituksen, silloin lukija on haavoittuva.
Mutta tärkein asia on, että tiedostoa avatessa

00:22:31.520 --> 00:22:38.080
siinä on statusviesti, että allekirjoitus
validointi ja kaikki

00:22:38.080 --> 00:22:44.289
allekirjoitukset ovat oikeita. Eli tämä oli
ensimmäinen taso ja lukijat olivat

00:22:44.289 --> 00:22:51.390
haavoittuvia tälle. Eli puhutaampa toisesta
hyökkäyslajista. Me kutsuimme sitä

00:22:51.390 --> 00:22:57.970
"allekirjoituksen paketointi hyökkäykseksi"
ja tämä oli monimutkaisin 3 :sta lajista.

00:22:57.970 --> 00:23:04.580
Ja nyt meidän pitää mennä yksityiskohtiin,
miten PDF allekirjoitukset luodaan.

00:23:04.580 --> 00:23:10.450
Kuvittele, että meillä on nyt PDF tiedosto.
Meillä on headeri ja alkuperäinen dokumentti.

00:23:10.450 --> 00:23:15.549
Alkuperäinen dokumentti sisältää headerin,
bodyn, XRef osan ja niin edelleen.

00:23:15.549 --> 00:23:21.919
Ja haluamme allekirjoittaa tämän
dokumentin. Teknisesti, jälleen,

00:23:21.919 --> 00:23:28.700
osittainen päivitys annetaan ja meillä on 
uusi katalogi tässä. Meillä on jotain muita

00:23:28.700 --> 00:23:35.159
objekteja, esimerkiksi, sertifikaatteja jne.
ja allekirjoitus objekteja. Ja keskitymme

00:23:35.159 --> 00:23:38.720
nyt tähän allekirjoitus objektiin, koska se
on keskeinen osa hyökkäykselle jota

00:23:38.720 --> 00:23:45.399
suoritamme. Ja allekirjoitus objekti 
sisältää paljon informaatiota, mutta

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.

00:23:51.460 --> 00:23:57.940
Sisältö käsittää allekirjoituksen arvon. 
Se on PKCS7 taltio sisältäen

00:23:57.940 --> 00:24:05.710
allekirjoituksen arvon ja sertifikaatit, 
joita käytetään allekirjoituksen validointiin

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.

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ä

00:24:23.090 --> 00:24:29.159
on tästä dokumentin alusta allekirjoituksen
alkuarvoon saakka.

00:24:29.159 --> 00:24:35.370
Miksi tarvitsemme tätä? Koska allekirjoituksen
arvo on osa allekirjoitettua aluetta. Eli meidän

00:24:35.370 --> 00:24:42.780
tulee erottaa allekirjoitusarvo dokumentin
käsittelystä. Ja näin tavu-arvoa

00:24:42.780 --> 00:24:49.179
käytetään. Ensimmäinen osa on dokumentin
alusta kunnes allekirjoitettu

00:24:49.179 --> 00:24:54.629
allekirjoitusarvo alkaa ja sen jälkeen kun
allekirjoitus loppuu aina tiedoston

00:24:54.629 --> 00:25:04.759
lopussa on toinen alue, jonka määrittää 
kaksi lukua C ja D. Eli nyt meillä on

00:25:04.759 --> 00:25:13.500
kaikki suojattu, paitsi allekirjoituksen
arvo itse. Mitä halusimme kokeilla, oli

00:25:13.500 --> 00:25:21.889
luoda lisää tilaa hyökkäyksillemme. Eli
ajatuksena oli siirtää toista allekirjoitettua

00:25:21.889 --> 00:25:30.350
aluetta. Ja kuinka teimme sen? Periaatteessa
voimme vain määritellä uuden tavu alueen.

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

00:25:40.240 --> 00:25:46.889
emme tehneet mitään manipulointeja tässä
osassa, emmehän? Sitä ei muutettu yhtään.

00:25:46.889 --> 00:25:53.309
Eli se on yhä validi. Ja toinen osa, uusi
C arvo ja seuraavat D tavua

00:25:53.309 --> 00:26:00.169
me emme muuttaneet mitään tässä, emmehän?
Eli periaatteessa emme muuttaneet mitään

00:26:00.169 --> 00:26:06.750
allekirjoitetulla alueella. Ja allekirjoitus
on edelleen validi. Mutta mitä teimme,

00:26:06.750 --> 00:26:13.980
loimme lisää tilaa haitallisille objekteille;
joskus tarvitsemme täytettä ja

00:26:13.980 --> 00:26:20.960
lisä osioita osoittamaan tähän
haitalliseen objektiin. Tärkeä asia oli,

00:26:20.960 --> 00:26:27.559
että tämä haitallinen XREf osio, sijainti
määritetään trailerissa. Ja koska

00:26:27.559 --> 00:26:32.799
emme voi muokata traileria, tämä sijainti
on kiinteä. Eli tämä on ainoa rajoite

00:26:32.799 --> 00:26:42.880
hyökkäyksessä, mutta se toimii hienosti.
Ja kysymys on nyt: Kuinka moni

00:26:42.880 --> 00:26:49.730
PDF lukija on haavoittuvainen tälle
hyökkäykselle? Ja kuten näette, tämä on

00:26:49.730 --> 00:26:58.169
allekirjoituksen paketointi sarake. 17
22:sta sovelluksesta on haavoittuva tälle

00:26:58.169 --> 00:27:06.000
hyökkäykselle. Tämä oli melko odotettu tulos
koska hyökkäys oli monimutkainen, emme

00:27:06.000 --> 00:27:14.789
mönenkaan kehittäjän olevan tietoinen
tästä uhasta ja tämä on syy, miksi

00:27:14.789 --> 00:27:22.600
niin monta haavoittuvuutta oli siellä. Ja nyt
viimeinen hyökkäys luokka, yleinen

00:27:22.600 --> 00:27:28.580
allekirjoituksen väärentäminen. Ja kutsumme
sitä yleiseksi allekirjoituksen väärentämiseksi

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

00:27:33.879 --> 00:27:40.909
implementointi virheiksi. Tulemme Pentestaus
alueelta ja tiedän, että moni teistä on

00:27:40.909 --> 00:27:49.880
penaajia myös. Ja monella teistä on 
kokemuksia, kiinnostavia kokemuksia

00:27:49.880 --> 00:27:58.460
nolla-tavujen kanssa, nolla arvojen tai
joidenkin outojen arvojen kanssa. Ja tätä

00:27:58.460 --> 00:28:06.309
koitimme tämän tyyppisessä hyökkäyksessä.
Koitetaan tehdä tyhmiä arvoja tai poistaa

00:28:06.309 --> 00:28:13.100
viittauksia ja katsoa mitä tapahtuu. Katsoessa
allekirjoitusta, siinä on kaksi tärkeää

00:28:13.100 --> 00:28:18.389
eri elementtiä: Sisältö, jossa on alle-
kirjoituksen arvo ja tavualue

00:28:18.389 --> 00:28:25.220
osoittamaan mitä oikeasti on allekirjoitettu.
Eli mitä tapahtuisi, jos poistamme

00:28:25.220 --> 00:28:30.679
sisällön? Toivoimme, että informaatio
allekirjoituksesta olisi edelleen näytetty

00:28:30.679 --> 00:28:37.779
lukijassa oikeana ilman, että mitään
allekirjoitusta validoitaisiin, koska se ei

00:28:37.779 --> 00:28:45.169
ole mahdollista. Ja allekirjoitus arvon
poisto oli ilmeinen ajatus. Ja emme

00:28:45.169 --> 00:28:48.899
onnistuneet tässä hyökkäyksessä. Mutta
jatketaan muiden arvojen kanssa

00:28:48.899 --> 00:28:57.090
esimerkiksi, sisältö ilman arvoa tai
sisältö saman arvoinen kuin NULL tai

00:28:57.090 --> 00:29:04.710
nolla tavua. Ja tämän viimeisen version
kanssa meilllä oli kaksi lukijaa, jotka

00:29:04.710 --> 00:29:15.049
olivat haavoittuvia hyökkäykselle. Ja toinen,
toinen tapaus oli, esimerkiksi, poistamalla

00:29:15.049 --> 00:29:19.929
tavu-alueen. Poistamalla tämän tavu-alueen
meillä on joku allekirjoitus arvo, mutta

00:29:19.929 --> 00:29:29.590
emme tiedä tarkalleen mitä on allekirjoitettu.
Eli koitimme tätä hyökkäystä ja tietenkin,

00:29:29.590 --> 00:29:38.390
tavu-aluetta ilman arvoa tai NULL tavuilla
tai tavu-alue miinuksella tai negatiivisena,

00:29:38.390 --> 00:29:46.169
negatiivisilla numeroilla. Ja yleensä tämä
viimeinen kaatoi paljon lukijoita. Mutta

00:29:46.169 --> 00:29:51.800
mielenkiinotisinta oli, että Adobe teki
tämän virheen vain poistamalla tavu-alueen.

00:29:51.800 --> 00:29:56.990
Pystyimme ohittamaan koko turvallisuuden.
Emme odottaneet tätä käyttäytymistä,

00:29:56.990 --> 00:30:00.950
mutta se oli tyhmä implementointivirhe,
joka salli meidän tehdä mitä tahansa tässä

00:30:00.950 --> 00:30:08.190
dokumentissa ja kaikki exploitit, joita 
näytämme esityksessä tehtiin Adobessa tässä

00:30:08.190 --> 00:30:14.909
hyökkäyksessä. Eli katsoitaan tulokset tästä
hyökkäyksestä. Kuten näette, vain

00:30:14.909 --> 00:30:21.110
4 22:sta lukijasta olivat haavoittuvia
tälle hyökkäykselle ja vain Adobe

00:30:21.110 --> 00:30:26.280
rajoittamattomasti; muiden osalta, oli
rajoituksia koska jos klikkaat allekirjoitus

00:30:26.280 --> 00:30:32.760
validointia, silloin varoitus näytettiin.
Adoben oli helppo korjata se.

00:30:32.760 --> 00:30:37.540
Ja kuten näette, Adobe ei erehtynyt, tehnyt
yhtään virhettä osittaisessa tallennuksessa,

00:30:37.540 --> 00:30:40.820
allekirjoituksen paketoinnissa, mutta 
väitetyssä allekirjoituksen väärennyksessä

00:30:40.820 --> 00:30:48.169
Siellä oltiin haavoittuvia tälle hyökkäykselle.
Ja tätä toivoimme lähestymisellämme.

00:30:48.169 --> 00:30:56.029
Yhteenvetona, onnistuimme rikkomaan
21 22:sta PDF lukijasta. Ainoa...

00:30:56.029 --> 00:31:00.850
Aplodeja
Kiitos

00:31:00.850 --> 00:31:08.149
Aplodeja
Ainoa turvallinen PDF lukija on Adobe 9,

00:31:08.149 --> 00:31:12.860
joka on vanhentunut ja jossa on remote
code execution. Ainoat...

00:31:12.860 --> 00:31:18.039
Naurua
Ainoat käyttäjät, jotka saavat käyttää

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

00:31:25.450 --> 00:31:31.779
ja siksi voit harkita sitä. Eli olen 
valmis puheessa PDF allekirjoituksista

00:31:31.779 --> 00:31:36.644
ja nyt Fabian voi puhua PDF
salauksesta. Kiitos.

00:31:36.644 --> 00:31:42.540
Fabian: Kyllä
Aplodeja

00:31:42.540 --> 00:31:46.759
OK, nyt kun olemme hoidelleet allekirjoitukset
puhutaanpa toisesta kryptografisesta

00:31:46.759 --> 00:31:52.759
tekijästä PDF:ssa. Ja se on salaus.
Ja osa teistä voi muistaa meidän

00:31:52.759 --> 00:31:58.481
PDFex haavoittuvuuden aiemmin tänä
vuonna. Se on tietenkin, hyökkäys logolla

00:31:58.481 --> 00:32:03.720
ja se näyttää kaksi uutta tech
tekniikkaa tähdäten PDF salaukseen jota

00:32:03.720 --> 00:32:08.029
ei ole koskaan kohdistettu PDF salaukseen
ennen. Eli yksi niistä oli nämä ns. suora

00:32:08.029 --> 00:32:12.549
exfiltrointi, jossa rikoimme kryptografian
jopa koskematta kryptografiaan.

00:32:12.549 --> 00:32:18.840
Eli ei salatun tekstin manipulointia tässä.
Toinen on niin kutsuttu

00:32:18.840 --> 00:32:24.690
muokattavat värkit. Ja ne ovat oikeasti
kohdistettuja muokkauksia dokumentin

00:32:24.690 --> 00:32:31.240
salattuun osaan. Mutta ensin, otetaan 
askel takaisin ja uudelleen otetaan

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.

00:32:39.519 --> 00:32:44.220
Eihän? Eli mennään kotiin. Salaus on hyvä.
No, tietenkään emme lopettaneet, vaan

00:32:44.220 --> 00:32:52.160
katsoimme tarkemmin. Eli he käyttävät CBC
toimintatilaa, eli cipher block chaining.

00:32:52.160 --> 00:32:58.309
Ja mikä tärkeämpää on, etteivät he käytä
mitään eheyden suojausta.

00:32:58.309 --> 00:33:04.120
Eli se on eheyssuojaamaton AES-CBC.
Ja saatat muistaa skenaarion

00:33:04.120 --> 00:33:08.909
hyökkäyksistä salattua sähköpostia vastaan,
eli vasten OpenPGPta ja S-MIMEa

00:33:08.909 --> 00:33:15.999
se on periaatteessa sama ongelma.
Mutta ensin kuka oikeasti käyttää PDF

00:33:15.999 --> 00:33:20.940
salausta? Voisit kysyä. Ensinnäkin löysimme
joidenkin paikallisten pankkien Saksassa

00:33:20.940 --> 00:33:26.030
käyttävän salattuja PDFia korvatakseen 
S-MIMEn tai OpenPGPn, koska heidän

00:33:26.030 --> 00:33:34.899
asiakkaansa eivät ehkä halua toimia, umh,
asettaa, ottaa salattua e-mailia käyttöön.

00:33:34.899 --> 00:33:39.740
Toiseksi, oli joitain drop-in plugineja 
sähköpostin salaukseen myös. Eli on

00:33:39.740 --> 00:33:44.570
joitain yrityksiä, jotka tekevät tuotteita,
jotka voit laittaa outlookiin ja voit käyttää

00:33:44.570 --> 00:33:51.330
salattuja PDF tiedostoja salatun
sähköpostin sijaan. Havaitsimme myös

00:33:51.330 --> 00:33:57.919
että jotkus skannerit ja lääketieteelliset
laitteet lähettävät salattuja PDFia e-mailina

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

00:34:02.990 --> 00:34:10.369
ja sinun pitää asettaa salasana
jollain toisella tavalla. Ja viimeisenä löysimme

00:34:10.369 --> 00:34:14.639
että jotkut valtiolliset organisaatiot käyttävät
salattuja PDF dokumentteja, esimerkiksi,

00:34:14.639 --> 00:34:20.409
US Oikeusministeriö antaa lähettää, 
lähettä joitain vaatimuksia salattujen

00:34:20.409 --> 00:34:25.280
PDFien kautta. Enkä ole aivan varma miten
he saavat salasanan, mutta ainakin he sallivat

00:34:25.280 --> 00:34:30.850
sen. Joten koska olemme akatemiasta,
otetaan askel takaisin ja katsotaan

00:34:30.850 --> 00:34:36.860
hyökkäysmalliamme. Meillä on Alice ja
Bob. Alice haluaa lähettää dokumentin Bobille.

00:34:36.860 --> 00:34:42.120
Ja hän haluaa lähettä sen salaamatonta
yhteyttä pitkin tai yhteyttä, johon hän ei

00:34:42.120 --> 00:34:48.610
luota. Joten tietenkin hän päättää salata
sen. Toinen skenaario on, he haluavat

00:34:48.610 --> 00:34:53.020
ladata sen jaettuun tallennukseen. 
Esimerkiksi Dropboxiin ja toiseen jaettuun

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

00:34:57.190 --> 00:35:05.120
päähän salausta. Oletetaanpa, että tämä jaettu
tallennus on oikeasti vaarallinen tai haitallinen.

00:35:05.120 --> 00:35:11.420
Alice lataa, tietenkin, taas salatun
dokumentin hyökkääjälle tässä tapauksessa

00:35:11.420 --> 00:35:17.490
joka suorittaa kohdistettua muokkausta
siihen ja lähettää

00:35:17.490 --> 00:35:22.290
muokatun dokumentin takaisin Bobille,
joka ilmoisesti syöttää salasanan, koska

00:35:22.290 --> 00:35:26.800
hänen näkökulmasta, sitä ei voi erottaa
alkuperäisestä dokumentista

00:35:26.800 --> 00:35:32.880
ja alkuperäinen selkoteksti vuodetaan
takaisin hyökkääjälle, rikkoen

00:35:32.880 --> 00:35:39.730
luottamuksellisuuden. Eli katsotaan
ensimmäistä hyökkäystä kuinka teimme sen.

00:35:39.730 --> 00:35:43.410
Se on suora exfiltrointi, eli kryptauksen
rikkominen koskematta mitenkään

00:35:43.410 --> 00:35:51.360
kryptografiaan, kuten tykkään sanoa. Mutta
ensin, salaus, pähkinänkuoressa, PDF salaus.

00:35:51.360 --> 00:35:54.570
Eli olette nähneet PDF dokumentin rakenteen.
Siinä on header, jossa on

00:35:54.570 --> 00:35:57.280
versionumero. Siinä on body, jossa kaikki
kiinnostavat objektit asuvat. Eli siinä

00:35:59.990 --> 00:36:06.820
on meidän luottamuksellinen sisältö jonka
haluamme oikeastaan, no

00:36:06.820 --> 00:36:14.740
exfiltroida hyökkääjänä. Ja lopuksi, siinä
on Xref taulu ja traileri. Eli

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.

00:36:19.730 --> 00:36:24.080
Eli luottamuksellisen datan sijaan, tietenkin
siellä on nyt jotain salattua salatekstiä

00:36:24.080 --> 00:36:29.010
Okei. Ja loppu pitkälti pysyykin
samana. Ainoa asia, joka lisätään on

00:36:29.010 --> 00:36:36.960
uusi arvo traileriin, joka kertoo meille,
kuinka tämän datan salaus avataan uudelleen.

00:36:36.960 --> 00:36:43.560
Eli siinä on oikeastaan rakenne purettuna.
Ja ajattelimme:

00:36:43.560 --> 00:36:50.120
Miksi näin? Ja katsoimme standardia.
Eli, tämä on ote PDF

00:36:50.120 --> 00:36:55.940
määritelmästä ja olen korostanut 
kiinnostavat osat teille. Salaus koskee

00:36:55.940 --> 00:37:00.690
vain stringeja ja streameja. No, niitä
arvoja, jotka oikeastaan voivat

00:37:00.690 --> 00:37:07.640
sisältää mitään tekstiä dokumentissa ja 
kaikki muut objektit ovat salaamatta. Ja

00:37:07.640 --> 00:37:12.270
se on, koska he haluavat sallia satunnaisen
pääsyn koko dokumenttiin. Eli ei mitään

00:37:12.270 --> 00:37:17.600
parsintaa koko dokumentille, ennen kuin
näytetään sivu 16 salatusta dokumentista.

00:37:17.600 --> 00:37:24.560
No, se vaikuttaa kohtuulliselta. Mutta se
tarkoittaa myös, että koko dokumentin

00:37:24.560 --> 00:37:27.970
rakenne on salaamaton ja ainoastaan
stringit ja streamit ovat salattuja.

00:37:27.970 --> 00:37:31.380
Tämä paljastaa paljon informaatiota
hyökkääjälle jota hänellä ei varmaan

00:37:31.380 --> 00:37:36.420
pitäisi olla. Se on ensinnäkin sivujen 
määrä ja koko, se on määrä

00:37:36.420 --> 00:37:42.610
ja koko objekteilla dokumentissa ja
se käsittää myös kaikki linkit, eli

00:37:42.610 --> 00:37:48.120
kaikki hyperlinkit dokumentissa, jotka
ovat siinä. Ja se on paljon informaatiota

00:37:48.120 --> 00:37:55.260
jota hyökkääjällä ei varmaan pitäisi
olla. Eli seuraavaksi mietimme, ehkä

00:37:55.260 --> 00:38:01.270
voisimme tehdä jotain lisää. Voimmeko
lisätä omaa salaamatonta sisältöä. Ja

00:38:01.270 --> 00:38:05.910
katsoimme standardia uudelleen ja löysimme
ns. crypt filttereitä, jotka tarjoavat tarkemman

00:38:05.910 --> 00:38:10.750
kontrollin salaamiseen. Tämä periaatteessa
tarkoittaa, että hyökkääjänä voin muuttaa

00:38:10.750 --> 00:38:15.920
dokumentin sanomaan, hei, vain
stringit dokumentissa ovat salattuja ja

00:38:15.920 --> 00:38:21.340
streamit ovat selkokielisiä. Sitä varten
identiteetti filtteri on. En tiedä miksi he

00:38:21.340 --> 00:38:27.190
päättivät lisätä sen dokumenttiformaattiin,
mutta siellä se on. Se tarkoittaa, että

00:38:27.190 --> 00:38:31.570
he tukevat osittaista salausta ja se taas
tarkoittaa, että hyökkääjän sisältö voidaan

00:38:31.570 --> 00:38:36.880
sekoittaa salatun sisällön kanssa. Ja
löysimme 18 erilaista tekniikkaa tähän

00:38:36.880 --> 00:38:42.290
eri lukijoissa. Eli on monta tapaa tehdä
se eri lukijoissa.

00:38:42.290 --> 00:38:48.150
Katsotaanpa demoa. Eli meillä on tämä
dokumentti, tämä salattu dokumentti,

00:38:48.150 --> 00:38:54.170
me syötämme salasanan ja saamme salaisen
viestimme. Me avaamme sen taas tekstieditorilla.

00:38:54.170 --> 00:39:00.140
Näemme, objektissa 4 0 alhaalla täällä, siellä
on oikeasti objektin salateksti,

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.

00:39:06.110 --> 00:39:15.670
OK, nyt päätämme lisätä uuden objektin,
joka sisältää, no, selkotekstiä.

00:39:15.670 --> 00:39:22.220
Ja, no, me vain lisäämme sen sisältö
jonoon dokumentissa. Me sanomme

00:39:22.220 --> 00:39:28.241
"näytä tämä ensimmäisellä sivulla"
tallennamme dokumentin. Avaamme sen ja

00:39:28.241 --> 00:39:38.300
laitamme salasanan ja, no tämä todella on
kiusallista. OK. Eli me olemme rikkoneet

00:39:38.300 --> 00:39:44.160
eheyden salatusta dokumentista. No, voit 
ajatella että ehkä he eivät halunneet mitään

00:39:44.160 --> 00:39:49.190
eheyttä salatuissa dokumenteissa. Ehkä se
on ihmisten käyttötapaus, en tiedä.

00:39:49.190 --> 00:39:55.060
Mutta ajattelimme, ehkä voisimme exfiltroida
selkotekstin jotenkin tätä kautta.

00:39:55.060 --> 00:40:00.040
Eli taas otimme askeleen takaisin ja katsoimme
PDF määritystä. Ja ensimmäinen asia jonka

00:40:00.040 --> 00:40:06.080
löysimme oli ns. lähetä lomake toiminto.
Ja se on periaatteessa sama kuin lomake

00:40:06.080 --> 00:40:10.550
web sivulla. Voit syöttää dataa. Olet
voinut nähdä tämän sopimuksessa,

00:40:10.550 --> 00:40:14.740
PDF sopimuksessa, minne voit laittaa nimesi
ja osoitteesi ja niin edelleen ja

00:40:14.740 --> 00:40:23.330
data tallennetaan sisään, sisään
stringeina ja streameina. Ja nyt

00:40:23.330 --> 00:40:27.760
muistakaa, että kaikki mitä on salattuna
dokumentissa. Ja tietenkin, voit

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,

00:40:32.101 --> 00:40:37.890
tietenkin, näppäintä painamalla, mutta
näppäintä painamalla on vähän laimeaa.

00:40:37.890 --> 00:40:42.120
Eli katsoimme taas standardia ja löysimme
ns. open action:in. Ja se on toiminto,

00:40:42.120 --> 00:40:47.190
esimerkiksi, lomakkeen lähettäminen, joka
voidaan suorittaa dokumenttia avatessa.

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.

00:40:54.980 --> 00:41:01.390
Eli meillä on URL tässä, joka on salaamaton
koska kaikki stringit tässä

00:41:01.390 --> 00:41:07.400
dokumentissa ovat salaamattomia, ja 
meillä on arvo objektille 2 0, jossa

00:41:07.400 --> 00:41:13.335
salattu data asustaa. Eli se on arvo
lomakkeen kentälle. Ja mitä

00:41:13.335 --> 00:41:17.120
tapahtuu hyökkääjän puolella kun heti
kun dokumentti avataan? No, saamme

00:41:17.120 --> 00:41:24.540
POST pyynnön, jossa on luottamuksellinen
sisältö. Pidetäänpä demo. Taas, meillä on

00:41:24.540 --> 00:41:30.620
tämä dokumentti. Annamme salasanan. Se on 
alkuperäinen dokumentti, jonka olette jo

00:41:30.620 --> 00:41:36.160
nähneet. Me avaamme sen uudelleen tekstin
lukijassa, tai tekstieditorissa, jälleen huomatkaa

00:41:36.160 --> 00:41:44.160
se on salattu ja päätämme muuttaa kaikki
stringit identity filtterissa. Eli salausta

00:41:44.160 --> 00:41:49.480
ei käytetä stringeissä tästä eteenpäin. Ja
sitten lisäämme koko blobin informaatiota

00:41:49.480 --> 00:41:55.940
open actioniin ja lomakkeeseen.
Eli tämä op- tämä suoritetaan

00:41:55.940 --> 00:42:00.350
heti kun dokumentti avataan. Siellä on
URL, p.df ja arvo

00:42:00.350 --> 00:42:07.540
on salattu objekti 4 0. Käynnistämme HTTP
palvelimen domainissa, jonka määritimme,

00:42:07.540 --> 00:42:12.970
avaamme dokumentin, annamme salasanan
taas ja heti kun avaamme dokumentin

00:42:12.970 --> 00:42:17.770
Adobe avuliaasti näyttää meille
varoituksen, mutta he klikaavat jo

00:42:17.770 --> 00:42:22.170
nappia muistamaan sen seuraavalla kerralla.
Ja jos hyväksyt sen, näet sinun

00:42:22.170 --> 00:42:29.390
salaisen viestin hyökkääjän palvelimella.
Ja tämä on jo aika paha sinänsä.

00:42:29.390 --> 00:42:36.480
OK. Sama toimii hyperlinkeillä, joten 
tietenkin linkkejä on PDF dokumenteissa,

00:42:36.480 --> 00:42:43.600
ja kuten Webissa, voimme määrittää base 
URLin hyperlinkeissä. Eli voimme sanoa

00:42:43.600 --> 00:42:49.940
kaikki URLit dokumentissa alkavat http://p.df.
Ja tietenkin voimme määritellä minkä tahansa

00:42:49.940 --> 00:42:57.260
objektin URLiksi. Eli mikä tahansa objekti,
jonka valmistelemme voidaan lähettää URLina,

00:42:57.260 --> 00:43:01.180
ja se tietenkin laukaisee GET requestin 
kun dokumentti avataan, jos määrittelit

00:43:01.180 --> 00:43:08.750
open actionin objektille. Eli taas aika
paha ja rikkoo luottamuksellisuuden. Ja

00:43:08.750 --> 00:43:16.380
tietenkin, kaikki rakastavat JavaScriptia
PDF tiedostoissa, ja se toimii hyvin. Okei.

00:43:16.380 --> 00:43:21.350
Puhutaanpas ciphertext hyökkäyksistä, eli
oikeista kryptologisista hyökkäyksistä, ei

00:43:21.350 --> 00:43:29.190
enää olla koskematta kryptoon. Voit muistaa
efail hyökkäykset OpenPGP ja S-MIMEen,

00:43:29.190 --> 00:43:34.160
ja niissä oli kolme edellytystä.
1: No, ciphertekstin muokattavuus.

00:43:34.160 --> 00:43:38.690
sitä kutsutaan muokattavaksi värkiksi, siksi
tarvitsemme ciphertekstin

00:43:38.690 --> 00:43:43.850
muokattavuuutta ja meillä ei ole eheyden
suojausta, se on plussaa. Sitten tarvitsemme

00:43:43.850 --> 00:43:48.680
jonkun tunnetun selkotekstin kohdenetuille
muokkauksille. Ja tarvitsemme exfiltrointi

00:43:48.680 --> 00:43:53.070
kanavan lähettämään datan takaisin 
hyökkääjälle. No, exfiltrointikanavat

00:43:53.070 --> 00:43:59.730
käsiteltiin jo kun meillä on hyperlinkit
ja formit. Joten voimme jo ruksata sen.

00:43:59.730 --> 00:44:05.800
Kiva, puhutaan vähän ciphertekstin
muokattavuudesta, mitä kutsumme värkeiksi.

00:44:05.800 --> 00:44:10.180
Jotkut voivat muistaa tämän Krypto 101:sta
tai miltä tahansa kryptografian luennolta

00:44:10.180 --> 00:44:15.290
Tämä on purkutoiminto CBC:ssa
eli Cipher Block

00:44:15.290 --> 00:44:24.030
Chainingissa. Ja se on periaatteessa, sinulla
on ciphertekstisi täällä ylhäällä ja selko-

00:44:24.030 --> 00:44:29.730
tekstisi täällä alhaalla. Ja se toimii 
yksinkertaisesti purkamalla lohkon ciphertekstiä,

00:44:29.730 --> 00:44:35.850
XORaamalla edellisen lohkon ciphertekstiä
siihen, ja saat selkotekstin.

00:44:35.850 --> 00:44:41.070
Eli mitä tapahtuu, jos koitat vaihtaa yhden
bitin ciphertekstissä, esimerkiksi, ensimmäisen

00:44:41.070 --> 00:44:47.530
bitin alustusvektorista? No, se
sama bitti vaihtuu myös oikeassa

00:44:47.530 --> 00:44:53.110
selkotekstissä. Odotas, mitä tapahtuu, jos
satut tietämään koko

00:44:53.110 --> 00:45:00.150
selkoteksti lohkon? No, voimme XORata sen
ensimmäiseen lohkoon ja periaatteessa

00:45:00.150 --> 00:45:05.890
saada kaikki nollaa, tai mitä kutsumme 
värkiksi tai tyhjän paperin, koska voimme

00:45:05.890 --> 00:45:14.130
kirjoittaa siihen ottamalla tunnetun selko-
tekstin ja XORaamalla sen tuloksiin. Ja näin

00:45:14.130 --> 00:45:18.740
voimme, esimerkiksi, rakentaa URLin itse
ciphertekstiin, tai oikeaan seuraavaan

00:45:18.740 --> 00:45:24.420
selkotekstiin. Mitä voimme myös tehdä näillä
värkeillä, värkkejä voidaan siirtää muualle

00:45:24.420 --> 00:45:28.580
dokumentissa, kloonata niitä, jolloin 
meillä voi olla useita värkkejä

00:45:28.580 --> 00:45:34.150
monessa kohdassa ciphertekstiä. Mutta
muistakaa, jos teette sen, sillä

00:45:34.150 --> 00:45:37.800
on aina lumivyöryefekti CBCssa,
eli sinulla on satunnaisia tavuja täällä

00:45:37.800 --> 00:45:45.590
mutta URL pysyy silti paikoillaan.
Okei. Se oli ciphertekstin muokattavuus.

00:45:45.590 --> 00:45:50.610
Kuten sanoin tarvitsemme vähän selkotekstiä.
Meillä pitää olla selkotekstiä. Ja PDF

00:45:50.610 --> 00:45:54.460
standardi on ollut avulias tähän asti, 
PDF salausta rikottaessa, joten

00:45:54.460 --> 00:46:02.071
kurkataan uudelleen. Ja mitä löydämme 
täältä: Oikeudet. Eli PDF dokumentissa voi

00:46:02.071 --> 00:46:08.040
olla eri oikeudet kirjoittajalle ja
dokumentin käyttäjälle. Tämä käytännössä

00:46:08.040 --> 00:46:11.020
tarkoittaa, että kirjoittaja voi muokata
dokumenttia ja käyttäjä ei voisi

00:46:11.020 --> 00:46:16.060
tehdä sitä. Ja tietenkin ihmiset alkoivat
muuttaa sitä- alkoivat sormeilla niitä

00:46:16.060 --> 00:46:20.220
arvoja, jos se oli jätetty salaamatta,
joten uusimmassa versiossa, tehtiin

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

00:46:27.310 --> 00:46:30.890
näyttävät? No, ensin, tarvitsemme tilaa 
laajennukselle. Tarvitsemme paljon

00:46:30.890 --> 00:46:36.100
oikeuksia. Sitten laitamme 4 tavua
itse oikeus arvolle - Se on myös selkokielisessä

00:46:36.100 --> 00:46:42.270
muodossa dokumentissa. Sitten tarvitsemme
yhden tavun salatulle metadatalle, ja jostain

00:46:42.270 --> 00:46:46.840
syystä tarvitsemme lyhenteen, "adb", jätän
teidät miettimään mitä se tarkoittaa.

00:46:46.840 --> 00:46:52.700
Ja lopuksi, meillä on 4 satunnaista tavua,
koska meidän täytyy täyttää 16 tavua,

00:46:52.700 --> 00:47:00.260
ja meiltä loppui ideat. Okei.
Otetaan tämä kaikki, salataan se, ja

00:47:00.260 --> 00:47:05.980
no, me tiedämme siitä paljon, ja se on
periaatteessa tunnettua selkotekstiä.

00:47:05.980 --> 00:47:12.940
Joka on paha. Katsotaan miltä tämä näyttää
dokumentissa. Eli, näette oikeus-arvon,

00:47:12.940 --> 00:47:16.410
merkkasin sen tänne alas. Se on oikeasti
laajennettu arvo, jonka olen näyttänyt

00:47:16.410 --> 00:47:22.750
viimeisellä kalvolla. Ja sen yläpuolella
näette puretun arvon, joka on oikeus-

00:47:22.750 --> 00:47:28.030
arvon sisällä, eli miinus 4 tässä kohtaa,
se on periaattessa bitti kenttä, oikealla

00:47:28.030 --> 00:47:33.610
näette oikean salatun sisällön, ja
avuliaasti, kaikki tämä on salattu

00:47:33.610 --> 00:47:37.750
koko dokumentin laajuisella avaimella
uusimmassa spesifikaation versiossa.

00:47:37.750 --> 00:47:43.510
Ja se tarkoittaa, että voime uudelleen
käyttää tätä selkotekstiä missä tahansa

00:47:43.510 --> 00:47:48.930
kohtaa dokumentissa ja voimme käyttää tätä
rakentaessa värkkejä. Yhteenvetona

00:47:48.930 --> 00:47:53.190
viimeisestä teille. Adobe päätti lisätä 
oikeudet PDF formaattiin ja ihmiset

00:47:53.190 --> 00:47:56.950
alkoivat peukaloimaan niitä. Joten he 
päättivät salata nämä oikeudet estääkseen

00:47:56.950 --> 00:48:06.360
peukaloinnin, ja nyt tunnettu selkoteksti
on saatavilla hyökkääjille. No niin. Eli

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

00:48:14.330 --> 00:48:20.180
avaamme tämän dokumentin, annamme ,
salasanan, no, heti kun Chrome päättää avata

00:48:20.180 --> 00:48:26.740
tämän dokumentin, annamme salasanan, se
on sama kuin aiemmin. Nyt olen

00:48:26.740 --> 00:48:31.630
valmistellut scriptin teille, koska en voi
tehdä tätä livenä, ja se periaatteessa

00:48:31.630 --> 00:48:35.400
tekee mitä sen teille kerroin tekevän. Se
ottaa tyhjiä värkkejä perms arvosta.

00:48:35.400 --> 00:48:39.670
Se generoi URLin siitä. Se generoi
kentän nimen, jotta se näyttää

00:48:39.670 --> 00:48:45.410
kivalta serverin päässä, me uudelleen
luomme tämän dokumentin ja laitamme

00:48:45.410 --> 00:48:50.080
lomakkeen sinne. Käynnistämme web palvelimen,
avaamme tämän muokatun dokumentin, annamme

00:48:50.080 --> 00:48:55.540
salasanan taas ja, no Chrome ei edes kysele.
Ja heti kun dokumentti on avattu Chromessa

00:48:55.540 --> 00:48:59.160
ja salasana on annettu, me saamme
meidän salaisen viestin toimitettuna

00:48:59.160 --> 00:49:07.080
hyökkääjälle.
Aplodeja

00:49:07.080 --> 00:49:13.510
Eli otimme 27 lukijaa ja havaitsimme, että
kaikki olivat haavoittuvia ainakin yhdelle

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

00:49:18.390 --> 00:49:22.730
Chromessa. Osa toimi käyttäjän toimien
avulla tietyissä tapauksissa, kuten näimme

00:49:22.730 --> 00:49:30.660
Adoben varoituksesta mutta yleisesti
kaikki näistä oli hyökättävissä jollain

00:49:30.660 --> 00:49:35.670
tavalla. No mitä tälle voi tehdä? No, voit
ajatella, että allekirjoitus auttaisi.

00:49:35.670 --> 00:49:40.250
Se on yleensä ensimmäinen seikka, jonka
käyttäjät tuovat esille. "allekirjoitus

00:49:40.250 --> 00:49:46.550
salatussa tiedostossa auttaa". No, ei. Ei 
oikeasti. Miksei ? No ensinnäkin rikkinäinen

00:49:46.550 --> 00:49:50.332
allekirjoitus ei estä avaamasta 
dokumenttia. Eli voimme silti pystyä

00:49:50.332 --> 00:49:54.360
exfiltroimaan heti kun salasana on annettu.
Allekirjoitukset voi poistaa, koska niitä

00:49:54.360 --> 00:49:57.700
ei salata. Ja kuten näitte aiemmin, ne
voidaan myös väärentää useimmissa

00:49:57.700 --> 00:50:02.960
lukijoissa. Allekirjoitukset eivät ole 
vastaus. Exfiltrointi kanavan sulkeminen

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

00:50:08.360 --> 00:50:14.690
kaikki exfiltrointikanavat 800 sivuisesta
standardista? Tarkoitan, että olemme vain

00:50:14.690 --> 00:50:18.430
vähän raapaisseet pintaa exfiltrointi 
kanavissa. Ja poistaisimmeko tosiaan

00:50:18.430 --> 00:50:24.290
lomakkeet ja hyperlinkit dokumenteista. Ja
pitäisikö meidän poistaa JavaScript? OK,

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

00:50:28.700 --> 00:50:34.300
yhteyttä web palvelimelle. Eli katsotaan
joitain valmistajien reaktioita. Apple

00:50:34.300 --> 00:50:38.680
päätti tehdä kuten kerroin teille: lisätä
dialogin käyttäjän varoittamiseksi ja

00:50:38.680 --> 00:50:44.460
näyttää koko URL salatun selkotekstin 
kanssa. Ja Google päätti lopettaa yrittämästä

00:50:44.460 --> 00:50:49.830
korjata rikkinäistä Chromessa. He korjasivat
automaattisen exfiltroinnin, mutta he eivät

00:50:49.830 --> 00:50:54.290
voi mitään standardille. Eli se on
ongelma jolle täytyy tehdä jotain

00:50:54.290 --> 00:51:00.230
standardissa. Ja siinä se periaatteessa oli.
Paketointihyökkäysten mitigoimiseksi meidän

00:51:00.230 --> 00:51:04.110
pitää poistaa osittainen salaus ja estää
pääsy salaamattomista objekteista

00:51:04.110 --> 00:51:08.450
salattuihin. Ja värkkihyökkäysiä vastaan,
meidän tulee käyttää autentikoivaa

00:51:08.450 --> 00:51:16.221
salausta, kuten AES-GCM. OK. Ja Adobe on
kertonut meille, että he eskaloivat tämän

00:51:16.221 --> 00:51:19.980
ISO työryhmälle, joka nykyisin vastaa
PDF standardista ja tämä otetaan

00:51:19.980 --> 00:51:24.710
huomioon seuraavassa versiossa.
Ja se on mielestäni voitto.

00:51:24.710 --> 00:51:30.950
Aplodeja

00:51:30.950 --> 00:51:36.330
Herald: Kiitos paljon, kundit. Se oli
todella mahtavaa. Olkaa hyvä ja

00:51:36.330 --> 00:51:41.290
jonottakaa mikrofoneille jos teillä on
kysyttävää, meillä on vähän aikaa Q & A:han

00:51:41.290 --> 00:51:45.180
Mutta mielestäni teidän tutkimus oli todella
kiinnostavaa, sillä se avasi mieleni siihen

00:51:45.180 --> 00:51:51.490
kuinka tätä voisi väärinkäyttää 
käytännössä? Kuten, en tiedä,

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

00:51:54.760 --> 00:51:59.020
kauan, sinulla on joku ajatus, minkälaisia
ilkeyksiä voisit keksiä tämän avulla.

00:51:59.020 --> 00:52:02.680
Fabian: Tarkoitan, tämä on silti hyökkäys
skenaario

00:52:02.680 --> 00:52:08.080
joka vaatii paljon resursseja ja 
erittäin motivoituneen hyökkääjän. Eli

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

00:52:13.680 --> 00:52:19.100
meistä ei ole NSAn kohteena, arvelen. Eli
tarvitset aktiivisen hyökkääjän, aktiivisen

00:52:19.100 --> 00:52:21.070
ihmisen keskellä toteuttaaksesi nämä
hyökkäykset.

00:52:21.070 --> 00:52:25.800
Herald: Hienoa, kiitos. Ja luulen, että
meillä on kysymys mikrofonilla numero

00:52:25.800 --> 00:52:28.850
neljä, ole hyvä.
Mikrofoni 4: Kyllä, kerroit, että seuraava

00:52:28.850 --> 00:52:32.700
standardin versio voisi sisältää korjauksen.
Tiedättekö kauanko kestää rakentaa

00:52:32.700 --> 00:52:41.450
sellainen standardi?
Fabian: No, me emme oikeastaan tiedä.

00:52:41.450 --> 00:52:44.640
Puhuimme Adoben kanssa ja he kertoivat
meille, että näyttävät seuraavan version

00:52:44.640 --> 00:52:48.950
standardista ennen sen julkaisua, mutta
meillä ei ole ajankohtaa heiltä.

00:52:48.950 --> 00:52:51.950
Mikrofoni 4: OK, Kiitoksia.

00:52:51.950 --> 00:52:57.400
Herald: Kiitoksia.
Mikrofoni numero viisi, ole hyvä.

00:52:57.400 --> 00:53:02.300
Mikrofoni 5: Kiitos mielenkiintoisesta 
esityksestä. Näytitte ensimmäisessä osassa

00:53:02.300 --> 00:53:09.140
että allekirjoituksessa on nämä neljä
numeroa tavu-avaruudessa. Ja miksi se

00:53:09.140 --> 00:53:15.580
siis, neljä numeroa, eivät ole osa
allekirjoitusta? Onko siihen tekninen syy?

00:53:15.580 --> 00:53:18.480
Koska tavu offset on ennustettava.

00:53:18.480 --> 00:53:24.470
Vlad: Se on! Tavu-avaruudet suojaa
allekirjoitus. Mutta me juuri määritimme

00:53:24.470 --> 00:53:31.710
toisen ja juuri siirsimme allekirjoitetun
varmenenttavaksi myöhemmin. Eli siinä on

00:53:31.710 --> 00:53:37.530
kaksi tavu-avaruutta. Mutta vain ensimmäinen,
manipuloitu, prosessoidaan.

00:53:37.530 --> 00:53:42.580
Mikrofoni 5: Kiitoksia
Herald: Kiitos paljon. Mikrofoni

00:53:42.580 --> 00:53:47.940
numero neljä, ole hyvä.
Mikrofoni 4: Oh, tämä on liian korkealla

00:53:47.940 --> 00:53:53.870
minulle. OK. Minulla on vastaus ja kysymys
teille. Mainitsit esityksen aikana, että

00:53:53.870 --> 00:53:58.690
et ole varma miten oikeusvirasto jakelee
salasanat PDF salausta varten.

00:53:58.690 --> 00:54:07.940
Vastaus on: Selkokielisenä, erillisessä 
sähköpostissa tai viikon

00:54:07.940 --> 00:54:14.300
salasanana, joka jaellaan eri
keinoin. Tämä on myös mitä

00:54:14.300 --> 00:54:20.370
kotimaan turvallisuuden virasto tekee,
ja armeija on vähän vähemmän tyhmä.

00:54:20.370 --> 00:54:27.030
Kysymyksenä: Minulla on noin puoli teraa
arkaluonteisia PDF:ia jotka haluaisin

00:54:27.030 --> 00:54:36.910
skannata hyökkäystänne varten ja samalla
poistovirheiden varalta. Tiedättekö mitään

00:54:36.910 --> 00:54:45.560
nopeaa ja toimivaa tapaa skannata dokumentteja
tämän tapaisen hyökkäyksen varalta?

00:54:45.560 --> 00:54:51.970
Fabian: En tiedä yhtään työkalua, mutta 
tarkoitan, skannaus värkki hyökkäyksiltä

00:54:51.970 --> 00:54:58.390
on oikeasti mahdollista, jos koitat tehdä
entropian tarkastusta. Eli koska uudelleen-

00:54:58.390 --> 00:55:01.870
käytät salatekstiä, sinulla on vähemmän
entropiaa salatekstissä, mutta se on vaikeaa.

00:55:01.870 --> 00:55:07.350
Suoran enxfiltroinnin havaitsemisen 
pitäisi olla mahdollista skannaamalla sanat

00:55:07.350 --> 00:55:12.300
kuten "identify". No sen lisäksi, 18 eri
tekniikkaa, jotka annettiin paperissa

00:55:12.300 --> 00:55:15.980
Mutta en tiedä mitään työkalua joka
tekisi sen automaattisesti.

00:55:15.980 --> 00:55:21.560
Mikrofoni 4: Kiitos.
Herald. Hienoa. Ja mikrofoni

00:55:21.560 --> 00:55:24.200
numero kaksi, ole hyvä.
Mikrofoni 2: Kiitos kiinnostavasta

00:55:24.200 --> 00:55:30.220
esityksestä. Minulla on yksi ehdotus ja
yksi kysymys mitigointi keinoista. Jos vain

00:55:30.220 --> 00:55:33.810
ajat PDF lukijaasi virtuaalikoneessa,
joka on palomuuritettu, eli sinun

00:55:33.810 --> 00:55:38.660
palomuuri ei sinun mennä ulos. Mutta
allekirjoitus väärennöksiin.

00:55:38.660 --> 00:55:43.020
minulla oli ajatus. En ole varma onko se
tyhmä idea, mutta harkitsitteko

00:55:43.020 --> 00:55:47.440
sertifikaatin väärentämistä? Koska
oletettavasti allekirjoitus on myyjän

00:55:47.440 --> 00:55:52.250
sertifikaatin suojaama. Sinä teet omasi,
ja allekirjoitat sillä sen. Saako se sen

00:55:52.250 --> 00:55:57.670
kiinni ja miten ?
Vladi: me harkitsimme sitä, mutta emme

00:55:57.670 --> 00:56:04.900
tässä paperissa. Oletamme, että sertifikaatti
ja koko luottamusketju tässä polussa on

00:56:04.900 --> 00:56:11.750
turvallinen. Se oli vain oletus keskittyä
vain hyökkäyksiin jotka olimme jo

00:56:11.750 --> 00:56:19.600
löytäneet. Eli, ehkä tähän tulee vielä
jatkotutkimusta toimestamme tulevina

00:56:19.600 --> 00:56:22.810
kuukausina ja vuosina.
Herald: Me saatamme kuulla teistä lisää

00:56:22.810 --> 00:56:27.890
tulevaisuudessa. Kiitos paljon. Ja nyt
kysymyksiä Internetistä, olkaa hyvä.

00:56:27.890 --> 00:56:34.800
Signal Angel: Minulla on kaksi kysymystä
ensimmäisestä osasta esitystä Internetistä.

00:56:34.800 --> 00:56:40.540
Ensiksi, mainistitte muutaman reaktion, 
mutta voitteko antaa lisää yksityiskohtia

00:56:40.540 --> 00:56:46.510
kokemuksistanne valmistajien kanssa kun
raportoitte nämä ongelmat?

00:56:46.510 --> 00:56:58.480
Vladi: Yeah. Me, ... kun ensimmäistä kertaa
aloitimme, pyysimme CERT teamia BSI:sta,

00:56:58.480 --> 00:57:04.790
CERT-Bund, auttamaan meitä, koska oli monia
valmistajia, joita asia koski emmekä pystyneet

00:57:04.790 --> 00:57:13.580
tukemaan heitä merkityksellisellä tavalla.
Joten he tukivat meitä koko matkan ajan.

00:57:13.580 --> 00:57:19.880
Me ensin teimme raportin, joka sisälsi
tarkan kuvauksen haavoittuvuuksista

00:57:19.880 --> 00:57:26.190
ja vanhoista exploiteista. Sitten jaoimme
sen BSI:lle ja he ottivat yhteyttä

00:57:26.190 --> 00:57:32.540
valmistajiin ja välittivät kommunikaation
ja siinä oli paljon kommunikaatiota.

00:57:32.540 --> 00:57:36.680
En ole varma kaikesta viestinnästä, 
vain teknisistä

00:57:36.680 --> 00:57:45.930
jutuista, mitä meitä pyydettiin uudelleen
kokeilemaan korjauksia ja niin edelleen.

00:57:45.930 --> 00:57:52.810
Eli siinä oli reaktio Adobelta, Foxit:lta ja
monet lukijat reagoivat hyökkäyksiimme ja

00:57:52.810 --> 00:57:58.210
ottivat yhteyttä meihin, mutta eivät kaikki.
Herald: Kiitos paljon. Valitettavasti siinä

00:57:58.210 --> 00:58:01.670
oli kaikki aika, mitä meillä oli
kysymyksille tänään. Luulen että te

00:58:01.670 --> 00:58:06.080
voisitte pyöriä tässä vielä hetken aikaa
jos jollain olisi vielä lisää kysymyksiä.

00:58:06.080 --> 00:58:10.930
Fabian, kiitän sinua... ja Vladislav liian
vähän. Kiitos oikein paljon.

00:58:10.930 --> 00:58:13.040
Se oli todella mielenkiintoista. Antakaa
heille suuret aplodit.

00:58:13.040 --> 00:58:14.793
Vladi: Kiitoksia sinulle.
Aplodeja

00:58:14.793 --> 00:58:20.299
36c3 Loppumusiikki

00:58:20.299 --> 00:58:43.000
Translated by Esa Lammi
(KYBS2004 course assignment at JYU.FI)