Symantec Mobile Threat Defense: Mistakes App Developers Should Avoid – Blind Trust

We owe a lot to mobile app developers. Their apps have enabled us to simplify, accelerate, and improve just about everything we do: get to and from places, communicate, work, access entertainment, make purchases – the list goes on and on. Because app developers are today’s innovators, they also have a unique responsibility to safeguard data. When it comes to security, many developers intentionally or unintentionally fail to implement key controls and processes to secure users’ data and privacy. Take a look at our recent snapshot of mobile security headlines and you’ll understand just how often poor app security controls lead to breaches.

This is the first in a series of articles that takes a look at the top security mistakes app developers must avoid. These oversights can lead to cracks in an app’s security, giving bad actors a way to get in and exploit sensitive data. Below we take a look at the first common mistake developers must avoid: not safeguarding user data from unauthorized access in the cloud.

Substandard Access Control to Cloud Data

Failing to protect users’ private and sensitive data in the cloud can have a huge impact on app users. Apps often communicate with users via one or more cloud services – and attackers know this – making this flaw one of their primary targets.

Access control to cloud data is critical, requiring app developers to have a solid understanding of how to use it to protect user data. Often, as we will show, app developers blindly trust that the cloud service provider already implements access controls for them, or they fail to understand what access controls to use, or they even overlook them completely. Regularly, we find no access controls in apps at all – that is, all private user data in an app is exposed to the world – or the private keys are easily found, or hard-coded, inside the app binary. In fact, chances are there is at least one app on your mobile device containing private cloud keys that expose your private data. The keys – as is often the case – open up the doors to the corporate kingdom, putting sensitive data at risk of exposure.

In the following sections, we’ll explore past research looking at the scope of this mistake and its impact, with a few real-world examples of apps and app developers. We’ll also provide tips for how you can avoid making this mistake to improve your app's security and user experience.

Scope

Past research conducted by Symantec’s Modern OS Security team looked at the largest cloud providers in use by mobile apps, and your app is likely using one of them. Our research discovered that many enterprise apps using the cloud providers below were providing substandard access control to cloud data.

Microsoft Azure

• From millions of apps analyzed we discovered 8225 mobile apps connecting to over 25000 different Azure accounts.
• 460 mobile iOS and Android apps were found to be leaking files – over 1.1 billion Android downloads, alone – were found leaking files from 223 unsecured Azure Blob service accounts
• More than 200 million database records were exposed, containing PHI (Protected Health Information) records (patient names, health symptoms, and medical history) and corporate documents, including contracts, invoices, inventory costs and tracking data

Google Cloud Platform

• 3,000 mobile iOS and Android apps – accounting for 620 million+ Android downloads alone – were found to be leaking data from 2,300 unsecured databases
• More than 100 million records were exposed, including:
  • 2.6 million plain text passwords and user IDs
  • 4 million+ PHI records including doctor/patient chat messages and prescription details
  • 50 thousand financial records including banking transaction details, payment, and cryptocurrency credentials

Amazon AWS

• Thousands of apps were found to be exposing Amazon S3 credentials
• In apps that leaked AWS credentials, in almost half the time (46%), we were able to access all Amazon S3 data buckets without requiring a username or password 
• Data that could be accessed includes medical claims, algorithms, legal documents, invoices, compliance records, CRM data, BI/analytics, AWS data, logs and backups

Impact

Failing to implement access controls to cloud data can result in financial and reputational consequences for app developers. Data hijacking by malicious actors could lead to ransomware, loss of user confidence in the app developer, and hefty regulatory fines. With GDPR in full enforcement, we recently saw British Airways receive a notice of intent proposing an eye-popping $228 million fine for a data breach affecting about 500,000 customers, and Marriott International received a notice of intent to be fined $124 million for a data breach exposing 339 million guest records.

Case Studies

Below are some examples of enterprise apps we found that could improve the way they secure data in the cloud. For the apps, we have contacted the vendor and app developers and followed responsible disclosure, protecting individuals, enterprises, and the internet infrastructure from exploitation whenever possible. 

Digicard by Microsoft Corporation

Digicard for iOS is an app developed by the Microsoft Office team. It is used by businesses to save, organize, and share work data in common formats, such as PowerPoint presentations, Word documents, or text files containing passwords and credentials.

Digicard uses Azure Blob storage, Microsoft's object storage solution for the cloud which is often used by apps to store pictures and documents. If this was your app, how would you go about setting up the proper access controls to protect your users’ data?

Looking at what Azure Storage offers for authorizing access to resources, we find the following options:

• Shared Key (storage account key)
• Shared access signature (SAS)
• Azure Active Directory (Azure AD)
• Anonymous public read access

User data should only be saved and accessible to users in the cloud, using, for example, the role-based access control (RBAC) provided by Azure AD. Data shouldn’t be accessible to the world (Anonymous public read access) nor should it be accessible to other users (Shared Key). What we often find, as is the case with Digicard and thousands of other apps, is the hard-coding of a shared key inside the app, which could expose all user data to the public.

When querying the data exposed by the shared keys, we find user's data and files are exposed.

Microsoft Blob Storage Directories

• https://digicard.blob.core.windows.net
  • dragoneyes/
  • files/
  • mydeployments/
  • web/
• https://dragongate.blob.core.windows.net
  • avatars/
  • companynews/
  • de-alpha/
  • de-alpha-fs/
  • dghelp/
  • digicardfiles/

Cryptoport

Cryptoport is a popular app used to monitor and manage cryptocurrencies across exchanges. Cryptocurrency investors use the app to have a single API key to access all their cryptocurrency accounts on multiple exchanges, and manage external accounts.

Cryptoport uses the Google Platform for cloud services, especially the Firebase Realtime Database, to store users’ cryptocurrency information, including private API keys to external exchanges and accounts. What access controls can be implemented here to protect user data?

Firebase Security Rules give Attribute Based Access Control (ABAC). The rules allow public read/write access to the data, or data sharing between all users. Firebase provides online tools for app developers to directly set and/or disable these security rules. Fortunately, these tools have a default behavior of setting a project in Locked Mode protecting full read/write access to all user data by default. Unfortunately, app developers sometimes intentionally set the project in 'Test Mode' exposing user data and/or misconfiguring rules in a way that exposes the data.

Cryptoport is among the thousands of apps we found allowing access to their users’ data without requiring authentication. Worse, the exposed data included users’ private access tokens to various exchanges, potentially allowing a bad actor to drain users’ cryptocurrency accounts, amounting to losses of hundreds of thousands of dollars.

Jacto Apps

In our first HospitalGown report in 2017 we highlighted Jacto Apps use of insecure backend servers to show it’s not just the big cloud providers that expose private data. Jacto is a global manufacturer of agricultural machinery such as self-propelled sprayers, tractor-mounted sprayers, and telemetry and autopilot systems for large-scale farms. Their machines connect to cellular and Wi-Fi networks to send information to dedicated servers via Jacto apps. Three apps were found to share the same insecure backend servers: Jacto Smart Selector, OtmisNET and OtmisNET - Homologation. These apps help set autopilot parameters and monitor operational data in real-time through their on-board mobile devices to manage the operational efficiency of spraying equipment. We found that the backend server, Elasticsearch, does not have adequate security controls in place, exposing all the data to the public.

Further, we found Jacto’s exposed tractor data had already been held for ransom at least once by an attacker demanding bitcoins for payment. The attacker apparently took a copy of the entire data store, offering to delete their copy after being paid. Judging by the presence of the ransom index dating back to January 2017 on the server, Jacto may not have responded to the attacker’s demands, or perhaps they paid, and failed to remove the reference to the attack from the data store.

How best to avoid  “blind trust” as an app developer

Developers don’t always use shared keys. Sometimes they use shared keys for all user data without implementing or setting up proper role-based account controls. Other times, the insecure shared keys are obtained from corporate IT, and app developers mistakenly assume the keys are secure without checking.

Developers should follow security best practices for sharing and using resources from the cloud storage provider. As we see in our app examples examined above, using the right access control options can prevent data exposure. Microsoft publishes a helpful security checklist and guidance for Azure Storage that can be found here: https://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide.

In particular, developers should never reuse cloud resources meant for user data, for internal corporate data, and should ensure all shares are appropriately locked down with permissions designed for the stored data.

Developers can also rely on tools to automate the discovery of insecure cloud services as part of their application Software Development Life Cycle (SLDC). 

Finally, developers should strongly consider hiring an app security expert to validate and verify the data is protected. This is especially important in cases where developers do follow security best practices only to have resources outside their control – often from Dev-Ops and IT – fail to protect their users data. For enterprises, Symantec Endpoint Security (SES) protects corporate mobile devices from exploitation of vulnerabilities occurring as a result of app developer oversights. SES detects issues within the app itself – for example, hard-coded credentials, usage of third-party cloud services, and data exfiltration – as well as protects mobile devices from other network, OS and app-level threats.

Additionally, Symantec Cloud Workload Protect (CWP) proactively scans enterprise cloud services for misconfigurations exposing data, to protect endpoints. CWP can be used to ensure that corporate accounts on cloud services are properly configured and secured.