Mobile app developers’ misconfiguration of third party services leave personal data of over 100 million exposed

Research by: Aviran Hazum, Aviad Danin, Bogdan Melnykov, Dana Tsymberg and Israel Wernik,

Intro

Modern cloud-based solutions have become a standard in the mobile application development world. Services such as cloud-based storage, real-time databases, notification management, analytics, and more are simply a click away from being integrated into applications. However, developers often overlook the security aspect of these services, their configuration, and of course, their content.

This research will describe the broad issue with misusing cloud-services – by both configuration and implementation – and portray the impact of “bad practices” on application developers and their users.

Overview

Check Point Research (CPR) recently discovered that in the last few months, many application developers put their data and users’ data at risk. By not following best practices when configuring and integrating 3^rd party cloud services into applications, millions of users’ private data was exposed. In some cases, this type of misuse only affects the users, however, the developers were also left vulnerable. The misconfiguration put users’ personal data and developer’s internal resources, such as access to update mechanisms and storage at risk.

In this research, CPR outlines how the misuse of real-time database, notification managers, and storage exposed over 100 million users’ personal data (email, passwords, names, etc.) and left corporate resources vulnerable to malicious actors.

Misconfiguring Real-Time Database

Real-time database allows application developers to store data on the cloud, making sure it is synched in real-time to every connected client. This service solves one of the most encountered problems in application development, while making sure that the database is supported for all client platforms. But what happens if the developer behind the app does not configure their real-time database with one of the most basic features – authentication?

This misconfiguration of real-time databases is not new, but to our surprise, the scope of the issue is still far too broad and affects millions of users. All our researchers had to do was attempt to access the data. There was nothing in place to stop the unauthorized access from being processed.

Figure 1 – Some apps on Google Play with open real-time database

While investigating the content on the publically available database, we were able to recover a lot of sensitive information including email addresses, passwords, private chats, device location, user identifiers, and more. If a malicious actor gains access these data it could potentially result in service-swipes (ie. trying to use the same username-password combination on other services), fraud, and identity theft.

Figure 2 – Email, Password, Username and ID of a user on Logo Maker

Astro Guru, a popular astrology, horoscope and palmistry app with over 10 million downloads, had the same issue.  After users input their personal information including their name, date of birth, gender, location, email and payment details, Astro Guru provides a personal astrology and horoscope prediction report. Imagine losing sensitive data for a horoscope prediction!

Figure 3 – User location, email and personal file shared on Astro Guru.

Storing personal information is one thing, but what about storing real-time data? This is what a real-time database is for. Through T’Leva, a taxi app with over 50,000 installs, we were able to access chat messages between drivers and passengers and retrieve users full names, phone numbers, and locations (destination and pick-up) – all by sending one request to the database.

Figure 4 – A private chat between a taxi driver and passenger on T’Leva.

As mentioned earlier, this type of data exposure affects both developers and users. From the developer’s perspective, it is possible to alter the behavior of an app if actions are taken based on the data available on this type of platform. Moreover, most of the apps we have found had ‘read‘ permissions and ‘write’ permissions. This alone could compromise an entire application, not even considering the hit to the developer’s reputation, their user-base, or even their relationship with the hosting market.

Push Notifications

Push notification manager is one of the most widely used services in the mobile industry. Developers need to send push notifications to engage with users. For instance, push notifications are used to flag newly available content (like a new video posted), display chat messages, emails, and much more. Most push notifications services require a key (sometimes, more than one) to identify the identity of the request submitter. What happens when those keys are just embedded into the application file itself?

Figure 5 – Credentials to Push Notification services embedded into an application

While the data of the push notification service is not always sensitive, the ability to send notifications on behalf of the developer is more than enough to lure malicious actors. Imagine if a news-outlet application pushed a fake news entry notification to its users that directed them to a phishing page requesting that they renew their subscription. Since the notification originated from the official app, the users will not suspect a thing, as they are sure that this notification was sent by the developers.

Cloud Storage

Cloud storage on mobile applications is an elegant solution to access files shared by either the developer or the installed application. Let’s take, for example, two apps that we have found on Google Play. With over 10 million downloads, an app named “Screen Recorder” is used to record the device’s screen and store the recordings on a cloud service. While accessing screen recordings through the cloud is a convenient feature, there can be serious implications if the developers embed the secret and access keys to the same service that stores those recordings. With a quick analysis of the application file, we were able to recover the mentioned keys that grant access to each stored recording.

The second app, “iFax”, not only had the cloud storage keys embedded into the app, but also stored all fax transmissions. After analyzing the app, we found a malicious actor could gain access to all documents sent by more than 500k users who downloaded this application.

Figure 6 – App on Google play with cloud storage keys exposed.

For ethical reasons, CPR did not access the storage account with the keys. We pulled evidence through the actual code of the apps to showcase that this type of sensitive information is accessible.

Cover ups

Many developers know that storing cloud services keys in their application is bad-practice. After analyzing dozens of cases, we found a few examples of keeping this issue “out of sight, out of mind” – ie. developers tried to “cover-up” the problem with a solution that did not fix the problem.

Hiding the keys

Below are a few examples of such misuse of cloud services keys. After inspecting a publicly available application with a free open source tool like “Jadx”, we can take a look into the application’s code and see the developer’s logic.
In the example below, the developer used a Base64 encoding in order to hide the key. Base64 is not only reversible, it also does not have a need for any shared secret. All we had to do was to take the same line of code, and just print the outcome of the decoding function, in order to be provided with the app’s keys.

Figure 7 – Documents upload from the iFax app

Figure 8 – Screen recording video upload

Even if the application’s does not use clear-text keys, all that is needed is to find the piece of code that initialize the cloud service interface, which mostly receives those keys as parameters, and follow their value. Eventually, if the keys are embedded into the app, we will get their value.

Figure 9 – variable storing keys ‘b.a’ and ‘b.c’.

Figure 10 – Initialize secret key using XOR

Vulnerable malware

To emphasis that this a developer issue, we researched mobile malware developers that implemented bad practices into their mobile malware. Let’s take a look at the CopyCat malware that Check Point Software previously reported on.
The CopyCat malware stores their cloud service credentials inside a class file, while its XOR encoded.  A quick analysis of the malware application allowed us to uncover the keys for the cloud-storage service that CopyCat use, and allow us to, if we wanted, to alter all of the data that exists on the storage. This storage is used for a few key components of the malware – as a hosting service for malicious payloads that are downloaded by CopyCat, and even as an update utility for the malware components.

Figure 11 – CopyCat’s cloud-storage key decoding

How to protect yourself

Check Point Harmony Mobile is the market-leading Mobile Threat Defense (MTD) and Mobile App Reputation Service (MARS) solution, providing the widest range of capabilities to help you secure your mobile workforce.
Check Point Harmony Mobile MARS solution automatically scans and identifies mobile security threats and vulnerabilities. Learn more 

Figure 12 – Check Point’s Harmony MARS report

Appendix 1 – Vulnerable Applications: