Penetrační test Autogramu: co zůstalo v aplikaci, kterou se na Slovensku podepisují dokumenty

V Citadelo jsme otestovali desktopového klienta, mobilní aplikaci i serverovou část. Nejzávažnější nález se skrýval v něčem, co běžný člověk nemusí považovat za vstupní vektor útočníka.

Autogram od Slovensko.Digital a jeho členské firmy Freevision vznikl z frustrace ze státních nástrojů pro elektronický podpis, u kterých velká část lidí podepisování vzdá dříve, než ho dokončí. Slovensko.Digital je občanské sdružení, které už více než 10 let tlačí na kvalitu státních digitálních služeb, a Autogram je jedním z jeho vlastních nástrojů. Dělá jednu věc: podepíše dokument se stejnou právní silou jako u notáře, a udělá to srozumitelně, na počítači i v mobilu. Spoléhá na něj mnoho lidí a Autogram používají i lidé z Citadelo. Dopad bezpečnostní chyby se v kybernetické bezpečnosti obvykle měří v ukradených datech nebo ve službě, která přestane fungovat. Tady je jiného druhu: zpochybní právní sílu podpisu a s ní důkaz o tom, kdo co podepsal.

Autogram má přitom výhodu, jakou většina testovaných aplikací nemá. Je open source, vyvíjí se ve veřejném repozitáři a roky si ho pod lupu bere slovenská IT komunita dobrovolně a bezplatně. To je přesně prostředí, ve kterém by se chyby měly najít samy. Zajímalo nás, co v něm zůstane, když na něj nasadíme cílené penetrační testování.

„Autogram má přibližně 9 000 aktivních uživatelů a v průměru se přes aplikaci Autogram v mobilu podepíše 100 dokumentů denně.“ Marek, programátor Slovensko.Digital

Jak probíhal penetrační test desktopové a mobilní aplikace

Spolupráce měla dvě části. Nejprve jsme testovali desktopového klienta, a to podle metodiky OWASP Thick Client Security. Poté následoval penetrační test mobilní aplikace a spolu s ní i serverové části, která ji obsluhuje, podle metodiky OWASP Mobile Top 10.

Serverová část je webové API, se kterým mobilní aplikace komunikuje. Čtyři z jedenácti nálezů mobilního testu jsou právě v API, a ne v aplikaci v telefonu.

Mobilní část přitom netvořila jedna aplikace, ale čtyři samostatné celky: verze určená přímo pro Android, verze pro iOS, společná verze, která je pro obě platformy stejná, a serverové API. Každá z nich má vlastní rozhraní navenek, a proto z mobilního testování vzešlo podstatně více nálezů než z desktopového. Testovali jsme v polovině května 2026 na verzi 1.5.0 (build 49), tedy na té, kterou v té době měli lidé nainstalovanou z Google Play a App Store.

K celému tomuto kódu jsme měli přístup jako kdokoli jiný. Veřejná není jen mobilní aplikace, ale i serverová část, která ji obsluhuje. Kombinovali jsme automatizované nástroje s manuálním testováním: nástroje ukážou podezřelá místa, ale až manuální penetrační test rozhodne, která z nich jsou skutečně zneužitelná. Protože Autogram provádí kryptografické operace, které mají právní následky, soustředili jsme se na důvěrnost dat, integritu aplikace během běhu a odolnost komunikace mezi službami.

Penetrační test desktopového klienta: jeden nález s nízkou závažností

U desktopového klienta jsme prošli lokálně uložená data, ochranu paměti aplikace, zpracování a náhled souborů i to, zda lze aplikaci při spuštění podstrčit cizí knihovnu. Všechno drželo.

Výsledkem byla jedna zranitelnost s nízkou závažností. Aby Autogram dokázal podepsat dokument, který mu pošle webová stránka, běží na počítači jako malá lokální služba a takovým stránkám odpovídá. To je záměr, ne chyba. To, že se jí smí ozvat kterákoli stránka, je vědomé rozhodnutí vývojářů, bez kterého by propojení s jinými službami nefungovalo.

Problém byl v tom, na co všechno tato služba odpovídala. Komukoli, kdo se zeptal, prozradila přesnou verzi nainstalovaného Autogramu a seznam ovladačů pro čtečky karet, které má uživatel v počítači. Útočník si tak může nepozorovaně zjistit, co přesně má oběť nainstalované. Pokud zjistí, že oběť používá neaktualizovanou verzi se známou chybou, může zaútočit přesně na ni místo střílení naslepo.

„Narazili jsme na desktopovou aplikaci, která byla opravdu bezpečná. Jak se později ukázalo, velká část slovenské IT komunity ji dobrovolně otestovala před námi a ještě více lidí ji reálně používá.“ Nazarii, penetrační tester v Citadelo

Proč je bezpečnost mobilních aplikací jiná disciplína než bezpečnost desktopu

Veřejný kód má své hranice a mobilní aplikace nám přesně ukázala, kde leží. Kód je plán. Z plánu lze vyčíst, jak je funkce napsaná. Co skutečně udělá s daty od jiné aplikace, se ukáže až ve chvíli, kdy jí tato data skutečně přijdou.

Mobilní aplikace totiž není desktopová aplikace s menším displejem. Má rozhraní, která na počítači neexistují: intenty, content providery, deep linky a systémové dialogy pro výběr souborů. Jsou to mechanismy, kterými si aplikace v telefonu navzájem předávají data a soubory. Každý z nich je zároveň místem, kam může něco poslat i aplikace, kterou si tam nikdo nepozval. Právě tam jsme se proto dívali nejpozorněji.

Co odhalil penetrační test mobilní aplikace

Jednu kritickou zranitelnost, jednu s vysokou závažností, jednu střední, čtyři nízké a čtyři zjištění na úrovni poznámky, která slouží ke zlepšení a zvýšení bezpečnosti aplikace jako takové.

Téměř všechny vážné nálezy měly jednu společnou příčinu: aplikace neověřovala, co do ní přichází.

Kritický nález se týkal právě takového vstupu, konkrétně názvu souboru. Autogram v mobilu je navržen tak, aby mu dokumenty mohly posílat jiné aplikace v telefonu, například prostřednictvím e-mailu, správce souborů nebo možnosti „sdílet“. Spolu se souborem od nich převezme i jeho název a pod tímto názvem si ho uloží mezi své dočasné soubory.

Tento název však nikdo nekontroloval, Autogram v mobilu mu důvěřoval. Škodlivá aplikace tak místo názvu jako „smlouva.pdf“ mohla poslat text, který se nechová jako název, ale jako cesta vedoucí ven z výchozího adresáře pro dočasné soubory. Autogram ho poslušně použil a soubor uložil tam, kam mu název souboru řekl. Takto bylo možné přepsat soubor v privátním úložišti Autogramu, včetně toho, ve kterém si aplikace pamatuje nastavení. Jsou v něm například údaje o tom, zda uživatel potvrdil podmínky, i předvolby, se kterými přistupuje k podepisování.

Nález s vysokou závažností šel opačným směrem, tedy ven. Autogram v mobilu důvěřoval odkazům na soubory, které dostal zvenčí, a neověřoval, zda odkaz směřuje na soubor, který uživatel skutečně smí vidět. Zneužít se to dalo několika způsoby.

Jeden z nich vypadal takto. Když v Autogramu v mobilu kliknete na přiložení dokumentu, telefon vám nabídne seznam aplikací, ze kterých si můžete soubor vybrat. Škodlivá aplikace se do tohoto seznamu dokáže dostat tak, že vypadá jako jedna z běžných možností. Pokud si ji uživatel vybere, může Autogramu místo dokumentu vrátit odkaz na jeho vlastní chráněný soubor. Autogram k tomuto souboru přístup má, takže ho otevře a pošle na server, čímž soubor opustí chráněné úložiště telefonu.

Fungovalo to i tehdy, když aplikace soubor nakonec odmítla. Nepodporovaný typ Autogram v mobilu zobrazit nedokázal a uživateli ukázal chybu, ale obsah jsme už našli v jeho komunikaci se serverem. Chybové hlášení na obrazovce tedy tomuto úniku dat nezabránilo.

Střední nález se týkal logování. Aplikace odesílala ladicí záznamy do externí služby pro sběr chybových hlášení. V logách se však ocitla i citlivá data: identifikátor dokumentu a jeho šifrovací klíč. Ven odešla až ve chvíli, kdy aplikace spadla, protože záznamy odcházejí spolu s hlášením o pádu. Kdo má tyto dva údaje, dostane se k dokumentu a nic dalšího k tomu nepotřebuje. Zapsat je do logu je stejné jako zapsat tam přihlašovací údaje.

Na jednom z méně závažných nálezů je dobře vidět, jak se z technické chyby stane sociální útok. Aplikace zobrazovala obsah dokumentu tak, jak přišel, bez jakékoli kontroly. Bylo do něj proto možné vložit funkční HTML (HTML injection), tedy kód, který se na obrazovce vykreslí jako skutečná část rozhraní. Útočník tak dokázal přímo nad oficiálním podpisovým rozhraním vykreslit falešný dialog, například výzvu k zadání PIN kódu k eID. Z technické chyby se tak stává připravená útočná plocha pro phishing.

„Dobře napsaný kód, který si přečetlo množství lidí, je velká výhoda. Neprozradí ale, jak aplikace zpracuje vstup, který nemá tvar, jaký očekávala. Bezpečnost se nedá vyčíst. Dá se jen vyzkoušet.“ Denis, penetrační tester v Citadelo

Zbytek nálezů tvořila chybějící ochranná opatření. Sama o sobě nejsou zranitelností, fungují jako dodatečné mechanismy, které útočníkovi ztěžují a zpomalují práci. Autogram například nezjišťoval, zda zařízení nebo síť nebyly kompromitovány. Většina lidí to zná z bankovních aplikací: na telefonu s odemčenými systémovými právy se mnohé z nich vůbec neotevřou, a když zjistí, že jim do komunikace někdo zasahuje, spojení samy ukončí. Aplikace, která tyto mechanismy má, tak může na kompromitovaném zařízení odmítnout podepisování.

Co se nám nepodařilo

Výsledkem testu není jen seznam nálezů. Patří do něj i to, co jsme vyzkoušeli a neprošlo, protože právě tam je vidět, co v aplikaci drželo a co v ní někdo navrhl správně a bezpečně.

Zápis do libovolného souboru jsme neposunuli dál. U takových chyb se útočník někdy dostane až k ovládnutí celého telefonu, musí však najít knihovnu, kterou si aplikace načítá při spuštění a kterou dokáže přepsat. Autogram takovou knihovnu nemá a jinou cestu k získání plné kontroly nad zařízením jsme nenašli.

Přesto jsme hodnocení nesnižovali. Nález zůstal kritický, protože přepisování nastavení aplikace, kterou lidé podepisují právně závazné dokumenty, je z našeho pohledu riziko, které nelze akceptovat.

K vnitřním rozhraním aplikace jsme se nedostali přímo. Autogram je má před ostatními aplikacemi v telefonu chráněná, a to je vědomé rozhodnutí, ne náhoda. Cizí aplikace si od nich soubor vyžádat nemůže. Museli jsme jít oklikou a přimět vnitřní část samotného Autogramu, aby si soubor vyžádala za nás.

Podobně tomu bylo na serverové části. Vstupní kontrola na serveru existuje. Když jsme podstrčili soubor, který není dokumentem, server ho odmítl. Zafungovala přesně tak, jak má.

Jeden serverový nález jsme nechali jako otevřenou otázku. Server posílá notifikace na adresu, kterou mu zařízení zadá při registraci, a tuto adresu nekontroluje. Alespoň teoreticky se tím otevírá cesta k odeslání požadavku i tam, kam nemá. Zneužití jsme ale neprokázali, a tak nález zůstal na nejnižší úrovni s doporučením, aby si to vývojáři interně ověřili. Nálezy, které nedokážeme, nenadhodnocujeme.

Oba nejzávažnější nálezy mají jedno podstatné omezení: nelze je spustit na dálku. Útočník musí mít v telefonu oběti vlastní aplikaci nebo musí oběť otevřít jeho odkaz. Na závažnosti to nic neubralo, škodlivé aplikace se šíří i mimo oficiální obchody Google Play a App Store. Pouze to zužuje okruh útočníků: není to náhodný člověk z internetu, ale někdo, kdo se do telefonu už jednou dostal.

Je tedy podpis Autogramem v pořádku jako celek? Na to náš test odpovědět nemůže. Testovali jsme Autogram a server, který ho obsluhuje, nikoli občanský průkaz ani státní komponenty, které podpis ověřují. Ty nejsou systémy Slovensko.Digital a bez zadání od jejich správce se do nich nezasahuje.

Penetrační test vs. automatizovaný sken zranitelností: proč skener tyto nálezy nenajde

Ani jeden ze dvou nejzávažnějších nálezů by samotný skener nepotvrdil, a právě v tom spočívá rozdíl mezi automatizovaným skenem zranitelností a manuálním penetračním testem. Skener přečte kód a označí podezřelé místo. Nedokáže prokázat, že je možné ho zneužít, ani co tím útočník získá.

Abychom zápis do libovolného souboru prokázali, bylo nutné vytvořit vlastní škodlivou aplikaci, která se Autogramu představí jako zdroj dokumentu a podstrčí mu předem připravený název souboru. Při úniku souborů jsme si vytvořili vlastní aplikaci pro výběr souborů a zaregistrovali ji do systému tak, aby si ji uživatel mohl vybrat místo té pravé. Skener protihráče nepostaví. Právě proto se při etickém hackingu útočný nástroj vyrábí na míru konkrétnímu cíli, jinak takovou chybu nelze ani potvrdit, ani vyvrátit.

Jak Slovensko.Digital opravilo nalezené zranitelnosti – oprava příčiny místo jedenácti záplat

Test má hodnotu až tehdy, když se podle něj něco změní. Tady lze přesně ukázat, co se změnilo.

Díky veřejnému kódu jsme se nezastavili u projevu problému, ale došli až k jeho příčině. To je rozdíl mezi doporučením „doplňte validaci vstupu“ a přesným místem, kde chybí.

Vývojáři připravili opravy, které námi zjištěné nedostatky odstraňují. Z tohoto důvodu doporučujeme aktualizovat aplikaci Autogram v mobilu pro Android co nejdříve.

Zajímavější než rychlost je totiž způsob. Místo záplaty na každém místě, kde se problém projevil, přidali jednu součást, která nejprve zjistí, kam odkaz na soubor skutečně vede, a až poté ověří, zda je toto místo na seznamu povolených. Opravili tak příčinu, nikoli jeden její projev.

Výhodou otevřeného vývoje je, že si tohle všechno může ověřit každý. Nemusíte věřit nám ani jim, ten pull request je veřejný. https://github.com/slovensko-digital/avm-app-flutter/pull/119 

Kritický zápis do souboru, únik lokálních souborů, šifrovací klíč v logách i HTML injection jsou opraveny v aktuální verzi Autogramu v App Store i Google Play. Pokud ho používáte, stačí ho mít aktualizovaný.

Nález, který nelze jednoduše opravit

Jeden nález ale zůstává otevřený a není to nedůslednost. V naší zprávě má nejnižší možnou závažnost, tedy pouze formu doporučení, a přesto je z celého testu nejzajímavější.

Když člověk podepisuje občanským průkazem, zadává dva kódy, o kterých mu celý život říkají, že je nesmí nikomu prozradit: BOK a podpisový PIN ke kvalifikovanému elektronickému podpisu. Aplikace si je musí na chvíli podržet v paměti, jinak by s nimi nemohla pracovat. Nám se podařilo paměť běžící aplikace přečíst a oba kódy jsme v ní našli v čitelné podobě.

Proč je to tedy jen poznámka? Protože útok předpokládá telefon, který útočník už plně ovládá. A hlavně proto, že v jazyce, ve kterém je aplikace napsaná, nelze takto citlivou hodnotu z paměti spolehlivě vymazat. Systém ji uvolní, až když se mu to hodí, a pokus o její přepsání se často vůbec neprovede, protože ho optimalizace vyhodí jako zbytečný. Skutečně čistě lze tento problém řešit pouze v jazycích, které pracují s pamětí přímo.

Nedá se to tedy opravit mazáním? Částečně ano, kódy lze v paměti držet kratší dobu a v takové podobě, kterou lze přepsat, ale záruku to neposkytne. Zbytek spočívá v tom, aby se útočník k paměti vůbec nedostal, o což se stará detekce kompromitovaného zařízení. Tu aplikace neměla a v naší zprávě šlo o samostatný nález, rovněž na úrovni poznámky. Právě tyto dva nejméně závažné nálezy tak společně vysvětlují více než ten kritický. Hranici opravitelnosti zde neurčuje vývojář, ale platforma, na které aplikace běží.

Co si z penetračního testu odnést, pokud vyvíjíte vlastní aplikaci?

Pokud vyvíjíte aplikaci pro více platforem, testujte každou z nich samostatně. Desktopová verze Autogramu byla v dobré kondici, mobilní měla kritický nález a nešlo o nedbalost. Byla to jednoduše jiná rozhraní.

Druhá věc je konkrétnější. Pokud vaše aplikace něco přijímá od jiných aplikací v telefonu, je vstupem pro útočníka všechno, co přichází, nejen obsah souboru. Také jeho název a odkaz, který na něj ukazuje. Téměř všechny naše nálezy měly tuto jednu příčinu.

Třetí věc: každý řádek logu, který obsahuje klíč nebo token, je přihlašovací údaj a je třeba s ním tak zacházet.

A ta hlavní: otevřený kód je obrovská výhoda a Autogram ji využil naplno, ale není náhradou za test bezpečnosti IT. Kód ukáže, co aplikace dělá. Útok ukáže, co se s ní dá udělat.

Potřebujete otestovat vlastní aplikaci?

V Citadelo provádíme penetrační testy mobilních aplikací, webových aplikací i infrastruktury, phishingové simulace a bezpečnostní prověrky na míru. Pokud vyvíjíte něco, co pracuje s identitou, podpisem nebo platbami, napište nám, co stavíte, a ozveme se s návrhem rozsahu testu.