NewsyList

Log4Shell vulnerability: Internet on fire

The explosiveness cannot be overestimated; comparisons with Hafnium, Heartbleed and ShellShock are certainly appropriate: The Log4Shell security gap that became known on December 10th is one of the most serious and far-reaching in the last ten years, the real impact of which cannot be assessed days and weeks later leaves.

The vulnerability has existed since September 2013 and lies dormant in countless Java apps on servers all over the world. But not only servers are affected, vulnerable versions of Log4j have also been discovered in some clients and in network equipment such as routers and WLANs. And because the gap has existed for so long, a number of embedded and IoT systems, including those from the smart home sector, are likely to be affected.

news.newsylist.com/Magazin-Banner/ct_mobil.jpg" style="aspect-ratio: 1200 / 693;" width="1200">

More from c't magazine

news.newsylist.com/Magazin-Banner/ct_desktop.jpg" style="aspect-ratio: 1830 / 500;" width="1830">More from c't magazine

More from c't magazine

The high level of explosiveness is mainly due to the fact that Log4Shell is extremely easy to use. It is usually sufficient for a server service to be accessible from the Internet in order to gain access with administrator rights and to be able to execute any code. When the BSI (Federal Office for Information Security) found out on December 11th that malicious code can even be inserted directly into the first request, it upgraded the gap to warning level red and triggered a major alarm.

This is the nightmare for every admin, because now it was no longer only systems that had direct internet access that were considered vulnerable – malicious code could also reach database servers in the backend, which for security reasons are incarcerated behind firewalls and cannot establish any internet connection themselves.

All the fuss is due to a small but momentous vulnerability in the Log4j library. Log4j is the Swiss Army Knife for all logging tasks in Java, roughly comparable to stderr in C or logging in Python. In circulation for over ten years, tried and tested a million times, suitable for all use cases from ten-liner to business-critical enterprise apps. And that was exactly the crux of the matter: When version 2.0 of Log4j was almost completely redeveloped in 2012 and 2013, a JNDI handler (Java Naming and Directory Interface) was upgraded in July 2013 in response to a feature request from LOG4J2-313. Log4j could no longer only be configured via the system settings or the environment, but also via a local XML file. The automated JNDI test, which was added as part of the patch for the JNDI handler in Log4j in version 2.0-beta9, also checks this way of working.

What the Log4j developers apparently overlooked then and for eight years everyone else: JNDI is an even bigger Swiss Army knife than Log4j. Using JNDI only to reload local XML configuration files is like using the legendary Wenger Giant with its 87 tools as a nail file – that works, but is only one of 141 functions. Because JNDI can not only access local resources, but also masters a number of network protocols in order to be able to obtain files from central configuration servers in a data center using LDAP in the case of Log4j – or from the Internet, if the specified URL refers there.

In Log4j, the JNDI handler processed all log data and examined them for instructions to reload files. These instructions have the form $ {jndi: ldap: //127.0.0.1: 1389 / a} – where JNDI also resolves host names via DNS and then reloads the data from an external server. Whenever such a character string should be logged, Log4j loaded an external file via JNDI and executed its code.

With Apple’s iCloud, for example, the device name served as a gateway: if the “magic character string” was added to the device name, Apple’s server downloaded code from the specified URL. For many other services, it was sufficient to include the JNDI instruction in the HTTP header or to change the browser’s user agent accordingly.

The Minecraft game servers were among the first to fall victim to the JNDI vulnerability in Log4j. Here it was even enough to send the “magic string” as a simple chat message to another player in order to take over Minecraft servers. But not only the servers were at acute risk, the Minecraft Java clients also contained the Log4Shell vulnerability. This officially confirmed for the first time that Log4Shell by no means only affects servers, but also private users.

The only difficulty for attackers was to find a way to be perpetuated in some log, to start a Bash or PowerShell and then take over the computer – hence the name Log4Shell. The servers of practically all well-known companies were affected, from Amazon to VMware – suddenly the entire Internet was ablaze.

“The internet just went up in flames.”
Adam Meyers, Senior Vice President of Intelligence, Crowdstrike

As a result, admins all over the world competed against criminal as well as state attackers to close the Log4j gap before backdoors and bridgeheads could be installed, for example for future ransomware blackmail. It was by no means trivial for admins to find all the vulnerable services, and it was even more difficult to close the loophole until updates were available and tested. Because applications no longer only use the libraries made available system-wide by the respective server. It is therefore not sufficient to search for older versions of the log4j-core library via the package management, for example.

Today applications often run as Docker containers or otherwise virtualized, where they bring their own set of libraries with them. In order to be able to track down vulnerable versions of Log4j in containers, the Docker project delivered an update of the plug-in “docker-scan-plugin” on December 11th. However, docker scan only finds vulnerable Log4j installations if they are not in a Java Archive (JAR) or if they are even hidden as a JAR in a JAR. Flatpaks, Snaps and AppImages also bring heaps of their own libraries with them, the version of which is regularly unknown. If there is only one vulnerable version of Log4j among them, the entire computer is vulnerable.

Some of the network components are also affected by Log4Shell. Cisco, for example, reacted quickly and has already identified a number of vulnerable products, but some updates should not be available until the new year. Ubiquiti also confirmed the Log4Shell vulnerability in its UniFi Network Application early on and fixed it on December 11th. Among other things, the program is responsible for the authentication of WLAN guests and is therefore also vulnerable on site via the WLAN. UniFi Access Points can be found in countless hotels, medical practices, bank branches, at companies, hairdressers and also at many private users.

The number of embedded and IoT systems in which Log4Shell is hidden has so far hardly been investigated. Java is extremely widespread in this area, for example in smart homes, but also in electronic locking systems. The main problem here is that the vulnerability in Log4j goes back eight years – this could also affect older systems that were sold years ago and for which there have long been no updates. There is just as little source code here that one could look into, as there is no possibility of logging into the systems and checking the version status of the libraries.

One could think that one would only have to send the device concerned a browser request with the “magic character string” in the user agent to find out whether it is affected by Log4Shell. However, what is specifically logged and whether code was reloaded is not displayed. That is why so-called canaries are used.

At canarytokens.org, for example, you can generate harmless JNDI calls for the Log4j vulnerability free of charge and receive an email if a vulnerable system tries to reload code (but also if a link preview from a browser or messenger tries to find the host name dissolve). But this method does not go far enough, because the user agent does not always end up in the log, and sometimes the connection is not established either, but only a successful login attempt. It is therefore possible that Log4Shell cannot be used via the user agent, but only via the user name when logging in or the host name of the test system set in the DNS resolver. There are no generic tests that can be used to track down all the vulnerable Log4j libraries from outside.

Log4Shell is undoubtedly one of the most far-reaching and serious security vulnerabilities in the last ten years. The admins are currently working flat out to fix vulnerable servers and to put successful attackers back on the doorstep. The vulnerability will keep admins and developers busy for months and will result in thousands and thousands of updates. Private users also have to stay on their toes and quickly import the updates that are pending for them for routers, WLANs, NAS and smart homes.

This is only the tip of the iceberg: State and criminal attackers have mainly used Log4Shell to install back doors and bridgeheads in previously highly secure areas as silently and undetected. The actual attacks on the IT infrastructure through data theft or encryption Trojans and subsequent extortion are still to come. Typically, attackers first research their victim extensively before they strike – also because all admins are currently alerted and watch out for the smallest signs. In spring, when everyday life has returned and some grass has grown over Log4Shell, the hot phase should only begin.

news.newsylist.com/imgs/18/3/2/3/9/6/2/1/titelcover_2-22-6f7ba8de1274c605.JPG" style="aspect-ratio: 1017 / 1433;" width="1017">

In c’t 2/2022 we have put together the c’t Emergency Windows 2022 for you. With the kit for the system running from the USB stick, you can find viruses, save data or reset passwords. We shed light on how the EU wants to use loopholes of the GDPR for content scanners, we tested high-end smartphones, mobile USB-C monitors and server software for private media collection. Issue 2/2022 is available from December 31st in the Heise shop and at the well-stocked magazine kiosk.


(mid)

To home page

.

See also  This sensor takes color photos in the dark

Share:

Facebook
Twitter
LinkedIn

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Social Media

Most Popular

On Key

Related Posts