Encryption’s Unfortunate, Unavoidable, and Unfix-Able Gap – And How to Fill It

Encryption stands as information’s last line of defense when perimeters are breached, identities stolen, and malware launched. Without effective encryption policies, you will first be victimized and then held liable (punished) by every information stakeholder (customers, partners, investors, regulators, the courts, etc.).

Just this week, Wired led with the headline Tinder’s Lack of Encryption Lets Strangers Spy on your Swipes where they wrote in part:

“In 2018, you’d be forgiven for assuming that any sensitive app encrypts its connection from your phone to the cloud, … But if you assumed that basic privacy protection for the world’s most popular dating app, you’d be mistaken.”

Whether or not Tinder faces any legal or regulatory jeopardy, the press coverage in Fortune Magazine, Wired, and even my local morning news shows cannot be doing their market share or brand any good.

For a longer treatment of another encryption catastrophe that resulted in $300M in fines and other expenses, see the sidebar “Punishing the Victim: Anthem data breach” inside The Six Degrees of Application Risk.

The hard truth is that when data is stored in the clear (unencrypted), it cannot be secured, and every information stakeholder knows this to be true (including bad actors). That is why, even though it is too early to predict what civil, criminal, or market penalties Tinder will face, the reporter’s incredulous disbelief is so pronounced.

Best practices dictate that sensitive data be encrypted whenever and wherever possible.

• When data is at rest (in files and databases—and especially with portable media) and
• When data is in motion (transmitted between applications, services, and networks—and especially over public networks—as with the Tinder example above).

However, there is one unfortunate, unavoidable, and unfixable hole in the encryption story. When data is in use (being processed by an application rather than sitting on a disk or flying across a wire), it must be processed in the clear.

In fact, as encryption policies become increasingly effective, hackers are inexorably drawn to the next best thing, application hacking as the attack vector of choice.

THE UNFORTUNATE, UNAVOIDABLE, UNFIXABLE ENCRYPTION GAP

Fortunately, even though data-in-use must be processed in the clear, that data is typically found only in app memory. Reading data in memory requires specialized utilities, and access to those tools can be limited. Debuggers are the hacker’s favorite because, in addition to accessing unauthorized data, they have the added advantage of modifying a running application to circumvent identity verification, authorization, and other critical controls.

…and every stakeholder—especially hackers, regulators, and the courts—knows this to be true, too.

Mitigating the encryption gap

Since data in use can’t be encrypted, the next best strategy is to restrict the unauthorized use of debuggers, rooted mobile devices, emulators, and other tools that hackers rely upon to access and modify application-resident data. Preventative, detective, and responsive controls combine to secure your applications and—by extension—the data that flows through them.

PREVENTION: Where possible, use OS and compile-time configuration settings to disable debugging and prevent remote code execution. Mobile devices, web app servers, build settings, etc., include these options to prevent these exploits.

While effective as a first line of defense, these settings can be overridden, bypassed, and/or modified (assuming they are set properly in the first place). To effectively secure sensitive data-in-use, additional controls are required to detect and respond when hackers attach debuggers or tamper with an app.

DETECT & RESPOND at a minimum to the following three progressively material scenarios:

1. Configuration values prohibiting debugging and preventing remote execution are NOT properly set (making it especially easy to execute this kind of exploit)
2. A debugger is attached to a running app processing sensitive data (indicating that an attack is in progress or, at a minimum, unauthorized probing is underway), and lastly
3. An app has been modified/tampered with post-build (suggesting that there has been a successful hack and the resulting compromised version is executing).

Securing apps and the data that flows through them

Writing code to enforce these policies is time-consuming, requires new development skills, must be coordinated across development teams, and potentially introduces additional runtime risks.

There is a better way: post-compile injection

As offered by PreEmptive Solutions Dotfuscator for .NET and DashO for Android and Java, post-compile injection of anti-root and anti-tamper, and various related runtime controls, offers a compelling alternative to coding.

Dotfuscator and DashO Injection advantages include:

• As a post-compile step, anti-debug and anti-tamper functionality can be included in a DevOps tool chain, simplifying development tasks and injected into existing executables and libraries by rebuilding rather than coding.
• Little or no additional development effort is required.
• Root detection and other evolving algorithms are continuously updated to keep up with new platforms and attack strategies.
• While most of the injected functionality can be considered “turnkey”, there are also, by design, straightforward extensibility points to support the inclusion of proprietary defenses and reporting capabilities.
• The configuration file that dictates how and where controls are injected serves double duty as an audit trail as you harden your code.

Application development compliance and the law

Security standards bodies, regulators, legislators, and the courts recognize the necessity of securing data in use. In addition to increasing the risk of a data-related breach, failure to implement appropriate, well-understood, and accepted security controls will almost certainly result in increased liability, fines, and dissatisfaction.

For illustration, consider the following excerpts from regulatory, legal, and standards bodies that demonstrate the general acceptance of these principles.

Financial Compliance

PCI Mobile Payment Acceptance Security Guidelines for Developers • September 2017

4.3 Prevent escalation of privileges

Controls should exist to prevent the escalation of privileges on the device (e.g., root or group privileges). Bypassing permissions can allow untrusted security decisions, thus increasing the number of possible attack vectors. Therefore, the device should be monitored for activities that defeat operating system security controls—e.g., jailbreaking or rooting—and, when detected, the device should be quarantined by a solution that removes it from the network, removes the payment-acceptance application from the device, or disables the payment application. Offline jailbreak, root detection, and auto quarantine are key since some attackers may attempt to put the device offline to further circumvent detection.

Hardening of the application is a method that may help prevent escalation of privileges in a mobile device.

Controls should include, but are not limited to, the device’s capability to produce an alarm or warning if an attempt is made to root or jailbreak it.

Privacy Legislation

General Data Protection Regulation (GDPR)

Recital 83 Security of processing

To maintain security and to prevent processing in infringement of this Regulation, the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption. Those measures should ensure an appropriate level of security, including confidentiality, considering the state of the art… In assessing data security risk, consideration should be given to the risks presented by personal data processing, such as … unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed…”

Application Security Standards

Open Web Application Security Project (OWASP)

OWASP Mobile Application Security Verification Standard v1.0

V8: RESILIENCE REQUIREMENTS: Control objective: Impede Dynamic Analysis and Tampering

8.1 The app detects and responds to the presence of a rooted or jailbroken device by alerting the user or terminating the app.

8.7 The app implements multiple mechanisms in each defense category.

8.8 The detection mechanisms trigger responses of different types, including delayed and stealthy responses.

You don’t need to be the fastest, but you cannot afford to be the slowest when running from the bear

If you care about data at rest and data in motion, then you need to care about data in use—it’s the same data and brings the same responsibilities, risks, and liabilities.

If your organization develops software, you need to ensure that you have implemented appropriate data-in-use controls throughout your application and DevOps lifecycles.

You will also want to update your supplier risk management checklist to ensure suppliers take equivalent steps to secure your “data in use” inside their applications and services.

Do not be the slowest running from the bear—vulnerabilities stemming from “data-in-use” exploits are a real and present threat.