36C3 - How to Break PDFs

Translated by Esa Lammi
(KYBS2004 course assignment at JYU.FI)

♪ 36c3 intromusiikki ♪

Herald: Seuraavaksi kuulemme kuinka murretaan
PDF, murretaan salaus ja allekirjoitukset

Puhujina Fabian Ising ja Vladislav
Mladenov. Heidän puheensa hyväksyttiin CCS

tänä vuonna Lontoossa ja he pitivät sen
marraskuussa. Se tulee tutkimuksesta joka

periaatteessa tuotti kaksi erilaista paperia
ja se on ollut... Ihmiset maailmanlaajuisesti

ovat olleet kiinnostuneita mitä on ollut
meneillään. Antakaa heille suuret

aplodit ja toivottakaa heidät
tervetulleiksi lavalle.

Aplodeja

Vladi: Eli kuulette minut? Yeah. Loistavaa.
OK. Nyt näette kalvot. Minun nimeni on

Vladislav Mladenov, tai vain Vladi jos
sinulla on jotain kysymyksiä minulle ja

tässä on Fabian. Ja meidän annetaan tänään
puhua kuinka murretaan PDFn turvallisuus

tai tarkemmin kuinka murretaan kryptografiset
operaatiot PDF tiedostoissa. Me olemme

suuri ryhmä Bochumin yliopistosta,
Muenster and Hackmanit GmbH:sta

Ja kuten mainitsin. Puhumme kryptografiasta
ja PDF tiedostoista. Toimiiko se?

Fabian: Okei. OK. Kokeillaan uudelleen.
Okei.

Vladi: Loistavaa. Tämä esitys koostuu
kahdesta osasta. Ensimmäinen osa on

digitaalisesti allekirjoitetuista PDF tiedostoista
ja kuinka voimme tunnistaa ne. Jos avaamme ne

näemme informaation, että tiedosto on
allekirjoitettu ja että kaikki varmistus

proseduurit ovat oikein. Ja lisää informaatiota
signature validation panelista

ja tietoa kuka on allekirjoittanut tämän
tiedoston. Tämä on ensimmäinen osa

esitystä ja minä esitän sen. Ja toinen
osa käsittelee PDF salattuja

tiedostoja ja kuinka voimme tunnistaa
sellaiset tiedostot. Jos koitat avata sellaisen

tiedoston, ensimmäinen asia jonka näet on
salasana kysely. Ja kun olet antanut oikean

salasanan, tiedosto puretaan ja voit lukea
sisällön tästä tiedostosta.

Jos avaat sen Adobella, täydentävää
tietoa siitä

onko tiedosto suojattu vai ei esitetään.
Ja tämä on toinen osa meidän

esitystä, ja Fabian puhuu: Kuinka voimme
murtaa PDF salauksen?, Joten ennen kuin

aloitamme hyökkäämään allekirjoituksiin tai
salaukseen, tarvitsemme vähän pohjatietoa.

Ja kuuden kalvon jälkeen olette asiantuntijoita
PDF tiedostoista ja ymmärrätte

niistä aivan kaiken. Mutta se on ehkä
hieman tylsää. Joten olkaa kärsivällisiä:

Sitä on vain kuusi kalvoa. Ja ensimmäinen on
melko helppo. PDF tiedostot ovat.. Ensimmäinen

määrittely oli 1993 ja miltei alusta
alkaen PDF kryptografiset operaatiot

kuten allekirjoitus ja salaus olivat siinä.
Viimeisin versio on PDF 2.0 ja se

julkaistiin 2017. Ja Adoben mukaan 1,6
miljardia tiedostoa on webissa ja

mahdollisesti enemmän on webin ulkopuolella.
Joten periaatteessa PDF tiedostot ovat kaikkialla.

Ja tämä on se syy miksi harkitsimme tätä
aihetta ja yritimme löytää tai analysoida

näiden ominaisuuksien turvallisuutta. jos
meillä on hyvin yksinkertainen tiedosto ja

avaamme sen Adobe Readerilla, näemme ensin,
tietenkin sisällön. "Hello world" tässä

tapauksessa ja lisää informaatiota tässä
sivussa ja kuinka monta

sivua tässä dokumentissa on. Mutta mitä
tapahtuisi jos emme käyttäisi PDF lukijaa ja

käyttäisimme vain jotain tekstieditoria.
käytämme Notepad++:aa avaamiseen ja

myöhemmin tiedoston manipulointiin. Eli
zoomaan tähän. Ja emmäisenä näemme, että

voimme lukea sitä. Ehkä se on vähän, vähän
hassua. Ja voimme silti saada jotain

informaatiota tästä tiedostosta. Esimerkiksi
jotain tietoa sivuista. Ja tässä

näet informaation, että PDF tiedosto koostuu
yhdestä sivusta, mutta kiinnostavampaa

on, että näemme sisällön koko tiedostosta
itsestään. Eli opimme tässä, että

voimme käyttää yksinkertaista tekstieditoria
näyttämään ja muokkaamaan PDF tiedostoja.

Ja hyökkäyksissämme käytämme vain tätä
tekstieditoria. Eli mennään yksityiskohtiin.

Kuinka PDF tiedostot on strukturoitu ja
kuinka ne prosessoidaan. PDF tiedostot

koostuvat 4 osasta: header, body ja body on
tärkein osa PDF tiedostoja. Body sisältää

kaiken tiedon, joka esitetään käyttäjälle.
Ja kaksi muuta osaa ovat: Xref osio ja

trailer. Erittäin tärkeä asia PDF
prosessoinnissa on, ettei niitä

käsitellä ylhäältä alas vaan alhaalta ylös.
Joten ensimmäinen

asia, jonka PDF lukija analysoi
tai prosessoi on traileri. Eli aletaan

tekemään sitä. Mikä informaatio aloittaa
tämän trailerin? periaatteessa siinä on

kaksi tärkeää tietoa. Ensimmäisellä
puolella tämä on se informaatio

mikä on tämän PDF tiedoston juurielementti?
Mikä on ensimmäinen objekti joka

prosessoidaan? Ja toinen tärkeä tieto on
mistä xref osio alkaa.

Se on vain tavu offset, joka osoittaa XRef
osion sijainnin PDF tiedostossa.

Eli tämä osoitin, kuten mainittu aiemmin
osoittaa XREF osioon

Mutta mistä XRef osiossa on kyse? XRef
osio on luettelo osoittamaan

tai sisältämään tiedon minne objektit,
jotka määritellään body:ssa on sijoitettu

tai tavu sijainnit tähän objektiin. Eli
kuinka voimme lukea tätä outoa XRef

osiota? Ensimmäinen tieto jonka puramme on
että ensimmäinen objekti, joka määritellään

tässä, on objekti jolla on ID 0 ja meillä on
5 lisä elementtiä tai objektia jotka on

määritelty. Eli ensimmäinen objekti on tässä.
Ensimmäinen luku on tavu sijainti

tiedostossa. Toinen on en versionumero. Ja
viimeinen merkki kertoo, onko

objektia käytössä vai ei. Eli luettaessa
sitä, tätä XREF osiota lukiessa saamme

tietoa, että objekti, jonka ID on 0 on
sijainnissa tavu osoite 0 eikä se ole

käytössä. Eli objekti, jonka id on 1 on
sijainnissa 9 ja niin edelleen. Joten

objektille IDlla 4 ja objektinumero tulee
vain laskemalla se: 0, 1, 2, 3 ja 4

Eli objekti IDlla 4 löydetään sijainnista
offset 184 ja se on käytössä. Toisin sanoen

PDF lukija tietää mistä mikin objekti
löytyy ja se voi esittää sen kunnolla

ja prosessoida sen. Nyt tulee tärkein osa:
Body, ja mainitsin, että

body osassa on kaikki sisältö, joka
esitetään käyttälle sisällytettynä.

Eli katsotaanpa. Objekti 4 0 on tämä ja
kuten voit nähdä, se sisältää sanan

"Hello World!". Muut objektit on ovat
mukana myös. Eli jokainen osoitin osoittaa

täsmälleen jokaisen objektin alku
sijaintiin. Ja kuinka luemme tätä objektia?

Katsohan, meillä on objekti joka alkaa ID
numerolla, sitten generaatio

numero ja sana "obj". Eli nyt tiedät
mistä objekti alkaa ja mihin

se loppuu. Nyt kuinka me voimme prosessoida
tämän body:n? Kuten mainitsin aiemmin,

trailerissa on tieto juuri elementistä ja
tämä elementti oli ID numerolla 1

ja generaationumerolla 0. Eli me alamme nyt
lukemaan dokumenttia tästä ja meillä on

katalogi ja viittaukset joihinkin sivuihin.
Sivut ovat vain kuvaus kaikista sivuista

jotka ovat mukana tiedostossa. Ja voimme
nähdä tässä, että meillä on tämä numerointi

kunhan, tai meillä on vain yksi sivu ja
viittaus sivuobjektiin, joka sisältää

kokonaisuudessaan tiedon sivun
kirjoituksesta. Jos meillä on

useita sivuja, sitten meillä on monia
elementtejä. Sitten meillä on yksi sivu.

Ja tässä meillä on sisältö, joka on viittaus
merkkijonoon, jonka jo näimme.

Hienoa. Jos ymmärsit tämän, sitten tiedät
kaiken tai lähes kaiken PDF

tiedostoista. Nyt voit vain ottaa editorisi
ja avata sellaisia tiedostoja ja analysoida

niitä. Sitten tarvitsemme yhden ominaisuuden.
Unohdin viimeisen osan. Yksinkertaisimman osan.

Headeri. Sen pitäisi olla vain yksi rivi,
joka kertoo mitä versiota käytetään. Esim.

Meidän tapauksessa, 1.4. Viimeisessä Adoben
versiossa tässä sanotaan 2.0. Nyt tarvitsemme

ominaisuuden nimeltä "Incremental Update".
Ja kutsun tätä ominaisuutta -Tiedättekö tämän

ominaisuuden korostamaan jotain PDF
tiedostossa tai lisätä muistilappuja.

Teknisesti sitä kutsutaan nimellä "Incremental
Update" Minä kutsun sitä arvioinniksi gradu

tai kanditöissä oppilailleni, sillä tämä on
tapa jolla toimin. Minä luen tekstin

ja korostan jotain ja tallennan
tiedon, jonka lisään siihen.

Teknisesti muistilapun lisäämällä. Tämä
lisä informaatio liitetään tiedoston lopun

jälkeen. Eli meillä on boby päivitys
joka sisältää juuri tiedon

informaation lisäyksestä, uudet objektit
ja, tietenkin, uuden XREF osion ja

uuden trailerin, joka osoittaa tähän uuteen
objektiin. Okei, olemme valmiita. Liittyen

tähän osittaiseen päivitykseen, näimme että
sitä pääasiassa käytettiin lappuihin ja korostuksiin.

Mutta havaitsimme jotain todella tärkeää,
koska osittaisessa päivityksessä voimme

uudelleen määritellä nykyisiä objekteja,
esimerkiksi, voimme uudellen määritellä

objektin ID:lla 4 ja luoda uuden sisällön.
Eli näin korvaamme sanan "Hello World!"

toisella lauseella ja tietenkin Xref osio
ja traileri osoittavat tähän uuteen

objektiin. Eli tämä on hyvin tärkeää.
Osittaisen päivityksen kanssa emme ole

rajoittuneita vain korostuksiin tai muisti-
lappuihin. Voimme uudelleenmäärittää

nykyistä sisältöä ja ehkä tarvitsemme tätä
hyökkäyksissä joita näytämme. Eli puhutaanpa

PDF allekirjoituksista. Ensin meidän pitää
erottaa elektroninen allekijoitus digitaalisesta

allekirjoituksesta. Elektroninen allekirjoitus.
Teknisestä näkökulmasta, se on vain kuva.

Minä vain kirjoitin sen PC:llani ja laitoin
sen tiedostoon. Siinä ei ole kryptografista

suojausta. Se voisin olla minä makaamassa
rannalla tekemässä jotain. Kryptologiselta

kannalta se on aivan sama. Se ei tarjoa
mitään turvaa, mitään kryptologista turvaa.

Mistä puhumme tässä ovat digitaalisesti
allekirjoitetut tiedostot, eli jos avaat

sellaisen tiedoston, sinulla on enemmän
tietoa liittyen allekirjoitusten varmistamiseen

ja kuka on allekirjoittanut tämän PDF tiedoston.
Eli kuten aiemmin mainitsin, tämä esitys

keskittyy vain näihin digitaalisesti
allekirjoitettuihin PDF tiedostoihin. Miten ?

Minkälainen prosessi on digitaalisesti
allekirjoitetuissa PDF tiedostoissa. Kuvittele

meillä on tämä abstrakti kuvaus PDF tiedos-
toista. Meillä on header, boxy, xref osa ja

traileri. Haluamme allekrjoittaa sen. Mitä
tapahtuu on, että otamme PDFn ja osittaisen

päivityksen kautta lisäämme informaation
siihen liittyen. Siinä on uusi katalogi ja

vielä tärkeämpää, uusi allekirjoitus objekti
sisältäen allekirjoituksen arvon ja

tiedon kuka allekirjoitti tämän PDF tiedoston.
Ja tietenkin, siellä on Xref osio ja

traileri. Ja sinulle oleellista: koko
tiedosto on nyt suojattu PDF

allekirjoituksella. Eli tämän alueen
manipuloinnin ei pitäisi olla mahdollista. Eihän?

Yeah, puhutaanpa tästä: Miksi se ei ole
mahdollista ja miten voimme rikkoa sen?

Ensiksi tarvitsemme hyökkäys skenaarion. Mitä
haluamme saavuttaa hyökkääjänä. Oletimme

tutkimuksessa, että hyökkääjällä on hallussa
tämä allekirjoitettu PDF. Tämä voisi olla vanha

sopimus, kuitti, tai meidän tapauksessa
lasku Amazonilta. Ja jos me avaamme tämän

tiedoston, allekirjoitus on oikea. Eli
kaikki on vihreää. Varoituksia ei näytetä ja

kaiki on hyvin. Mitä koitimme tehdä, oli
ottaa tämä tiedosto, manipuloida sitä jotenkin

ja lähettää se uhrille. Ja nyt uhri odottaa
saavansa digitaalisesti allekirjoitetun

PDF tiedoston, eli vain digitaalisen alle-
kirjoituksen poistaminen on hyvin tavallinen

skenaario ja emme harkinneet sitä, koska
se on tavallinen. Me harkitsimme, että uhri

odottaa näkevänsä, että siinä on digitaalinen
allekirjoitus ja että se on oikea. Eli varoituksia

ei esitetä ja koko vasen laita on täysin
kuin tavallisessa toiminnassa.

Mutta toisessa laidassa, sisältö on vaihdettu,
eli me manipuloimme

kuittia ja vaihdoimme sen toiseen sisältöön.
Kysymys on, kuinka voimme tehdä sen

tekniseltä kannalta? Ja tässä loimme kolme
hyökkäystä: Osittainen tallennus hyökkäys,

allekirjoituksen kääriminen ja yleinen
allekirjoituksen väärenys. Ja nyt esittelen

tekniikat ja kuinka nämä hyökkäykset
toimivat. Ensimmäinen hyökkäys on

osittainen tallkennus hyökkäys. Eli kuten
mainitsin aiemmin, osittaisen tallenuksen

tai osittaisen päivityksen kautta, voimme
lisätä, poistaa ja jopa uudelleenmäärittää

nykyisiä objekteja ja allekirjoitus pysyy
eheänä. Miksi näin tapahtuu ?

Ajatelkaa taas meidän tapausta. Meillä on
header, body, Xref taulu ja trailer ja

tiedosto on nyt allekirjoitettu ja alle-
kirjoitus suojaa vain alekkirjoitettua aluetta.

Mitä tapahtuisi jos vain laitan muistilapun
tai korostusta? Osittainen päivitys

tapahtuu. Jos avaan tiedoston, yleensä tämä
tapahtuu: Meillä on informaatio, että tämä

allekirjoitus on oikea, koske se alle-
kirjoitettiin ja niin edelleen. Meidän

ensimmäinen idea oli tehdä body päivitys,
uudelleenmäärittää sisältöä ja Xref taulua

ja trailerissa osoitetaan uuteen sisältöön.
tämä on aika helppoa, koska se on

sallittu toiminto PDF tiedostossa, eli me
emme sen odottaneet toimivan emmekä

olleet niin onnistuneita. Mutta ensimmäinen
idea: Käytimme tätä hyökkäystä, me avasimme

sen ja saimme tämän viestin. Eli se on
aika outo viesti, sillä kokenut

käyttäjä näkee oikean, mutta dokumentti
on päivitetty ja sinun pitäisi tietää

mitä se oikeasti tarkoittaa. Mutta me emme
pitäneet tätä hyökkäystä onnistuneena

koska varoitus ei ole sama tai
allekirjoituksen validointi ei ole sama.

Eli mitä teimme, arvioimme tätä ensimmäistä
tätä helppoa tapausta vastaan vanhempia

lukijoita mitä meillä on ja Libre office
esimerkiksi, oli haavoittuva tälle

helpolle hyökkäykselle. Tämä oli ainoa
lukija, joka oli haavoittuva tätä helppoa

versiota kohtaan. Mutta sitten kysyimme
itseltämme: Okei, muut lukijat ovat

melko turvallisia. Mutta kuinka ne tunnistavat
nämä osittaiset päivitykset? Ja kehittäjän

näkökulmasta, laiskin asia mitä voimme tehdä
on tarkastaa onko toinen XRef taulu ja

traileri lisätty allekirjoituksen jälkeen.
Eli lisäsimme vain body päivitykset, mutta

poistimme kaksi muuta osaa. Tämä ei ole
standardin mukainen PDF tiedosto. Se on

rikki. Mutta toivoimme, että PDF lukija vain
korjaa tömön kaltaisen jutun meille ja

että nämä lukijat ovat vikasietoisia. Ja
olimme melko onnistuneita, koska varmistus

logiikka toimi: Onko olemassa Xref taulua
ja traileria allekirjoituksen jälkeen?

Ei ? Okei
Kaikki on hyvin. Allekirjoitus täsmää.

Varoituksia ei esitetty. Mutta sitten
sovelluslogiikka näki, että osittainen

päivitys on tehty ja korjasi sen meille
ja prosessoi nämä body päivitykset eikä

varoituksia näytetty. Osa lukijoista vaati,
trailerin olemassaoloa. En tiedä miksi

se oli black box testausta. Eli me vain
poistimme Xref taulun, mutta traileri

oli siellä ja me pystyimme rikkomaan
lisää PDF lukijoita. Monimutkaisin

versio hyökkäyksestä oli seuraava. Meillä
oli PDF lukijoita tarkastamassa, sisältääkö

jokainen osittainen päivitys allekirjoitus
objektin. Mutta ne eivät tarkastaneet

kattaako tämä allekirjoitus osittaisen
päivityksen. Eli me vain leikkaa-liimasimme

allekirjoituksen joka annettiin tässä ja me
pakotimme PDF lukijan validoimaan

allekirjoitetun sisällon kahdesti - ja silti
tekemämme body päivitykset prosessoitiin

ja esimerkiksi, Foxit ja Master PDF olivat
haavoittuvia tämän tyyppiselle hyökkäykselle.

Eli hyökkäyksen arviointi: Me kokeilimme
osana arviointia 22 eri

lukijaa - muiden mukana, Adobea
eri versioina, Foxit ja niin edelleen.

Ja kuten näette 11 - 22:sta olivat
haavoittuvia osittaiselle tallennukselle.

Eli 50 prosenttia, ja olimme aika yllättyneitä
koska näimme, että kehittäjän näkivät, että

osittaiset päivitykset voisivat olla
vaarallisia allekirjoituksen validoinnille.

Mutta pystyimme silti ohittamaan nämä
heidän harkintansa. Meillä oli täydellinen

keino allekirjoituksen ohittamiseen, tarkoittaen
ettei uhrilla ole keinoa tunnistaa hyökkäystä.

Rajoitettu allekirjoituksen ohittaminen
tarkoittaa, että uhri halutessaan varmistaa

allekirjoituksen, klikkaa yhtä - vähintään
yhtä lisäikkunaa ja haluaa juuri varmistaa

allekirjoituksen, silloin lukija on haavoittuva.
Mutta tärkein asia on, että tiedostoa avatessa

siinä on statusviesti, että allekirjoitus
validointi ja kaikki

allekirjoitukset ovat oikeita. Eli tämä oli
ensimmäinen taso ja lukijat olivat

haavoittuvia tälle. Eli puhutaampa toisesta
hyökkäyslajista. Me kutsuimme sitä

"allekirjoituksen paketointi hyökkäykseksi"
ja tämä oli monimutkaisin 3 :sta lajista.

Ja nyt meidän pitää mennä yksityiskohtiin,
miten PDF allekirjoitukset luodaan.

Kuvittele, että meillä on nyt PDF tiedosto.
Meillä on headeri ja alkuperäinen dokumentti.

Alkuperäinen dokumentti sisältää headerin,
bodyn, XRef osan ja niin edelleen.

Ja haluamme allekirjoittaa tämän
dokumentin. Teknisesti, jälleen,

osittainen päivitys annetaan ja meillä on
uusi katalogi tässä. Meillä on jotain muita

objekteja, esimerkiksi, sertifikaatteja jne.
ja allekirjoitus objekteja. Ja keskitymme

nyt tähän allekirjoitus objektiin, koska se
on keskeinen osa hyökkäykselle jota

suoritamme. Ja allekirjoitus objekti
sisältää paljon informaatiota, mutta

haluamme tätä hyökkäystä varten vain kaksi
elementtiä ovat tärkeitä. Sisältö ja tavu-alue.

Sisältö käsittää allekirjoituksen arvon.
Se on PKCS7 taltio sisältäen

allekirjoituksen arvon ja sertifikaatit,
joita käytetään allekirjoituksen validointiin

ja tavu-alueen. Tavu-alue sisältää 4 eri
arvoa ja mihin näitä arvoja käytetään.

Ensimmäiset kaksi, A ja B määrittävät
ensimmäisen allekirjoitetun alueen. Ja tämä

on tästä dokumentin alusta allekirjoituksen
alkuarvoon saakka.

Miksi tarvitsemme tätä? Koska allekirjoituksen
arvo on osa allekirjoitettua aluetta. Eli meidän

tulee erottaa allekirjoitusarvo dokumentin
käsittelystä. Ja näin tavu-arvoa

käytetään. Ensimmäinen osa on dokumentin
alusta kunnes allekirjoitettu

allekirjoitusarvo alkaa ja sen jälkeen kun
allekirjoitus loppuu aina tiedoston

lopussa on toinen alue, jonka määrittää
kaksi lukua C ja D. Eli nyt meillä on

kaikki suojattu, paitsi allekirjoituksen
arvo itse. Mitä halusimme kokeilla, oli

luoda lisää tilaa hyökkäyksillemme. Eli
ajatuksena oli siirtää toista allekirjoitettua

aluetta. Ja kuinka teimme sen? Periaatteessa
voimme vain määritellä uuden tavu alueen.

Ja kuten näette tässä, tavu-alue osoittaa
aluetta A:sta B:hen. Eli tähän alueeseen

emme tehneet mitään manipulointeja tässä
osassa, emmehän? Sitä ei muutettu yhtään.

Eli se on yhä validi. Ja toinen osa, uusi
C arvo ja seuraavat D tavua

me emme muuttaneet mitään tässä, emmehän?
Eli periaatteessa emme muuttaneet mitään

allekirjoitetulla alueella. Ja allekirjoitus
on edelleen validi. Mutta mitä teimme,

loimme lisää tilaa haitallisille objekteille;
joskus tarvitsemme täytettä ja

lisä osioita osoittamaan tähän
haitalliseen objektiin. Tärkeä asia oli,

että tämä haitallinen XREf osio, sijainti
määritetään trailerissa. Ja koska

emme voi muokata traileria, tämä sijainti
on kiinteä. Eli tämä on ainoa rajoite

hyökkäyksessä, mutta se toimii hienosti.
Ja kysymys on nyt: Kuinka moni

PDF lukija on haavoittuvainen tälle
hyökkäykselle? Ja kuten näette, tämä on

allekirjoituksen paketointi sarake. 17
22:sta sovelluksesta on haavoittuva tälle

hyökkäykselle. Tämä oli melko odotettu tulos
koska hyökkäys oli monimutkainen, emme

mönenkaan kehittäjän olevan tietoinen
tästä uhasta ja tämä on syy, miksi

niin monta haavoittuvuutta oli siellä. Ja nyt
viimeinen hyökkäys luokka, yleinen

allekirjoituksen väärentäminen. Ja kutsumme
sitä yleiseksi allekirjoituksen väärentämiseksi

mutta suosin toisen määritelmän käyttämistä
tälle hyökkäykselle. Kutsun niitä tyhmiksi

implementointi virheiksi. Tulemme Pentestaus
alueelta ja tiedän, että moni teistä on

penaajia myös. Ja monella teistä on
kokemuksia, kiinnostavia kokemuksia

nolla-tavujen kanssa, nolla arvojen tai
joidenkin outojen arvojen kanssa. Ja tätä

koitimme tämän tyyppisessä hyökkäyksessä.
Koitetaan tehdä tyhmiä arvoja tai poistaa

viittauksia ja katsoa mitä tapahtuu. Katsoessa
allekirjoitusta, siinä on kaksi tärkeää

eri elementtiä: Sisältö, jossa on alle-
kirjoituksen arvo ja tavualue

osoittamaan mitä oikeasti on allekirjoitettu.
Eli mitä tapahtuisi, jos poistamme

sisällön? Toivoimme, että informaatio
allekirjoituksesta olisi edelleen näytetty

lukijassa oikeana ilman, että mitään
allekirjoitusta validoitaisiin, koska se ei

ole mahdollista. Ja allekirjoitus arvon
poisto oli ilmeinen ajatus. Ja emme

onnistuneet tässä hyökkäyksessä. Mutta
jatketaan muiden arvojen kanssa

esimerkiksi, sisältö ilman arvoa tai
sisältö saman arvoinen kuin NULL tai

nolla tavua. Ja tämän viimeisen version
kanssa meilllä oli kaksi lukijaa, jotka

olivat haavoittuvia hyökkäykselle. Ja toinen,
toinen tapaus oli, esimerkiksi, poistamalla

tavu-alueen. Poistamalla tämän tavu-alueen
meillä on joku allekirjoitus arvo, mutta

emme tiedä tarkalleen mitä on allekirjoitettu.
Eli koitimme tätä hyökkäystä ja tietenkin,

tavu-aluetta ilman arvoa tai NULL tavuilla
tai tavu-alue miinuksella tai negatiivisena,

negatiivisilla numeroilla. Ja yleensä tämä
viimeinen kaatoi paljon lukijoita. Mutta

mielenkiinotisinta oli, että Adobe teki
tämän virheen vain poistamalla tavu-alueen.

Pystyimme ohittamaan koko turvallisuuden.
Emme odottaneet tätä käyttäytymistä,

mutta se oli tyhmä implementointivirhe,
joka salli meidän tehdä mitä tahansa tässä

dokumentissa ja kaikki exploitit, joita
näytämme esityksessä tehtiin Adobessa tässä

hyökkäyksessä. Eli katsoitaan tulokset tästä
hyökkäyksestä. Kuten näette, vain

4 22:sta lukijasta olivat haavoittuvia
tälle hyökkäykselle ja vain Adobe

rajoittamattomasti; muiden osalta, oli
rajoituksia koska jos klikkaat allekirjoitus

validointia, silloin varoitus näytettiin.
Adoben oli helppo korjata se.

Ja kuten näette, Adobe ei erehtynyt, tehnyt
yhtään virhettä osittaisessa tallennuksessa,

allekirjoituksen paketoinnissa, mutta
väitetyssä allekirjoituksen väärennyksessä

Siellä oltiin haavoittuvia tälle hyökkäykselle.
Ja tätä toivoimme lähestymisellämme.

Yhteenvetona, onnistuimme rikkomaan
21 22:sta PDF lukijasta. Ainoa...

Aplodeja
Kiitos

Aplodeja
Ainoa turvallinen PDF lukija on Adobe 9,

joka on vanhentunut ja jossa on remote
code execution. Ainoat...

Naurua
Ainoat käyttäjät, jotka saavat käyttää

tai käyttävät sitä ovat Linux käyttäjät,
sillä se on viimeinen versio saatavilla Linuxille

ja siksi voit harkita sitä. Eli olen
valmis puheessa PDF allekirjoituksista

ja nyt Fabian voi puhua PDF
salauksesta. Kiitos.

Fabian: Kyllä
Aplodeja

OK, nyt kun olemme hoidelleet allekirjoitukset
puhutaanpa toisesta kryptografisesta

tekijästä PDF:ssa. Ja se on salaus.
Ja osa teistä voi muistaa meidän

PDFex haavoittuvuuden aiemmin tänä
vuonna. Se on tietenkin, hyökkäys logolla

ja se näyttää kaksi uutta tech
tekniikkaa tähdäten PDF salaukseen jota

ei ole koskaan kohdistettu PDF salaukseen
ennen. Eli yksi niistä oli nämä ns. suora

exfiltrointi, jossa rikoimme kryptografian
jopa koskematta kryptografiaan.

Eli ei salatun tekstin manipulointia tässä.
Toinen on niin kutsuttu

muokattavat värkit. Ja ne ovat oikeasti
kohdistettuja muokkauksia dokumentin

salattuun osaan. Mutta ensin, otetaan
askel takaisin ja uudelleen otetaan

muutama avainsana. Eli PDF käyttää AES. OK.
Okei, AES on hyvä. Mikään ei voi mennä pieleen.

Eihän? Eli mennään kotiin. Salaus on hyvä.
No, tietenkään emme lopettaneet, vaan

katsoimme tarkemmin. Eli he käyttävät CBC
toimintatilaa, eli cipher block chaining.

Ja mikä tärkeämpää on, etteivät he käytä
mitään eheyden suojausta.

Eli se on eheyssuojaamaton AES-CBC.
Ja saatat muistaa skenaarion

hyökkäyksistä salattua sähköpostia vastaan,
eli vasten OpenPGPta ja S-MIMEa

se on periaatteessa sama ongelma.
Mutta ensin kuka oikeasti käyttää PDF

salausta? Voisit kysyä. Ensinnäkin löysimme
joidenkin paikallisten pankkien Saksassa

käyttävän salattuja PDFia korvatakseen
S-MIMEn tai OpenPGPn, koska heidän

asiakkaansa eivät ehkä halua toimia, umh,
asettaa, ottaa salattua e-mailia käyttöön.

Toiseksi, oli joitain drop-in plugineja
sähköpostin salaukseen myös. Eli on

joitain yrityksiä, jotka tekevät tuotteita,
jotka voit laittaa outlookiin ja voit käyttää

salattuja PDF tiedostoja salatun
sähköpostin sijaan. Havaitsimme myös

että jotkus skannerit ja lääketieteelliset
laitteet lähettävät salattuja PDFia e-mailina

Eli voit asettaa salasanan siihen koneeseen
ja ne lähettävät salatun PDFn sähköpostilla

ja sinun pitää asettaa salasana
jollain toisella tavalla. Ja viimeisenä löysimme

että jotkut valtiolliset organisaatiot käyttävät
salattuja PDF dokumentteja, esimerkiksi,

US Oikeusministeriö antaa lähettää,
lähettä joitain vaatimuksia salattujen

PDFien kautta. Enkä ole aivan varma miten
he saavat salasanan, mutta ainakin he sallivat

sen. Joten koska olemme akatemiasta,
otetaan askel takaisin ja katsotaan

hyökkäysmalliamme. Meillä on Alice ja
Bob. Alice haluaa lähettää dokumentin Bobille.

Ja hän haluaa lähettä sen salaamatonta
yhteyttä pitkin tai yhteyttä, johon hän ei

luota. Joten tietenkin hän päättää salata
sen. Toinen skenaario on, he haluavat

ladata sen jaettuun tallennukseen.
Esimerkiksi Dropboxiin ja toiseen jaettuun

tallennukseen. Ja taas, he eivät luota
tallennukseen. Ja taas he käyttävät päästä-

päähän salausta. Oletetaanpa, että tämä jaettu
tallennus on oikeasti vaarallinen tai haitallinen.

Alice lataa, tietenkin, taas salatun
dokumentin hyökkääjälle tässä tapauksessa

joka suorittaa kohdistettua muokkausta
siihen ja lähettää

muokatun dokumentin takaisin Bobille,
joka ilmoisesti syöttää salasanan, koska

hänen näkökulmasta, sitä ei voi erottaa
alkuperäisestä dokumentista

ja alkuperäinen selkoteksti vuodetaan
takaisin hyökkääjälle, rikkoen

luottamuksellisuuden. Eli katsotaan
ensimmäistä hyökkäystä kuinka teimme sen.

Se on suora exfiltrointi, eli kryptauksen
rikkominen koskematta mitenkään

kryptografiaan, kuten tykkään sanoa. Mutta
ensin, salaus, pähkinänkuoressa, PDF salaus.

Eli olette nähneet PDF dokumentin rakenteen.
Siinä on header, jossa on

versionumero. Siinä on body, jossa kaikki
kiinnostavat objektit asuvat. Eli siinä

on meidän luottamuksellinen sisältö jonka
haluamme oikeastaan, no

exfiltroida hyökkääjänä. Ja lopuksi, siinä
on Xref taulu ja traileri. Eli

mikä muuttuu his päätämme salata tämän
dokumentin? No, oikeastaan, ei paljon mikään.

Eli luottamuksellisen datan sijaan, tietenkin
siellä on nyt jotain salattua salatekstiä

Okei. Ja loppu pitkälti pysyykin
samana. Ainoa asia, joka lisätään on

uusi arvo traileriin, joka kertoo meille,
kuinka tämän datan salaus avataan uudelleen.

Eli siinä on oikeastaan rakenne purettuna.
Ja ajattelimme:

Miksi näin? Ja katsoimme standardia.
Eli, tämä on ote PDF

määritelmästä ja olen korostanut
kiinnostavat osat teille. Salaus koskee

vain stringeja ja streameja. No, niitä
arvoja, jotka oikeastaan voivat

sisältää mitään tekstiä dokumentissa ja
kaikki muut objektit ovat salaamatta. Ja

se on, koska he haluavat sallia satunnaisen
pääsyn koko dokumenttiin. Eli ei mitään

parsintaa koko dokumentille, ennen kuin
näytetään sivu 16 salatusta dokumentista.

No, se vaikuttaa kohtuulliselta. Mutta se
tarkoittaa myös, että koko dokumentin

rakenne on salaamaton ja ainoastaan
stringit ja streamit ovat salattuja.

Tämä paljastaa paljon informaatiota
hyökkääjälle jota hänellä ei varmaan

pitäisi olla. Se on ensinnäkin sivujen
määrä ja koko, se on määrä

ja koko objekteilla dokumentissa ja
se käsittää myös kaikki linkit, eli

kaikki hyperlinkit dokumentissa, jotka
ovat siinä. Ja se on paljon informaatiota

jota hyökkääjällä ei varmaan pitäisi
olla. Eli seuraavaksi mietimme, ehkä

voisimme tehdä jotain lisää. Voimmeko
lisätä omaa salaamatonta sisältöä. Ja

katsoimme standardia uudelleen ja löysimme
ns. crypt filttereitä, jotka tarjoavat tarkemman

kontrollin salaamiseen. Tämä periaatteessa
tarkoittaa, että hyökkääjänä voin muuttaa

dokumentin sanomaan, hei, vain
stringit dokumentissa ovat salattuja ja

streamit ovat selkokielisiä. Sitä varten
identiteetti filtteri on. En tiedä miksi he

päättivät lisätä sen dokumenttiformaattiin,
mutta siellä se on. Se tarkoittaa, että

he tukevat osittaista salausta ja se taas
tarkoittaa, että hyökkääjän sisältö voidaan

sekoittaa salatun sisällön kanssa. Ja
löysimme 18 erilaista tekniikkaa tähän

eri lukijoissa. Eli on monta tapaa tehdä
se eri lukijoissa.

Katsotaanpa demoa. Eli meillä on tämä
dokumentti, tämä salattu dokumentti,

me syötämme salasanan ja saamme salaisen
viestimme. Me avaamme sen taas tekstieditorilla.

Näemme, objektissa 4 0 alhaalla täällä, siellä
on oikeasti objektin salateksti,

eli viesti, ja näemme se on AES salattu
32 tavuisella avaimella, eli se on AES-256.

OK, nyt päätämme lisätä uuden objektin,
joka sisältää, no, selkotekstiä.

Ja, no, me vain lisäämme sen sisältö
jonoon dokumentissa. Me sanomme

"näytä tämä ensimmäisellä sivulla"
tallennamme dokumentin. Avaamme sen ja

laitamme salasanan ja, no tämä todella on
kiusallista. OK. Eli me olemme rikkoneet

eheyden salatusta dokumentista. No, voit
ajatella että ehkä he eivät halunneet mitään

eheyttä salatuissa dokumenteissa. Ehkä se
on ihmisten käyttötapaus, en tiedä.

Mutta ajattelimme, ehkä voisimme exfiltroida
selkotekstin jotenkin tätä kautta.

Eli taas otimme askeleen takaisin ja katsoimme
PDF määritystä. Ja ensimmäinen asia jonka

löysimme oli ns. lähetä lomake toiminto.
Ja se on periaatteessa sama kuin lomake

web sivulla. Voit syöttää dataa. Olet
voinut nähdä tämän sopimuksessa,

PDF sopimuksessa, minne voit laittaa nimesi
ja osoitteesi ja niin edelleen ja

data tallennetaan sisään, sisään
stringeina ja streameina. Ja nyt

muistakaa, että kaikki mitä on salattuna
dokumentissa. Ja tietenkin, voit

myös lähettää kaiken tämän takaisin
hyökkääjälle, tai no, laillinen käyttötapaus,

tietenkin, näppäintä painamalla, mutta
näppäintä painamalla on vähän laimeaa.

Eli katsoimme taas standardia ja löysimme
ns. open action:in. Ja se on toiminto,

esimerkiksi, lomakkeen lähettäminen, joka
voidaan suorittaa dokumenttia avatessa.

Eli miltä tämä voisi näyttää? Tältä PDF
lomake näyttää. hyökkäys jo mukana.

Eli meillä on URL tässä, joka on salaamaton
koska kaikki stringit tässä

dokumentissa ovat salaamattomia, ja
meillä on arvo objektille 2 0, jossa

salattu data asustaa. Eli se on arvo
lomakkeen kentälle. Ja mitä

tapahtuu hyökkääjän puolella kun heti
kun dokumentti avataan? No, saamme

POST pyynnön, jossa on luottamuksellinen
sisältö. Pidetäänpä demo. Taas, meillä on

tämä dokumentti. Annamme salasanan. Se on
alkuperäinen dokumentti, jonka olette jo

nähneet. Me avaamme sen uudelleen tekstin
lukijassa, tai tekstieditorissa, jälleen huomatkaa

se on salattu ja päätämme muuttaa kaikki
stringit identity filtterissa. Eli salausta

ei käytetä stringeissä tästä eteenpäin. Ja
sitten lisäämme koko blobin informaatiota

open actioniin ja lomakkeeseen.
Eli tämä op- tämä suoritetaan

heti kun dokumentti avataan. Siellä on
URL, p.df ja arvo

on salattu objekti 4 0. Käynnistämme HTTP
palvelimen domainissa, jonka määritimme,

avaamme dokumentin, annamme salasanan
taas ja heti kun avaamme dokumentin

Adobe avuliaasti näyttää meille
varoituksen, mutta he klikaavat jo

nappia muistamaan sen seuraavalla kerralla.
Ja jos hyväksyt sen, näet sinun

salaisen viestin hyökkääjän palvelimella.
Ja tämä on jo aika paha sinänsä.

OK. Sama toimii hyperlinkeillä, joten
tietenkin linkkejä on PDF dokumenteissa,

ja kuten Webissa, voimme määrittää base
URLin hyperlinkeissä. Eli voimme sanoa

kaikki URLit dokumentissa alkavat http://p.df.
Ja tietenkin voimme määritellä minkä tahansa

objektin URLiksi. Eli mikä tahansa objekti,
jonka valmistelemme voidaan lähettää URLina,

ja se tietenkin laukaisee GET requestin
kun dokumentti avataan, jos määrittelit

open actionin objektille. Eli taas aika
paha ja rikkoo luottamuksellisuuden. Ja

tietenkin, kaikki rakastavat JavaScriptia
PDF tiedostoissa, ja se toimii hyvin. Okei.

Puhutaanpas ciphertext hyökkäyksistä, eli
oikeista kryptologisista hyökkäyksistä, ei

enää olla koskematta kryptoon. Voit muistaa
efail hyökkäykset OpenPGP ja S-MIMEen,

ja niissä oli kolme edellytystä.
1: No, ciphertekstin muokattavuus.

sitä kutsutaan muokattavaksi värkiksi, siksi
tarvitsemme ciphertekstin

muokattavuuutta ja meillä ei ole eheyden
suojausta, se on plussaa. Sitten tarvitsemme

jonkun tunnetun selkotekstin kohdenetuille
muokkauksille. Ja tarvitsemme exfiltrointi

kanavan lähettämään datan takaisin
hyökkääjälle. No, exfiltrointikanavat

käsiteltiin jo kun meillä on hyperlinkit
ja formit. Joten voimme jo ruksata sen.

Kiva, puhutaan vähän ciphertekstin
muokattavuudesta, mitä kutsumme värkeiksi.

Jotkut voivat muistaa tämän Krypto 101:sta
tai miltä tahansa kryptografian luennolta

Tämä on purkutoiminto CBC:ssa
eli Cipher Block

Chainingissa. Ja se on periaatteessa, sinulla
on ciphertekstisi täällä ylhäällä ja selko-

tekstisi täällä alhaalla. Ja se toimii
yksinkertaisesti purkamalla lohkon ciphertekstiä,

XORaamalla edellisen lohkon ciphertekstiä
siihen, ja saat selkotekstin.

Eli mitä tapahtuu, jos koitat vaihtaa yhden
bitin ciphertekstissä, esimerkiksi, ensimmäisen

bitin alustusvektorista? No, se
sama bitti vaihtuu myös oikeassa

selkotekstissä. Odotas, mitä tapahtuu, jos
satut tietämään koko

selkoteksti lohkon? No, voimme XORata sen
ensimmäiseen lohkoon ja periaatteessa

saada kaikki nollaa, tai mitä kutsumme
värkiksi tai tyhjän paperin, koska voimme

kirjoittaa siihen ottamalla tunnetun selko-
tekstin ja XORaamalla sen tuloksiin. Ja näin

voimme, esimerkiksi, rakentaa URLin itse
ciphertekstiin, tai oikeaan seuraavaan

selkotekstiin. Mitä voimme myös tehdä näillä
värkeillä, värkkejä voidaan siirtää muualle

dokumentissa, kloonata niitä, jolloin
meillä voi olla useita värkkejä

monessa kohdassa ciphertekstiä. Mutta
muistakaa, jos teette sen, sillä

on aina lumivyöryefekti CBCssa,
eli sinulla on satunnaisia tavuja täällä

mutta URL pysyy silti paikoillaan.
Okei. Se oli ciphertekstin muokattavuus.

Kuten sanoin tarvitsemme vähän selkotekstiä.
Meillä pitää olla selkotekstiä. Ja PDF

standardi on ollut avulias tähän asti,
PDF salausta rikottaessa, joten

kurkataan uudelleen. Ja mitä löydämme
täältä: Oikeudet. Eli PDF dokumentissa voi

olla eri oikeudet kirjoittajalle ja
dokumentin käyttäjälle. Tämä käytännössä

tarkoittaa, että kirjoittaja voi muokata
dokumenttia ja käyttäjä ei voisi

tehdä sitä. Ja tietenkin ihmiset alkoivat
muuttaa sitä- alkoivat sormeilla niitä

arvoja, jos se oli jätetty salaamatta,
joten uusimmassa versiossa, tehtiin

päätös, että se pitäisi salata 16 tavuisena
arvona. Eli meillä on 16 tavua. Miltä ne

näyttävät? No, ensin, tarvitsemme tilaa
laajennukselle. Tarvitsemme paljon

oikeuksia. Sitten laitamme 4 tavua
itse oikeus arvolle - Se on myös selkokielisessä

muodossa dokumentissa. Sitten tarvitsemme
yhden tavun salatulle metadatalle, ja jostain

syystä tarvitsemme lyhenteen, "adb", jätän
teidät miettimään mitä se tarkoittaa.

Ja lopuksi, meillä on 4 satunnaista tavua,
koska meidän täytyy täyttää 16 tavua,

ja meiltä loppui ideat. Okei.
Otetaan tämä kaikki, salataan se, ja

no, me tiedämme siitä paljon, ja se on
periaatteessa tunnettua selkotekstiä.

Joka on paha. Katsotaan miltä tämä näyttää
dokumentissa. Eli, näette oikeus-arvon,

merkkasin sen tänne alas. Se on oikeasti
laajennettu arvo, jonka olen näyttänyt

viimeisellä kalvolla. Ja sen yläpuolella
näette puretun arvon, joka on oikeus-

arvon sisällä, eli miinus 4 tässä kohtaa,
se on periaattessa bitti kenttä, oikealla

näette oikean salatun sisällön, ja
avuliaasti, kaikki tämä on salattu

koko dokumentin laajuisella avaimella
uusimmassa spesifikaation versiossa.

Ja se tarkoittaa, että voime uudelleen
käyttää tätä selkotekstiä missä tahansa

kohtaa dokumentissa ja voimme käyttää tätä
rakentaessa värkkejä. Yhteenvetona

viimeisestä teille. Adobe päätti lisätä
oikeudet PDF formaattiin ja ihmiset

alkoivat peukaloimaan niitä. Joten he
päättivät salata nämä oikeudet estääkseen

peukaloinnin, ja nyt tunnettu selkoteksti
on saatavilla hyökkääjille. No niin. Eli

siinä oli käytännössä kaikki edellytykset,
ja jälleen tehdäänpä demo. Eli jälleen

avaamme tämän dokumentin, annamme ,
salasanan, no, heti kun Chrome päättää avata

tämän dokumentin, annamme salasanan, se
on sama kuin aiemmin. Nyt olen

valmistellut scriptin teille, koska en voi
tehdä tätä livenä, ja se periaatteessa

tekee mitä sen teille kerroin tekevän. Se
ottaa tyhjiä värkkejä perms arvosta.

Se generoi URLin siitä. Se generoi
kentän nimen, jotta se näyttää

kivalta serverin päässä, me uudelleen
luomme tämän dokumentin ja laitamme

lomakkeen sinne. Käynnistämme web palvelimen,
avaamme tämän muokatun dokumentin, annamme

salasanan taas ja, no Chrome ei edes kysele.
Ja heti kun dokumentti on avattu Chromessa

ja salasana on annettu, me saamme
meidän salaisen viestin toimitettuna

hyökkääjälle.
Aplodeja

Eli otimme 27 lukijaa ja havaitsimme, että
kaikki olivat haavoittuvia ainakin yhdelle

hyökkäyksistämme. Eli osa niistä toimi
täysin ilman käyttäjän toimia kuten näimme

Chromessa. Osa toimi käyttäjän toimien
avulla tietyissä tapauksissa, kuten näimme

Adoben varoituksesta mutta yleisesti
kaikki näistä oli hyökättävissä jollain

tavalla. No mitä tälle voi tehdä? No, voit
ajatella, että allekirjoitus auttaisi.

Se on yleensä ensimmäinen seikka, jonka
käyttäjät tuovat esille. "allekirjoitus

salatussa tiedostossa auttaa". No, ei. Ei
oikeasti. Miksei ? No ensinnäkin rikkinäinen

allekirjoitus ei estä avaamasta
dokumenttia. Eli voimme silti pystyä

exfiltroimaan heti kun salasana on annettu.
Allekirjoitukset voi poistaa, koska niitä

ei salata. Ja kuten näitte aiemmin, ne
voidaan myös väärentää useimmissa

lukijoissa. Allekirjoitukset eivät ole
vastaus. Exfiltrointi kanavan sulkeminen

ei myöskään ole vastaus, sillä ensinnäkin
se on vaikeaa. Ja kuinka edes löytäisit

kaikki exfiltrointikanavat 800 sivuisesta
standardista? Tarkoitan, että olemme vain

vähän raapaisseet pintaa exfiltrointi
kanavissa. Ja poistaisimmeko tosiaan

lomakkeet ja hyperlinkit dokumenteista. Ja
pitäisikö meidän poistaa JavaScript? OK,

ehkä meidän pitäisi. Ja lopuksi, jos sinun
täytyy tehdä se, kysy käyttäjältä ennen

yhteyttä web palvelimelle. Eli katsotaan
joitain valmistajien reaktioita. Apple

päätti tehdä kuten kerroin teille: lisätä
dialogin käyttäjän varoittamiseksi ja

näyttää koko URL salatun selkotekstin
kanssa. Ja Google päätti lopettaa yrittämästä

korjata rikkinäistä Chromessa. He korjasivat
automaattisen exfiltroinnin, mutta he eivät

voi mitään standardille. Eli se on
ongelma jolle täytyy tehdä jotain

standardissa. Ja siinä se periaatteessa oli.
Paketointihyökkäysten mitigoimiseksi meidän

pitää poistaa osittainen salaus ja estää
pääsy salaamattomista objekteista

salattuihin. Ja värkkihyökkäysiä vastaan,
meidän tulee käyttää autentikoivaa

salausta, kuten AES-GCM. OK. Ja Adobe on
kertonut meille, että he eskaloivat tämän

ISO työryhmälle, joka nykyisin vastaa
PDF standardista ja tämä otetaan

huomioon seuraavassa versiossa.
Ja se on mielestäni voitto.

Aplodeja

Herald: Kiitos paljon, kundit. Se oli
todella mahtavaa. Olkaa hyvä ja

jonottakaa mikrofoneille jos teillä on
kysyttävää, meillä on vähän aikaa Q & A:han

Mutta mielestäni teidän tutkimus oli todella
kiinnostavaa, sillä se avasi mieleni siihen

kuinka tätä voisi väärinkäyttää
käytännössä? Kuten, en tiedä,

kuten, mitä mieltä olet? Luulen, että
kun olet työskennellyt tämän parissa

kauan, sinulla on joku ajatus, minkälaisia
ilkeyksiä voisit keksiä tämän avulla.

Fabian: Tarkoitan, tämä on silti hyökkäys
skenaario

joka vaatii paljon resursseja ja
erittäin motivoituneen hyökkääjän. Eli

tämä ei välttämättä ole tärkeä tavalliselle
käyttäjälle. Ollaan tosissaan. Suurin osa

meistä ei ole NSAn kohteena, arvelen. Eli
tarvitset aktiivisen hyökkääjän, aktiivisen

ihmisen keskellä toteuttaaksesi nämä
hyökkäykset.

Herald: Hienoa, kiitos. Ja luulen, että
meillä on kysymys mikrofonilla numero

neljä, ole hyvä.
Mikrofoni 4: Kyllä, kerroit, että seuraava

standardin versio voisi sisältää korjauksen.
Tiedättekö kauanko kestää rakentaa

sellainen standardi?
Fabian: No, me emme oikeastaan tiedä.

Puhuimme Adoben kanssa ja he kertoivat
meille, että näyttävät seuraavan version

standardista ennen sen julkaisua, mutta
meillä ei ole ajankohtaa heiltä.

Mikrofoni 4: OK, Kiitoksia.

Herald: Kiitoksia.
Mikrofoni numero viisi, ole hyvä.

Mikrofoni 5: Kiitos mielenkiintoisesta
esityksestä. Näytitte ensimmäisessä osassa

että allekirjoituksessa on nämä neljä
numeroa tavu-avaruudessa. Ja miksi se

siis, neljä numeroa, eivät ole osa
allekirjoitusta? Onko siihen tekninen syy?

Koska tavu offset on ennustettava.

Vlad: Se on! Tavu-avaruudet suojaa
allekirjoitus. Mutta me juuri määritimme

toisen ja juuri siirsimme allekirjoitetun
varmenenttavaksi myöhemmin. Eli siinä on

kaksi tavu-avaruutta. Mutta vain ensimmäinen,
manipuloitu, prosessoidaan.

Mikrofoni 5: Kiitoksia
Herald: Kiitos paljon. Mikrofoni

numero neljä, ole hyvä.
Mikrofoni 4: Oh, tämä on liian korkealla

minulle. OK. Minulla on vastaus ja kysymys
teille. Mainitsit esityksen aikana, että

et ole varma miten oikeusvirasto jakelee
salasanat PDF salausta varten.

Vastaus on: Selkokielisenä, erillisessä
sähköpostissa tai viikon

salasanana, joka jaellaan eri
keinoin. Tämä on myös mitä

kotimaan turvallisuuden virasto tekee,
ja armeija on vähän vähemmän tyhmä.

Kysymyksenä: Minulla on noin puoli teraa
arkaluonteisia PDF:ia jotka haluaisin

skannata hyökkäystänne varten ja samalla
poistovirheiden varalta. Tiedättekö mitään

nopeaa ja toimivaa tapaa skannata dokumentteja
tämän tapaisen hyökkäyksen varalta?

Fabian: En tiedä yhtään työkalua, mutta
tarkoitan, skannaus värkki hyökkäyksiltä

on oikeasti mahdollista, jos koitat tehdä
entropian tarkastusta. Eli koska uudelleen-

käytät salatekstiä, sinulla on vähemmän
entropiaa salatekstissä, mutta se on vaikeaa.

Suoran enxfiltroinnin havaitsemisen
pitäisi olla mahdollista skannaamalla sanat

kuten "identify". No sen lisäksi, 18 eri
tekniikkaa, jotka annettiin paperissa

Mutta en tiedä mitään työkalua joka
tekisi sen automaattisesti.

Mikrofoni 4: Kiitos.
Herald. Hienoa. Ja mikrofoni

numero kaksi, ole hyvä.
Mikrofoni 2: Kiitos kiinnostavasta

esityksestä. Minulla on yksi ehdotus ja
yksi kysymys mitigointi keinoista. Jos vain

ajat PDF lukijaasi virtuaalikoneessa,
joka on palomuuritettu, eli sinun

palomuuri ei sinun mennä ulos. Mutta
allekirjoitus väärennöksiin.

minulla oli ajatus. En ole varma onko se
tyhmä idea, mutta harkitsitteko

sertifikaatin väärentämistä? Koska
oletettavasti allekirjoitus on myyjän

sertifikaatin suojaama. Sinä teet omasi,
ja allekirjoitat sillä sen. Saako se sen

kiinni ja miten ?
Vladi: me harkitsimme sitä, mutta emme

tässä paperissa. Oletamme, että sertifikaatti
ja koko luottamusketju tässä polussa on

turvallinen. Se oli vain oletus keskittyä
vain hyökkäyksiin jotka olimme jo

löytäneet. Eli, ehkä tähän tulee vielä
jatkotutkimusta toimestamme tulevina

kuukausina ja vuosina.
Herald: Me saatamme kuulla teistä lisää

tulevaisuudessa. Kiitos paljon. Ja nyt
kysymyksiä Internetistä, olkaa hyvä.

Signal Angel: Minulla on kaksi kysymystä
ensimmäisestä osasta esitystä Internetistä.

Ensiksi, mainistitte muutaman reaktion,
mutta voitteko antaa lisää yksityiskohtia

kokemuksistanne valmistajien kanssa kun
raportoitte nämä ongelmat?

Vladi: Yeah. Me, ... kun ensimmäistä kertaa
aloitimme, pyysimme CERT teamia BSI:sta,

CERT-Bund, auttamaan meitä, koska oli monia
valmistajia, joita asia koski emmekä pystyneet

tukemaan heitä merkityksellisellä tavalla.
Joten he tukivat meitä koko matkan ajan.

Me ensin teimme raportin, joka sisälsi
tarkan kuvauksen haavoittuvuuksista

ja vanhoista exploiteista. Sitten jaoimme
sen BSI:lle ja he ottivat yhteyttä

valmistajiin ja välittivät kommunikaation
ja siinä oli paljon kommunikaatiota.

En ole varma kaikesta viestinnästä,
vain teknisistä

jutuista, mitä meitä pyydettiin uudelleen
kokeilemaan korjauksia ja niin edelleen.

Eli siinä oli reaktio Adobelta, Foxit:lta ja
monet lukijat reagoivat hyökkäyksiimme ja

ottivat yhteyttä meihin, mutta eivät kaikki.
Herald: Kiitos paljon. Valitettavasti siinä

oli kaikki aika, mitä meillä oli
kysymyksille tänään. Luulen että te

voisitte pyöriä tässä vielä hetken aikaa
jos jollain olisi vielä lisää kysymyksiä.

Fabian, kiitän sinua... ja Vladislav liian
vähän. Kiitos oikein paljon.

Se oli todella mielenkiintoista. Antakaa
heille suuret aplodit.

Vladi: Kiitoksia sinulle.
Aplodeja

36c3 Loppumusiikki

Translated by Esa Lammi
(KYBS2004 course assignment at JYU.FI)