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)