Third party SDKs can undermine the security of your mobile app, all unbeknownst to you. Mobile applications, including iOS, Android, and WinMo apps, are built using native code usually written by developer teams; however, a chunk of the code is always sourced from 3rd party SDKs (commercial or open source). Leveraging external components is very normal for mobile apps, as 99% 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 SDKs have FULL access to the app 's private data, permissions, network connections, TLS sessions, etc. There is no separation nor sandbox between the app’s internal code and the 3rd-party SDK. 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 3rd-party SDKs, an unvetted, uncontrolled, and unknown source, have:
- Access to the entire app *and* all its data
- SDKs can read, write, or delete any data located in private storage
- Access to the app’s TLS layer
- SDKs can disable TLS for the entire app (to all endpoints, not just the SDK’s)
- Access to the parent’s app’s existing permission
- SDKs can pull data from the device, including end-user
- Contact Lists
- Geo-Location
- SMS Logs
- Photos
- Camera
- Microphone
- [any device permission the parent app has been granted]
- SDKs can pull data from the device, including end-user
- Basically, the SDK has access to anything the app has access to
An Illustration of the Issue
Let’s take a quick look at MDLive, a popular medical app that connects doctors with end-users in need of medical assistance. MDLive has 10+ third party SDKs in its iOS mobile app, which is very normal. One of its SDKs is called TestFairy, a popular tool to help developers distribute apps to internal teams, collect logs, solicit user feedback, obtain crash reports, and record videos of end-user activity. These features help developers improve their mobile apps from one release to the next.
- Can you name the security flaw and privacy gap from the feature list above?
Well, it turns out the 3rd Party SDK (TestFairy) has an awesome "Video Recording" feature that has significant security and privacy implications. According to federal courts in the state Florida, the MDLive app was taking screenshots of real end-user activity, which includes all presented data, and sending it to a 3rd party (TestFairy). Well, what actually happened is that the TestFairy SDK was configured to collect screenshots of live user activity (it just looked like MDLive since there is no distinction from the App and its SDKs). Since the MDLive app leverages medical data, this equates to a 3rd party SDK receiving ePHI data of several thousand MDLive users (on another apps, the data could very well be credit card numbers, social security numbers, account balances, etc.).
- So what went wrong here?
MDLive's mobile developers chose a SDK to improve their work flow, which is the right thing to do. Unfortunately, they enabled a feature from the SDK that collects end-user data from live app sessions. Did the security team know that TestFairy was being used? Did the security team know that TestFairy is collecting screenshots with live end-user data and sending it to TestFairy's headquarters, which happened to be in Israel? As a reminder, developer choose a variety of SDKs to enhance their app on an everyday basis, which is nothing new. The problem is that 1 of the 10+ SDKs had a significant security issue associated with it, which no one knew about until the federal courts got involved.
Okay, how does this issue compare to other attack classes, within mobile app security or other platforms? In our opinion, this attack surface is considerable, considering the amount of data that can be compromised. Let’s compare the major attack classes from client/server apps, web apps, and mobile apps altogether, which is shown below in Table 1.0. We will compare buffer overflows, SQL Injection, Cross-Site Scripting, and Mobile SDKs.
Table 1.0
As shown above, buffer overflows still rule the Win32 world; however, attacks on windows native apps are less common (and not as sexy anymore). 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 the full control of data, developer sourced, and customer data, SDKs can gather large volumes of data with just one attack, where reflected XSS cannot (only persistent could). Furthermore, misbehaving SDKs are a bit harder to detect as several SDKs are legitimate, not evil at all. An enemy that looks like a friend is much harder to defend against than something known to be evil.
- Okay, so what have we learned today?
SDKs are a major blind-spot for enterprise security teams, as the emerging attack surface can destroy a mobile app’s security model with behavior that developers perform everyday. While traditional app security teams focus on security flaws within the app, rightfully so, many of them are not aware of this attack surface at all. App security teams usually have 1) no idea which commercial/open source SDKs are bundled in the app 2) nor do they know which SDKs introduce security issues to the app.
More Real-world Examples
- Okay, so where else is this happening?
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 are below:
- Kochava SDK (Android)
- Issue: Disables TLS Certificate Validation on the entire app and its connections
- Source: Data Theorem, Inc.
- Silverpush
- Issue: Tracks user habits without the user knowledge or permission
- Source: Federal Trade Commission
- VPon
- Issue: Records audio, captures videos, collects geo-location & contacts
- Source: Google, Inc.
- iBackdoor (Not a legitimate SDK, but rather a purposely built library to steal data)
- Issue: Collects audio, screenshots, geo-location, and accessed data in private storage/iOS keychain
- Source: Fireeye, Inc.
Please note, these four SDKs are not exhaustive, just a small sample.
- "What did the president know, and when did he know it"
A famous quote by Howard Baker in the middle of the Watergate scandal. Now that you know of this new class of issues, how do your apps rank? Data Theorem scans the App Store/Google Play on a daily basis, so if you have any concerns about your apps or their SDKs, please feel free to contact us and we’ll let you know either way free-of-charge. A full list of apps that have security or privacy issues sourced from a third party SDKs are listed below:
- https://itunes.apple.com/us/genre/ios/id36?mt=8
- https://play.google.com/store/apps
- Okay, so the sky is falling, right?
NO, the sky is not falling. Data Theorem has dynamically scanned over 10,000 SDKs and like everything else, 80% of them are just fine. 80/20 rule applies here too, where 20% of the SDKs cause 80% of the problems. Many of these SDKs introduce security issues by mistake, while others were purposely built to attack mobile apps and their data.
- What’s next, what should I be doing?
There are a few next steps here:
- Visibility is critical
- Enumerate the commercial SDKs and open source libraries in your app. This will remove the blind spot(s):
- Developers usually have a list of the SDKs somewhere, but not necessarily in a consolidated format
- Data Theorem provides real-time visibility for your mobile apps and it's 3rd-Party SDKs for free
- Enumerate the commercial SDKs and open source libraries in your app. This will remove the blind spot(s):
- Continuous testing
- Each commercial SDK and/or open source library, and each version of it, needs to be evaluated for the following items:
- What data, if any, does the SDK pull from the app?
- What security issues, if any, does the SDK introduce to the app?
- If the SDK is commercial…
- What are the privacy terms of the SDK?
- What security audits have been performed?
- If the library is open source…
- Who has reviewed the code for security flaws?
- Each commercial SDK and/or open source library, and each version of it, needs to be evaluated for the following items:
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 since it needs to be continuous and completed for every app’s 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 (both consume or enterprise data).
By: Data Theorem courtesy of Peerlyst
No comments:
Post a Comment