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)