The Calm Before the Mobile API Data Breach Storm
Prediction: Mobile App Security Practices Will Become a Third Party Data Risk
Mobile security may not be as easy to exploit as other established attack styles, but this latest news could change that for the worse. The Center for Advanced Security Research Darmstadt (CASED) in Germany has responsibly disclosed a cloud application security issue it discovered and published in a white paper. CASED found 56 million sets of unprotected user data from Facebook’s Parse, Amazon, and other cloud data sources. The data includes passwords, health records, as well as email addresses and other sensitive, unique data such as financial transactions, data about individuals children, and more personally identifying and sensitive information including mental illnesses.
What does it mean for security leaders and risk managers? If your customers API keys have been exposed and are being reused, you may have some very stealthy activity happening on your network. Evidence of exploits connected directly to Parse and Amazon APIs in the wild, however, are unknown to researchers at this time. News of other types of API hacks are occurring more frequently as of late.
The research highlights the deltas in mobile app security practices of developers and data living in the cloud. It also exposes the relative blindness of users to these issues because they are established behind the veil of app functionality and out of a user’s direct knowledge (or ability to secure themselves).
“It seems as if the warnings that went unheeded months ago about the vulnerable designs of API-based application authentications and permission settings are being noticed by the information security community,” said Chief of Research for SecurityScorecard, Alex Heid.
“The research conducted by CASED confirms the alarms that have been raised by other security researchers months ago. The exploitation of mobile apps making use of the Parse.com backend was first brought to light in April 2015 by security researcher Jheto Xekri.”
Xekri has a history in security circles. A Forbes article about hackers looking for jobs from last year pointed out Xekri was one of the many defendants in the Zeus civil case from 2012.
This configuration issue is a subject of debate. Application developers are ignoring security recommendations for synchronization with Backend-as-a-Service (BaaS) technologies. Similarly, BaaS providers are allowing access control to be easily avoided, though they do provide recommendations and functionality to perform stronger authentication.
Mobile apps often store user data in the cloud to help with synchronization across devices, and according to the German researchers, developers appear to be ignoring the security advice of the cloud providers because of convenience and ease-of-use priorities.
Poor Design Or Ease of Use?
“Every cloud provider, including Parse.com, _does_ provide [a] mechanism to implement secure access control, but the app developers have to be aware of those mechanisms and have to invest the time to study them and implement them in their app,” wrote Dr. Eric Bodden, Head of Secure Software Engineering at Fraunhofer SIT, TU Darmstadt and EC SPRIDE, and Principal Investigator in Secure Services at CASED, in an email to SecurityScorecard. “This is typically where things go wrong; The problem arises, though, if app developers use this ‘simple mode’ also to seemingly ‘protect’ private data. This should actually never be done but, as we found, is done in the vast majority of cases.”
In order to function, for example, Parse.com applications store API keys and authentication tokens in the compiled client side Java apps. These keys and tokens are used as authentication mechanisms.
“When the app is decompiled, a malicious user can extract the keys and then create their own app that makes use of the authentication credentials in their own custom way,” said SecurityScorecard’s Heid. “In the example provided by Jheto Xekri on GitHub and his blog, he demonstrates how the keys can be placed within a custom application that dumps all user email addresses contained within the database.”
According to Xekri, when Facebook was notified of the issue, the response was that these scenarios were intentional functionalities of Parse.com. It seems that the developers who are making use of these BaaS products are not going far enough to ensure that proper permissions are being set for the end user of the application.
Who Is to Blame?
“Developers must write code under the assumption that any authentication credentials will eventually be compromised and/or extracted, and therefore should limit the post-authentication functionalities to the minimum that is required,” Heid observed. “However, the abilities for a developer to enforce restrictions will be limited to the intended abilities of the backend service platform, which may or may not include restrictive configuration options.”
The initial research discoverer of the issue, Xekri, was reached today and provided this comment verbatim (English is not his first language): “The problem really lies in the bad design of the security system… Everyone knows what worse can do about storing keys on the client side is that the backend does not check if they are used for the right app.”
Essentially, researchers agree that key storage needs better validation by design. But don’t let developers off the hook completely, advises CASED’s Bodden.
“I would say primarily the developers, although one could argue that maybe the cloud providers should not even allow for an ‘insecure mode in the first place, or should explicitly name it as such,” Bodden wrote to us. “That would yield better transparency…”.
Security analysts and mobile app development companies should examine the access control documentation for Parse and AWS and follow the guidance within:
For more information, read Dr. Bodden’s FAQ.
SecurityScorecard’s analysis of these data points is factored in to our web application security module, the social engineering module, and the leaked credentials module.