On the 9th of December, 2021 the world of IT security abruptly went into a state of shock. An alarming message was spreading like wildfire:

    RCE 0-day exploit found in log4j   

For the uninitiated, there is a lot to unpack here. “RCE” stands for remote code execution: similar to when somebody takes control of your computer with TeamViewer to run programs of their choosing. In this context, however, control is exerted without the consent, or even the knowledge of the owner.

A zero day exploit is a major software vulnerability, previously unknown to the developer. They must act quickly to develop a patch because, by the time the developer learns about it, adversaries could already be exploiting the opening.

The log4j library allows Java software to log (report) certain conditions, and is widely used in Java software. A vulnerability in it could allow an adversary to execute arbitrary code in the context of the underlying software.

Put it all together and you get this: at the time the above headline was published, a system tool used by companies all over the world – in cloud servers, game servers and financial platforms – was already being exploited by hackers, allowing them to take control of servers and data centers.

News spread fast about the staggering vulnerability

93% of the world’s cloud services affected

According to the Wall Street Journal, “U.S. officials say hundreds of millions of devices are at risk, hackers could use the bug to steal data, install malware or take control.”

One estimate stated that the vulnerability affected 93% of enterprise cloud environments. At EPFL, all IT administrators were sent instructions to patch their server software immediately. Even Oracle Corporation, world leaders in information security, had to send out a distress call:

“Due to the severity of this vulnerability and the publication of exploit code on various sites, Oracle strongly recommends that customers apply the updates provided by [our] Security Alert as soon as possible.”

It is hard to gauge the full extent of the damage caused, but it is clear that these vulnerabilities have real-world impact: among confirmed victims of the log4j bug are the Belgian Ministry of Defence, the UK’s National Health Service and a range of financial trading platforms. So the question begs itself – what are corporations like Oracle doing about it?

As a matter of fact, Oracle had already been working against this kind of vulnerability long before the log4j zero day. The log4j library uses deserialization: a server receives structured data (a form of code and object relationships) for processing. If the checks during deserialization are insufficient, and allow the attacker leeway in how the data is interpreted, it often results in RCE. Identifying the vulnerabilities exposed during the deserialization process had long been a subject of interest to Oracle researchers by 2020, when they reached out to Prof. Mathias Payer of EPFL’s HexHive lab:

“We had already covered fuzzing and program analysis, and had worked on cloud security as part of EPFL’s EcoCloud Center,” explains Prof. Payer, “but we had not approached these deserialization bugs.  Then we got to work with Oracle Labs (part of Oracle Inc) who provided funding via a gift. François Gauthier and Kostyantyn Vorobyov, two Oracle researchers from Oracle Labs introduced us to the complex technical issues that they were facing. And then we worked together, and developed a platform for discovering deserialization vulnerabilities.

“People have been attempting to find and exploit vulnerabilities in deserialization code, including Oracle’s, for years: either intent on gaining some kind of direct advantage, or to earn money by submitting bug reports. Either way, these are dedicated, manual attacks. In these manual attacks, the analyst thoroughly analyzes the source code of the target and then painstakingly crafts the exploit. What we have developed is a mechanism that automates the process, and allows Oracle to get ahead of the attackers.

Eight moves ahead, like a chess grandmaster

“In addition to this, the bugs that we are finding can be much more complex than the ones that experts are finding manually. Most analysts are trained to search to a depth of two manipulations: an entry and a control vector. Our platform creates an abstract dependency graph for all available classes, and can do a fuzzy search to a depth of up to eight manipulations.”

The battle between IT security managers and attackers is one where the defenders hope to find bugs before the attackers do. However, Prof. Payer explains that security managers have one key advantage when it comes to using HexHive’s platform: “Although our tool is neutral, i.e., it can be used by both attackers and defenders, developers have full access to and understanding of their own code, which gives them a huge advantage over a hacker when it comes to interpreting the results. They therefore have a very good chance of finding weak points before the attacker.”

Negotiations are under way to set up internships for HexHive researchers at Oracle Corporation. “This will be good for Oracle because they will have people who actually developed some of the code on site, which will make it easier to integrate the platform into their pipeline. Another thing I appreciate is that our prototype will remain open source, and bug reports will be published.”

So long as information technology is around, the battle between security managers and hackers will rage on. Thanks to their collaboration with HexHive, however, Oracle will be able to keep one step ahead of the aggressor: faster, higher, stronger.