3 Risks of Insecure Mobile SDKs & How to Mitigate Them

Written by Brian Adam Pratama

Mobile SDKs (Software Development Kits) provide developers with pre-built tools, code, resources, and libraries they need to add features and capabilities to their Android and iOS applications. Instead of building from scratch common or highly specialized functionalities, such as analytics, ad mediation/attribution, audio/video/image processing, socials, and user authentication, they can be easily integrated into the applications through SDKs to speed up the time to market. On average, a mobile application uses about 30 SDKs with 90% of code sourced from third parties , but this number can be higher depending on the app’s complexity and functionality.

The widespread use of mobile SDKs requires not only mobile application developers to vet the third-party SDKs they use but also demands SDK developers to ensure the security of their SDKs. This blog explores the potential risks of insecure SDKs and what developers can do to mitigate them.

Key takeaways:

• Without strong code protection and security hygiene, threat actors could understand and tamper with insecure mobile SDK’s internal logic to steal the embedded IP/business logic.
• One security vulnerability in a mobile SDK could result in a large-scale breach impacting all mobile apps that use it. This could ultimately lead to reputation damage, loss of business, non-compliance, and even criminal lawsuits.
• Compiler-based code hardening and runtime protection tools like DexGuard and iXGuard enable SDK developers to safeguard against tampering and reverse engineering attacks by interweaving layers of polymorphic security controls inside the SDK code.

Risk #1: Unauthorized modification & IP theft

Depending on the use case, industry, and regulations, publishers apply varying levels of security to their mobile apps . This makes it impractical or even impossible for mobile SDK developers to ensure the security of their software solely by relying on the security of the app publisher.

Without sufficient code hygiene and protection against tampering and reverse engineering, threat actors could decompile or disassemble the mobile app to expose the embedded mobile SDK’s internal logic, gain insights into its functionality, and modify its behavior. For example, an Ad mediation SDK that is vulnerable to tampering and reverse engineering would allow threat actors to inspect how the algorithm works and allow them to inflate the number of ads shown as well as clicks to earn more ad revenue. Attackers could also steal the business logic/algorithm/embedded IP to be cloned or sold, disrupting the SDK developer’s business operations and eroding competitive advantage. With close to 90% of organizations experiencing mobile app security incidents throughout 2023, mobile SDK developers should prioritize security in their development process.

Risk #2: Large-scale breach

As mobile SDKs are often utilized in multiple applications with thousands, if not millions, of end-users, they provide an extremely lucrative attack vector for threat actors. One security breach on the SDK level could potentially affect all applications that use it. One notable example of this is a popular file-sharing service provider’s Android SDK that was utilized by ± 6,000 applications on the Google Play store. A severe vulnerability ( CVE-2014–8889) in the SDK was identified that allowed remote attackers to obtain sensitive information via crafted malware or a drive-by-download attack. While the SDK developer was able to act quickly and patch this vulnerability before it caused damage, this case highlights the scale of impact an insecure SDK can have, and the importance of security testing throughout the development process in minimizing this risk.

The consequences could be more severe for mobile SDKs that provide critical functionalities. For example, Know Your Customer (KYC) SDKs are widely used by financial services organizations in their mobile banking apps. In 2023, a security research team discovered that hackers were able to bypass mobile KYC verification flows of popular neobank and crypto wallets using tools such as emulators, rooted or jailbroken devices, and hooking frameworks. This security vulnerability allows threat actors to create fraudulent banking accounts on banking applications that utilize the SDK to commit financial crimes. Consequently, the SDK developer could be held responsible for damages caused by these security breaches. Therefore, SDK developers should ensure that threat actors cannot tamper or reverse engineer with the SDK while maintaining the integrity of the environment it runs on.

Risk #3: App store policy, standards, and regulatory non-compliance

Another risk that is associated with deprioritized mobile SDK security is the failure to comply with the app store policies, standards, as well as regulatory requirements. For instance, Android and iOS apps containing insecure SDKs could be rejected from Google Play Store and Apple App Store. Consequently, this could result in delayed time-to-market for the mobile app publishers, which could lead to a loss of trust and business for the SDK developer. Even when the application passes the app store’s vetting process, any unaddressed security vulnerabilities could result in security breaches which, depending on the severity, could lead to the mobile application being removed from the app store impacting revenue and brand reputation as well as potential lawsuits for the SDK developer.

Additionally, the lack of proper code protection and strong security hygiene will make it challenging for SDK developers to comply with industry-specific security requirements. For example, SDK developers who support digital payment processing capabilities will need to comply with the Payment Card Industry (PCI) 3DS Security Standard. Specifically, SDK developers are required to ensure that their SDK cannot be tampered with or operated on a rooted or jailbroken device, and when a debugger is attached.

The role of code hardening & runtime protection

Applying different code hardening techniques (i.e. obfuscation, encryption) to your mobile SDK during development will make it significantly harder for attackers to analyze your code statically. This first line of defense will render your code illegible — while maintaining its full functionality and performance — preventing malicious actors attempting to decompile the mobile app from interpreting your SDK’s internal logic.

Detecting runtime integrity violations using runtime application self-protection (RASP) will prevent threat actors from being able to tamper with and modify the behavior of your SDKs at runtime. These static and dynamic attack defenses can be achieved using SDK code protection tools like Guardsquare’s DexGuard and iXGuard. Thanks to its compiler-based approach, these tools interweave the security controls throughout your SDK, transforming the code into a uniformly obfuscated “haystack”. Additionally, this approach allows you to automatically “ reset the clock “ on the attackers by ensuring the protections are applied uniquely with each release.

“Guardsquare has made it harder to break or modify our SDK, without affecting the performance.” — Product Manager, leading US mobile payment app SDK Company

Automated security testing for better security hygiene

On top of code protection techniques, SDK developers should also consider incorporating automated mobile-specific security testing throughout the development process, for a more robust security posture. Tools like AppSweep by Guardsquare, provide an efficient way to integrate this activity within the SDLC and DevOps workflows, allowing your team to detect and act on the security issues and dependencies frequently in a cost-effective way. You can scan your SDK now for free with AppSweep.

Need help securing your Android or iOS SDK? Connect with our experts.

Originally published at https://www.guardsquare.com on August 20, 2024.