Encryption’s unfortunate, unavoidable, and unfix-able gap - and how to fill it

When perimeters are breached, identities stolen and malware launched, encryption stands as information’s last line of defense. 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) that data 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).

There is, however, one unfortunate, unavoidable and unfix-able 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), that data 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, UNFIX-ABLE ENCRYPTION GAP

Fortunately, even though data-in-use must be processed in the clear – that data is typically found only in app memory – and 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 being able to modify a running application to circumvent identity verification, authorization, and other critical controls as well.

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

Mitigating the encryption gap

Since data in use can’t be encrypted, the next best strategy is to restrict 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 precisely these kinds of 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 must be addressed:

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 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 a variety of 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 into a DevOps tool chain simplifying your development’s 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 new 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, and
• The configuration file that dictates how and where controls are injected do double duty by serving 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 to secure data in use. In addition to increasing your 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. (Emphasis added)

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 to be made, 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 and root detection and auto quarantine are key since some attackers may attempt to put the device in an offline state to further circumvent detection.

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

Controls should include, but are not limited to providing the capability for the device to produce an alarm or warning if there is an attempt to root or jailbreak the device.

Privacy Legislation

General Data Protection Regulation (GDPR)

Recital 83 Security of processing (Emphasis added)

In order 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, taking into account the state of the art… In assessing data security risk, consideration should be given to the risks that are 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 either 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 it brings with it 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 that suppliers are taking 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 is a real and present threat.

For .NET developers that want to get into implementation detail, here’s a terrific article from November’s MSDN Magazine that includes links to sample code.

(Java and/or Android developers, contact me for some platform specific instruction options)

For continuing updates on topics related to development and compliance, consider registering for one of PreEmptive's ongoing webinars.