The mobile app vulnerability epidemic and its impact on global business

There is a widespread mobile app vulnerability epidemic unfolding and it’s impacting organizations across industries around the world. The cause? The absence — or in some cases — a complete lack of app security measures needed to protect app code, prevent reverse engineering, and deter follow-on attacks.

Recent research by Aite Group assessed just how widespread mobile app vulnerabilities are — and the findings indicate that the massive attack surface presented by apps and the resulting security risk to organizations is great.

Before we get into the results, let’s go over some basics — a bit of a mobile app security Q&A, if you will:

• What exactly is mobile app security? Mobile app security refers to the practices and policies put in place to protect mobile applications (especially those apps that collect personal information, contain business-critical IP, or handle financial transactions) from reverse-engineering, tampering, and other app-level attacks.

• Why should we care about mobile app vulnerabilities? Apps are often used to process sensitive customer data and access back-end systems or intellectual property (think personal information, including bank credentials and credit card numbers). This data is at risk of being exposed if an app is compromised, and can result in brand damage, financial loss, intellectual property theft, and even government penalties.

• How can my mobile app be compromised? Today’s apps are required to perform at the speed of the customer — lightning-fast. As a result, app developers have moved more business logic from the back-end (server side) of the app infrastructure to the front-end (client side). This means two things: 1) critical business logic is moved out in front of the firewall and other network security systems, and 2) without code protection for that application, any business logic or sensitive information contained in the app code is now at risk. In most cases, app developers are not taught secure coding techniques. Poor coding or coding mistakes create an exploitable vulnerability for an organization, but good coding can also provide a roadmap for how to further attack an organization’s infrastructure via exposed APIs (application programming interface), hard-coded encryption keys, improperly implemented encryption protocols, and more.

• Who’s impacted by app vulnerabilities? Any organization across any industry with an app that requires a login collects personal information and/or handles financial transactions is at risk of being exploited through any vulnerabilities present in the app.

Top mobile application security vulnerabilities

In the Aite Group study on mobile app vulnerabilities commissioned by Digital.ai, formerly Arxan, senior cybersecurity analyst and white-hat hacker, Alissa Knight examined mobile app security risks across eight financial services sectors. During her research, it took an average of 8.5 minutes to compromise each of the 30 apps analyzed — every single financial services vertical was found to be vulnerable. Study findings include the following 11 types of vulnerabilities, many of which can be found on the OWASP Top 10 (Open Web Application Security Project).

Lack of binary protections

What is it?

Lack of binary protections means the source code for a mobile app isn’t obfuscated in some way, making it easy to decompile, reverse-engineer, and read the app code in clear text without needing any special tools. Once decompiled, it’s easy to search app source code for markers including APIs, encryption keys, and tokens.

What is the potential business impact?

An astounding 97% of apps examined during the study suffered from a lack of binary protection, making it possible to decompile the apps and view the source code using a simple APK Extractor tool, available for free download from the app store. If encryption keys or tokens are discovered, it’s also possible to crack private-key passwords offline, giving adversaries the ability to inject malware into the code and repackage the app as a rogue/pirated app hosted in a third-party app market, or to send it to victims via smishing (SMS phishing). Once reverse-engineered, sensitive intellectual property stored within an app could also be left exposed.

Insecure data storage

What is it?

Insecure data storage means data transmitted via an app was insecurely stored, either temporarily or permanently, outside of a “sandbox” and in the device’s local file system, in external storage, or copied to the clipboard — allowing other apps or attackers to access it.

What is the potential business impact?

The Aite research discovered that 83% of apps tested stored data insecurely, increasing the risk of exposure of a user’s personal data, including names, email addresses, phone numbers, home addresses, and social media handles. Storing data, even temporarily, in an insecure area of the app or the device could allow access to sensitive data from other apps or if the device is breached. In the event of an acquisition of a mobile device by an adversary, data could be easily accessed, manipulated, and used to further penetrate the back-end servers of an organization through its APIs.

Unintended data leakage

What is it?

Unintended data leakage means that either 1) data is stored in an area of the mobile device easily accessible by other apps or users (see previous section, Insecure data storage), or 2) apps are sharing services with other apps on a device, leaving data from the app accessible to any other application on the user’s device.

What is the potential business impact?

In 90% of apps tested, it was found they were inadvertently leaking data due to sharing services with other apps on a device. This type of vulnerability could result in the breach of user privacy and lead to unauthorized use of sensitive data.

Client-side injection

What is it?

This type of vulnerability refers to the execution of malicious code on the client side of the mobile device via the mobile application. Client-side attacks create holes through which various functions of the mobile device can be accessed. An injection vulnerability might even allow adversaries to adjust trust settings on the device for the apps, possibly breaking out of sandboxes put in place as a security control.

What is the potential business impact?

The study found that 43% of apps tested were vulnerable to client-side injection (that is, malicious code could be inserted in the app — the “client side” — without the attacker having access to the server). The inserted/injected malicious code can harm businesses in a number of ways including skimming user credentials or payment info (resulting in follow-on fraud) or stealing copyrighted content or other sensitive IP.

Weak encryption

What is it?

Weak encryption within an application can result from using algorithms that are outdated, weak, or suffer from extensive vulnerabilities (such as MD5, RC4, DES, SHA1). Sometimes chosen for their ease of implementation or speed, many of these earlier encryption algorithms have been superseded by newer, more secure algorithms such as AES, 3DES, RSA.

What is the potential business impact?

It was discovered that 80% of apps tested during the study implemented weak encryption algorithms, or incorrect implementation of a strong cipher. Weak encryption can translate into full access to see or modify user data in transit between the time a user inputs data via the app, and the time it reaches the app’s server. Incorrect or weak implementation or usage of encryption algorithms may result in sensitive data exposure, key leakage, broken authentication, and spoofing attacks.

Weak encryption enables attackers to decrypt sensitive data back to its original form and then manipulate or steal it. A weak cipher renders encryption useless and provides attackers full access to see or modify data in transit that would have otherwise been encrypted and not possible to crack.

Private key exposure

What is it?

In the case of a private key exposure vulnerability, should an attacker gain access to this key file, offline cracking of the private key’s password will be possible.

What is the potential business impact?

It was discovered that 27% of the apps tested used hard-coding of the API keys and private certificates in the apps, or stored them in files on the file system. Hardcoding is not a secure practice because once the app is cracked open, the attacker has the “key” to decrypt encrypted data and communications. Those thought to be “secured” financial transactions, for example, are now vulnerable to being intercepted.

Once the password is recovered, the attacker can use it to decrypt encrypted sessions between the app and back-end and gain access to sensitive financial data being encrypted in transit or to login credentials. The impact being that an attacker can use this key in follow-on attacks against the server, circumventing perimeter security by impersonating a legitimate user.

Implicit trust of all certificates

What is it?

A public key certificate, also known as a digital certificate or identity certificate, is used in cryptography to allow trusted communications between the client browser or app and the issuing server. Certificates from major financial services organizations are validated by a certificate authority to ensure they’re from legitimate businesses and can be trusted to conduct business.

What is the potential business impact?

In this case, 10% of apps tested during the study implicitly trusted certificates presented to them without checks. Implicit trust of all certificates means the app automatically grants access to any certificate presented without confirming whether the certificate is legitimate, making the app susceptible to man-in-the-middle attacks — the exploiter sits between the mobile device and the app’s servers, pretending to be “both sides of the conversation.” Not only can data be intercepted and decrypted, but also modified while in transit, leading to the interception of bank account numbers and changes to account transactions — which can result in an account takeover.

Execution of activities as root

What is it?

Code execution within an app at the root level (a superuser privilege level that grants the application access to all files, executables, and data on the device) creates the potential for an adversary to disable the normal security checks being performed by the operating system or surrounding environment.

What is the potential business impact?

It was found that 40% of apps tested during the study execute activities on the mobile device as the root user account. Access can be gained to any resource allowed by root access (so really, everything), resulting in executing code, disabling services, and reading restricted data. Any number of bad outcomes can result from apps compromised with root access such as enabling a bad actor to turn on cameras and microphones, all transactions copied to a shadow server, or access gained to any app or stored files on a device.

World-readable/writable files and directories

What is it?

Using world-readable/writable files and directories allows any process or user to read and write to and from the files and directories.

Fortunately, it was discovered that only 3% of apps tested have directories or files configured with world-readable and writable permissions (though that’s 3% too many). In these instances, information was not obfuscated. Once the app was cracked open, the information was human-readable, meaning sensitive data is vulnerable and customer data no longer secure.

What is the potential business impact?

Applications with world-readable/writable files and directories provide easy access to any app running on the device to spy on data being transmitted to a financial service organization. This also allows for the potential to insert malicious code into the app via shared files.

Exposure of database parameters and SQL queries

What is it?

In this case, exposure of database parameters and SQL queries provides the “keys” to the underlying database and how the information in the database is accessed. This reveals how the app interacts with proprietary data and can also result in an unintended data leakage, plus all related consequences.

What is the potential business impact?

60% of apps tested during the study exposed sensitive database parameters, configurations, and SQL queries in their code, allowing for SQL database query manipulation and injection. An SQL injection attack executed through an app’s access to back-office systems can enable an attacker to bypass all security measures in place. Once access to the database is granted, an attacker can gain complete access to all data on a server to alter balances, void transactions, or transfer money to their account. In a worst-case scenario, the SQL injection can be the initial vector, allowing the attacker access to an organization’s internal network from behind the firewall.

Insecure random number generation

What is it?

In the case of insecure random number generation, a mobile app uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.

What is the potential business impact?

An astounding 70% of apps tested during the study used an insecure random number generator, making sensitive information easy to guess. Secure communication with an organization’s servers is dependent on the ability of the app to generate secure keys to encrypt all transmissions. Given the current state of computational capabilities, attackers have the ability to expose insecure keys in seconds to minutes. Once decoded, keys can be used to spy on transmissions or execute server-side attacks to gain access to back-office systems.

What can we do to keep mobile apps safe?

When a company fails to implement proper application security technology, it opens up the app to reverse-engineering and tampering, potentially leading to a breach. Such breaches can result in significant financial losses and damage to brand, customer loyalty, and shareholder confidence — as well as the possibility of being hit with government penalties.

To keep apps secure, organizations must adopt a comprehensive approach to app security including three foundational in-app protection capabilities: app shielding, encryption, and threat detection.

• Application shielding is a process in which the source code of an app is obfuscated to prevent adversaries from easily reverse-engineering the app to uncover vulnerabilities, or repackaging it to distribute it with malware. App shielding also provides other security measures such as application binding, repackaging, detection, and data-at-rest encryption.

• Encryption for in-app keys and sensitive data is delivered via whitebox encryption. This capability encrypts static and dynamic keys and protects app data utilizing mathematical techniques and transformations so they cannot be discovered or extracted from the app.

• App-level threat detection identifies and alerts on exactly how and when apps are attacked at the code level — beginning with alerts if an app is downloaded onto a device that has been rooted or jailbroken — continuing to identify suspicious behavior such as reverse-engineering or debugging attempts and code tampering. Threat response can trigger immediate actions, such as shutting down an application if tampering is detected, sandboxing a user, revising business logic, and repairing code.

A few other app security best practices to consider:

• App developers should receive proper secure programming training and implement rigid security protocols throughout the software development lifecycle.
• Don’t assume a mobile app has been securely developed or that there is nothing in the code that could put your organization at risk. Download your own mobile app, decompile the code, and take a look around. If you see anything you don’t recognize, beware — and say something to your developer or security team.
• Many of the study’s findings at the application layer would have been more difficult to make if app security at the code level (including code obfuscation) had been implemented. Always ensure source code is unreadable.
• Ensure developers aren’t writing code that stores sensitive data in insecure areas. Instead, use sandboxes to store any temporary files or data where it can’t be seen by the file system or other apps on the mobile device without being decrypted.
• Make sure the mobile app performs operations at the minimum privilege level required (nothing should ever be executed at the superuser or root level) to minimize potential for an adversary to disable the normal security checks being performed by the operating system or surrounding environment.
• Implement control mechanisms such as threat detection and response capabilities within the application to detect when an app is being reverse-engineered. By applying an application security solution with real-time threat detection, you can stop app-level attacks at the reconnaissance stage and generate alerts when they occur — not after the fact when it’s too late.

Concluding remarks

The prevalence and severity of mobile app vulnerabilities discovered across every single financial service sector examined in this study boldly underlines the widespread absence of, and need, for app security. And if app security is lacking in a highly regulated industry such as financial services, how safe and secure are apps in other industries or verticals?

Mobile app vulnerabilities may lead to a range of exploits against businesses and/or their customers, including account takeovers, synthetic identity fraud, credit application fraud, identity theft, gift-card cracking, and credential stuffing attacks. Looking to other areas like healthcare or connected medical devices, apps open up risks to exposing patient data, revealing sensitive IP, or potentially putting lives at risk. With connected cars, apps can open up risk to car functions like unlocking doors or overriding car operations. In mobile gaming, a cracked app could lead to cheating or piracy which could destroy a game’s revenue stream and lose customers.

With 84% of app attacks starting at the application layer, businesses cannot afford to remain complacent when it comes to the security of their apps. The time to protect against mobile app security risks is now.