A scientific paper that contains concrete information about our code analysis is currently under submission and not yet publicly available. But the main points are listet in our FAQs.
What does Backend-as-a-Service (BaaS) mean?
Many users of mobile applications want their data to be synced across multiple platforms (iOS/Android/Windows/OSX/...). For app developers it is typically hard to support synchronization, as they need to set up backend servers on which the data can be stored and synchronized. Cloud providers such as Amazon and Parse.com therefore provide backends as a service (BaaS). With BaaS, app developers can simply connect to pre-configured servers using a few lines of program code. This makes data storage and synchronization through the cloud very easy. Some apps use BaaS to share public data, which is ok as long as the data is configured to be read-only. Many apps, however, use BaaS also to store confidential data such as user names, email addresses, contact information, passwords and other secrets, photos and generally any kind of data one can think of. Such data should only be accessible to the individual app user who stored the data.
What is the problem with how BaaS is used?
When app developers include a BaaS into their app with just a few lines code, this typically constitutes an insecure usage of the service. All cloud providers extensively document on their webpages how apps must include the BaaS such that secure access to the data is guaranteed. Most developers seem to be missing this crucial piece of information, though, and opt for the simple but insecure usage of the service, probably not even aware that they are putting their user's data at risk.In virtually all apps the research team investigated, access to the data associated with the app is secured only by a secret key, which is directly embedded into the app. As the researchers showed, for anyone with a somewhat deeper knowledge of mobile application code it is quite easy to extract this key from the app's binary code. Using the key, the attacker can then, in many cases, access the entire data that has been stored in the database associated with that app, and in many cases even modify that data.Examples of data that could be accessed include:
- Full names and (verified) email addresses
- Location information
- Postal address information
- Photos, including photos of children
- Voice-, Audio- and Video-Records
- Private Facebook Information (who is a friend of whom)
- Friend-Relations in messaging apps (who is a friend of whom, who is blocking whom)
- Health records including information about alcohol or tobacco-level and indications (e.g., Obsessive-Compulsive Disorder), as well as child growth and feeding information
- Money Transactions
- Device Information such as manufacturers, version numbers of installed apps, etc.
- Complete access to web storages and servers
- Backups of complete servers, databases, and log files
What can app users do to protect their data?
Right now, unfortunately, there is not much that end users could do. The problem is that the misuse of those interfaces is very widespread. While the researchers found thousands of vulnerable apps, this might just be the tip of the iceberg. Also, to users there is no real indication of whether any given app is using a BaaS, and if so, if it is using the BaaS securely. In general, app users should thus be conscious of the data they enter into apps, and ideally prefer such apps that have been validated for security by a trustworthy third party. Fraunhofer SIT but also other institutes offer detailed security screenings of apps that guarantee to find security issues such as the ones mentioned here.
Why do you give no information about what apps are vulnerable?
Unfortunately German and EU law currently does not allow security researchers to distribute product warnings. To find out whether a given app is vulnerable, customers should therefore best ask the app's vendor.
Which apps did you evaluate?
With the help of Intel Security / McAfee, the team tested about 2 Mio. apps collected from various sources, such as Google Play. These apps contained malicious as well as benign applications. The researchers found misuses for both categories, where the malicious apps were vulnerably mostly due to the fact that these apps added malicious content to benign application that contained a BaaS issue.
What can app developers do?
App developers should carefully re-read the security documentation offered by the BaaS providers. They should then implement sensible, restrictive access-control lists in their apps. Fraunhofer SIT is happy to assist in such cases through paid consultancy services.
AWS, for instance, provides security best practices documentation and tutorials on how to use the above, including:
Thanks to Don Bailey at Amazon for providing this information. He further writes:
Finally, AWS “Cognito" is a relatively new web service released last year from Amazon that makes it simple to implement AWS security best practices. Cognito gives mobile app developers unique identifiers for their end users and then lets developers securely store and sync user app data in the AWS Cloud across multiple devices and OS platforms. This requires just a few lines of code, and developers' apps can work the same, regardless of whether a user’s devices are online or offline. This means a developer's app can access the resources it needs to provide users a great experience, and developers don’t have to hardcode security credentials in their apps. For more information about Cognito, see here.
What are the BaaS providers doing?
We are in contact with Facebook (the owner of Parse.com), Amazon (the owner of Amazon Web Services, AWS), Google and also Apple, in order to find and warn the developers of apps which we found to be vulnerable. Thus, even though the providers are not at fault they are doing their best to help keep their customers' data secure.
Why don't BaaS providers more secure defaults?
While secure defaults might be desirable, we understand that in such cases in which the data stored in the cloud is public this would significantly and unduly complicate the inclusion of the BaaS in an app. As so often, security costs time and money, this time on the side of the app developer. BaaS providers are interested in providing a service that is as easy to use as possible; ease of use is the primary selling point for BaaS offers. This requirement is in conflict with defaults that would require a potentially complicated security configuration. Fraunhofer SIT is offering to work together with BaaS providers to provide simple to use and yet more secure interfaces in the future.
What disclosure process was employed?
Immediately upon discovering the problem, and in particular its magnitude, the researchers contacted Amazon, Facebook/Parse, Google, Apple as well as the German Federal Office for Information Security (BSI) about the problem. Each BaaS provider was given a list of problematic apps that had been found, while indicating that this list is not exhaustive. The providers contacted the respective app developers, making them aware of the problem. After a period of several weeks, the researchers then went public.
Is the decision to go public with this information not putting users at risk?
Fraunhofer SIT usually follows a process of responsible disclosure, not announcing vulnerabilities until they have been fixed. In this case, however, such a disclosure process was impossible. Similarly to the Heartbleed bug, the BaaS problem affects thousands of applications. Through Amazon and Facebook/Parse, Fraunhofer SIT informed ahead of time the subset of app developers in whose apps problems were found. But given the fact that those are hundreds of development companies, from this time on the information is already known to a large circle of people; it cannot be kept secret. At this point it therefore becomes more important to inform about the problem as many app developers as possible, and the end users of apps who should be informed that their data might be at risk.Secondly, while it is not easy to find evidence for this, it might very well be the case that attackers are already exploiting the mentioned vulnerabilities to harvest private user information right now, especially given the fact that the technical skills required to conduct an attack are comparatively low. This makes it more pressing to fix as many applications as quickly as possible.For the future, the BSI has discussed to partner with other international CERTs to set up a notification list which app developers can subscribe to so that they will become aware of similar security risks more easily.
How did you become aware of the problem?
Fraunhofer SIT was alerted of the problem by a student, Robert Hahn, who had been looking to use one of the BaaS interfaces in a mobile application. Given the security education he had received at TU Darmstadt, he noticed the insecure defaults of the BaaS offerings immediately. A team comprising Rober Hahn, Siegfried Rasthofer, Steven Arzt, Stephan Huber, Max Kolhagen, Marc Miltenberger, Jens Heider and Eric Bodden then explored to what extent apps stick to those insecure defaults. The shocking finding was that the insecure defaults are used in the vast majority of applications.