In mobile penetration testing, third-party modules or libraries are often considered out of scope for several reasons, although it’s worth noting that the decision to include or exclude third-party components can vary depending on the specific requirements of the assessment and the agreements between the testing team and the client. These third-party modules, or libraries, come packaged in various file formats tailored to specific programming languages and platforms. For instance, in Java, libraries are often distributed as.jar files, encapsulating compiled bytecode alongside resources and metadata. Similarly, Android libraries adopt the. aar extension, bundling Android-specific resources and dependencies for seamless integration into Android projects. Windows-based systems rely on.dll files, while Unix-based systems favor.so files, both serving as dynamic link libraries dynamically linked to applications at runtime. macOS and iOS ecosystems utilize.dylib files, or. framework directories, containing compiled code, resources, and metadata. In this blog, we will outline a concise methodology for testing mobile SDKs. By following this methodology, security pentesters can uncover vulnerabilities and weaknesses within mobile SDKs, helping developers fortify their apps against potential threats.
The testing involves a great deal of understanding of the SDK and it’s use cases to build various test cases based on its functionality. We will see below how testing is done for the mobile SDK in various phases, explaining various examples and vulnerabilities found in each phase.
Like typical mobile application penetration testing, mobile SDK testing also comprises phases like below:
This involves decompiling the library file, reverse engineering the code to potentially extract source code, and then reviewing the codebase for vulnerabilities. This step may utilize various automated and semi-automated tools like MobSF, JadX, APKtool, Ghidra, DNSpy, etc. to potentially gain access to a source of the library/package. Once the package is decompiled, it is analyzed to discover vulnerabilities, much like static analysis in Mobile application pentest. Some of the common vulnerabilities discovered in this step are below:
(All these individual topics may be covered in a separate blog post.)
This involves traffic interception and inspecting the API or network traffic for vulnerabilities. Analyze the application during runtime to potentially exploit misconfigurations identified in static analysis. Exposure of sensitive data, managing permissions, and interaction of the application with other installed applications.
(All these individual topics may be covered in a separate blog post.)
This involves carefully examining the documentation provided by the SDK developers to understand the recommended implementation practices. By scrutinizing the SDK documentation, security analysts can identify potential pitfalls or misconfigurations that could result in insecure integration. Once these insecure integration methods are identified, steps can be taken to update the documentation, providing clear warnings and guidance to developers on how to implement the SDK securely.
Let’s consider a different scenario involving the initialization of a hypothetical encryption library called “CryptoLibrary,” which provides encryption and decryption functionalities for sensitive data storage in Android applications.
Example:
CryptoLibrary.init(context);
CryptoLibrary.setEncryptionKey("static_key_insecure_here");
In this insecure example, the setEncryptionKey (insecure_key”) method is called during initialization to set the encryption key for the crypto library. However, the key used (insecure_key) is hardcoded directly into the code, which poses a significant security risk.
Secure version:
String encryptionKey = retrieveEncryptionKeyFromSecureStorage();
CryptoLibrary.init(context, encryptionKey);
In the secure example, the encryption key is not hardcoded into the code. Instead, it is retrieved from a secure storage mechanism, such as Android Keystore, during initialization.
In this step, the SDK default initialization is analyzed to discover any vulnerabilities. SDKs often come with default configurations that may not prioritize security or may inadvertently introduce vulnerabilities. The default initialization analysis also involves reviewing the SDK documentation to understand how default settings impact security. Based on the findings of the default initialization analysis, recommendations can be made to developers on how to securely integrate the SDK into their applications. Some of the examples of vulnerabilities identified are:
In conclusion, mobile SDK penetration testing is a critical aspect of ensuring the security of mobile applications. By thoroughly assessing both static and dynamic aspects of SDK integration, security professionals can identify vulnerabilities and weaknesses that could be exploited by malicious actors.
Device Binding to Protect Your Banking and UPI Apps
How Poor Cryptographic Practices Endanger Banking Software Security
Cloud Pentesting 101: What to Expect from a Cloud Penetration Test?