Popular Approaches to Preventing Code Injection Attacks Are Dangerously Wrong

DZone 's Guide to

Popular Approaches to Preventing Code Injection Attacks Are Dangerously Wrong

Name Space Layout Randomization (NSLR) is promising to make code injection attacks a thing of the past, and vastly increased Java-based AppSec.

· Security Zone ·
Free Resource

According to the 2016 Verizon Data Breach Investigation Report, web application attacks are the top source of data breaches today. During the past decade, address space layout randomization (ASLR) has become a feature present in all major OS and a significant guard against buffer overflows and similar attacks by randomizing the location where system executables are loaded into memory.

While ASLR has been effective at the OS level, the principles have not been applied as a means of securing managed virtual machines and runtime environments. Traditional heuristic methods of protection are increasingly ineffective, requiring new approaches to application security. This talk will explore the past, present, and future of Java-based application vulnerabilities before sharing a newly developed technology created as a runtime solution to specifically address code injection attacks as a class.

Name Space Layout Randomization (NSLR) is based on the same principle as ASLR but applied for the first time as an application security feature for the Java runtime. NSLR hardens the Java virtual machine (JVM) by randomizing the JRE namespace (Java packages). Using NSLR inside the JVM, the ownership of bytecode loading is standardized and unvalidated bytecode fails to be executed. In effect, this makes bytecode tampering and a range of code injection exploits so difficult to execute that they become unfeasible, protecting against known and unknown vulnerabilities, including zero-day exploits.

The Problem

Current approaches for protecting against known code injection attacks in applications that run on managed runtime environments involve applying a patch, fixing the vulnerability, or disabling the flawed functionality, if possible.

Alternatively, web application firewalls can mitigate some threats but are often plagued by false positives. Zero-day attacks are notoriously difficult to protect against since they are, by definition, unknown exploits.

The Solution

We will present a novel approach to dealing with unvalidated bytecode tampering and a range of code injection attacks. With NSLR enabled, JRE packages and classes such as the java.lang.System class are randomized and renamed. Therefore, any exploit that attempts to invoke java.lang.System will fail because it will not know the new randomized package name. Since NSLR generates a unique package name every time the JVM boots, it is impossible for attackers to guess the new randomized names. Also, it is impossible to access the randomized host package name from the application, since this randomization is not visible to it.

The randomized host package names are transparent to the guest applications and cannot be viewed or accessed from the JRE. In addition, NSLR prevents brute force attacks by using customizable high entropy (96 to 1,024 bits), which would likely require several thousands of years to crack. Finally, NSLR identifies when a code injection attack is attempted, logs the event, and throws a ClassNotFoundException that gracefully terminates the attack.

To summarize, NSLR hardens the JVM by randomizing the JRE namespace, which prevents unvalidated bytecode tampering and a range of code injections from executing regardless of the attack vector and the vulnerability (known or zero-day) that is being exploited.

This approach provides absolute protection against both known and unknown code injection vulnerabilities with zero false positives and does not require any changes to the application code.

Key Takeaways

Unvalidated bytecode tampering and injection in the JVM is a type of code injection attack that was never addressed properly. Code injection attacks rank 6th among 2055 known vulnerabilities according to MITRE.

Currently, the most common approach to protecting against them is to identify and fix/patch those vulnerabilities. This is not ideal, and may or may not be feasible. A firewall, IPS or WAF can be used to try to mitigate code injection attacks, but they are often plagued by false positives. More importantly, all the mainstream JVMs lack the appropriate mechanisms to identify and protect against these types of code injection attacks.

security ,appsec ,code injection ,vulnerabilities ,cyberattack

Published at DZone with permission of John Matthew Holt , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}