Vyrábíme PDF, které vypadá, jako by ho podepsala jiná osoba

Úvod, aneb reakce na první článek

Cílem prvního článku bylo veřejně upozornit na skutečnost, že některé programy pro práci s PDF soubory ignorují jméno a příjmení skutečného autora elektronického podpisu a zobrazí podvrženou informaci. Je tak možné vytvořit PDF dokument, který vypadá, jako by ho podepsala jiná osoba, než ho skutečně podepsala.

Také jsme chtěli varovat, že je v některých případech možné pozměnit již podepsaný elektronický dokument a na tuto změnu nemusí být uživatel programu pro práci s PDF soubory nijak upozorněn. Dokonce je maten informací, že elektronický podpis je platný a dokument nebyl změněn (v případě Adobe Acrobat Readeru). Aktualizace PDF totiž není v některých případech zohledněna v seznamu revizí dokumentu.

První článek byl psán poměrně obecně a možná i trochu bulvárně, chtěli jsme trochu „popostrčit“ autory vybraných programů, aby se konečně našimi oznámeními začali zabývat. Připomínám, že autoři nejpoužívanějších aplikací byli kontaktováni s dostatečným předstihem (někteří již v únoru). Někdo se rozhoupal až po přečtení prvního dílu článku, někdo zachovává mlčení doposud. Nicméně v polovině června již nevidím důvod dále čekat, pojďme se tedy podívat na to, jak takové „padělané PDF“ vzniká. Čas kvapí a nejsou-li ještě stále připraveni autoři programů, musí IT specialisté vědět, jak rozpoznat potenciální hrozbu, jak jí čelit a jak varovat uživatele PDF aplikací ve firmách a na úřadech.

Zastávám názor, že nejlépe se technické detaily demonstrují v praxi. Proto se v článku zaměřím na klíčové části aplikace, která „podvržené PDF“ dokáže vyrobit. Nebudu citovat PDF specifikaci, tu si může každý najít sám. Místo toho upozorním na klíčové funkce programu a části PDF, díky kterým PDF soubor s podvrženým autorem podpisu vypadá relativně věrohodně.

Stáhněte si zdrojové soubory a vše důležité: stáhnout.

Co je třeba pro sestavení aplikace

Určitě se neobejdeme bez následujících ingrediencí:

1. Podofo, nejlépe ve verzi 0.9.6, nebo přímo aktuální verze z SVN,
2. závislosti, tj. OpenSSL, zlib, FreeType, libpng (a další), za sebe bych určitě přidal i Libidn (Podofo potom umí i 256bit AES encryption/decryption, což se hodí),
3. kompilátor, Cmake,
4. patch, který nám dovolí zavolat SetSignatureName(PdfStrin­g(„libovolnejmeno“));,
5. příkaz, kterým cmake požádáme, aby nám vytvořil ten správný makefile (v mém případě .sln).

Osobně Podofo sestavuji nejčastěji přes Visual Studio ve verzi 2010 (ještě stále nějaký ten klient potřebuje používat Windows XP a když je třeba novější C++, pomůže Clang). Výběr kompilátoru je ale na ctěném čtenáři.

Nebudu se zde dlouze rozepisovat o tom, jak zkompilovat knihovnu v C++. Většina čtenářů Root.cz to beztak ví, nebo pomůže dnf/apt. Jakmile se nám podaří Podofo dostat do použitelného stavu, můžeme začít tvořit program. Jako základ jsem použil Signaturetest.cpp (součást Podofo) a řadu částí přepsal. Upozorňuji předem, že program vznikal narychlo (důvod je na konci článku) a pouze za účelem demonstrace pro Root.cz. Nebylo cílem psát cokoliv v produkční kvalitě.

Výsledkem je jednoduchá POC aplikace, která vezme PDF soubor, podepíše ho elektronickým podpisem a snaží se při tom nehavarovat. Znalce knihovny Podofo možná napadne, proč jsem nepoužil jako základ PodofoSign. Důvod je ten, že elektronickým podpisem PDF dokumentů jsem se začal zabývat dávno před přidáním programu PodofoSign do Podofo a jako základ pro laborování mi tak Signaturetest.cpp slouží poměrně dlouhou dobu.

Tři nejdůležitější části „podvrženého PDF souboru“

Aby PDF vypadalo věrohodně, musí být splněny tři podmínky:

Musí být přítomné pole s podpisem

Máme otestováno, že ke zmatení drtivé většiny uživatelů úplně stačí připravit si signature field s těmi správnými částmi.

Vhodné je podvržené jméno a příjmení, falešné datum podpisu, informace „digitálně podepsal“ a důvod podpisu. Lidé jsou zvyklí tento formát vídat u podpisů, které do PDF přidává Adobe Acrobat reader a nikoho ani nenapadne, že by mohlo být něco v nepořádku. Po kliknutí na pole podpisu by měl být uživatel nasměrován na vlastnosti elektronického podpisu. Bez toho bychom přišli o informaci „platný podpis“ po najetí myší nad signature field. Pokud není žádoucí, aby se po kliknutí na signaturu otevřel panel podpisu v Adobe Acrobat readeru, lze tuto vlastnost obětovat.

Pole podpisu je realizováno naprosto standardně, tj. je specifikován font, velikost písma, alternativní jméno je nastaveno na Alberta Einsteina (v našem případě).

Zde je třeba upozornit na zažitý mýtus – pole podpisu nemusí být vůbec přítomné (může být vložen tzv. „neviditelný podpis“, tj. anotace s nulovou velikostí). Často pole podpisu vůbec neobsahuje jméno.

Musíme přidat podvrženou informaci „/Name“ na to správné místo

Jak již bylo napsáno, vybrané programy v některých případech naprosto nepochopitelně ignorují jméno a příjmení z certifikátu, pokud v PDF tuto podvrženou informaci najdou. Dojde-li k zobrazení vlastností podpisu, je jako první zobrazena právě tato podvržená informace a správné jméno skutečného autora podpisu se zobrazí až po rozkliknutí podrobností o certifikátu. Typickými zástupci jsou aplikace NitroPDF a v ČR značně rozšířený Finereader. Rozhodně se tak přimlouvám za to, aby byly otestovány používané aplikace hlavně na elektronických podatelnách. Pokud nějaký program generuje seznam došlé pošty, není žádoucí, aby se tam vyskytoval podvržený údaj.

V tomto případě se o vše potřebné postará přidání malé funkce do Podofo, kód nepotřebuje bližší komentář. Divím se, že v Podofo dosud není.

void PdfSignatureField::SetSignatureName(const PdfString & rsText)
{
    if( !m_pSignatureObj )
    {
        PODOFO_RAISE_ERROR( ePdfError_InvalidHandle );
    }
    if(m_pSignatureObj->GetDictionary().HasKey(PdfName("Name")))
    {
        m_pSignatureObj->GetDictionary().RemoveKey(PdfName("Name"));
    }
    m_pSignatureObj->GetDictionary().AddKey(PdfName("Name"), rsText);
}

Musíme PDF uložit přes WriteUpdate

PDF sestavujeme s využitím třídy PdfMemDocument. Aby vše správně fungovalo, je třeba stávající PDF aktualizovat, nikoliv uložit přes zavolání Write. Bez toho by nefungoval korektně náš druhý „vtípek“ – doplňování již existujících elektronicky podepsaných dokumentů.

Splníme-li výše uvedené podmínky, je výsledkem dokument, který řada programů akceptuje a při zobrazení vlastností podpisu některé z nich ještě označí podvrženého autora podpisu za skutečného autora. Excelují informací, že podpis je platný a je-li přítomné časové razítko, vypadá to v kombinaci s informací o úspěšném ověření podpisu skutečně velice věrohodně.

Naštěstí Adobe Acrobat zobrazí skutečného autora podpisu ve chvíli, kdy kliknete na podvržené pole podpisu. To ale musí běžného uživatele kancelářské techniky napadnout/musí být proškolen, aby to udělal. Navíc i toto lze řešit – bezdomovec si za drobný finanční obnos rád nechá zřídit elektronický podpis, který poskytne dále. Je-li do vlastností podpisu následně přidán text typu „pověřený podpisem elektronického dokumentu“, u velké skupiny lidí to může projít.

Změna již existujících elektronicky podepsaných dokumentů

Díky volání WriteUpdate není problém podepsat již podepsaný dokument (není-li uzamčen či certifikován) a pole podpisu může obsahovat libovolný text/obrázky a být libovolně veliké. Když si tyto dvě věci dáte dohromady, snadno vás tak napadne, jak funguje úprava již podepsaných PDF dokumentů.

Signature field samozřejmě není určen k tomu, aby obsahoval klasický text (např. podvržené číslo účtu pro platbu), nicméně jde takto použít. Za mě autoři PDF programů danou oblast trochu podcenili. Většina lidí na tímto způsobem připravené PDF skočí, není třeba ani pověstný naviják. Drobná změna kursoru při najetí myší nad nově přidané informace většinu lidí nijak neupozorní.

Nedochází-li k dalším změnám a je-li pole podpisu správně vloženo, Adobe Acrobat reader neoznámí další revizi dokumentu a dokument označí za nezměněný, s platným podpisem. Je zmíněn jen původní autor podpisu. Korektní přístup má např. PDF X-change, který naprosto správně oznámí (zkráceno) „Text dokumentu (revize) nebyl změněn, ale dokument ano“. To už by uživatele mohlo upozornit.

Další skupina programů označí všechny revize za neplatné, zde ale nebylo záměrem vytvářet PDF soubor, který je obecně akceptován. Cílem byl hlavně Adobe Acrobat reader. Pro úplnost uvádím, že použitý zdrojový kód mám otestovaný na dokumentech z Finančního úřadu a od Českého telekomunikačního úřadu. Za mě je tak naprosto nezbytné varovat pracovníky ve firmách a na úřadech, slušně napsaný a hromadně rozeslaný e-mail by mohl způsobit nemalé škody.

Cílem je varovat uživatele

Ve filmu Studujeme za školou padla památná věta: „Co je platné, že umím dvě stránky o dodacím listu, když ho neumím vyplnit?“ Tímto citátem jsem naštval za dobu svých školních let nejednoho vyučujícího a řídím se jím i v současnosti. Nehodlám tak čtenáře nudit detailním popisem jednotlivých částí zdrojového kódu a dovolím si je rovnou odkázat a příslušný soubor .cpp.

Cílem tohoto článku není vypustit do světa univerzálně použitelný nástroj pro „padělání“ PDF souborů, ale upozornit na problém. Proto si na závěr dovolím několik doporučení pro běžné uživatele a prosím ctěné IT kolegy(ně), ať je svými ústy předají dále:

• Vždy si zobrazte certifikát autora podpisu a nespoléhejte se jen na informaci ve vlastnostech podpisu. Důležité elektronicky podepsané PDF soubory neotevírejte v prohlížečích, které neumí ověřovat platnost elektronického podpisu u PDF dokumentů. Nespoléhejte se na to, co vidíte.

• V Adobe Acrobat readeru si zobrazte panel podpisu, klikněte na poslední zobrazenou revizi pravým tlačítkem myši a vyberte „Zobrazit podepsanou verzi“. Obdobný postup zvolte i v případě dalších aplikací. Tím eliminujete „načerno“ přidaný text.

• Ve spolupráci s IT specialisty prověřte, zda programy na podatelnách nepotřebují úpravy a pokud ano, vyviňte tlak na dodavatele sw řešení, aby problém vyřešili.

Věřím, že kolegové a kolegyně v diskusi danou problematiku patřičně rozvinou a vznikne tak série postupů/doporučení pro běžné uživatele. Také očekávám vylepšení popsaného postupu. Já se přípravě detailnějšího „prof of conceptu“ bohužel věnovat nemohl, v mém okolí nyní řádil GrandCrab a to mělo prioritu (s úsměvem mohu konstatovat stoprocentní úspěšnost záchrany dat). To je ale již jiný příběh a možná materiál pro text na téma data recovery/IT forenzní analýza.