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)