Log4shell gap: what makes it so dangerous and what can be done about it?

Log4shell gap: what makes it so dangerous and what can be done about it?

If one wants to put it harmlessly, once again a new spectre haunts 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 as of Version 2.0.1 to 2.14.x (Version 2.15.0 is already fixed, but contains further security holes, version 1.x is not affected). In the meantime, version 2.16.0 are available, which should definitely be used. An update to the newest version is, wherever possible, urgently recommended.

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. The current version of the log4j library can be found on the Apache website.

The BSI (German Federal Office for Information Security) has already announced the Warning level red proclaimed (IT Threat Level 4). This means that the IT-Threat level declared as extremely critical is classified. As a result, both the Failure of many services as well as the regular operation is not possible.

Using 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 feature is not used, you are safe on this device or system for now. But the problem is, that you can’t simply check if the Java function is used or not. Logging can also be done in a different way and does not have to be done with the Java library log4j.

To paraphrase: The affected devices or programs do not even have to be a direct part of the attack themselves. Because if a system uses the log function of the Java library log4j, it not only logs what happened, but also tries to interpret the log text. This can be software that logs e-mails using this log library, for example, an internal ticket system.

Here the interpreter can contact an external server from which the device accepts Java code.

Docusnap is not affected by the issue

Also our Docusnap experts have set out first to check possible attack points in Docusnap. Therefore, we may announce at this point right away that Docusnap not affected by the vulnerability is. Neither the server components nor the frontend are vulnerable to the attacks. This Java technology in our documentation software not used.

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 risk of this happening in our own IT networks and IT systems a real danger Due to the variety and enormous number of systems and programs in use, it is important to. Self large and widespread providers, 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. And in doing so, it is not guaranteed that all the older devices, which use this log function of Java, in the near future a Update or be found at all in various lists.

This currently spreads a lot Uncertainty among IT managers and important questions arise: Can we trust our systems? Are our systems affected? And if so, how do we track them down?

The approach taken by some in such incidents, namely to sit out the danger, is not a good idea, as was the case with the Exchange exploits in the spring.

First measure – inventory: What do we have in use??

With a professionally managed IT department exist at least one accurate documentation and a Inventory of all IT systems in use. In fact, the first step is to determine which devices are in use in our own IT network (and also in the individual locations). Not only the manufacturer and the device name are necessary, but in this case also the version numbers of the device firmware crucial. If this information is not available in the documentation, the first step for IT managers is to take action. Determining which devices are in use with which firmware.

Does your IT use an professional documentation software like Docusnap, this can be easily read out by means of a report. Docusnap has the following information at its disposal automatic inventory always having the most up-to-date data on all accessible devices in the network. 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 really gets tricky and costly. For each device it must be determined whether it Java used, respectively whether it is the affected Log function of the Java libraries uses with the affected versions.

If it concerns computers or servers, this is often still easy to reconstruct itself. For the affected Java library can be found in the JAR archives of Java. These can be searched and traced with special tools such as the log4j-detector. It can be that on a system for different programs also different versions of the log4j library are installed. This is handled differently by each software provider.

More difficulties with IT devices

If this is the case Appliance (i.e. hardware with software deployed on it by the manufacturer as a complete system), it will be more difficult. Usually you don’t have access to the internal packages or systems there. Here you have to rely on the manufacturer, that this also really timely and reliably checks all devices for this problem – and in further consequence a Update provides. In contrast to the locally installed Java, the program library cannot be simply exchanged.

Testing by external services

Or you can test the services specifically by sending the appropriate string to the logging Java device. Since you usually don’t get any feedback, the CanaryTokens service can help. Here a corresponding text can be generated for the log4j problem, which can be used to check the device affected by it. CanaryTokens controls whether Java code is retrieved or not.

Find log4j files on Windows and Linux systems with Docusnap

Docusnap can do a lot in tracking down the vulnerability Save work and especially precious time. Due to the reliable search on all Windows and Linux systems countermeasures can be set as quickly as possible on the affected systems.

Docusnap Software Overview System

In our detailed HowTo we show you how to identify the log4j problem with the help of Docusnap and how to act accordingly.

If Linux systems are also used in your network, please install the Docusnap patch from December 2021 (version 11.0.1928.21348). Thus the required extension for Linux systems added. For the search on Windows systems is No need to update Docusnap.

Docusnap Software Report Linux

Docusnap Software Report Linux

Conclusion

Even the most advanced software and the latest hardware do not protect against future security gaps. However, one can protect oneself already from the ground up in the best possible way against it and in case of emergency, as just now, with as much as possible effective means how to proceed. The most important weapon against these threats is complete and up-to-date data and information about your own IT-network, which can be accessed via the professional documentation software Docusnap rapid clarification of the situation made possible.

You are not yet using Docusnap, but would like to have a significant relief from 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.

Like this post? Please share to your friends:
Leave a Reply

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: