Säkerhetsblogg

Tankar kring konsten att bedöma bankomater

illustration sedlar ur bankomat säkerhetJag måste erkänna att bankomater alltid har fascinerat mig. Jag vet att det kan låta som ett ganska “misstänkt” uttalande av uppenbara skäl, men det handlar inte om de pengarna som de håller utan snarare om hur de är konstruerade.

Därför blev jag lycklig när jag nyligen fick en möjlighet att ta mig an en rad olika bankomater. Det var i samband med en större säkerhetsrevision som syftade till att utvärdera nätverks- och applikationssäkerheten på ATM:er för en av de mest berömda bankerna i världen (mer om det på nyhetssidan). Därför tyckte jag att det kunde vara trevligt att dela med mig av mina erfarenheter från ett roligt och givande uppdrag, speciellt då det är ett ovanligt case.

Fastställa exponeringsytan

Jag började med att undersöka och definiera hur bankomater fungerar och arbetar i praktiken och vilka som är de kritiska komponenterna och gränssnitten, dvs vilken är den faktiska “exponeringsytan”.

Genom att titta på en bankomat vet du att de flesta har två huvudingångar (kortläsare och knappsats) och fyra utgångar (skärm, kvitto, kassaskåp och högtalare). Att hacka sig in i en bankomat genom att utnyttja sådana användargränssnitt är dock inte ett rekommenderat tillvägagångssätt. Inte minst för att ATM-applikationen då måste ha stora logiska brister.

Naturligtvis blir bilden en annan när vi tittar på den mer intressanta och “rikare” baksidan av bankomaten. Där finns en hel massa ingångs-/utgångsgränssnitt samt anslutningspunkter som bildar den “mörka sidan” av en bankomat (den IT-relaterade sidan som ingen någonsin ser), dvs. saker som anslutningen till den auktoriserande bankens finansiella host, administration, applikationer, nedladdning av programvara, operativsystemuppdateringar, övervakning av ATM, bedrägeribekämpning – bara för att nämna några. Hur som helst, om sanningen ska fram, är bankomaterna som andra vanliga (fristående) nätverksanslutna enheter. Det innebär i grunden att, liksom alla andra gemensamma nätverksåtkomliga enheter, kan alla utsatta tjänster, system eller applikationsgränssnitt attackeras av alla som har tillgång till ett lokalt eller intilliggande nätverkssegment. Det var kärnan i mitt uppdrag som ATM-säkerhetsbedömare: Att försöka manipulera de olika gränssnitten med målet att avgöra om obehörig åtkomst eller annan skadlig aktivitet skulle kunna leda till otillåten utdelning av pengar.

XFS och övergripande arkitektur

Jag kände att det fanns ett behov av att studera den ATM-specifika arkitekturen som ligger till grund för den ordinarie ATM-applikationen. Vanligtvis, körs inte ATM-programmet direkt på OS (ofta är ett fristående Windows-skrivbordssystem, till exempel Windows 7 eller XP på plats) men det finns några lager mellan. Bortsett från olika ad hoc-säkerhetslösningar som kan variera och tillåter ATM-programmet att köras i en mycket restriktiv miljö med begränsade tjänster och processer i bakre änden, innefattar en ATM-arkitektur alltid ett så kallat XFS ( EXtensions for Financial Services) middleware lager. En sådan middleware tillhandahåller normalt sett en klient-server arkitektur för finansiella applikationer byggda ovanpå Windows-plattformen.

XFS är en internationell standard som främjas av Europeiska kommittén för standardisering (känd under förkortningen CEN, följaktligen CEN / XFS). Den tillhandahåller ett gemensamt API för åtkomst till och hantering av olika utrustning och finansiella serviceanordningar oavsett tillverkare.

ATM-applikationen kommunicerar sedan genom XFS-skiktet, vilket i sin tur är det som verkligen ger kommandon till hårdvaran. Som sådan är det därför den som till exempel interagerar med en ATM:s kassaautomat för att dispensera kontanterna, vilket förklarar varför åtkomst till XFS-kommandon bör begränsas mycket noggrant genom ATM-operativsystemets kontrollmekanismer.

Detta förklarar också varför kunskap kring XFS kan vara nyckeln när man bedömer bankomater. Detta var överlägset den mest tidskrävande delen av minaförberedelser, inte minst eftersom XFS vanligtvis är resultatet av en egenutvecklad utveckling av ATM-tillverkaren och involverade mycket dokumentation.

Pentest av tillvägagångssätt

Det är självklart att ens förberedelser beror på det faktiska tillvägagångssättet som kommer att följas under den aktiva delen av testningen. Vad jag menar är att om man ska genomföra ett white-box penetrationstest, så är ett test av tillvägagångssättet ett måste. Om du istället är i ett grått / svart-box område så är det upp till dig att avgöra, beroende på om du tror att du kommer att lyckas få tillgång till antingen den ordinarie ATM-applikationen eller operativsystemet.

Man inser snabbt att man bör behandla bankomater som vilken enhet som helst som är ansluten till ett nätverk. Därför kommer i de flesta fall en penetrationstestare troligtvis inte att tvingas arbeta utanför sin vanliga komfortzon. Detta betyder dock inte att det är lätt att bedöma bankomater. Bankomater har särskilda hotmodeller som man måste vara medveten om!

Network Traffic Sniffing

Bortsett från att försöka bryta sig in i systemet via credentials brute forcing vid detekterad inloggningspunkt och försöka utnyttja eventuella opatchade eller osäkert konfigurerade nätverks-tjänster, kan en annan bred uppsättning av testaktiviteter utföras som avgörs genom en inspektion av ’sniffed’ nätverkstrafik (om och när det finns möjlighet att göra det).

De som är bekanta med nätverkstrafikanalyser kommer att veta vilken utmaning en sådan fas kan vara, särskilt när det finns massor av (nästan aldrig självförklarande) anslutningar till och från miljön. Att sätta all trafik i ett sorterat och förståeligt format kan vara svårt och innebära många ovanliga proprietära protokoll. Det kommer emellertid att ge massor av användbar information som kan förlänga räckvidden av en pentesters checklista. Vi har till exempel bara ett sätt för att bestämma huruvida svagt krypterad eller till och med vanlig textkommunikation kan överföra möjliga kritiska eller känsliga data.

Även om många kan betrakta det som en del av en tråkig testfas, har jag faktiskt fått några av de mest intressanta resultaten under ett sådant skede! Om man tittar på genererad nätverkstrafik avslöjar man vad som händer bakom kulisserna och kan både bekräfta den typ av fynd som upptäckts i tidigare (mer aktiva) faser och samtidigt indirekt gissa andra system- och programkonfigurationer som inte kunde inspekteras direkt.

Försvar i djupet

Det var i ett sådant skede, tack vare den kunskap som samlats in genom analys av nätverkstrafik, som en intern nätverk/applikations pentest förvandlades till en mer proaktiv säkerhetsrådgivning. Jag fokuserade på själva ATM-systemet och hjälpte min tekniska kontaktperson att definiera en uppsättning skräddarsydda patchpaket som var inställda för att uppnå följande säkerhetsmål:

  • Aktivera bara nödvändiga system- och nätverkstjänster och inaktivera allt annat
  • Förhindra att ATM-applikationen kopplas till något nätverksgränssnitt
  • Härda nödvändiga tjänster och operativsystem enligt de mest relevanta accepterade konfigurationsstandarderna
  • Förhindra direkt inkommande tillgång till nödvändiga tjänster genom en kombination av både lokala och perimeter FW-policyer
  • Revidera kryptering av alla klientkomponenter så att endast bästa möjliga chiffer och protokoll aktiveras (om och när möjligt, naturligtvis, kompatibelt med vad de olika server endpoints faktiskt hanterar)
  • Tillåt aldrig något textutbyte mellan klient- och server-endpoints, inte ens för mindre tillbehörstjänster

Ett lyckligt slut

Genom att införa alla de ovannämnda delarna på en och samma gång, och tillfoga några andra ad-hoc-säkerhetsmekanismer, såsom IP-baserade anslutningsregler till server endpoints med tvåvägs certifikatvalidering, blev den nätverksrelaterade ytan för exponering av alla in-scope-bankomater effektivt reducerad.

Slutsats

Det är inte en lätt uppgift att beskriva ett så omfattande jobb i ett inlägg och jag kan av uppenbara skäl inte avslöja för många detaljer. Annars skulle det här varit en mer tydlig teknisk handledning.

En sak är säker och det är att det är nästan omöjligt att uppfylla de förväntade säkerhetsmålen utan att först att förstå målens natur och övergripande sammanhang, särskilt när de är så ovanliga. Därför bör man allokera tillräckligt med tid för att studera, läsa dokumentation, googla runt och samla på sig så mycket kunskap som möjligt. Och man bör fråga alla möjliga frågor – ju mer kunskap man har ju effektivare blir testerna.

Avslutningsvis vill jag hänvisa till en resurs som hjälpte mig att ta fram en skräddarsydd checklista, PCI ATM Security Guidelines (särskilt kapitel B), det är ett riktigt inspirerande dokument vid en säkerhetsbedömning av detta slag.

  • 24 Solutions AB
  • Smedjegatan 2C
  • SE-13154 Nacka, Sweden
  • +46 (0)8 535 24 100
  • info@24solutions.com