During a Black Hat Europe talk about (In)Security of Backend-as-a-Service, researchers warned that thousands of popular mobile apps have hard-coded backend credentials which could allow anyone to access millions of sensitive records. “Attacks are free, effortless, and simple,” they warned.
Siegfried Rasthofer and Steven Arzt, PhD students at TU Darmstadt in Germany, focused on apps that use Backend-as-a-Service (BaaS) frameworks from the providers Amazon Web Services, CloudMine and Parse.com, which is owned by Facebook. This is the “first comprehensive security evaluation of several popular BaaS providers and APIs as well as their use in real-world Android and iOS applications.”
They called the results “quite shocking” as attackers can gain access to huge amounts of sensitive data records like “medical information, credit card data, photos, voice-, audio- and video-records, money transaction records, etc. Some apps even contained credentials” that could give attackers “full control over the remote storage.”
Many times, an attacker “can manipulate and delete records at will. Some BaaS instances even suffer from remote code execution vulnerabilities.” Adversaries could also “hijack Amazon S3-Buckets which gives them the ability to modify sensitive customer databases, add malicious code to well-known websites or directly run malware on the cloud at the app developer's expense.”
“We found that while all three BaaS service providers offer security features that would allow for secure data storage, their defaults are mostly alarmingly insecure,” the research paper (pdf) stated. Most app developers accept the default settings, “failing to include appropriate means of protection such as access control or data encryption.”
“By default, most BaaS solutions require an application only to authenticate using an ID that uniquely identifies the app, and a so-called ‘secret’ key, used to indicate that the app uses the ID legitimately.” They explained how “adversaries can extract these two values from apps with ease, allowing them to easily forge a malicious application, which inherits the very same backend-privileges that the original application had. If the original application was able to list all records of a customer database, the impersonator can do so as well.”
For testing purposes, the researchers built a HAVOC tool, “a fully-automated exploit generator” that can extract BaaS access keys even if the app was obfuscated.
After analyzing “over 2,000,000 applications from the Google Play Store and alternative markets,” they “found over 1,000 backend credentials, many of them re-used in several applications.” They wrote, “In total over all apps, we found that more than 18,670,000 records with over 56,000,000 individual data items were freely accessible.” That’s not all they found as they discovered a mobile Trojan using a BaaS service to store stolen text messages.
Citing AppBrain, the researchers said “Parse is used in 1.35% of all apps in the Google Play Store and in 4.23% of all apps that are part of the Google Play Store's Top 500 list.” That might seem like a low number, yet it affects a large number of data records and poses a “severe threat to system security” such as through remote-code execution or user privacy.
When evaluating 902 apps that were likely to contain the Parse library, 268 apps had a total of 308 ID/key pairs and 440 names of accessed Parse tables. “In total, all tables contained more than 18,670,000 records,” they wrote. “The largest number of records found through one single app was 2,611,760. On average, every app gave access to about 70,000 records. In the notion of Parse, one record is an object. Just like a table can have multiple columns, serialized Parse objects can have fields. We found that, on average, a Parse object has 6.66 fields, making the number of individual data items being exposed even larger. Counted individually, all tables contained more than 56,000,000 data items.”
When evaluating Amazon AWS and 7,922 apps, the researchers discovered 763 apps had 772 ID/key pairs. “Only 106 of these keys, however, were unique, which means that application developers who create multiple applications often share one ID/key pair between multiple apps. The worst case was one key which was used in 195 apps. Two other keys were used in 124 and 122 apps respectively. This is critical, because it hinders a conceptual isolation in the backend. A security vulnerability with one of the apps leads to all apps with that key being affected as well.”
The researchers found the same problem of developers embedding their keys into the apps rather than using more secure authentication methods with iOS apps in the official App Store.
They gave specifics of sensitive records exposed without naming developers or app names.
- “A chat application gave access to pictures uploaded by the respective users and the contents of websites that were hosted via the same S3 storage instance.”
- “In an online dating application, tables containing voice-chat messages were freely accessible,” they wrote. “The app vendor claims that more than 90 million people have signed up for their dating website and app. The Google Play Store reports that the app has between 10 and 50 million installations.”
- One app insecurely stored sensitive health information, allowing access “to more than 1,400 records of baby-growth and feeding data as well as photos of the respective children” and parents’ email addresses. “An attacker did not need to know any credentials from the parents or the children to get access; the application ID and key extracted from the app's code were sufficient.”
- One app contained more than one million email addresses
- By extracting a vulnerable app’s ID and key, they could have gained access to an app that downloads and stores a user’s friend list, including non-public friends.
- They also could have retrieved “Excel spreadsheets containing customer data (full names and customer IDs), server logs, and database backups.”
- “One application allowed users to record car-crash data. When a crash happened, the user can take photos of the scene, record voice comments on the situation, and make additional notes.” Since an attacker only needs the app ID and key to “manipulate each record inside every table of the whole database,” an attacker could, for example, manipulate those car records before the case goes to court.
Although the researchers responsibly disclosed their findings to Facebook in April, and Facebook forwarded it to Parse in May, in November they still could access 56 million data items…the same number as when they responsibly disclosed the security flaw.
In the end, only a few developers applied "security by obscurity," but the rest didn’t even use obfuscation. Some of the developers have moved on to other projects, meaning it’s unlikely the devs will make changes to protect their users’ data. It’s up to developers to fix this problem, but the researchers said there are mitigations.
BaaS providers should have “more restrictive default security settings,” could include “easily usable end-to-end encryption and authentication methods into their open-source client SDKs,” and could even detect and boot apps, or warn developers, about apps that use root access keys to connect to their services.