Extracting Secrets from a Mobile App Code
When I tried to search in the JAVA SOURCE, I could find these variables (CONSUMER_KEY/CONSUMER_SECRET), but not the original extracted strings. So, I presume that they are byte-coded and MobSF is extracting real data somehow from the code.
- Where this information (key and secret pair) is being saved in my APK? It could being saved as bytecode?
Secrets aren't always hardcoded in the Java/Kotlin code, they can also be found at:
strings.xmlAndroidManifest.xml- app
build.gradle
- In
C native code through the use of JNI/NDK
I wrote a series of articles on Mobile API Security and you can read about the several approaches to hide and extract secrets in the article How to Extract an API key from a Mobile App with Static Binary Analysis:
The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.
During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.
In this article I also use MobSF framework to extract the secrets that were hidden in several ways, except for the secret hidden with JNI/NDK, but this one can be easily extracted when the secret has a known prefix (some big names use prefixes in their secrets). If this approach doesn't work then an attacker will simply perform a MitM attack to steal the secret, even when certificate pinning is being used, as I show on the article How to Bypass Certificate Pinning with Frida on an Android App:
Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
Possible Solutions to Protect Secrets in a Mobile App
- What's the best approach to protect this information and avoid its exposure on a reverse code analysis? hide/obfuscate ??
Hiding the secrets in the code, even within C native code it will be not enough, because they can then be extracted with a MitM attack, as a mentioned in the previous section and linked to the article that shows you how to do it.
Obfuscating code only serves to protect intellectual property, the business logic. Secrets cannot be obfuscated, but you may store them encrypted in the code, and if so then the decryption keys will need to be somewhere in the code, thus we circle back to the same problem. Also at runtime an attacker can use Frida to manipulate your code and hook into functions to extract its return values, like secrets, decryption keys, etc.. If you read the article I linked above you saw how Frida is very powerful and simply to use.
I will recommend you to read my accepted answer to the question How to use an API from my mobile app without someone stealing the token where the Runtime Secrets Protection seems your best option.
In a nutshell you will have the secret stored in the cloud and have it delivered just-in-time of being used to your mobile app, but only if the same is not being under attack, running on a root or jaill broken device, isn't attached to a debugger or running in an emulator.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
