Audit ATM – Replay Attack
ATM již několik desetiletí patří k neodmyslitelné součásti našeho života. Jsou ale peníze opravdu v bezpečí?
V několika posledních letech se nám naskytla příležitost provést audit a penetrační test několika výrobců a dodavatelů ATM a to nejen v České Republice. V průběhu auditu jsme prověřovali všechny známé zranitelnosti, jak na vrstvě XFS, tak na vrstvě operačního systému, samozřejmostí bylo také prověření fyzické bezpečnosti, jak popisovali již moji kolegové v článku Bezpečnost bankomatů
Pod rukama nám tak prošlo mnoho aplikací zajišťujících interakci s klientem ATM a periferními zařízeními. Zásadním zjištěním bylo, že každý výrobce si aplikuje vlastní řešení, neexistuje zde žádný standard nebo koncept, kterého by se drželi. Při auditu jsme narazili na aplikace napsané v různých programovacích jazycích, jako například C#, C++, Java a mnoho dalších. Většina z nich integrovala GUI v HTML, jako hlavní rozhraní pro komunikaci s klientem, tedy to, co klient při operacích prováděných na ATM vidí na obrazovce. Většina obrazovek, které vidí běžný uživatel při provádění transakcí je v podstatě čisté HTML, obsluhované některou z výše zmíněných aplikací. Tyto HTML stránky se načítají z různých servisních adresářů. Důvod je vcelku jasný, je potřeba mít prostor pro rychlou aktualizaci především reklamních sdělení.
Většina ATM je tedy založena na následujícím principu:
Služba nebo při startu spuštěná aplikace, nejprve provede nepřeberné množství kontrol všech rozhraní a dostupnosti domovských serverů, následně jsou-li kontroly bez chyb, načte HTML stánky a zobrazuje je na obrazovce ATM. V pasivním modu ATM většinou zobrazuje reklamní sdělení. Pokud startovací kontroly nedopadly úspěšně, zobrazí se informace s omluvou o nedostupnosti ATM. Pasivní mód se změní v momentě, kdy klient přistoupí k ATM a vloží do něj platební kartu. Bezprostředně po vložení karty se načtou obrazovky pro zadání pinu a dále pak dle vybrané činnosti například stránky pro výběr, vklad, platbu, zjištění zůstatku, změnu pin a mnoho dalších operací v závislosti na bance a typu ATM.
Při výběru transakce je na pozadí provolávána funkce aplikace, která následně většinou provolává přímo XFS vrstvu. Tato vrstva pak slouží ke komunikaci s jednotlivými perifériemi, například pinpadu, dispenseru, tiskárny, kamery a mnoha dalších. XFS vrstva je v podstatě jediná standardizovaná část celého ATM. Zbytek je plně v režii výrobce a distributora. Stalo se nám tedy na jednom z testovaných ATM, že jsme narazili na docela zvláštní funkcionalitu, která nás zaujala, a tak jsme se ji pokusili více prověřit.
Na ATM běžela aplikace, která po startu bankomatu otevírala velké množství portů naslouchajících pouze na loopbacku. Pak jsme ve výpisu netstat mohli vidět například následující informace:
Naslouchající porty a navázaná spojení by nemusely být problém, spojení se navazuje pouze v rámci loopback, takže nikdo z externí sítě se k portům a komunikaci nedostane, navíc dnešní modely ATM využívají nové verze Windows i s řádně nastavenou filtrací na integrovaném Firewallu.
Stejně jsme se rozhodli, že zkusíme prověřit, co na těchto naslouchajících portech probíhá za komunikaci a kdo naslouchající porty oslovuje. Jelikož jsme již měli povýšená práva na lokálního administrátora, spustili jsme sniffer, který dokáže odposlouchávat loopback komunikaci a zkusili jsme provést kompletní výběr z ATM i s tiskem potvrzení o transakci.
Následně, když jsme analyzovali odchycenou komunikaci, nás okamžitě překvapilo, že pokud se odesílají data na určitý port, není vyžadována žádná autentizace. Dále jsme zjistili, že v průběhu výběru z ATM bylo osloveno několik portů a komunikace, která na nich probíhala, byla vždy částečně binární, ale obsahovala také čitelné informace ve formátu XML. Podrobnější analýzou jsme zjistili, že před každým XML je odesláno 5 bajtů binárních dat. Rychlou analýzou jsme zjistili, že se v podstatě jedná o hlavičku protokolu, která pomocí těchto bajtů 5ti definuje délku následujících přenesených dat.
Například na odchycené komunikaci na obrázku výše je hlavička, která obsahuje bajty DD 41 01 00 00:
- DD – je s největší pravděpodobností oddělovač jednotlivých zpráv, to se ale můžeme pouze domnívat, vyskytoval se vždy před přenosem další hlavičky a zprávy.
- 41 01 – je HEX zápis pro délku následujících dat. V tomto případě je to 321 bajtů těla zprávy, což opravdu koresponduje s délkou XML zprávy.
Nedalo nám to, a tak jsme zkusili ještě několik podobných transakcí. Opět jsme analyzovali odchycenou komunikaci, tentokrát jsme se zaměřili především na tělo zprávy tedy samotné XML. Zaujal nás fakt, že data zasílaná na port služby, obsluhující dispenser, se příliš neliší. Pouze v několika málo bajtech, bližší analýzou jsme zjistili, že pouze v částce, kterou jsme jako klient požadovali vybrat z ATM. XML nezahrnovalo žádný kontrolní součet, žádná unikátní ID, HMAC nic co by mohlo bránit útoku „Replay Attack“.
Co se tedy nabízelo? Zkusit poslat na port služby obsluhující dispenser paket hlavičky a paket s XML a požadovanou částkou. Toto jsme tedy provedli. Využili jsme jeden z našich nástrojů pro odesílání libovolných binárních dat přes TCP protokol. Poslali jsme pakety vyextrahované ze snifferu přímo na naslouchající službu obsluhující dispenser port 50000. Ozval se všem dobře známý zvuk, dispenser začal extrahovat bankovky z kazet v trezoru. Tím to ovšem skončilo, peníze se z ATM nevysunuly. Zkusili jsme tedy opět odeslat stejný paket a opět stejný výsledek, zvuk napočítávání bankovek, ale shutter zůstal zavřený. Napřed nás to zarazilo, říkali jsme si, že by nám ATM mělo peníze také vydat. Prošli jsme tedy znovu, dříve odchycenou komunikaci a zjistili jsme, že po paketu odeslaném na službu obsluhující dispenser následuje paket pro vydání karty z card readeru a teprve následující paket opět oslovuje službu dispenseru, ale také shutteru.
Rozbor komunikace po jednotlivých paketech:
- Paket 342 – port 50000 – hlavička zprávy, binární data (5 bajtů).
- Paket 343 – port 50000 – obsahuje XML s XFS příkazy, požadavek na vydání 10 Euro (ulAmount 0xa).
- Paket 344 – port 50000 – je odpovědí serveru, že je vše ok.
- Paket 345 – port 50002 – hlavička zprávy, binární data (5 bajtů).
- Paket 346 – port 50002 – obsahuje XML s XFS příkazem, který zajistí vrácení karty z Card Readeru.
- Paket 347 – port 50002 – hlavička zprávy, binární data (5 bajtů).
- Paket 348 – port 50002 – je odpovědí serveru, že vše proběhlo ok (XML data).
- Paket 349 – port 50000 – hlavička zprávy, binární data (5 bajtů).
- Paket 350 – port 50000 – obsahuje XML s příkazem XFS, požadavek na otevření shutteru.
Vyextrahovali jsme tedy další pakety z odchycené komunikace a poslali je opět na službu obsluhující dispenser.
Bingo.
ATM po zaslání tohoto paketu otevřelo shutter a vydalo nám předchozími požadavky napočítanou částku.
Pokud se člověk zamyslí, nad tím, jak probíhá výběr z ATM, musí mu být hned jasné proč je potřeba odeslat více požadavků na ATM. Stačí si jen projít flow při výběru peněz.
Klient po zadání pin si vybere činnost, například výběr, následně částku a potvrdí ji, dále má možnost si vybrat, zda chce stvrzenku. Po potvrzení a ověření správnosti PINu začne pracovat dispenser a napočítá požadovanou sumu, tu přesune do shutteru, ale ten ponechá ještě uzavřený. Následně ATM většinou vydá zvukový signál a vrátí klientovi kartu, a teprve po odebrání karty otevře shutter a klient si může odebrat požadovanou částku.
Proto je nutné výběr provádět dvěma pakety, jeden osloví dispenser a napočítá částku, druhý otevírá shutter.
Po tomto zjištění a jsme si vytvořili jednoduchou aplikaci, která umožňuje vybírat požadovanou částku. Odesílá dva pakety na požadovaný port, jedním vybere peníze z trezoru, druhým otevře shutter.
Základní slovník pojmů:
- Card Reader – čtečka karet.
- Dispenser – zařízení nad trezorovou částí ATM, umožňující výběr požadovaných bankovek z trezorové části ATM.
- Shutter – přihrádka pro výběr případně vklad peněz.