November 6, 2020

Mobile Apps and their SDKs

By Himanshu Dwivedi

Data Theorem

Third party SDKs can destroy your mobile app, all unbeknownst to you. Mobile applications, including iOS, Android, and WinMo apps, are built using native code usually written by in-house developer teams; however, a chunk of the code is always sourced from 3rd party commercial SDKs. Leveraging foreign components is very normal for mobile apps, as 100% of all apps have some sort of 3rd-party commercial or open source SDK embedded in the binary. So what is the problem here?

The big issue is that 3rd-party commercial SDKs have FULL access to the app and its data. There is no separation nor sandbox between the app’s internal code and code from the 3rd-party. Once the SDK is included, the SDK *is* the app too, which includes all commercial for-profit SDKs and as well as the two-person developer projects on GitHub. Okay, so yeah, what is the problem here? The problem is that third party SDK have:

#1 Access to the entire app *and* all its data

So… it can read, write, or delete any data located in private storage

#2 Access to the app’s TLS layer

So… iIt can disable TLS for the entire app (to all endpoints, not just the SDK’s)

#3 Access to the parent’s app’s existing permission

             So… it can pull data from the device, including end-user:

1. Contact Lists

2. Geo-Location

3. SMS Logs

4. Photos

5. Camera

6. Microphone

7. [any device permission the parent app has been granted]

An Illustration of the Issue

A quick tangent. Let’s take a quick look at Signal, a popular open source mobile app for end-to-end encrypted communication. Signal has 10+ third party SDKs in its iOS mobile app, which is very normal. One of its SDK is iRate, which prompts you to rate the app on the App Store. Despite all the efforts from the Signal development team, if the iRate developer team “has a bad day”, things could go very wrong for the Signal app, its users, and its data, all at no fault of the Signal developer team. For example, SDKs are known to disable TLS certification valuation for the entire app, transfer user email address to third party servers, and even collect geo-location of the user even when the app is off. If iRate added such code into their SDK, it would have full access to Signal’s user’s data. As a reminder, there is no wrong doing here from the internal development team at Signal, the problem is the  SDK included in the app that has significant security issues with it, which destroys the app without the user’s knowledge or permission.

Okay, how do these issues compare to other classes of attack, within mobile appsec or other platforms? In our opinion, this attack surface is significant, considering the amount of data that can be compromised. To be clear, let’s compare the major attack classes from client/server apps, web apps, and mobile apps altogether, which is shown below. We will compare buffer overflows, SQL Injection, Cross-Site Scripting, and SDKs. 

As shown above, buffer overflows still rule the Win32 world; however, attacks on windows native apps are less and less common (and not as sexy anymore either). SQL Injection still reigns strong for web apps, but notice SDKs actually have stronger impact on data than Cross-Site Scripting. While XSS and SDKs mirror each other in terms of control of data, developer driven, and customer data, SDKs can gather large volumes of data with just one attack, where reflected XSS cannot (persistent could). Furthermore, XSS is always malicious, so whenever you see it, you should get rid it of; however, SDKs are harder as several SDKs are legitimate, not evil at all. An enemy that looks like a friend is much harder to defend against than something know to be evil. 

At this point it should be known that SDKs are a major blind-spot for enterprise security teams, as this emerging attack surface that can destroy a mobile app’s security model within seconds. While traditional appsec teams focus on security flaws within the app, rightfully so, many of them are not aware of this attack surface at all. Appsec teams usually have 1) no idea what commercial/open source SDK is bundled in the app 2) nor do they know which SDKs introduce security issues to the app. 

Kochava SDK (Android)

• Disable TLS Certificate Validation for the entire app

Okay, so where has this happened in the real world? Well, all over the place. To date, Data Theorem, Google, the FTC, and FireEye have published most of the articles on this topic. A few examples below:

Silverpush

• Tracks user habits without information the user

VPon

• Records audio, capture screenshots/videos, collections geo-location, and Contacts

iBackdoor

• iBackdoor was not a legitimate SDK, but rather a purposely built library to steal data. It collected audio, screenshots, geo-location and accessed data in private storage and the keychain

Please note, the four SDKs are not exhaustive, just a small list out of thousands. 

Okay, so the sky is falling, right? NO, the sky is not falling. Data Theorem has dynamically scanned over 25,000 SDKs and like everything else, 80% of them are just fine. 80/20 rule applies here too, where 20% of the SDKs cause all the problems. Many of these SDKs introduce security issues by mistake, while others were purposely built to attack on mobile apps in order to compromise users and their data. Nonetheless, a full list of apps that have security or privacy issues sourced from a third party SDK is listed below:

• https://itunes.apple.com/us/genre/ios/id36?mt=8 

• https://play.google.com/store/apps 

What’s next? There are a few next steps here:

Visibility is Critical

1. Enumerate the commercial SDKs and open source libraries in your app. This will remove the blind spot(s)

• Developers usually have this data as well, but not necessarily in a consolidated list format

• Data Theorem provides this service for free 

2. Testing (and Keep Testing)

Each SDK/library, and each version of it, needs to be evaluated for the following items:

1. What data, if any, does that app pull from the app?

2. What security issues, if any, does the SDK introduce to the app?

3. If the SDK is commercial, what are the privacy terms of the SDK? What security audits have been performed?

4. If the library is open source, who has reviewed the code for security flaws? 

As you can see from the above, this is no easy task. Item number 2 is easy on paper, but hard to implement at scale because it’s continuous and needs to be done for every app, every release. Despite the challenge, it is something that must be done, as an absence of any action could very well lead to the compromise of large volumes of data. Is the SDK issue a hole in your mobile app security program? - Let’s talk. Contact HD@datatheorem.com.