Log4Shell: An inventory


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 to the Y2K panic of the early 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) has therefore lowered the warning level for the gap 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.

However, admins should remain vigilant, according to a spokesman for the NCSC. It is to be expected that attackers will continue to search for vulnerable systems. In addition, it is likely that targeted attacks will continue to be carried out on unpatched systems for the foreseeable future.

What about the security situation of all the small and medium-sized businesses, public and private organizations or even individuals whose devices are affected? After all, Java is in everything, from the servers that power our clouds to millions of embedded systems in smart homes and industrial plants around the world. In the cloud alone, 93 percent of all corporate environments were vulnerable when the vulnerability was published, estimate the auditors from Ernest & Young and the cloud security startup Wiz. It is difficult to estimate how many self-administered servers, routers and smart home devices had or still have vulnerable Java loggers on board.

Holger Unterbrink, who is responsible for threat analysis at Cisco’s Talos Group, believes that the danger is far from over. Since the Log4Shell vulnerability became known, “only limited activities by attackers could be observed”, but this cannot be taken as an all-clear. Unterbrink sees “difficulties in finding and patching all vulnerable areas” at many companies that use Log4j. That in turn would give “perpetrators time to carry out complex, targeted and effective attacks.” So Log4j is just too common; Smaller companies in particular seem to be poorly equipped to secure their entire infrastructure.

The security company Sophos estimates that Log4Shell will be with us for years to come. Experts at the company suspect that a large number of systems – and the networks they belong to – have been compromised by successful Log4Shell attacks without this being detected. The attackers used the vulnerability to establish a beachhead without being noticed – so the theory goes – before the gap was closed. In such a case, the admins and security teams tasked with securing them may not have realized that those systems were already under the control of attackers because they established another backdoor and then played dead. In this case, patching the Log4Shell vulnerabilities is not sufficient. In other words, there could be an enormous number of unreported systems out there that look secure but are actually under the control of attackers and could become zombies at any time.

At the end of December, c’t editor Mirko Dölle came to a similar assessment: “State and criminal attackers have mainly used Log4Shell to install back doors and bridgeheads in previously highly secured areas as silently and undetected as possible. The actual attacks on the IT infrastructure through data theft or encryption Trojans and subsequent blackmail are still to come. Typically, attackers first explore their victims extensively before they strike – also because all admins are currently alert and pay attention to the smallest signs. In spring, when everyday life has returned and something Once grass has grown over Log4Shell, the hot phase is only just beginning.” Apparently, this hot phase has not yet started. But in the security community everyone seems to be waiting for the late effects of Log4Shell to become visible.

Unterbrink sees it similarly. Cisco Talos assumes “that attackers gain access to networks via Log4J and then remain inactive for months. Sophisticated threat actors usually use this time to explore the environment and plan further steps.” Unterbrink assumes that in the coming months security incidents will come to light “whose original infection vector was Log4j.”

Although Log4Shell is a really dangerous vulnerability, the large-scale public alert and the prompt action of those responsible, especially at the large tech companies, prevented worse from happening. Although threat scans and attacks have decreased significantly since the beginning of January, according to several anti-virus manufacturers, it must still be expected that there are still tens, if not hundreds of thousands of systems vulnerable to the vulnerability lying dormant on the Internet. Because an attack via Log4Shell always has to be fairly tailored to the program in which the logger is used, it could be that almost all systems that can be taken over fully automatically have already been attacked. However, systems that are still vulnerable can still fall victim to the vulnerability quite easily if an attacker takes the trouble to take targeted action.

If you have problems playing the video, please enable JavaScript

Likewise, there remains an impossible-to-assess unreported number of systems that may look secure but aren’t because they contain undiscovered beachheads from attackers from the first attack waves in December. Log4Shell will probably still cause a lot of unrest. However, not as some might have expected – in many places at once. Less publicity, but not necessarily less devastating.


(bme)

To home page



Source link -64