Mobile apps have become a favorite target for hackers because they are (1) easy to attack (2) have high usage and subscribers (3) handle or store valuable data that can be monetized.
One of the ways hackers attack apps is by targeting a 3rd party component inside the app which they already know is there. Keep in mind that almost all mobile apps contain 3rd party components, such as pre-built libraries and SDKs, which play a critical role in how mobile apps function.
In some recent high profile examples of Rogue SDKs, Facebook recently announced it’s suing analytics firm OneAudience for allegedly paying developers to include an SDK in their mobile apps that secretly stole user data without their permission. Then there’s the Tushu and Twoshu SDKs which infected hundreds of apps downloaded from Google Play, helping fraudsters steal millions of dollars through mobile advertising fraud. Adobe and Twitter have also been recent victims of security breaches that originated from poorly designed or badly implemented SDKs.
And these are just a few examples. This type of fraud and theft happens every single single day, even for the biggest brands and apps in the world.
Reverse Engineering Apps to Commit Ad Fraud
As an app developer, 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 a widely implemented SDK can instantly expose tens of millions of users across every app in which the SDK has been implemented. And those users remain exposed until the SDK is re-implemented to patch the vulnerable code.
So how do lapses like this happen anyway? Rogue SDKs are not born; they are enabled. What I mean by that is SDKs need to be implemented by developers. And there are lots of ways that problems can occur in the wild if the developer doesn’t take specific measures to implement the SDK securely AND to protect the data that the SDK can access. Data breaches can occur through active modification of SDKs or 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 new ways fraudsters are attacking mobile advertising SDKs is through a technique called SDK Spoofing, where hackers modify a mobile SDK inside the app to fake out the mobile attribution process to steal or divert mobile ad revenue.
In order to do this, the hacker reverse engineers the app (thru static or dynamic analysis) to learn how a mobile app or SDK behaves under certain “success” conditions (ie: a transaction that results in a completed purchase, ad click or ad payment). Then they re-create or simulate the success conditions at scale to artificially boost activity, or they modify the app to “attribute’’ the successful transaction or ad payment to themselves.
There are many freely available tools that hackers use to reverse engineer apps to understand their functions, to access source code, or to inject code (Frida, IDA, Hopper just to name a few).
Fraudsters can also use man-in-the-middle attacks, an attack technique where they insert themselves in between a mobile app/user and whatever backend service the app is communicating with. Then they trick the user reveal information that they can go monetize.
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.
Recommendations for mobile app developers
If you 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:
Data Encryption
- Encrypt data at rest stored in the app sandbox as well as in strings, preferences, resource folders. Even data transiently stored in memory can expose information that hackers can use.
- Don’t pass sensitive authentication elements in URLs or response strings unless it’s absolutely required for the app to function, and if so, encrypt that data.
- Encrypt all elements used or derived in authentication, especially those with high degrees of privilege or entitlement such as API Keys and Secrets.
Protect Data in Transit
- Validate CAs, and certificates, implement certificate pinning
- Refresh sessions and tokens regularly.
- Ensure all sessions an updated version of TLS
Code Obfuscation
- 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.
Control Mobile Permissions
- Apply robust permission controls in your app. Avoid over-permissioning by only granting permissions to resources that the 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.
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 mobile security and SDK implementations using a no-code app development platform 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.
Originally published at https://www.programmableweb.com on March 27, 2020.
