• United States



Container security: How Waratek blocks Java exploits

Jul 31, 20176 mins
Application SecurityJavaSecurity

Waratek relies on just-in-time compiling and focuses exclusively on one of the biggest security risks within most organizations: applications running Java.

secure container java box circuitry
Credit: Thinkstock

In general, container cybersecurity works by creating a virtual machine to host a protected application and then restricting what it can do to reach out of that container. Because of its reliance on virtual machines, containerization only recently became popular because of cloud computing, which also relies heavily on virtualization.

Waratek is entering this space from a completely different angle compared to other container security firms, relying on just-in-time compiling and focusing exclusively on one of the biggest security risks within most organizations, applications running Java. Coming to the security space from the prospect of compiler engineers gives the Waratek software a unique flavor and approach that has been overlooked and unexplored by most other companies.

Java applications are divided into two components: You have the baseline Java 8 or 9 stack, which hosts the app and provides the garbage collector process. For the most part, that section is fairly simplistic and completely secure. And then you have the upper layer, which is comprised of the actual code of the running application, plus all the support programming to give it interactivity. The upper layer can consist of millions of lines of code and can be based on any version of Java going all the way back to Java 4. It’s potentially very insecure and os often the focal point for common attacks like SQL injections used to steal information inside protected databases.

The Waratek Application Security Platform leaves the baseline, secure part of Java alone and concentrates on containerization of the upper part of the stack. It uses runtime application self-protection (RASP), to defeat and prevent real-time attacks. Once installed, Waratek creates a RASP container that virtualizes the entire application portion of the stack, separating it from the host Java virtual machine and the system OS. The virtualized application stack sits on top of the Waratek security controls, enabling users to direct how applications can be used and what exploits to block from ever leaving the container.

Installing the Waratek platform on our test network was extremely easy. First, the main Waratek console needs to be installed. It can run on-premises or in the cloud, though according to Waratek engineers, most of their clients prefer it installed on site so they can keep all of their security tools together. Once that is ready, several lines of code need to be added to the default configuration file to affect all Java apps. The new code basically pushes an agent out to each application, instructing the apps to link up with the console, and to create the container around the application stack.

Waratek 1 deployed John Breeden/Waratek

This shows the simplicity of deploying the Waratek agents. It’s only a few lines of code, basically telling apps to check in with the Waratek console before spinning up.

Back at the console, a list of the apps that have checked in can be examined. The final step is to authorize the connection and program the security. This is all done with a nice graphical interface in only a few clicks.

Waratek 2 main console John Breeden/Waratek

The main console of the Waratek platform is mostly used to configure app containers. It also records attempted attacks against apps, but there is no need to respond given that all attacks against a protected container will fail.

To test the Waratek platform, we first conducted a SQL code injection attack against an unprotected app, trying to get it to spit out the fields of a protected Oracle database. This was extremely easy, and in no time we were looking at lots of simulated, protected PII.

Then we activated Waratek security and placed the app stack in a virtualized container. When assigning security for SQL injections specifically, you can either simply deny them all, or you can dive into specific types of SQL injection techniques like Network:Bind, Path:Traversal, Redirect:Servlet and others. Each one can be set to warning, deny or allow, taking the appropriate action. This could be helpful if someone wanted to allow a specific type of SQL injection, such as for debugging purposes, though it’s probably highly unlikely. We locked them all down, setting them to deny. 

Qaratek 3 SQL injectection John Breeden/Warakek

Here an unprotected app falls to a SQL code injection, returning the names and information contained inside a protected database.

After that, we repeatedly tried to induce different types of SQL injection attacks, with error messages returning each time. On the backend, all of our probing was recorded by the Waratek platform, and that data could also be shared with a SIEM like Splunk if needed. Because Waratek blocks specific actions in all cases, it’s nearly impossible to generate any type of false positive. Either a user tries to implement a restricted process within the container, or they don’t. Waratek even offers customers $10,000 for every single false positive their system produces, and say they have never had to pay out even once.

Waratek 4 SQL halted John Breeden/Waratek

Once each Java app is containerized, they become invulnerable to any code executions outside of their approved parameters. Here, the same attack from before has failed, and the console notified about the attempt.

It’s also interesting to note that the Waratek platform works by utilizing real-time memory tracing that marks all user-input data sent to a Java app, such as HTTP request parameters, as untrusted. When that untrusted data is converted to structured grammar, the tainted lexical analysis easily identifies it as malicious. So Waratek doesn’t need to rely on heuristic or pattern matching, and there is no need to change the code of the core program. The memory-tracing feature is very lightweight in terms of system resources, only adding, at most, 2 percent more load to the application.

One final advantage to the Waratek platform that moves a bit outside of the cybersecurity arena is the fact that the virtualized RASP containers separate the app from the core of Java and the OS. Because of that, it can be used to help keep aging programs working, even if they are incompatible with newer versions of Java. Organizations can thus upgrade to Java 9, and use the Waratek containerization technology to keep their aging apps in place, even those written to work with older versions of Java, down to Java 4.

Right now, the Waratek platform only works with Java, though implementation and containerization for .NET architectures is due later this year. Pricing for the platform is a reasonable subscription model based on how many virtualized RASP containers the software needs to produce for the host organization, so completely pay as you go.

Java is an incredibly useful language, but its complexity and flexibility also opens a myriad of security holes that require constant patching and monitoring. The Waratek Application Security Platform can eliminate those vulnerabilities, locking down applications with a secure containerization technology that is guaranteed to do its job perfectly without any false positives.