Applications themselves should have security built in that detects that the application is being pushed to the background says Giovanni Verhaeghe. Then any user input should be blocked and the placing overlay eliminated
Two-factor authentication has long been seen as a sure-fire way to thwart cyber-criminals from exploiting the weaknesses of mobile banking, whether they are technical or human. But there are concerns centred around a new form of attack that been making the rounds recently, which combines elements of classic social engineering with exploitation of inherent security weaknesses found in mobile banking apps themselves.
Users of banking apps worldwide have been targets of an especially insidious method of attack for several years now. The so-called Overlay malware detects when a user opens a banking app, and pushes the app to the background while presenting an environment that is almost identical to the real deal. Any data the user enters – such as passwords and codes – is stolen, and transaction data is altered so the user unwittingly sends transactions to the criminals behind the malware. In most cases, overlay malware takes the form of a trojan, a seemingly legitimate application downloaded from a legitimate website or app marketplace. The question is, who should be responsible for protecting the apps?; the app developer, or the app provider?, and what can be done to protect against Overlay attacks?
It’s a question that many companies should be asking too, especially in the finance sector. One recent example of such malware targeting them, was BankBot. In the past, this Android-targeting malware has mainly targeted clients of Russia banks, but newer iterations have broadened its geographical scope substantially and taken aim at 420 banks in Germany, France, Austria, the Netherlands, Turkey and the United States. Masquerading as a normal app that could be downloaded from Google Play, BankBot used the overlay attack principle to trick users into giving up usernames, passwords, pin codes and card details, among other things. It can also intercept SMS text messages, a common second factor used by banking apps to authorise payments. The user has no idea something is amiss until it turns out their account has been plundered or payments have been redirected to criminal accounts.
Multiple approaches of attack
BankBot and other overlay attacks basically combine two classic ways cyber-criminals operate. It is partly the result of social engineering, where hackers would dupe users into giving them access to their systems. Like all Trojan malware, the user has no idea he or she is installing something malicious. BankBot, for example, was at first disguised as a weather forecast application and later as different video apps, both downloadable on Google’s Play Store for a period before being discovered and flagged. After installation, it demanded administration rights from the user. While that should be a tell-tale warning sign (weather apps don’t need admin rights to function normally), many users just allow it to proceed. And, finally, the overlay itself is a way of duping users into doing things they would not actually want to do, such as sharing banking details or even give the green light for transactions they do not mean to do.
But overlay malware does not just exploit user inexperience or lack of knowledge. They also work because of weaknesses inherent in the mobile platform itself and the apps running on it. They can be installed by drive-by downloads for example, which means that the user only needs to open a certain webpage to be compromised. More typically for overlay malware, they push banking apps to run in the background, something most apps by themselves do not detect. The app keeps on functioning normally and accepts user inputs, even when there technically cannot be a human operating the app as it runs in the background; hence the earlier question about where the responsibility lies for the overall security of the app.
The rise of overlay attacks has increased the need for multi-layer protection, since even robust two-factor authentication cannot protect Android devices on its own. Arguably, this is where the responsibility of the institutions providing the apps comes into play. The banking application itself should also have some form of security built in that detects that the application is being pushed to the background. The standard reaction should then be that any user input is blocked and that the placing of the overlay is eliminated, regardless of which specific application (or, rather, malware) is placing it. Overlay attacks should, therefore, be prevented as a security method, rather than as part of blocking a specific piece of malware. New malware appears all the time and BankBot proves it is neither the first nor the last that will try to use that method. In the future, more enhanced malware may, for example, exploit hitherto unknown platform weaknesses. That’s why app developers and app providers are encouraged to work together, so they can ensure that if cyber-criminals exploit just one specific weakness on an app, it is not enough to compromise the user.
Of course, two-factor authentication still remains a vital part of the user’s defences. Cyber-criminals that manage to steal credentials or even card details, for example, will have very little use for them if they also need the possession of a physical device or a cryptographic key, whether it is in the form of hardware-based or software-based tokens that receive a new code every time the user wants to perform a potentially sensitive action.
A much more sophisticated approach to this security can be found in the form of Runtime Application Self-Protection technology (RASP). This is better suited to that task as it puts in place multi-layered security by integrating the security directly into the mobile apps. Therefore, instead of having to breach just one layer of security to compromise a device, a hacker would now have to breach through multiple layers that are tough to break down. Additionally, RASP detects behaviour rather than specific codes, giving it a greater ability to stop overlay attacks dead in their tracks.
If then the technology exists to prevent overlay attacks, the questions remain, who will take up the initiative to ensure it’s integrated? Surely, there’s a commercial benefit for app developers to state that their apps integrate application security, two-factor authentication and electronic signing. And, equally, shouldn’t app providers – especially in the financial services sector that has a duty to protect customer data and assets – that go to great lengths to make assurances that their apps are safe, do so on the basis that their apps really are?
This article was originally posted on: SC Magazine UK