A new spectre in the IT world
If you want to put it innocuously, a new specter is once again haunting the security world of IT. The Java library log4j threatens to become a serious problem for countless systems and programs (National Vulnerability Database -NVD- CVE-2021-44228). Affected are the Java log4j libraries from version 2.0.1 to 2.14.x (version 2.15.0 is already fixed but contains further vulnerabilities, version 1.x is not affected). In the meantime, version 2.16.0 is also available, which should definitely be used. An update to the latest version is strongly recommended wherever possible.
To avoid mistakes – the log4j is a library of the Apache Software Foundation (Open Source Software), which is not automatically used or installed by every Java version. Therefore, to upgrade log4j to the latest version, it is not sufficient to simply install the latest and most recent Java version. The latest version of the log4j library can be found on Apache’s website.
Also, the BSI (German Federal Office for Information Security) has already declared warning level red (IT threat level 4) (link to german webpage) over the weekend. This means that the IT threat situation is classified as extremely critical. A consequence of this is the failure of many services and regular operation is also not possible.
The use of an affected Java version does not necessarily mean that the problem is present. The program or device using these versions must also have the logging feature enabled. If this function is not used, one is safe on this device or system for now. The problem with this, however, is that you cannot simply check whether the Java function is being used or not. Any logging can also be done in a different way and does not necessarily have to be done via the Java library log4j.
To paraphrase: The affected devices or programs do not even have to be a direct part of the attack themselves. If a system uses the log function of the Java library log4j, it not only logs the events, but also tries to interpret the log text. This can be software that logs e-mails with this log library, for example, such as an internal ticket system.
Here, the interpreter can contact an external server from which the device accepts Java code.
A more detailed analysis of the problem can also be found at the IT specialists of heise.de (german blog).
Docusnap is not affected by the problem
Our Docusnap experts also set out first to check possible points of attack in Docusnap. Therefore, we may announce at this point right away that Docusnap is not affected by the vulnerability. Neither the server components nor the frontend are vulnerable to the attacks. This Java technology is not used in our documentation software.
Java is very widely used
Even though we as developers of Docusnap are not directly affected by this and none of our customers need to worry about this, there is a real danger in our own IT networks and IT systems due to the variety and enormous number of systems and programs used. Even large and widespread vendors, such as VMware, use affected Java libraries for logging.
The manufacturers of the devices and software are currently trying to clarify whether a system is actually affected and therefore vulnerable. This can take weeks or even months under certain circumstances. And it is not guaranteed that all older devices, which use this log function of Java, will receive an update in the near future or will be found in various lists at all.
As a result, a lot of uncertainty is currently spreading among IT managers and important questions are being asked: can we trust our systems? Are our systems affected? And if so, how do we track them down?
As with the Exchange exploits (german blog) from earlier this year, the approach taken by some when such incidents occur, namely to sit out the threat, is not a good idea.
First measure – inventory: what all do we have in place?
In a professionally managed IT department, there is at least accurate documentation and an inventory of all IT systems in use. The first step is to determine which devices are in use in the company’s own IT network (and also in the individual locations). Not only are the manufacturer and device designation necessary, but in this case the version numbers of the device firmware are also crucial. If this information is not available in the documentation, the first measure for IT managers already begins. Determining which devices are in use with which firmware.
If your IT uses professional documentation software such as Docusnap for this purpose, this can easily be read out by means of a report. Docusnap always has the most up-to-date data on all accessible devices in the network thanks to automatic inventory. Not only device information such as name and IP address is stored there, but also the firmware data of the device.
The next step
And now it actually gets tricky and time-consuming. For each device, it must be determined whether it uses Java, or rather whether it uses the affected log function of the Java libraries with the affected versions.
If it is computers or servers, this is often still easy to trace yourself. Because the affected Java library is in the JAR archives of Java. These can be searched and traced with special tools such as log4j-detector. It is possible that different versions of the log4j library are installed on a system for different programs. This is handled differently by each software vendor.
More difficulties with IT devices
If it is an appliance (i.e. hardware with software installed on it by the manufacturer as a complete system), it becomes more difficult. Usually one has there no access to the internal packages or systems. Here you have to rely on the manufacturer that he really checks all devices for this problem promptly and reliably – and subsequently provides an update. In contrast to locally installed Java, the program library cannot simply be replaced.
Test by external services
Or one tests the services specifically, in which one sends the suitable string to the logging Java device. Since you usually don’t get any feedback, the CanaryTokens service helps. Here, a corresponding text can be generated for the log4j problem, which can be used to check the device affected with it. CanaryTokens checks whether Java code is retrieved or not.
Finding log4j files on Windows and Linux systems with Docusnap
Docusnap can save a lot of work and, most importantly, precious time in finding the vulnerability. By reliably searching on all Windows and Linux systems, countermeasures can be taken on the affected systems as quickly as possible.
In our detailed HowTo, we show you how to use Docusnap to identify the log4j problem and act accordingly.
If Linux systems are also used in your network, please install the Docusnap patch from December 2021 (version 11.0.1928.21348). This adds the required extension for Linux systems. Searching on Windows systems does not require an update to Docusnap.
Update from March 15, 2022 – In the meantime, a patch in Docusnap has extended the search. Any files and software installations on all systems can now be found.
More information in our blog article “Cross-system file and software search in Docusnap
Conclusion
Even the most advanced software and the latest hardware do not protect against future security vulnerabilities. However, it is possible to protect against them as best as possible from the ground up and, in the event of an emergency, as is the case right now, to take action against them with the most effective means possible. The most important weapon against these threats is the gapless and most up-to-date data and information about one’s own IT network, which enables rapid clarification of the situation by means of the professional documentation software Docusnap.
You do not use Docusnap yet, but would like to enable a significant relaxation of security problems of this kind in the future? Then simply test our 30-day demo version – free of charge, without obligation and with full functionality.
Additional information
Here you can find additional information about the topic
