Web network security —–Log4j high-risk vulnerability principle and repair

Series article directory

Web network security —– information collection of red and blue attack and defense

Article directory

  • Series Article Directory
  • What is Log4j?
  • 1. Log4j Vulnerabilities
  • 2. The cause of the vulnerability
    • 1. What is the Lookups mechanism
    • 2. How to use JNDI for injection
      • Introduction to JNDI
      • LADP
      • RMI
  • 3. Log4j vulnerability repair
  • Summarize

What is Log4j?

Log4j is log for java (java log), which is an open source project of Apache. By using Log4j, we can control the destination of log information transmission to be console, file, GUI component, or even socket server and NT event record Server, UNIX Syslog daemon, etc.; we can also control the output format of each log; by defining the level of each log information, we can control the log generation process in more detail. The most interesting thing is that these can be flexibly configured through a configuration file without modifying the application code.

1. Log4j vulnerability

The remote code execution vulnerability [cve-2021-44228] of log4j2 that broke out on December 8, 2021 is called the “epic nuclear bomb vulnerability”, which has the following characteristics:

Trigger Mode Remote
User authentication User authentication is not required
Configuration method Default
Affected versions Apache Log4j 2.0-alpha1 to 2.14.1 (including these versions) Apache Log4j 1.2.19 to 1.2.20 (including these version)
Extremely low difficulty of exploitation Remote code execution without authorization
Threat Level serious, can cause RCE

(The scope of this vulnerability may change over time)
After understanding the basic characteristics of Log4j, you will know that the most advanced vulnerabilities often adopt the simplest “cooking method”, which is simple, harmful, and easy to operate.

2. The cause of the vulnerability

The Lookups mechanism is provided in Log4j2, and Lookups provides a method to add values anywhere in the Log4j configuration file; in the Lookups mechanism, there is JNDI, which is output in the Log4j log When the character legality is not strictly restricted, the remote malicious script loaded by the JNDI protocol is executed, resulting in RCE.

The following will introduce in detail what is Lookups and JNDI

1. What is the Lookups mechanism

“ Lookups provide a way to add values to the Log4j configuration at arbitrary places. They are a particular type of Plugin that implements the StrLookup interface. ”
The above content is copied from the official log4j2 document lookup – Office Site. It clearly shows that the main function of lookups is to provide another way to add some special values to the log to maximize loose coupling and provide configurable attributes for users to call in an agreed format. (lookups are a specific type of plug-in that implements the StrLookup interface) lookups provide developers with more convenient debugging efficiency in the back-end development process

Lookups can execute some commands and operations through {$xx}, and log4j supports using this expression to execute commands in the log. The following is a simple example of log4j using lookup, which can print system os information.

public void test() {<!-- -->
        log.info("{$java:os}");
}

In this way, we can understand why the payload of common Log4j vulnerabilities is in the following format:

${jndi:ldap}
${jndi:ldaps}
${jndi:rmi}
${jndi:iiop}
${jndi:iiopname}
${jndi:corbaname}
${jndi:dns}
${jndi:nis}

Observing the payload above, you can find that there is jndi in each payload. The function of JNDI will be introduced below

2. How to use JNDI for injection

Introduction to JNDI

JNDI (Java Naming and Directory Interface–Java) Naming and Directory Interface is an API that provides an interface for naming and directory services in Java. It can be known from the name that JNDI is mainly composed of two parts: Naming (naming) and Directory (directory), where Naming refers to binding an object to a context Context through a unique identifier, and at the same time can obtain an object through a unique identifier search, and Directory mainly refers to binding an attribute of an object to the context DirContext of Directory At the same time, the properties of the object can be obtained by the name and the properties can be manipulated.
JNDI is mainly composed of JNDI API and JNDI SPI. Java applications access directory services through JNDI API. The JNDI API will call the Naming Manager to instantiate the JNDI SPI, and then use the JNDI SPI to operate the naming or directory services such as LDAP, DNS, RMI, etc. JNDI has implemented the operation API for directory servers such as LDAP, DNS, and RMI.

From the above, we can know that JNDI can realize the operation of services such as LADP and RMI, so the attacker only needs to build a remote service of LADP or RMI, and let the remote server return the malicious class

LADP

What is LDAP (Lightweight Directory Access Protocol): As the name implies, it is a lightweight directory access protocol used to access directory services (Directory Service).
As an access protocol, the LDAP protocol is a CS architecture model in terms of technical architecture: Taking IDaaS as an example, the three problems that IDaaS products need to solve are all accessing LDAP Server as LDAP Client (here LDAP Server and Directory Service is equivalent), to achieve the function

RMI

RMI (Remote Method Invocation) is an application programming interface (API) for a distributed application on the Java platform. It is the implementation of the Java Remote Method Protocol (JRMP). This protocol represents the Java language-specific remote procedure call (RPC) system. .

RMI allows an object to be called on another virtual machine through a network, these objects are called remote objects

After understanding the above things, I drew a picture to help understand
The attacker defines an interface, and defines database operations, etc. in the interface.
The attacker carries the lookup support expression to request the server.
The server prints out the request information through log4j.
The JNDI operation will be performed after the log4j print is completed.
This explains the generation of loopholes, extremely high risk!

3. Log4j vulnerability repair

1. Upgrade to the fix for the affected version:
(1) For Apache Log4j 2.x users, it is recommended to upgrade to version 2.17.0 or later. These releases fix vulnerabilities and include other security enhancements.
(2) For Apache Log4j 1.x users, there is currently no official repair version for the 1.x version. It is recommended to upgrade to Log4j 2.x version, or consider using another logging library.

2. Prevent the use of JNDI to load remote resources:
If you cannot immediately upgrade to a fixed version, you can reduce the risk by disabling the use of JNDI to load remote resources in the Log4j configuration. This can be achieved by removing the JndiLookup class from the configuration or setting it to a safe FallbackJndiLookup or DummyLookup in the log4j2.xml file.

3. Enable the security policy:
To further reduce potential risks, you should consider enabling security policies to restrict code execution. It can be achieved by adding security policy configuration in the log4j2.xml file.

4. Clear the cache of the affected system:
Log4j has a caching mechanism that stores parsed XML configuration. To ensure the new configuration takes effect, you may need to clear the cache. This can be achieved by clearing Log4j’s context selector cache.

In addition to the above methods, it is very important to understand and pay attention to the officially released vulnerability fixes and updates, because the details and degree of fixes of the vulnerability may change. It is recommended to follow security best practices and keep an eye on official vulnerability notices and security updates.

Summary

Log4j vulnerabilities can cause RCE and other hazards. The so-called do whatever they want. Although most systems have already installed patches for repair and upgrade, there are still some old systems that have not been repaired. This is a major vulnerability that we cannot ignore in security testing. Of course, the Log4j version needs to be checked and repaired.

Do not steal without authorization, please specify when reposting