Facebook recently announced it’s suing analytics firm OneAudience for allegedly paying developers to include a rogue software development kit ( SDK) in their mobile apps that siphoned off users’ data without their permission. And the Tushu and Twoshu SDKs were found to have infected hundreds of apps with millions of downloads on Google Play, helping fraudsters siphon off large sums of money via mobile ad-fraud.
These recent events prove vigilance is required by developers to guard against rogue SDKs in their mobile apps.
Risks mount for rogue SDKs
There are thousands of mobile SDKs (16,842 according to ProgrammableWeb). Every mobile app contains SDKs, as they play a critical role in how apps Function. According to SDK analytics firm SafeDK, the average number of SDKs per app is 18.2.
As an app-maker, it’s impossible to ignore the importance of security in SDK implementations. Mobile SDKs are at the intersection where user privacy, data protection, and app security all converge. A security breach in any of these SDKs could have a significant negative impact on a corporation’s brand and bottom line overnight.
Rogue SDKs are not born; they are enabled. And this enablement is multi-faceted and nuanced: it can be intentional or accidental, malicious or non-malicious. It can occur through willful and deliberate action, such as developers who specifically instrument an SDK to actively collect personally identifiable information (PII) about users without permission. Or it can be enabled through carelessness, inaction or neglect, such as app makers who ignore vulnerabilities in their apps, store user data in clear-text, or leave their mobile app Source Code exposed in the wild.
One of the key ways fraudsters conduct SDK Spoofing is via reverse engineering, an attack technique used to simulate fake app installs and fake ad-clicks (for the purpose of stealing ad revenue). Hackers run apps through freely available de-compilers, fuzzers, and debuggers so they can deconstruct the source code (which sits unprotected in many apps on Google Play and Apple’s App Store, by the way). The main goal of reverse engineering in ad-fraud is to learn how a mobile app or SDK behaves under certain “success” conditions, i.e. a condition which triggers a transaction or ad payment. Fraudsters then recreate the success conditions in a way that “attributes'' the ad-payment to themselves. They often do this by taking control of resources involved in the attribution process, which determines how the ad revenue gets divvied up.
There are many different ways to do this. For example, a developer can build a fake app that imitates the real app, then use automation tools to simulate a bunch of fake ad-clicks to an SDK. Fraudsters can also use man-in-the-middle attacks to insert themselves in the middle of the transaction by hijacking a user’s session, stealing or sniffing cookies, modifying tokens or SAML insertions to take-over an account and effectively assume the identity of the real user.
Recommendations for mobile app developers
Mobile SDKs handle highly sensitive data and process many critical transactions, which makes them a high-value target for hackers, fraudsters and nation-states. At a minimum, most SDKs will need to authenticate to the app’s backend, and they often pass highly-sensitive user information (PII) or connect to critical systems of record with a highly-privileged level of access. Tokens are passed back and forth and stored in shared storage areas where other SDKs lurk, some of which, like advertising SDKs, are ravenous in their thirst for user data.
Given how vital SDKs are to an app, developers can’t rely on SDK providers to regulate themselves, especially when collecting and analyzing vast amounts of user detail is often a fundamental part of their business model.
Don’t want the bad actors and SDKs to ‘go rogue’ on your app? Don’t make it easy for them. Secure your app, control your SDK implementation and make app security a part of your Continuous Integration / continuous development ( CI/CD) workflow.
Here are some key best-practices app developers can follow to protect mobile apps against rogue SDKs:
- Protect the data stored inside your mobile apps and transmitted via your app’s APIs to prevent rouge SDKs (or the bad actors which install/control such SDKs) from stealing user credentials or other sensitive information. There are several way to accomplish this:
- Encrypt sensitive data stored in the app and in memory, including in-app preferences, strings, resources, in-app secrets.
- Do not pass sensitive Authentication elements in URLs or response strings.
- Encrypt all elements used or derived in authentication, especially those with high degrees of privilege or entitlement such as API Keys and API Secrets.
- Validate CAs, and certificates, implement certificate pinning, refresh sessions and tokens regularly .
- Obfuscate your code and app logic, including obfuscation of any 3rd party components, libraries or SDKs you bring into your app.
- Isolate sensitive authentication information in the app. Many apps store API keys, API secrets, and authentication tokens in a ‘shared storage area’ provided by the underlying mobile OS. This data should be placed in a separate storage area (non-shared storage), where the information is encrypted and not visible to data-hungry SDKs.
- Apply robust permission controls in your app. Avoid over-permissioning by only granting permissions to resources that the SDK or service absolutely needs in order to do its job. Prevent apps from having access to resources and data that they don’t need such as location data, the camera, messages, microphone, contact list and dial pad.
- Include app security and SDK implementations into your CI/CD workflows, by automating the implementation. In doing so, you can ensure that key fraud prevention features — like Rate Limiting, Encrypting API Keys and Secrets, secure cookie handling, device fingerprinting, MFA — are enabled by default.
Eliminate complexity with automation
Mobile security is complex to understand and difficult to implement, and manual implementations exacerbate the problem. In a world of rapid release cycles and continuous integration, SDK and app security are often overlooked because the time required to implement security is usually longer than the time allocated for the app’s release.
Automating the process of SDK implementations would make them more ‘science’ and less ‘art’ by removing human interpretation and subjectivity from the process. It also gets app security out of the direct line of competition with active feature development, where it loses the priority battle every-time. By automating your app security lifecycle, developers make it easy on themselves and their colleagues to do what everyone knows is the right thing to do.