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.

Pre-Requisites for Mobile SDK Security:

• Obtain the Mobile SDK file (e.g. ,.jar,.aar ,.so,.dll files).
• Acquire a demo application already integrated with the SDK.
• Ensure access to testing accounts and the API key required for configuring the SDK within the application.
• Mobile SDK integration documentation.
• Source Code (if required)

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:

1. Static Analysis
2. Dynamic Analysis
3. Insecure Integration of the SDK
4. Default security of SDK

Static Analysis:

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:

1. Hardcoded Secrets
2. Insecure Deeplinks
3. Insecure Webviews
4. Insecure application components (like exported activity, content provider, etc)
5. Client-side SQL Injection
6. Excessive permissions
7. Insecure Storage
8. Insecure logging of sensitive data
9. and many more

(All these individual topics may be covered in a separate blog post.)

Dynamic Analysis:

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.

1. Testing Web Services and REST API for OWASP vulnerabilities
2. Root detection
3. SSL/Certificate Pinning Bypass
4. Runtime Analysis
5. Bypass Static and Runtime protections
6. Testing Resiliency against Various Defenses
7. Test for Cryptography

(All these individual topics may be covered in a separate blog post.)

Insecure Integration of SDK:

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.

Default security of SDK

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:

1. Default Encryption Settings: Ensures the default initialization of the SDK uses strong encryption algorithms.
2. Debug mode is enabled by Default
3. Use of Insecure channel by default
4. SDK Requests overly broad permissions by default, which are not required by the SDK
5. The documentation does not highlight the potential security implications of default settings.

Conclusion:

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.

Recommended Reading

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?

The post Mobile SDK Security: Effective Testing Methodology appeared first on WeSecureApp :: Securing Offensively.

*** This is a Security Bloggers Network syndicated blog from WeSecureApp :: Securing Offensively authored by Siva Krishna Samireddy. Read the original post at: https://wesecureapp.com/blog/mobile-sdk-security-effective-testing-methodology/