Soft Token Cloning Attacks and Mitigations
Two-factor authentication (2FA) is a technology that authenticates users by means of two different factors. Soft token apps for Android and iOS are modern implementations of the second factor. Many soft token products consider the mobile operating system as trusted, but provide little additional protection of the secret data in case the default containerization mechanisms are broken. Unfortunately, an increase in mobile banking Trojans and root malware is expected in the coming years. When the victim's device is rooted, soft token apps that don't implement additional protections are exposed to (remote) cloning attacks. I have demonstrated similar attacks at HITB GSEC on VASCO DIGIPASS and RSA SecurID, and described the technical process in an exhaustive paper.
To prevent these attacks, we recommend the following mitigation strategies:
Activate The PIN Feature
One defense against the attacks shown in this paper is to securing the data with a PIN code. The generated OTPs should be directly dependant on the user's PIN. For example, RSA SecurID generates the OTP using five rounds of AES, and the user's PIN is used as a part of the last round key (if no PIN is set, the default value of "0000" is used). An adversary stealing the config data from the phone but lacking the PIN will be unable generate valid OTPs (or, to be exact, he'll have a 3-in-10000 chance to guess the correct PIN before the account is locked).
In an Enterprise scenario, PIN mode should be enforced for all users. This is usually done on the authentication server or administrative interface provided by the vendor. For RSA SecurId, activating PIN mode is described in the Best Practices for RSA SecurID Software Tokens.
The second takeaway is a more general one: If you use your smartphone as a 2FA token, try to prevent getting compromised by root malware. As a regular user, don’t log into web-banking from the same rooted Android phone you use browsing shady porn sites. Be aware that sideloading cracked APKs or opening suspect attachments can open the phone up for attack. Enterprise scenario, mobile security policies and controls should be deployed to minimize the risk of a compromise.
Better Protection for Sensitive Apps
While perfect software protection doesn't exist, there are in fact measures vendors can implement to deter attackers. Strong obfuscation, anti-tampering and device binding can make the cloning process so difficult that it can become infeasible for most attackers. Vendors may also leverage the short release cycles of mobile apps to make protections more dynamic, causing additional, continuous effort for the reverse engineer.
We'll be addressing this topic in the upcoming OWASP Mobile Security Testing Guide in the form of two test categories: Defense-in-Depth (DID) and Resiliency Against Reverse Engineering (RARE). If you want to join this effort, please let us know on the OWASP Mobile Security Project mailing list.
About the Author
Bernhard Mueller is a full-stack hacker, security researcher, and winner of BlackHat's Pwnie Award.
Follow him on Twitter: @muellerberndt