When approaching the development of a mobile application, one of the key design decisions revolves around the server side aspect of the application. Specifically, storage of information relevant to the app’s usage, as well as the backend API’s allowing the app to query the server for information in real time (as opposed to static data that’s stored in files).
In addition to the examples above, significant numbers of apps have started to rely on cloud based databases (such as Firebase), allowing the app developer to focus on storing and accessing the data without being concerned about infrastructure and APIs.
There are several popular “go to” cloud solutions providing the services described above that are widely used: AWS by Amazon, Azure by Microsoft, Google Storage and Google Firebase to name a few.
The stated purpose of all of these services is to reduce the complexity of configuring access to the relevant storage container, and allow the app developer to “focus on the important things.”
However, the process of securing these cloud containers used by mobile applications tends to be overlooked by app developers while the impact of a misconfigured cloud container on the app developer, their business and their users can be extremely high.
This blog will cover the latest research uncovered by Cyber Armors’s zLabs Team, including our findings on thousands of mobile apps with unsecured cloud containers throughout global markets and across both major mobile operating systems (iOS and Android).
If you are a mobile app developer and would like to know if your apps have unsecured cloud storage issues:
In our analysis, 14% of mobile apps that use cloud storage had unsecure configurations and were vulnerable to the risks described in this post. In apps around the world and in almost every category, our analysis revealed a number of significant issues that exposed PII, enabled fraud and/or exposed IP or internal systems and configurations.
We will shed light on how widespread these types of configuration errors are, and how the different aspects of the leaked information can be exploited by a malicious attacker.
Another goal of this blog is to create an “aha!” moment for app developers, as one of the biggest challenges we have encountered was actually reporting our findings to the specific app developers who have unsecured cloud storage. Very few publishers have a clear path for vulnerability disclosures, so risks may remain unreported and unresolved (and possibly actively exploited).
So, in addition to helping app developers assess the current security status of apps’ cloud containers, and providing them with the tools and solutions needed to effectively secure the cloud container of choice and prevent information from leaking, we would like to raise awareness from an industry standpoint on the need for mobile app develops to be more accessible so they can receive and address security concerns stemming from the app being developed.
In today’s world, apps have become ubiquitous. We have an app for everything we want to do.
How many steps you’re taking in a day? There’s an app for that.
Need to listen to your favorite playlist. App for that.
Get the latest news. You get the idea.
But, apps need data. Constantly available. Redundant. Scalable. Enter “the cloud.”
App developers rely heavily on several service providers that provide cloud infrastructure allowing access to data through a variety of forms – – from static files, to full-fledged databases to APIs.
Our zLabs research focused specifically on four main cloud storage services:
All of these services allow you to easily store data and make it accessible to your apps. But, herein lies the risk, the ease of use of these services also makes it easy for the developer to misconfigure access policies – – potentially allowing anyone to access and in some cases even alter data.
The main allure of these services is that they allow the developer to turn over the “burden” of thinking about anything but the app they are developing, with security, access controls and an overall approach to securing data being relegated to the cloud provider’s default settings.
And even though the cloud providers provide very detailed guidelines on how to secure access, most app developers neglect to follow them.
In the following section, we’ll explore what kind of data leaks when cloud storage is unsecured, and provide examples of real leaks from misconfigured cloud storage used by apps.
Before providing examples of apps with unsecure cloud storage, it is useful to describe the types of data that we discovered to be leaking. We can divide the information into:
This is personally identifiable information (PII), such as profile pictures, personal details (addresses, financial information etc), medical details (medical test data), etc.
The risks of this information leaking are pretty self-evident – there is a potential legal risk of leaking PII data (i.e. the people whose data is leaking might sue the app developers) and also brand damage (i.e., App X is leaking its users data, therefore all users stop using App X).
This type of information leak exposes various configuration information relevant for the normal operation of the app and the infrastructure it uses. For example, we detected apps that leak their entire cloud infrastructure scripts, definitions (including SSH keys), etc. Other types of configurations are web server config files, installation files and even passwords to payment kiosks.
This kind of information could enable an attacker to understand how the computing infrastructure of a company is built. Having access to all of the infrastructure information can also allow an attacker to take over the backend infrastructure of the company, which in turn can allow the attacker to potentially “jump” to other infrastructure and hurt other products.
In our analysis, 14% of iOS and Android apps that use cloud storage had unsecure configurations and were vulnerable to a number of significant issues that exposed PII, enabled fraud or exposed IP or internal systems. A few examples of each include:
The image below shows the distribution of categories (verticals) for the apps with unsecure storage issues. We can see that the bigger verticals are: Business, Shopping, Social, Communications and Tools.
During our review, we encountered several apps relying on both Google and Amazon storage that was accessible without any security. In one example, the information we were able to obtain included profile pictures and other PII information.
Since many apps revolve around people sending information to one another, the fact that specific information – not intended to be shared – can be accessed by an unauthorized third party, can cause damage to the app developer and the privacy of their users.
Other apps leak information that enables fraud. In one example, an app shows images containing physical payment implements such as checks. These contain personal and financial information (account numbers, addresses, valid account holder names etc) and can be used to perpetuate forgery and other real-world crimes:
Another popular use-case for business/financial apps is online shopping. One online shopping app was exposing customer ID’s, login session ID’s and even payment related information (in the form of tokens). An attacker can actually use this to perform payments, steal money and even hijack accounts:
Another category of apps exposes configuration information that could be used for further investigation or penetration. For example, one may think music apps don’t have any important information to protect, however, we identified cases where the entire server infrastructures, scripts, servers and much more was exposed publicly. An attacker gaining access to this information can easily compromise the entire server infrastructure of the app developer.
The screenshot above shows a script that adds an SSH key to the list of authorized users. By having the ability to see SSH keys, an attacker can have access to the app developer’s servers.
To make matters worse, an attacker could obtain a full list of all of the backend resources (servers, caches, databases etc) used by the app’s infrastructure, which could allow an attacker to potentially compromise the entire infrastructure.
The simplest thing you can do is make sure your cloud storage/database is not accessible from the outside world without any sort of security around it (each cloud provider has full documentation on how to achieve this).
Once you’ve closed off your cloud service to unauthorized external access, the next thing you can do is to use a service that assesses your secure software development lifecycle as part of your standard development process.
The leading solution for continuous mobile app security testing (MAST) is Cyber Armors’s zScan solution, part of the industry leading Cyber Armors Mobile Application Protection Suite.
Not only is it going to help you prevent leaky cloud storage, but also other security pitfalls.
That’s where zScan comes in. It integrates as part of your CI/CD process, and scans your app each time it gets built. If there are any issues found, zScan will then highlight any security issues it finds. We’ve included some example reports below:
In conclusion, I’d like to thank Asaf Peleg for all of his efforts with this research. For any press wanting to learn more, please reach out to firstname.lastname@example.org.