Kernun proti útokům na datové schránky

Včera proběhla v Praze další (v pořadí již druhá) tisková konference, věnovaná tématu útoků na informační systém datových schránek. Pořádala ji společnost TNS (Trusted Network Solutions, a.s.), a na rozdíl od jiné  tiskovky konané minulý týden (společností 4Safety, viz článek: Co je nedostatečně bezpečné? Datové schránky nebo osvěta?) ji vedla v mnohem věcnější rovině, i o to méně bombasticky. Navíc s výrazným podílem osvěty, byť fakticky šlo o prezentací jednoho konkrétního komerčního řešení, šitého na míru datovým schránkám  (produktu Kernun – bezpečná schránka od společnosti TNS, viz dále).

Ani tentokráte přitom nešlo o žádné „nabourání“  do datových schránek v pravém slova smyslu, jako přímé překonání zabezpečovacích mechanismů tohoto systému. Byl zde předveden (a řádně vysvětlen) jeden konkrétní druh útoku, vedený opět  „u uživatele“. Konkrétně se jednalo o to, že uživatel si  do svého browseru nainstaloval jeden konkrétní plug-in, o kterém ale nevěděl, že kromě své řádné funkce ještě někomu přeposílá  obsah cookies dosud neukončených (neuzavřených) relací. Čímž vlastně „krade“ SSL relace.

Pak už stačilo, aby se uživatel takto napadeného  browseru řádně přihlásil do své datové schránky (klidně i pomocí certifikátu, to je vlastně nepodstatné) – ale po skončení své práce se schránkou se z ní nesměl řádně odhlásit, ale místo toho musel jen zavřít svůj browser. Právě to byla příležitost pro „cinknutý“ plug-in: na signál o zavírání browseru ještě odeslal obsah cookie k dosud neuzavřené relaci s ISDS na jiný počítač. Pro ten už pak nebylo těžké v neuzavřené relaci pokračovat dále. Tedy vlastně pracovat s cizí datovou schránkou, bez nutnosti se znovu přihlašovat.

První otázka, na kterou jsem se následně zeptal (a to přítomného pana Smolíka, za provozovatele ISDS), byla, jak je něco takového možné: proč nemá ISDS proti takovýmto „únosům relací“ zabudovanou ochranu? Proč používá persistentní cookie a proč nekontroluje  IP adresu v průběhu relace, a při změně ji ihned neukončí (tj. uživatele sám neodhlásí)?

Kontrola změny IP adresy se prý teprve zavádí (a snad bude do 14 dnů, stejně jako nepersistentní cookies). A důvod, proč tomu tak dosud nebylo, souvisí se způsobem připojení orgánů veřejné moci: většina z nich využívá služby KIVS (Komunikační infrastruktury veřejné správy), a vzhledem k jejímu fungování se prý z pohledu ISDS jeví, jako kdyby všichni přicházeli z jediné IP adresy (resp. několika málo IP adres). A ta se prý někdy v čase mění, třeba i během jediné delší relace (delšího připojení, například nějaké spisové služby). Takže mechanické odpojování při změně IP adresy by prý narušilo „řádné“ relace dlouhodoběji připojených uživatelů  z řad orgánů veřejné moci.

No, zajímavé vysvětlení. Zná někdo ze čtenářů podrobněji fungování KIVSu z pohledu IP adresace, různých bran, cache apod.?

Jinak obecná obrana proti tomuto druhu útoku se nijak neliší od obvyklých zásad „osobní hygieny“ v online prostředí: nestahovat neznámé věci (natož nepodepsané plug-iny, či plug-iny s neplatným či nevěrohodným podpisem), a také explicitně ukončovat probíhající připojení (relaci se serverem) skrze odhlášení – a neřešit to pouhým ukončením (zavřením) browseru.

Jaké jsou možné útoky na informační systém datových schránek?

Když jsem říkal, že tisková konference měla i svou osvětovou část, pak v té se hovořilo hlavně o tom, jaké druhy útoků na datové schránky vůbec připadají v úvahu, jak jsou náročné na kvalifikaci (na straně útočníka), jak malá či velká je příležitost k jejich uskutečnění, a jaké je riziko, že skutečně budou provedeny.

Základní sdělení, které nabízí i tabulka, je takové, že nabourat se skutečně do samotného informačního systému datových schránek (ISDS) je relativně nejtěžší. Snazší je vést útok přes uživatele, resp. přes klienta a jeho vybavení. A i zde jsou nejjednodušší takové  útoky, které míří na jeho znalosti a aktivity: na to, že uživatel musí nebo naopak nesmí něco udělat, že neví jak přesně to udělat atd. V tabulce jde hlavně o body 4 a 5, které alespoň z mého pohledu poněkud splývají (a mají také stejné hodnocení).

Samozřejmě nejde o žádné převratné zjištění, resp. o něco dosud nepoznaného. Je všeobecně známo, že nejslabší článek řetězu je ten mezi židlí a klávesnicí (typy 4 a 5). Teprve po něm následuje to, co je mezi klávesnicí a síťovou přípojkou (vlastní počítač, jeho operační systém, aplikace), a to, co je „venku“.

Takže je určitě na místě očekávat, že většina útoků na datové schránky povede právě přes tento nejslabší článek řetězu, tedy přes samotné uživatele. Ostatně, útoky předváděné včera (společností TNS) i minulý  týden (společností 4Safety), vedené „přes uživatele“, jsou tohoto dokladem. 

I proto je ale smutné, že z pohledu jakési „péče o bezpečnost“ je tomu přesně naopak: zřizovatelé a provozovatelé datových schránek sice nějak řeší bezpečnost svého systému (serverů, databází atd.), ale osvětě a vzdělávání koncových uživatelů je věnováno minimum pozornosti. A vzhledem k tomu, co jsem v různých článcích zde na Lupě popisoval (třeba kauzu serverových certifikátů ISDS, či hrátky s adresami, kde datové schránky běží) si dovolím dokonce konstatovat, že u nejslabšího článku celého řetězce je bezpečnost spíše ještě dále podrývána, než nějak zlepšována, či dokonce systematicky budována. Nehledě již na tikající bombu v pozadí v podobě nevyřešeného dlouhodobého statutu elektronických dokumentů, kterou se zatím asi nikdo nepokouší deaktivovat.

Na druhou stranu tento stav o to více otevírá prostor pro komerční subjekty, aby nabídly řešení zvyšující bezpečnost. Jako právě v případě společnosti TNS, která kromě předvedeného útoku představila i své řešení, které před ním (a mnoha dalšími) dokáže ochránit.

Jak funguje Kernun?

Včera představený produkt Kernun – bezpečná schránka  (Kernun BS) je řešením, postaveným na míru právě datovým schránkám, a to na bezpečnostní platformě Kernun. Odsud také jeho název.

Princip fungování Kernun BS není nepodobný klasickému útoku zvanému „Man in the Middle“. Samozřejmě s tím rozdílem, že v něm nejde o to někoho podvést, ale naopak ochránit. Jak, to si můžeme naznačit na následujícím obrázku:

Koncový uživatel si myslí, že pracuje přímo s datovou schránkou přes její webové rozhraní. Iluze je bohužel dokonalá i v tom, že k tomu potřebuje nainstalovaný 602XML Filler. Ve skutečnosti ale jeho browser komunikuje s prostředníkem (Kernun-BS), který se vůči jeho browseru chová jako SSL proxy. Díky tomu dokáže upravovat průběh relace s ISDS takovým způsobem, že jakoby „překládá“ přihlašovací údaje: uživatel zadává určitou sadu přihlašovacích údajů (jméno a heslo), na obrázku zelené –  ale Kernun BS do datové schránky posílá jiné přihlašovací údaje (ty „ostré“, na obrázku červené).

To má ten významný efekt, viz následující obrázek, že i když by někdo koncovému uživateli jakkoli „ukradl“ jeho přihlašovací údaje (ty „zelené“), stejně by mu byly k ničemu – protože kdyby se s nimi chtěl následně přihlásit k datové schránce uživatele (již přímo, a nikoli přes Kernun BS), pak neuspěje. Bude mít nesprávné údaje (ty zelené), zatímco pro úspěšné přihlášení by potřeboval mít ty červené.

Ztratit ony „zelené“ přihlašovací údaje proto není až tak nebezpečné, zvláště když si Kernun BS ještě hlídá, kdo může využívat jeho služeb a kdo ne. V zásadě by mohly být i veřejné (pokud by se nikdo jiný nemohl připojit na Kernun BS tak, aby je dokázal využít).

Logická vazba mezi „zelenými“ a „červenými“ přihlašovacími údaji přitom vzniká v rámci konfigurace Kernun BS, při vytváření uživatelského účtu, viz obrázek:

Z pohledu koncového uživatele to pak skutečně vypadá tak, že se přihlašuje pod takovým jménem a heslem, jaké si sám zadal při vytváření svého uživatelského účtu v rámci Kernun BS. Například já jsem si místo kryptického „ph4hos“ mohl dovolit uživatelské jméno peterka, a to pak také zadávat do přihlašovacího formuláře datové schránky, viz obrázek.

Nenechte se přitom zmást tím, že předchozí obrázek se vztahuje ke zkušebnímu prostředí: Kernun BS „umí“ pracovat jak s tím zkušebním, tak samozřejmě i s tím ostrým. A způsob práce je v obou případech identický, odlišnost je pouze při úvodním rozcestníku, který se ptá zda si uživatel chce udělal Kernun účet pro zkušební nebo ostrou verzi datových schránek.

Zajíamvé také je, že Kernun BS si prý nepamatuje „ostré“ přihlašovací údaje (aby se nedostal do konfliktu se zákony). Místo toho si vytvoří a pamatuje funkci, která po zadání správného (zeleného) jména a hesla vypočítá správné ostré (červené) přihlašovací údaje.

Dalším prvkem, zvyšujícím bezpečnost, je možnost kdykoli se podívat na historii přístupů k datové schránce přes Kernun BS, viz následující obrázek:

V tomto ohledu je samotné prostředí webového rozhraní ISDS mnohem skromnější: při úvodním přihlášení vám sice řekne, kdy jste byli přihlášení naposledy. Ale už vám třeba neřekne, z jaké IP adresy. Natož abyste viděli nějakou hlubší historii aktivit kolem své datové schránky, a mohli třeba i jen ex-post poznat nějaký (ne)oprávněný přístup odjinud.

Kernun BS samozřejmě musí nějak pamatovat i na speciální případy, které nejde realizovat při zapnutém „překladu“ přihlašovacích údajů (zelených na červené). Dělá to tak, že na určitou krátkou dobu (5 minut) otevře uživateli „nechráněný“ přístup k jeho datové schránce –  tak aby zde mohl provést to, co v řádném („chráněném“) režimu udělat nemůže – jako například změnu hesla každých 90 dnů.

A jak Kernun chrání proti kradení cookies a celých relací, jaké na včerejší tiskovce předvedli jeho autoři? Na stejném principu, jako proti krádeži přístupových údajů, i před jinými útoky: relace mezi koncovým uživatelem a Kernun BS je jiná, než mezi Kernun BS a datovou schránkou. Takže i když by ji někdo „ukradl“ a chtěl v ní pokračovat, již přímo vůči ISDS, opět mu nebude k ničemu, protože v ní nedokáže pokračovat – viz obrázek.

Na závěr jen konstatování, že „Kernun – bezpečná schránka“ existuje ve dvou variantách: verze Retail je „hotové“ a předem nakonfigurované řešení v podobě malého počítače, které stačí jen zapnout a používat (a na klientských počítačích jej nastavit v browserech jako SSL proxy). Naproti verze Enterprise je řešením pro větší zákazníky, které musí nejprve nakonfigurovat jejich síťový administrátor, podle konkrétního zapojení do firemní sítě a podle způsobu koexistence z firemním firewallem.