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.
Attendee 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.
OWASP AppSec USA Attendees will leave this presentation with a working knowledge of how the next generation of application security solutions will be used against code injections. In the future, web-based applications will be protected by highly accurate, easy to operate virtualized technology in the runtime.
Speaker
John Matthew Holt CTO and Founder, Waratek John Matthew Holt is the founder and CTO of Waratek. A JVM/JIT compiler engineer, John Matthew is a recognized expert in Java, virtualization and application security.
This presentation was given at OWASP AppSec USA Security Conference in Orlando.
