theDocumentId => 1341087 Most Mobile Apps Can Be Compromised in 15 Minutes ...

Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

10:00 AM
Alan Bavosa
Alan Bavosa
Connect Directly
E-Mail vvv

Most Mobile Apps Can Be Compromised in 15 Minutes or Less

In the name of releasing apps quickly and delivering a smooth user experience, mobile app security is often given short shrift.

The state of mobile app security is not strong; a large majority of Android and iOS apps across every industry and vertical lack even the most basic security protections. As a result, they can be compromised with very little time and effort. The Verizon Mobile Security Index 2021, for instance, found that 76% of respondents experienced pressure to sacrifice mobile security for expediency. 

Related Content:

Agility Broke AppSec. Now It's Going to Fix It.

Special Report: Assessing Cybersecurity Risk in Today's Enterprises

New From The Edge: How to Get Employees to Care About Security

At my company, we regularly analyze apps from Fortune 500 companies to help assess their security weaknesses via black-box penetration testing. Nearly all the apps we see can be compromised within 15 minutes. It's not that developers aren't implementing any security measures — they are. But in most cases, the limited protections we come across are easily bypassed using freely available tools. Generally speaking, the security deficiencies can be grouped into three main categories. 

1. Weak or Incomplete App Hardening
The very first layer of defense in any mobile app security strategy should consist of hardening or "shielding" the app by implementing basic runtime application self-protection (RASP) measures like anti-tampering, anti-debugging, anti-reversing, and jailbreak/rooting prevention. It's rare that our security team comes across apps that have more than one of these protections in place, and we often find that the protections are either superficially implemented (such as anti-tampering that only checks once at app initialization) or hardcoded into largely un-obfuscated source code.

2. Lack of Obfuscation
Code obfuscation makes it difficult for attackers to understand an app's source code and control flows. Hackers use open source, freely available disassemblers, decompilers, and debuggers to reverse engineer mobile apps and understand the source code. With this information, they can craft more successful attacks. 

Even more skilled cybercriminals can use dynamic instrumentation toolkits such as Frida to attach to running processes, hook into applications remotely, and dynamically inject code into memory during runtime, allowing attackers to alter an app's behavior, functionality, logic, and state — all while the app is running. Plus, these tools can help them cover their tracks to remain undetected. 

For example, Facebook recently announced it discovered Chinese hackers embedded malware in many popular Uyghur-themed Android apps distributed in online app stores they set up. These apps targeted, tracked, and spied on activists and journalists of the Uyghur ethnic group living abroad. 

3. Weak or Insufficient Encryption
The third major area is lack of data protection. Most apps employ weak or insufficient encryption, and some ignore encryption altogether for data stored in the code. For example, in our security audits, our security researchers are almost always able to access highly sensitive API keys and secrets stored in the clear as strings in the app. We have also been able to intercept usernames and passwords in the clear as they traverse a network, such as when a user logs in to a mobile banking app. Other places where we find an abundance of unprotected data are app preferences, XML strings, and app resources. 

You might expect that this data would be encrypted by default. Simply put, it's not. Encrypting data can complicate sharing authentication and authorization with back-end servers and other apps, which degrades the user experience if encryption breaks it. Plus, there are a dizzying number of choices to make in terms of key size/strength, key derivation technique, cipher strength, and encryption algorithms. Each and every one of these choices can have a dramatic effect on performance and security if it is wrong. 

As a result, in the name of releasing apps quickly and delivering a smooth user experience, these critical areas of mobile app security are often given short shrift. The consequences, though, can be dire. These security deficiencies enable hackers to take over accounts, compromise financial transactions, conduct screen overlay and man-in-the-middle attacks, inject code remotely, and create Trojans that look and feel like the real thing.

Securing These Exploits is Difficult
Closing such large security gaps requires a multilayered app defense made up of complementary and self-reinforcing features. To accomplish this, developers need to implement multiple app shielding techniques like anti-tampering, anti-debugging, anti-reversing, checksum validation, and app-integrity checking, all of which operate on different native and non-native API layers in the app. Data at rest must be encrypted using dynamic key-generation methods for data stored in the app sandbox and anywhere else data lives in the apps. Data in transit must be protected against man-in-the-middle (MitM) attacks by implementing certificate validation, certificate authority validation, and secure certificate pinning. Developers must implement obfuscation for native and non-native code, libraries, frameworks, classes, and objects, as well as app logic and debug info.

Encryption and obfuscation are difficult and complex but implementing them is much less painful than suffering a major hack, which could cause untold damage to a company's IT infrastructure, finances, and brand. It's worth taking the time to do them right.

Alan is VP Security Products at Appdome. A longtime product exec and serial entrepreneur, Alan has previously served as chief of product for Palerra (acquired by Oracle) and Arcsight (acquired by HP). View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-07-26
ArchiSteamFarm is a C# application with primary purpose of idling Steam cards from multiple accounts simultaneously. Due to a bug in ASF code `POST /Api/ASF` ASF API endpoint responsible for updating global ASF config incorrectly removed `IPCPassword` from the resulting config when the caller did no...
PUBLISHED: 2021-07-26
The CheckMK management web console (versions 1.5.0 to 2.0.0) does not sanitise user input in various parameters of the WATO module. This allows an attacker to open a backdoor on the device with HTML content and interpreted by the browser (such as JavaScript or other client-side scripts), the XSS pay...
PUBLISHED: 2021-07-26
In RPCMS v1.8 and below, the "nickname" variable is not properly sanitized before being displayed on page. When the API functions are enabled, the attacker can use API to update user nickname with XSS payload and achieve stored XSS. Users who view the articles published by the injected use...
PUBLISHED: 2021-07-26
In RPCMS v1.8 and below, the "nickname" variable is not properly sanitized before being displayed on page. Attacker can use "update password" function to inject XSS payloads into nickname variable, and achieve stored XSS. Users who view the articles published by the injected user...
PUBLISHED: 2021-07-26
In RPCMS v1.8 and below, attackers can interact with API and change variable "role" to "admin" to achieve admin user registration.