The growth of mobile technology and the increased importance of cybersecurity have dominated news cycles in the past year. At the same time, one of the biggest threats we’re seeing against mobile are overlay attacks - combining social engineering with inherent security weaknesses found in mobile apps, these attacks take advantage of users to trick them into sharing sensitive data.
In the past, these attacks were only spotted in Russia, but we’ve seen the first examples in Europe, such as the MazarBot Android malware, and the US, and there are likely to be more.
So how does it work? What can be done about it? What can organizations and financial institutions do to guard against becoming victims of this malicious attacks?
Understanding the threat and what it means for mobile banking apps
In the majority of cases, overlay malware takes the form of a trojan, and is downloaded as a supposedly legitimate application from a legitimate website or app store. They can also be installed by drive-by downloads, which means a user would only need to be on a certain webpage to be compromised.
The malware lies dormant on infected devices, waiting until a user opens up a banking application. Once this happens, the malware pushes the legitimate app to the background, something most apps would not detect as unusual by themselves. In other words, the app wouldn’t know that it’s been pushed to the background and would keep on functioning normally, accepting user inputs, even though a human couldn’t possibly operate the app.
Simultaneously, the malware creates a window that mimics the look and feel of the app that’s been affected. So, for all intents and purposes, the user would assume they were still interacting with their mobile banking app.
Because the user is none the wiser, they’ll proceed to enter sensitive data while using the banking app as normal. This could be anything from passwords, codes, and financial details. This information is then stolen by the malware, and to make matters worse, data is altered so that the user unknowingly sends transactions to the criminals behind the malware.
Crossing geographical borders: BankBot
A recent example of this trojan malware is BankBot. While older samples of BankBot mainly targeted Russian financial institutions, in April 2017 the Dutch company Securify came across a new sample of the malware, showing that BankBot was targeting European and American banks as well.
Newer iterations have targeted at least 420 banks in countries such as Germany, France, Austria, the Netherlands, Turkey and the United States. BankBot, first disguised as a weather forecast application, and then as different video apps, can be downloaded from Google Play and tricks users into giving up usernames, passwords, pin codes, card details, as well as intercepting SMS text messages.
This means it can intercept the text message sent by banking apps to authorize payments. Unfortunately for the user, it’s only when their balances start dropping, or transactions are redirected to criminal accounts, that they realize something’s wrong.
Taking responsibility: developers or providers?
So who’s responsible for protecting against mobile overlay attacks? Is it the app developer or the app provider? Ideally, they should work together, which would ensure that if cyber-criminals exploit one specific weakness on an app, it’s not enough to compromise the user.
The banking application itself should have security built in that detects when the app has been pushed to the background and prevents the user for inputting any details that could be sensitive. However, malware evolves, so there’s always potential for unknown platform weaknesses to be exploited, which is where the joint effort of both developers and providers becomes all the more important.
The solution: RASP & 2FA
The best approach is the sophisticated Runtime Application Self-Protection that integrates multi-layered security directly into the mobile apps. So instead of only having one layer of security to break through, hackers would need to compromise numerous layers that are tough to get through to begin with.
RASP also takes into account behavior as well as specific codes, which means it has greater ability to prevent overlay attacks. However, to be truly effective, the RASP solution chosen shouldn’t provide protection against specific malware samples (eg. the latest version of the BankBot malware) but instead against multiple malware families, such as BankBot, svpeng and Marcher. Many malware families use similar techniques to create overlays so generic RASP solutions will provide more than adequate protection.
If this is then combined with two-factor authentication, even if a hacker does obtain user credentials, they’ll be of no use if they then need a second piece of information. This could be anything from a one-time code, possession of a physical device, biometric authentication, and so one.
Evidently, the technology to prevent overlay attacks already exists but the question of who will take on the responsibility of making sure everything works together still remains. There is so much to gain from integrating applications security, two-factor authentication and any other solution that ensures users’ confidence and peace of mind. Especially for financial institutions that have a duty to protect customer data and assets. When you consider the great lengths these organizations go to make assurances that their apps are really safe, shouldn’t these apps be as safe as they say they are?