Log4Shell: Taking stock | hot online


Many observers from the security scene rated the Log4Shell vulnerability as one, if not the greatest software vulnerability of all. Even the initial CVSS score of 10 made most admins startle and some security experts canceled their weekend plans at the beginning of December for this reason. The vulnerability in the Java logging framework Log4j is so perfidious because Java is in everything and in many cases attackers only have to write something in the log of a program in order to run code with admin rights on the corresponding system. And writing things to an application log is easy—often it can be done with a simple web request. With the Java version of the hit video game Minecraft, even a chat message in the game was enough.

Log4j does not simply write the data that comes from outside – and should therefore actually be considered potentially dangerous – into a log file. It deserializes these strings and treats the contents like Java objects, which are commands to be executed. At some point the Java developers thought that it would be useful if Java could reload configuration files from the network, i.e. also from the vast expanse of the Internet. So they invented the Java Naming and Directory Interface (JNDI) – which does exactly that: load Java objects from the network at runtime.

In the context of Log4j, however, JNDI becomes a large-caliber handgun aimed directly at one’s own foot. Because now an attacker can simply write a path to malicious code in their web requests or Minecraft chat messages. Unfortunately, Log4j does not simply write this path as text, but thanks to JNDI, interprets it as a command, gets the bad code onto the system and executes it. And because a logger usually has admin rights, the attacker has completely taken over the system with a simple request. Overall, this is more of a feature than a bug.

Given the mass of vulnerable systems and the ease with which attackers can exploit Log4Shell vulnerabilities, it is surprising that the big bang hasn’t materialized so far. Surprisingly, although a large part of the global Internet infrastructure was initially affected – including Amazon’s AWS, Google’s Cloud Platform, Microsoft’s Azure, Apple’s iCloud, Cloudflare’s servers and web services such as Twitter – there were no major failures. Only a successful attack on the Belgian Ministry of Defense and a series of hacks in which criminals installed ransomware and cryptominers made headlines. So far, the internet as a whole seems to have gotten off pretty lightly. Why is that?

After the first reports of the vulnerability, a mood of catastrophe spread like lightning – ironically above all on Twitter, which was still vulnerable at the time. As a result, the entire IT industry seems to have been shaken up at once. The English news portal The Register compare that with the Y2K panic at the beginning of the 21st century. Except that the corresponding message signaling pathway developed in minutes the effect that was achieved in months at the time.

It was immediately clear how widespread, dangerous and easy to exploit the vulnerability is. As a result, all those responsible for security who were reasonably well informed and worth their money immediately set about finding and securing vulnerable software in their area of ​​application or taking it out of circulation for the time being. At first glance, this collective effort by the IT industry seems to have been very effective. All major players with corresponding standard procedures (SOPs) and security policies apparently secured their systems against Log4Shell attacks within a short time at the beginning of December.

The Federal Office for Information Security (BSI) therefore has the warning level for the gap now downgraded from red to yellow. According to the BSI, the situation has “relented significantly”. The National Cyber ​​Security Center (NCSC) of the Netherlands also sees the threat situation as less worrying than in December.