Log4j: Why the security breach will keep the connected world busy for years to come
by Tina Siering
What lies behind the Log4j vulnerability?
The Log4j vulnerability became known on December 10, 2021. It was a zero-day vulnerability - meaning that operators only became aware of the exploit after criminals had already actively exploited it.
The weakness in Log4Shell allows attackers to inject and execute arbitrary code on the host system. In this way, systems that use Log4j are vulnerable. Criminals have launched several attacks and compromised numerous systems since the vulnerability became known.
How is the Log4j vulnerability exploitable?
What makes the vulnerability particularly dangerous is that it is relatively easy to exploit. For example, it is sufficient for the service to be accessible via the Internet. In this case, the attackers simply send manipulated requests to the services and hope for a response. In this case, it is possible to transfer the malicious code to the host system, obtain administrator rights and thus launch the cyberattack. In practice, attacks with ransomware as well as other malware have already been observed.
Due to this simple attack vector as well as the high damage potential in combination with the large distribution of Log4j, the German Federal Office for Information Security (BSI) rated the vulnerability with a red warning level on December 11 and issued a major alert.
What makes the Log4j vulnerability so threatening?
This vulnerability is so special and dangerous at the same time because of the way Log4j is distributed. Log4j is a Java framework that provides a single function. This is the logging of application messages. Log4j has established itself as the de facto standard for application message logging. Many applications need such a function.
At the same time Log4j is open source. Many programmers resort to such open source components to provide the desired function in their final product. This saves time and provides reliable functionality. For this reason, the framework is integrated into a large number of programs. As if that were not enough, Log4j is also directly integrated into numerous hardware components, as part of the firmware's basic functions. Logging messages is one of the functions that numerous devices require. These include routers and hardware in networks in general, as well as IoT and embedded systems. To make matters worse, Log4j has been around since 2013. Accordingly, the vulnerability goes back a long way, and all systems that have relied on the Log4j framework since that time are affected.
The integration of the Java framework into numerous programs and hardware is the real danger. It is impossible for users to determine whether Log4j is part of the software in use or not. This is especially true for companies and organizations. Their own IT infrastructure consists of a very large number of different software platforms and hardware systems. Since Log4j is not a standalone software, such as Microsoft Office or an FTP client, administrators in organizations face the impossible task of finding out whether Log4j is part of the systems in use.
Why is updating Log4j so complicated?
Most security vulnerabilities in programs are closed within a few days after they become known. The manufacturer of the software releases a patch, which in many cases even installs itself automatically.
The Apache project is responsible for Log4j, and they also closed the gap in Log4j in a very short time. The 2.15.0 update was released in December 2021 and prevents the security hole in the framework.
However, all applications that have Log4j integrated as a component must update and then distribute this update, as Log4j is not a standalone software. This means that programs are still vulnerable if they include the outdated Log4j library.
If the publishers of the software do not provide an update, the outdated Log4j version remains in use. Administrators are therefore currently faced with the task of identifying systems that use Log4j. In practice, this is more difficult than it seems at first glance. If you search for "log4j-core" via the package management, you will get an overview of the existing libraries and their versions. Then there is the possibility to search for updates for this software or to deactivate the programs in question.
In some cases, however, the publishers have also used modified versions and renamed them. In that case, a search will not return any results. To make matters worse, the modern IT infrastructure is highly fragmented. Microservices running in containers are a particular challenge. These have their own libraries that run in this environment. Although the damage caused by an attack on individual applications in isolated containers is limited, a successful attack here also disrupts operations or can result in serious data loss. Depending on the application, cybercriminals thus also have the opportunity to steal valuable or personal data.
The provider of the container software Docker has already released a plugin on December 11, 2021, which can be used to scan its own containers for a Log4j installation. However, this scan only finds the libraries if they are not packaged in a Java archive. For these reasons, searching for the Log4j version does not provide an absolutely reliable result, but it is a first and important step in identifying vulnerable platforms.
Thus, in the case of software, administrators still have the opportunity to react to the situation. Network components with integrated software are of greater concern. For these, there is usually no access to the software. Users are therefore dependent on updates from the manufacturer. Cisco, who are known for professional network technology, have already released the first patches for their own hardware, as has Ubiquiti. Both manufacturers have simultaneously confirmed that their own products are affected and vulnerable. However, for some of Cisco's products, it will take until 2022 before security updates are available.
At this point, the whole dimension of the security vulnerability becomes apparent. All versions of Log4j from 2.0-beta9 up to version 2.14.1 are affected, which covers a period from September 2013 to December 2021. All software or hardware that uses Log4j and was released during this period of more than eight years is impacted. In many cases, vendors have long since stopped releasing updates for their own products, or they no longer exist at all. This can apply to older network technology, for example. Then it is impossible for users to close the security hole.
What does the situation imply for the future?
Currently, it is impossible to estimate how many programs and network components are affected. Manual scanning is time-consuming, complicated and does not provide reliable results. For this reason, IT security experts agree that the Log4j vulnerability will continue to be exploited as a gateway for cyberattacks for many years to come. Moreover, the exploit has been used in the first instance by professional hackers for targeted attacks. These include, for example, data espionage or secretly setting up a backdoor. If such actions remain undetected, there is a threat of future attacks via the already laid access points – regardless of the Log4j status.
In addition, the fact that the attack vector is now publicly known means that all criminals now know the method. It is therefore to be expected that the volume of attacks will increase and that users will fall victim to the attacks indiscriminately. In the case of attacks by regular cybercriminals, it is also likely that they will increasingly rely on extortion with ransomware, which will lead to significantly higher direct damage to the IT infrastructure.
Which options are there to protect yourself?
Administrators and responsible parties are in a race against time and cybercriminals. The potential for damage is enormous, because attackers have the opportunity to gain full access rights via the gap and initiate ransomware attacks.
As a first step, it is important to deploy systems for early attack detection, if this is not already the case. Such solutions actively scan the activities in the network and look for conspicuous actions. This is done permanently and in real time. Among the activities that attack early detection systems find are attempts to attack the Log4j vulnerability. This is done with specially modified strings that attackers use to exploit the vulnerability. Likewise, the attackers then access the network and perform suspicious actions. Such activities are visible in the logs of network devices and programs. However, manual control is impossible due to the amount of data. Attack early detection software takes over this task and monitors even complex networks in real time.
The Active Cyber Defense Service (ACD) from secion is such a service solution. secion provides this service via the network. Local installation or changes to the systems are therefore not necessary. secion's ACD service monitors all systems within a network, from databases to services for authentication to IoT devices at the edge of the network, and reports identified anomalies. If necessary, the secion analyst team immediately informs the responsible persons in IT Security of the company concerned. In this way, it is possible to detect attacks almost in real time, before any damage is done - and without the need for enormous investments in the company's own IT department.
The second task is to identify as many of the vulnerable systems as possible. While this is a labor-intensive task, there is currently no alternative to finding the affected systems. A method for testing one's own network components is available at canarytokens.org. Here, harmless JNDI calls, which are structured like the attacks on the Log4j gap, can be sent to the network devices. If these react and are thus vulnerable, it is possible to remove the devices from operation immediately. However, even this method does not provide complete security.
Conclusion on the Log4j security vulnerability
The combination of a vulnerability that remained undiscovered for so long, a component that is extremely widespread, and the enormously high potential for damage as well as a simple attack vector represents a major disaster in IT security. It is difficult to impossible to protect against cyberattacks via the vulnerability. This depends primarily on the complexity of the company's own network structures. It is therefore all the more important that companies and organizations initiate measures for early attack detection now at the latest. In situations like this, early attack detection is the last line of defense against cyberattacks via undetected security gaps.
We provide a daily updated list of all callback domains and more information on the topic inside this related blog arcticle.