Mobilní bankovnictví se stalo nezbytným uživatelským standardem. Člověku se tomu skoro ani nechce věřit. První mobilní banku jsme s Komerční bankou uváděli teprve v roce 2012. V průběhu času se přitom změnil pohled na to, jak vytvořit mobilní bankovnictví, které je bezpečné.
„Mobilní bankovnictví 1.0“ bezpečnost řešilo spíše okrajově. V roce 2012 totiž nikdo nevěděl, zda obsluhu účtu přes chytrý telefon bude vůbec někdo chtít. Proto bylo mobilní bankovnictví spíše inovačním projektem, v duchu „tak pojďme to tedy zkusit“.
Průlomová byla v tomto ohledu až aplikace od Raiffeisenbank. Ta jako první v Česku představila koncept „silné kryptografie“ oddělené do samostatného kryptografického jádra odolného proti různým typům útoku.
Následně tento koncept převzaly v podstatě všechny ostatní retailové banky, pro které je mobilní bankovnictví důležitým kanálem kontaktu s klientem. Vzniklo „Mobilní bankovnictví 2.0“ – regulérní a dobře zabezpečený digitální kanál banky, o jehož obchodním přínosu a nezbytnosti již nikdo nepochyboval.
Přestože oddělené kryptografické jádro poskytuje velmi dobrou míru zabezpečení, útočníci nespí a hrozby – které jsou nyní mířeny přímo proti mobilnímu bankovnictví – se neustále vyvíjí a stávají se sofistikovanějšími. Aktuální zabezpečení tak pomalu přestává dostačovat. Je nutné přijít s konceptem zabezpečení pro „Mobilní bankovnictví 3.0“ a téma, které je pro něj více než aktuální, je zabezpečení runtime aplikací. Ale co si pod tím přesně představit?
Stručný úvod do runtime mobilních aplikací
Základní charakteristikou každého chytrého telefonu na Alze je jeho operační systém. Dnes jsou relevantní dva operační systémy: Android (zhruba 80 procent) a iOS (kolem 20 procent). Ostatní operační systémy jsou pak víceméně okrajové.
V operačním systému běží aplikace. To, co je na běhu aplikací v mobilním operačním systému zajímavé, je, že na rozdíl od aplikací na klasickém desktopu běží ve svém vlastním sandboxu. Toto platí s drobnými odchylkami jak na iOS, tak na Androidu.
Mobilní aplikace jsou od sebe vzájemně a od operačního systému oddělené pomocí sandboxu
Sandbox je jakýsi virtuální prostor, který odděluje aplikaci od operačního systému a také od ostatních aplikací instalovaných na zařízení. Aplikace tak může číst a zapisovat pouze v rámci svého sandboxu a nemůže sahat pod ruce ostatním aplikacím nebo měnit vlastnosti operačního systému.
Výjimku tvoří systémové aplikace – ty, které jsou v telefonu od výrobce. Ty mohou například využívat privátní systémová rozhraní (API) a mít tak přístup k širší sadě funkcí než aplikace dostupné na aplikačním marketplace. Navíc v operačním systému běží také aplikace, které vůbec nejsou vidět – takzvaní démoni. Příkladem je třeba proces „apsd“ běžící na iOS, který se stará o konektivitu ke službě pro zasílání push notifikací. Obě tyto kategorie aplikací mají typicky zvýšená oprávnění a mohou tak opět přistupovat k nadstandardní sadě funkcí.
Samozřejmě že pokud by aplikace stažená z aplikačního marketplace byla v sandboxu uzavřena zcela neprodyšně, nebylo by to moc praktické. Kontakt uložený v aplikaci Kontakty by nebyl dostupný z žádné jiné aplikace, nebylo by možné vybrat fotografii z galerie nebo například integrovat do telefonu aplikaci čtečky pro nevidomé. Aplikace tedy mohou využívat systémová rozhraní k tomu, aby vykonaly některé dobře definované funkce (vybraly kontakt, pořídily fotografii a uložily ji do galerie telefonu, či třeba četly aktuální obsah obrazovky) a částečně tak opustily prostor, který jim vymezuje sandbox.
A aplikace mobilního bankovnictví není v ničem jiná. Jedná se o klasickou aplikaci staženou z aplikačního marketplace, která žije se standardním oprávněním v rámci svého aplikačního sandboxu a se světem komunikuje skrze systémová rozhraní.
Jak zaznělo v úvodu, součástí moderního mobilního bankovnictví je pak samostatné „kryptografické jádro“. To je typicky implementované na nízké systémové úrovni tak, aby bylo složité nabourat jeho runtime či číst nebo modifikovat paměť související s kryptografickými procesy.
Kryptografické jádro je zodpovědné primárně za podepisování aktivních operací a za počítání podpisů pro řízení přístupu (přihlášení do aplikace). Často pak má celou řadu dalších benefitů jako zjednodušená autentizace pro widgety a hodinky nebo speciální typ podpisu pro smlouvy uzavírané s bankou. Obchodně lze také komunikovat to, že správně připravené kryptografické jádro pomáhá bance splnit regulatorní požadavky na silné ověření klientů s využitím více faktorů dle definice v PSD2 legislativě (SCA).
Mobilní banka je standardní aplikace, která má svůj sandbox a s okolím komunikuje přes systémová rozhraní
Celý obrázek vypadá takto velmi dobře. Jsou zde pouze dva drobné potenciální problémy: lidé jsou zlí a software obsahuje chyby.
Útočníci jsou stále vynalézavější v tom, jak zneužívat standardní systémová rozhraní k tomu, aby způsobili škodu, a to v podstatě s minimálními náklady na jejich straně.
Jedna z často zneužívaných vlastností je například možnost instalovat do operačního systému vlastní klávesnice, které mohou fungovat jako keylogger a zcizit tak citlivá data, ať už se jedná o hodnotu aktivačního kódu mobilní aplikace (útočník si „napáruje“ aplikaci na cizí účet rychleji než legitimní klient), nebo třeba údaje právě zadávaného platebního příkazu.
Dále se jedná třeba o využití systémového rozhraní pro implementaci přístupnosti nevidomým (accessibility), kdy podvržená čtečka obrazovky sbírá všechna data, která jsou na obrazovce zobrazena. Nakonec se jedná například o rozhraní pro sdílení obrazovky na externím monitoru, o možnost kreslit aplikační overlay (rozhraní vykreslené nad běžící aplikací — zde se bavíme o takzvaných overlay attacks), nebo třeba o API pro tvorbu systémových screenshotů.
Útoky přes standardní systémová API jsou nepříjemné samy o sobě. Ale ještě více nepříjemné jsou v kombinaci s technikou eskalace oprávnění (získání práva root). Moderní malware velmi často využívá kód aplikace Framaroot. Ta umožňuje snadné rootování na klik poměrně velkého počtu Android zařízení. Malware tak získá oprávnění root (nejvyšší systémové oprávnění), zatímco mobilní banka stále běží se standardní sadou oprávnění.
Mobilní malware je tak schopný penetrovat aplikační sandbox, připojit se přímo do běžící mobilní aplikace a číst či modifikovat uživatelské rozhraní nebo data v paměti, jak se mu zlíbí.
Útočník může zneužít slabinu OS a systémová rozhraní tak, aby obešel existující zabezpečení aplikace. Kryptografické jádro pak může nechat zcela nedotčené.
Nepříjemné na tom je, že přestože „kryptografické jádro“ samo o sobě je proti těmto útokům odolné, malware s root právy může napřed od uživatele získat hodnotu PIN kódu (například sledováním dotyků na obrazovce) a následně využít získaný PIN kód k tomu, aby do neporušeného kryptografického jádra poslal regulérní požadavek na podepsání podvodné platby. To vše bez vědomí a souhlasu uživatele. Problematické jsou přitom dvě věci:
- Uživatel má velmi malou šanci podobný malware odhalit za předpokladu, že částka bude rozumně maskována („Roční poplatek bance“). V případě Androidu může být podobný typ útoku dokonce distribuován skrze oficiální distribuční kanál, pokud si útočník dá práci s obfuskací svého kódu.
- Z pohledu banky se takto zadaná platba jeví jako legitimní, zadaná ze správného zařízení a podepsaná správným PIN kódem. Není tedy možné průkazně potvrdit či vyloučit, že zadaná platba byla zadaná bez vědomí uživatele.
Nyní již nejspíš vidíme problém. Klasický příklad nejslabšího článku: Útočník nebude atakovat silně chráněné kryptografické jádro, ale zaměří se na slabiny operačního systému a běžně dostupná systémová rozhraní.
Co tedy lze s tímto problémem dělat? Je boj předem prohraný a vyplatí se tedy složit zbraně? Přestože v teoretické rovině je útočník ve výhodě a nakonec zvítězí, je zde jedna věc…
Bojujte
Proti všem popsaným útokům existuje jediná trnitá cesta obrany: kombinací obfuskace aplikace (skrývání principu fungování), detekčních a obranných mechanismů a maskovacích technik útočníka unavit, znechutit a odradit od útoku právě na vás a vaši mobilní banku.
Kdykoliv aplikace zjistí, že je zneužívané nějaké systémové rozhraní, musí na to umět adekvátně reagovat – zastavit útok, nebo se raději ukončit. Aplikace například musí zkontrolovat, že screenreader, který chce číst obsah obrazovky, je ten správný a oficiální, nikoli nějaký podvržený. Stejně tak musí umět detekovat, že se k ní snaží připojit jiná aplikace, a opět se této hrozbě postavit (typicky tím, že se ukončí).
Wultra App Shielding chrání aplikaci v sandboxu tím, že předchází, detekuje a reaguje na nestandardní situace
To vše musí přitom dělat takovým způsobem, aby útočník a jeho malware s root právy nemohli tento typ ochrany snadno odhalit a vypnout – ochranné prostředky tedy nesmí být snadno zjistitelné a musí být v kódu maskovány. Obrana musí – ve stylu indiánského boje – umět přechytračit útočníka, přestože má méně zdrojů a výrazně horší výbavu.
V obchodní praxi tento typ boje naráží na zásadní problém: Je poměrně náročný na know-how a programátorské zdroje, práce nikdy nekončí, protože se objevují stále nová systémová API a nové, chytřejší typy útoků, a přitom z obchodního hlediska koncovému uživateli tento vývoj nepřinese nic užitečného.
Jednoduchou integraci lze dosáhnout zcela bez programování, pouze aplikací nástroje. Následně lze dorůst do produktu integrací App Shielding SDK
Ochrana proti malware není nová funkce, která by někomu udělala radost nebo vyřešila problém s placením či financemi. Není tedy jasné, jaký je její obchodní přínos. A z tohoto důvodu zatím všechny české banky nechávají runtime ochranu bez pozornosti a vystavují tak své aplikace a jejich uživatele potencionálnímu útoku na runtime.
Přestože téma mobilního malware a run-time zatím nezískalo ze strany bank v Česku pozornost, jakou si v dnešní době zaslouží (v Německu, Anglii či skandinávských zemích je tento typ ochrany mobilního bankovnictví již běžný, protože tamní banky měly možnost výše popsané útoky potkat), dobrá zpráva je, že už máme první vlaštovky. Například naše firma vyvíjí nástroj Wultra App Shielding, který bude bránit mobilní aplikaci jedné významné české banky.
Wultra App Shielding zajišťuje ochranu runtime aplikace. Sleduje standardní systémová rozhraní a detekuje potenciální útočníky s právy root a jejich aktivitu a na každou nestandardní situaci, kterou zaznamená, má připravenou odpovídající reakci.
Z pohledu implementace je hezké především to, že základní integrace ochrany probíhá bez nutnosti jakéhokoliv programování, pomocí shieldingu již existujícího aplikačního balíku. Jednoduchým nástrojem lze tedy zvýšit bezpečnost runtime mobilního bankovnictví, zatímco programátoři aplikace se věnují vylepšením pro koncové uživatele.
Následně lze využít integraci App Shielding SDK a „postupně dorůstat do produktu“ tím, že se některé nestandardní situace ošetří s vyšší mírou přesnosti.
Text původně vyšel na blogu autora.
