Omgaan met ‘overlay’ aanvallen: omarmen van ingebouwde beveiliging om mobiel gebruik te beschermen

RASP2FA

De groei van de mobiele technologie en het toegenomen aandeel van cybersecurity hebben het afgelopen jaar het nieuws gedomineerd. Tegelijkertijd zijn overlay-aanvallen een van de grootste bedreigingen die we waarnemen tegen mobiele apparaten. Door social engineering te combineren met inherente zwakke punten in de beveiliging die in mobiele apps zijn gevonden, maken deze aanvallen misbruik van gebruikers om ze te verleiden gevoelige gegevens te delen. In het verleden werden deze aanvallen alleen in Rusland gezien, maar we hebben de eerste voorbeelden in Europa gezien, zoals de MazarBot Android malware, en in de VS zijn er waarschijnlijk heel wat meer.

Hoe werkt het dan? Wat kan er aan gedaan worden? Wat kunnen organisaties en financiële instellingen doen om te voorkomen dat ze het slachtoffer worden van deze kwaadaardige aanvallen?

Eerst en vooral, het goed begrijpen van de dreiging en wat deze dreiging inhoudt voor mobiele bankapplicaties. In de meeste gevallen neemt overlay malware de vorm aan van een trojan en wordt gedownload als een zogenaamd legitieme toepassing van een officiële website of app store. Deze malware kan ook worden geïnstalleerd door drive-by downloads, wat betekent dat een gebruiker alleen op een bepaalde webpagina hoeft te staan om gecompromitteerd te worden. De malware ligt dan sluimerend op geïnfecteerde apparaten te wachten tot een gebruiker een bankapplicatie opent.

Zodra dit gebeurt, duwt de malware de legitieme app naar de achtergrond, iets wat de meeste apps zelf niet als ongebruikelijk zouden herkennen. Met andere woorden, de app zou niet weten dat hij naar de achtergrond is geduwd en blijft normaal functioneren, waarbij gebruikersinputs worden geaccepteerd, ook al is de app overgenomen door de malware. Tegelijkertijd creëert deze een venster dat de look en feel van de getroffen app nabootst. De gebruiker gaat er dus in feite vanuit dat hij nog steeds interacteert met zijn app voor mobiel bankieren.

Omdat de gebruiker niet beter weer, voert hij gevoelige gegevens in terwijl hij de bankapp gebruikt. Dit kan van alles zijn, wachtwoorden, codes en financiële details. Deze informatie wordt vervolgens door de malware gestolen en tot overmaat van ramp worden de gegevens zodanig gewijzigd dat de gebruiker onbewust transacties verstuurt naar de criminelen achter de malware. Runtime applicatie zelfbescherming is dan ook van cruciaal belang voor mobiele app beveiliging. 

Geografische grenzen overschrijden: BankBot

Een recent voorbeeld van deze trojan malware is BankBot. Terwijl oudere steekproeven van BankBot zich voornamelijk richtten op Russische financiële instellingen, kwam het Nederlandse bedrijf Securify in april 2017 een nieuwe steekproeftrekking van de malware tegen, waaruit bleek dat BankBot zich ook richtte op Europese en Amerikaanse banken.

Nieuwere iteraties waren gericht op ten minste 420 banken in landen als Duitsland, Frankrijk, Oostenrijk, Nederland, Turkije en de Verenigde Staten. BankBot, eerst vermomd als weersvoorspellingstoepassing en vervolgens als verschillende video-apps, kan worden gedownload van Google Play en misleidt gebruikers door gebruikersnamen, wachtwoorden, pincodes, kaartgegevens op te geven en sms-tekstberichten te onderscheppen.

Dit betekent dat het sms-berichten kan onderscheppen dat door bankapps wordt verzonden om betalingen te autoriseren. Helaas voor de gebruiker, is het pas wanneer hun saldo begint te dalen, en dus transacties worden omgeleid naar criminele rekeningen, dat ze beseffen dat er iets mis is.

Verantwoordelijkheid nemen: ontwikkelaars of leveranciers?

Dus wie is verantwoordelijk voor de bescherming tegen mobiele overlay-aanvallen? Is het de app-ontwikkelaar of de app-provider? Idealiter zouden ze moeten samenwerken, wat ervoor zorgt dat als cybercriminelen één specifieke zwakte van een app uitbuiten, het niet genoeg is om de gebruiker te compromitteren.

De bankapplicatie zelf moet voorzien zijn van een beveiliging die detecteert wanneer de app naar de achtergrond is geduwd en voorkomt dat de gebruiker gevoelige gegevens kan invoeren. Echter, malware ontwikkelt zich, dus er is altijd een kans onbekende zwakke plekken in het platform te benutten. Dat is waar de gezamenlijke inspanning van zowel ontwikkelaars als providers steeds belangrijker wordt.

De oplossing: RASP & 2FA

De beste aanpak is de geavanceerde Runtime Application Self-Protection, die meerlagige beveiliging direct in de mobiele apps integreert. Dus in plaats van slechts één laag beveiliging te hebben om door te dringen, zouden hackers tal van lagen moeten compromitteren die moeilijk te doorbreken zijn om mee te beginnen.

RASP houdt ook rekening met gedrag en specifieke codes, wat betekent dat het meer mogelijkheden heeft om overlapaanvallen te voorkomen. Om echt effectief te zijn, zou de gekozen RASP-oplossing echter geen bescherming moeten bieden tegen specifieke malwarevoorbeelden (bijvoorbeeld de nieuwste versie van de BankBot malware), maar in plaats daarvan tegen meerdere malwarefamilies, zoals BankBot, svpeng en Marcher. Veel malwarefamilies gebruiken soortgelijke technieken om overlays te creëren, zodat generieke RASP-oplossingen meer dan voldoende bescherming bieden.

Veel malwarefamilies gebruiken soortgelijke technieken om overlays te creëren, zodat generieke RASP-oplossingen meer dan voldoende bescherming bieden.

Als dit dan wordt gecombineerd met twee-factor authenticatie, zelfs als een hacker toch op een onrechtmatige wijze toegang tot gebruikersgegevens krijgt, heeft het geen zin omdat ze dan een tweede stukje informatie nodig hebben. Dit kan van alles zijn, van een eenmalige code, het bezit van een fysiek apparaat, biometrische authenticatie, enzovoort.

Blijkbaar bestaat de technologie om overlapaanvallen te voorkomen al, maar de vraag wie de verantwoordelijkheid op zich zal nemen om ervoor te zorgen dat alles samenwerkt, blijft onbeantwoord. Er valt veel te winnen bij het integreren van applicatiebeveiliging, twee-factor authenticatie en elke andere oplossing die het vertrouwen en de gemoedsrust van gebruikers garandeert. Speciaal voor financiële instellingen die verplicht zijn klantgegevens en -activa te beschermen. Als je kijkt naar de moeite die deze organisaties doen om zeker te stellen dat hun apps echt veilig zijn, zouden deze apps dan niet zo veilig moeten zijn als ze zeggen.

Frederik Mennes, Senior Manager Market & Security Strategy, OneSpan Security Competence Center