On 12/9/2021 a critical vulnerability in Java library Log4j was disclosed (CVE-2021-44228, Base Score 10 CRITICAL CVSS3.x)1. The BSI classified this as an extremely critical threat situation on 12/11/2021 and published a cyber security alert of warning level red2.
This assessment results from the following factors:
- Java and Java libraries are very widely distributed3
- An attacker can remotely execute custom code on a system without authentication and thus take over the system
- Exploitation of the vulnerability is relatively simple
- Proof-of-concept POC was already available4
- Mass scans looked for vulnerable systems5
As of Saturday, 11.12.2021, many companies and public authorities had to ask themselves whether they are affected by this security vulnerability. In particular, if the company is part of the CRITIS or personal data is processed, this question becomes more important. In both cases, there could be an obligation to report6 7 to the authorities.
In accordance with the Incident Response Process8 (Preparation, Detection & Analysis, Containment and Post Incident Activity), the Detection & Analysis phase begins as soon as the security vulnerability becomes known. Here, the speed of the response is of elementary importance. In a race against time, the necessary countermeasures must be implemented in good time9.
Even without in-house software development in Java, it was already clear on Friday that a large number of companies were very likely to be affected by this vulnerability. The analysis of the attack surface showed that it does not only affect systems connected to the Internet, but that the problem can also reach far into the backend. The reason for this is that the vulnerability is based on a function of Log4j that interprets entries in log files in order to then execute external code if necessary. Thus it was clear that it will also affect industrial systems, embedded systems, desktop applications and isolated applications like hotspots.
Defence in depth
With the knowledge of the attack vectors and to reduce the attack surface, the outbound firewall rules were checked to ensure that no internal system could connect to the Internet.
The next step is to look for signs of compromise (Indicator of Compromise (IoC)) in the systems. The first question to be answered here is which hardware and software systems are relevant at all and what priority should be given to them.
At the beginning of the weekend, only a few vendor reports were available, so a manual check of asset databases and vulnerability scans (which did not yet detect the vulnerability) became necessary after a possible use of Java. The matching of lists of affected systems, which have been compiled on GitHub since Sunday, proved very helpful here.10
In addition, requests were made to manufacturers and suppliers over the weekend, especially if they were critical systems or small suppliers. For the most part, the response to these requests was quick and meaningful.
Patches11 have been available for the Java library Log4j since Monday, December 13, 2021. However, this is primarily only of interest to companies that use this library for their products or services. If a product (router, end-point security, hotspot, etc.) is affected by the vulnerability, it is necessary to wait for the manufacturer's patch. Additional security measures may have to be taken here, such as monitoring, restricting communication connections, or shutting down the service.
This security vulnerability is probably the most serious of 2021 and will certainly keep us busy for several weeks into 2022. The background to this is, on the one hand, that new security vulnerabilities are being added (CVE-2021-45105, CVE-2021-45046 and CVE-2021-44832)12 and that manufacturers or software developers must first check their systems and services and further affected systems can be expected. In addition to traditional IT, the industrial sector is also affected. For example, the BSI reported that manufacturers in the industrial environment are also affected (Siemens, Schneider Electric and Rockwell Automation)13.
In the meantime (03.01.2022), there are over 750 reports from manufacturers affected by the security vulnerability14. The IoT sector is also affected by this security gap. Bosch, for example, reported on 12/14/2021 that the Bosch IoT Suite was affected15.
Although these are not really new findings, it has become clear that key success factors for coping with the indicator are the provision or presence of
- qualified personnel
- an established incident response process
- speed of analysis
- the ability to make decisions quickly
- an up-to-date and complete asset management system, and
- audit reports
are. For companies with their own software development, this security gap has shown how important it is to have an internal software repository that can only be used for development. This is the only way to track which library and programs are used where and in which version. This will become even more important with the increasing use of container- and microservice-based applications, as the way in which the container and microservice work (which programs and libraries are used within the container and microservice) is often not transparent. Particularly when using open source software, it is a good idea to subject critical components to a code review and report this back to the developers.
Investigations of systems and applications in companies will continue as described. Since the vulnerability is also suitable for extending privileges or lateral movement16 after an attack, corresponding further investigations should take place in the Post Incident Activity Phase.
BSI: Arbeitspapier Detektion und Reaktion Log4j Schwachstelle, Version 1.4
tagesschau live: BSI informiert über IT-Sicherheitslücke
Nationaal Cyber Security Centrum (NCSC-NL):
- Log4j overview Scanning software
- Log4Shell Detection & Mitigation
- Overview of software (un)affected by Log4j
by Bernd Kohler @ dainox 26-01-2022
 github.com/tangxiaofeng7/apache-log4j-poc (gelöscht)
 CEO of Cloudflare twitter.com/eastdakota/status/1469800951351427073
 §8b Abs. 4 BSIG
 Art. 33 DSGVO
 B. Schneier, “The Future of Incident Response,” in IEEE Security & Privacy, vol. 12, no. 5, pp. 96-96, Sept.-Oct. 2014, doi: 10.1109/MSP.2014.102.
Bits And Splits/ stock.adobe.com ©