Mobilní malware je stále chytřejší, aneb proč už vaše mobilní bankovnictví nemusí být bezpečné
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 (~80%) a iOS (~20%). 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 narozdí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.
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ě funkčností, 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 — tzv. démoni. Příkladem je třeba proces “apsd” beží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ě funkčností.
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 vykonali 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 jsme již řekli 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).
Celý obrázek vypadá takto velmi dobře. Jsou zde pouze dva drobné potenciální problémy:
- Lidé jsou zlí.
- 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 tzv. “overlay attacks”), a 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í či data v paměti jak se mu zlíbí.
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 regulerní 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ě OS Android 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 jako lev!
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čí). To vše musí přitom dělat takovým způsobem, aby útočník a jeho malware s právy roota 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.
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.
Existuje tedy nějaký postup, jak problém vyřešit? Ano!
Naštěstí jsou na to tooly…
Nyní vlastně přichází odpověď na otázku “A proč DOOPRAVDY píšete tento článek?” :)
Do naší produktové propozice jsme nedávno doplnili nový produkt, Wultra App Shielding (produktový list), který zajišťuje komplexní ochranu runtime aplikace. Sleduje standardní systémová rozhraní, detekuje potenciální útočníky s právy roota 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 velmi rychle a velmi výrazně 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.
Ufff… už to tedy někdo dělá?
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 místní banky měly možnost výše popsané útoky potkat), dobrá zpráva je, že už máme první vlaštovky.
Wultra App Shielding bude bránit mobilní aplikaci jedné významné české banky. A která to je? :) To zatím necháme na vaše internetové spekulace. Jakmile bude vše připraveno a dílo bude venku, nebojte — hned vám o tom povíme…
