As long as there has been a commercial internet, cybersecurity has largely been predicated on the concept of guess work, better known as Heuristics. Looking for patterns or matching words and phrases that were close enough to known or variations of known vulnerabilities/attacks have been the norm. These solutions are, by definition, trial and error.
But with a seemingly never-ending increase in vulnerabilities, hackers and attacks, the cyber security status quo is simply not sufficient to provide the level of certainty needed to instill confidence and improve reliability in an app driven, interconnected world. We need higher accuracy, less complexity and more simplicity as more devices, applications and individuals join the internet.
The inspiration for one powerful new solution can be found in the past – in a seemingly unrelated technology.
Attacking the OS to get to an app
Back in 2001, hackers were still largely amateurs who created malware or penetrated systems for fun or academic credibility. The first DoS attacks occurred that year and so did a new approach to OS security: Address Space Layout Randomization or ASLR.
ASLR is now a standard component of most mainstream operating systems, from MS Windows and Apple OS to Android and even Nintendo 3DS. Before ASLR was adopted, OS address locations were well known or easy to predict by hackers looking for an avenue of attack.
The approach of the PaX Project to block these attacks was deceptively simple: randomize the address of OS processes. If a malicious attacker entered a wrong address location, the target application would crash, the exploit would be halted and a sys admin might be alerted.
Now comes Name Space Layout Randomization – NSLR
Name Space Layout Randomization or NSLR is the equivalent of ASLR for Java-based web applications. To be successful, a malicious attacker who wants to introduce a Code Injection exploit in Java needs to know the exact names of classes and packages to be invoked. Making the Java class packages non-deterministic, or randomized, defeats any code injection exploit.
For example, with NSLR enabled, the java.lang.System class will be randomized and renamed to something like java$85rbuLjHNERijUhN.lang.System. Any exploit that tries to invoke java.lang.System will automatically fail. For attackers to successfully execute an attack they would need to know the randomized package name which changes each time the JVM boots.
Attempts to brute force the system and retrieve the randomized package name is not feasible, either. Waratek’s standard configuration includes NSLR with a minimum level of security at 96-bit names, which would require several thousand years to crack the encryption. Namespaces can be randomized up to up to 1024 bits.
A code injection attack attempted in an NSLR enabled JVM will generate a ClassNotFoundException, ending the attack.
NSLR is the kind of emerging security solution that could be the replacement for heuristics we’ve all be waiting to arrive.
