how to prevent MFA Bypass attacks, a more common tool for cybercriminals to exploit mobile apps.

How to Prevent MFA Bypass in Mobile Apps

AlanB
The Startup
Published in
5 min readSep 28, 2020

--

In this blog post, I’ll discuss how to prevent MFA Bypass attacks which are becoming an increasingly more common tool for cybercriminals to compromise iOS and Android apps and steal user data.

Multi-factor authentication (MFA) is one of the most widely recommended best-practices that security experts recommend — to defend against unauthorized access to sensitive systems and data via insecure mobile apps. It’s alarming, though not terribly surprising, to see that hackers are getting better at defeating security defenses using a variety of sophisticated MFA Bypass methods. They are even using malware, bots, and highly automated tools and techniques to make their attacks more robust, scalable, and ultimately successful — resulting in high-profile successful account takeovers, data theft, and mobile fraud operations, mobile ransom and more. Some recent examples of malware that are turning MFA Bypass into a successful attack vector are Eventbot, Cerberus and Rampant Kitten. The vulnerabilities inherent to MFA were discussed at RSA2019, in the 12 ways to hack MFA session. And Abnormal Security recently published a blog that explains how attackers bypass MFA.

How to Prevent MFA Bypass Attack Methods

Protecting mobile apps against MFA bypass requires a multi-layered approach because cybercriminals use ‘blended’ techniques to attack mobile apps and bypass MFA. These techniques exploit multiple attack vectors and use a combination of different attack methods to achieve their goals with increased efficiency, effectiveness, and stealthiness (the latter is achieved by obfuscating attack methods, hiding in normal traffic, and using advanced cloaking technology specifically developed for that very purpose). Because of this, organizations must adopt a mix of cybersecurity measures to counter these sophisticated attacks, using multiple detection and prevention mechanisms and applying them in different locations and at different layers within a mobile app. Keep reading to understand exactly what I mean with this statement.

Below are some common techniques hackers use to Bypass MFA, as well as some key preventative and countermeasures to deal with these sophisticated threats.

Static and Dynamic Analysis

In static and dynamic analysis (both forms of ‘reverse engineering’), hackers often use debuggers and emulators to understand how the MFA provider’s authentication sequence works (as well as other critical functions of a mobile app). Hackers also supplement the information they learn from the app with other important data that they learn from MFA providers who over-expose information about their service in API calls, responses, and headers. That’s precisely how hackers were able to successfully bypass Google Authenticator’s MFA challenge. The hackers studied Google’s authentication sequence to learn how to bypass it, as Google was including artifacts in the header of the OTP (one-time-password) it communicated to the end-user (violating an OWASP Mobile Top 10 risk through overexposure). Hackers exploited that information in multiple ways:

  1. Fingerprint the google service
  2. Piece together the sequence of operations for Google’s 2FA service
  3. Then use this information to pose as the legit user

Recommended Protections: The following mobile app protections would be effective at preventing or making it difficult for attackers to employ reverse engineering methods or tools to gain the necessary information to bypass MFA authentication: Anti-debugging, preventing malicious use of emulators, code obfuscation, scramble/relocate control flows and app logic, strip debug logs and info from your production builds.

Extracting Unencrypted Credential & Authentication information stored inside browsers and mobile apps

Mobile apps often store cookie information unencrypted in shared locations inside the app (app preferences, strings, shared resources provided by the OS. Hackers extract cookies/credentials in a number of ways:

  • Decompiling, disassembling, or simply renaming the app binary to read the code stored inside.
  • Exploiting known CVEs in 3rd party libraries. Oftentimes the 3rd party libraries used by developers when they build mobile apps are not vetted. Hackers know this, and they routinely exploit known security holes and bugs in application code simply by searching through MITRE’s database to figure out if an app uses 3rd party libraries with known vulnerabilities.
  • Cross-site scripting can also be used to extract credentials for mobile apps that use JavaScript-based Webviews.
  • Code injection using a tool like Frida to dynamically inject malicious code into non-native, hybrid and also native apps.

The above attack methods are super easy for non-native apps where you don’t even need to decompile the app, because the source code for non-native apps is typically not compiled into binary code at compile time. It is instead ‘saved-as’ inside the app and zipped in a jar file — which all one needs to do is simply rename the folder and extract the jar file to access the Javascript source code files or java class files.

Recommended Protections: Binary code obfuscation, Non-native code obfuscation, encrypting strings, preferences, and resources, encrypting DEX files, prevent re-use of stale sessions.

MiTM attacks, Fake Certificates, and Old School Phishing Attacks

  • Credentials are also obtained via traditional MiTM attacks, fake proxies, or MiTM combined with Phishing/Screen Overlays to trick users into revealing credentials. These kinds of attacks are often ‘blended’ with attacks that compromise vulnerable certificates or CAs to increase their effectiveness.

Recommended Protections: MiTM attack prevention, Malicious proxy prevention, Certificate pinning, Certificate/CA validation

Exploiting Weak MFA Solutions

  • And finally, there are certain types of MFA that are inherently weak (eg: SMS based MFA where OTPs are sent via a single channel). Most security-centric organizations do not consider SMS-based 2FA or MFA to be secure due to the inherent design flaws. NIST has several advisories against such approaches.

Recommended Protections: Use an ‘in-app’ approach to MFA (such as using Push-notifications vs SMS, or supplementing with biometric security such as using in-app FaceID/TouchID/fingerprint on a per-app basis. That way if the device pincode or the MFA solution is compromised, all is not lost since you still have an in-app defense based on hard-to-fool biometric characteristics.

Recommendations for Mobile App Developers

My number one recommendation is to stop using MFA as your sole protection against unauthorized access. MFA remains an important weapon in your arsenal of protection measures, but it’s not a panacea, and clever hackers are getting around it. So to protect your app against MFA bypass, you need to build a comprehensive, multi-faceted layered defense that protects all mobile data, mobile users as well as the app itself.

Thanks for reading. Here’s some great free content: Download the Developers Guide for Mobile App Security and learn what you can do to improve the security of your mobile apps and protect your mobile businesses and users immediately —all without coding.

That’s it for today. Hope you enjoyed the post. Drop me a line if you have any feedback. And stay safe!

--

--

AlanB
The Startup

ALAN BAVOSA is VP of Security Products at Appdome, a no-code cyber defense automation platform for mobile apps.