The German Federal Office for Information Security (BSI) warns: The Log4Shell IT security vulnerability poses a great danger, especially for companies. Accordingly, there was a great deal of interest in the digital After Work Talk at "it-sa 365". Around 150 participants were informed and advised by IT experts Michael Gisevius and Cristian Avram on this burning issue during a presentation from the "it-sa insights" series. The recording of the presentation with subsequent Q&A session (German) is still available on it-sa 365.
Mr Avram, what does Log4Shell stand for?
Log4Shell refers to a vulnerability that was identified in December last year. Log4j is an open source framework. Wherever users and developers use this Java library, the vulnerability is present. The doors into IT are potentially open for now!
What do the hackers' attacks look like?
Hackers are already exploiting the vulnerability in many ways. For example, we have observed ransomware attacks or attempted implementations of cryptominers. Many hackers have probably already sneaked in or are lying in wait in the network of the victim companies. Therefore, many more attacks will certainly take place in the coming months. Some will be noticed, others not.
How can one protect oneself?
Currently, the first thing to do is to update the vulnerability if you have located it in your IT. In addition, administrators should keep a particularly close eye on their systems in the near future. Attackers will have already penetrated through the gap.
How well or how could those affected have protected themselves?
Many do not even know where Log4j is hiding in their IT infrastructure. The cornerstone for a successful defence should therefore actually be laid beforehand: organisations should have a clear overview of their IT infrastructure and a transparent, ideally complete overview of their software inventory. Organisations that have taken such an IT inventory and continue to maintain it are already one step ahead in their defence. Because they know immediately where to start in order to solve the problem.
Even better positioned are organisations that have relied on a zero-trust architecture from the very beginning. For example, LDAP requests originating from web servers are currently the means of choice to exploit the vulnerability. If Zero Trust were in place, these attempts would be prevented from the outset.
Finally, IT managers should rely on a so-called defence-in-depth architecture, a multiple layered defence. The best protection is still offered by prevention, which continues current detection and response technologies.
The data from Bitdefender telemetry, i.e. the information from the installed Bitdefender systems, show us very specifically which modules of a layered defence actively contribute to blocking these attacks. This includes protecting the network by checking the URL/IP reputation or analysing suspicious process behaviour, such as fileless malware and attacks that the attackers are driving. Equally important remains the detection of known and the discovery of unknown malware payloads by anti-malware engines - the latter based on heuristic behavioural analysis.
Security gaps are similar to the Hydra from Greek mythology: if you close one gap, two new ones open up, right?
The comparison is somewhat misleading, since security gaps are not directly mutually dependent like the severed heads of the Hydra. Newly discovered gaps do not necessarily result from a previously discovered one. Almost all software has such vulnerabilities. Many are fixed early by the developers - even before the software is deployed. Many, however, remain undiscovered for a long period of time: as in the case of Log4Shell, so that the affected open-source programme code could spread widely before the vulnerability was known.
Perhaps another image fits better: the detection of new vulnerabilities is like that of a space telescope. The further it sees and the better the observer can look at space, the more stars he sees. The situation is similar in cyber security: the more analysis technologies improve, the more vulnerabilities are identified.
Author: Reinhold Gebhart