Hi, I’m crooked.

Last week you were all overwhelmed by the log4j logging bug?

When I saw this bug, I noticed that it had “a very wide range of effects and was very easy to use”.

I just want to verify how difficult it is to get started, so I turned over a lot of articles, are similar, say loopholes, very awesome, hurry to fix it, late will be over. Then a screenshot evokes a calculator and it’s over, with no one telling me how to play it.

I also want to evoke the calculator, learn (pretend) learn (pretend) (force).

So I looked up a bunch of information on the Internet, and I groped around. It took about an hour from finding the data to completing the attack.

I was shocked: it was really easy to learn.

At first I wanted to write about the recurrence of the bug, but the idea was dispelled.

First of all, even if I reproduce it, I still don’t quite understand how it works. All I know is that an attacker’s class can be loaded through JNDI, and since it was written by an attacker, a lot of things can be done in that class.

Think about it, I can execute some of the code I wrote in your code environment, even if I don’t know how to attack, I write an infinite loop, write a sleep statement can also play you dead ah.

If you really want to write valuable articles, a good place to look is at JNDI-related technologies.

But I don’t think I can roll it, so I’m not going to write it.

Secondly, I checked and couldn’t write in too detail. After all, it is a loophole, and it is not good to spread its recurrence method. It seems to involve legal issues, so it is good for everyone to know how to prevent it.

Besides, this is what the security guys do, and I don’t want to eat their food.

In the end, I actually found a detailed video demo on site B. Post a link, except I don’t know how long this video will last:

www.bilibili.com/video/BV1FL…

Because the current solution is to upgrade the JAR package, so this article I mainly introduce a plug-in to you, can improve the upgrade speed to a certain extent.

I also use it at ordinary times, with a smooth, fragrant than.

Sb’s log

I’m not being rude, I’m talking about SpringBoot logs.

Now everyone’s application is based on SpringBoot to build, so SpringBoot default logging framework is what?

I don’t know, so I’m going to build a pure SpringBoot project to take a look.

How pure?

When I was building a new project with IDEA, I didn’t introduce any other packages except to specify SpringBoot version 2.6.1.

Then, we look at the POM file, which is very sparse:

It’s pure. It’s like pure water.

And then we started the project:

Look, the magic thing happened. I didn’t touch a single line of code, nothing was configured, and the log automatically typed.

So I had never noticed it before, but this incident got me thinking about this:

What is the default logging framework for SpringBoot?

The first thing THAT came to my mind was this:

Guess what, can use code to solve the problem less beep, add two lines of log print is done?

I can tell from the output, oh, I’m using logback.

Other methods

How else do you know if it’s logback?

My next thought was to look at the POM dependency graph.

In IDEA, there is a one-click way to view THE POM dependency graph, especially easy.

Just click on this icon in the Maven TAB:

If you don’t find it, you can also right-click in the POM file and select Maven->Show Dependencies:

You should then see an interface like this with the Logback-core package, which introduces the logback logging implementation:

There is also a log4J-API in the dependency. What makes you think you’re not using Log4j?

There is only API, there is no core package, the core implementation is in the core package.

For example, this time log4j exposed the problem of the code, namely lookup that block of logic, is in the core package.

But why does the fix suggest we expel log4J-API and log4J-core at the same time?

I personally think that core is no longer used, so it doesn’t make much sense to keep the API. If there were only log4J-API dependencies, it would not be a problem based on the attack principles I understand.

Well, without further ado, back to the pure SpringBoot project.

The way I told you to look at dependency graphs, I don’t usually use them.

Why is that?

Because in a real project, dependencies can be extremely complex and seem so dense that you don’t have any desire to see them. For example, showing everyone the POM dependency chart of Dubbo project is very exciting and very impacting.

Let’s start with a question: What do you usually do when you open a POM file?

Is it needed when checking for jar conflicts or finding JAR packages?

So in the previous page, you can press Ctrl+F to search, like this:

But when you use it, it’s really not easy to use.

So, here comes the plug-in I want to introduce you to.

Plugins.jetbrains.com/plugin/7179…

This add-on is a nice touch.

How to install will not be introduced, pay attention to their corresponding IDEA version on the line.

I’m just going to show you how it works.

Once installed, you open the POM file again and see this underneath:

The inside looks like this:

This is where we focus our attention, and I’ll give you a note as well:

In this case, there are two core functions.

  • Troubleshoot dependency conflicts.
  • Query JAR package dependencies.

For example, let’s take a look at the log-related package in our pure project:

At a glance, we also see the logback-core package mentioned earlier.

We practice

Instead of practicing maven-Helper, here’s a hands-on look at using Maven-Helper.

For example, we take Dubbo, which is really easy to use.

For example, we need to check all the log4J-API and log4J-core packages in the project.

I chose this module from the Dubbo project to demonstrate:

For example, open the POM file under autoconfigure:

Then search log4j:

As you can see, log4J-API is introduced by spring-boot-starter-logging.

Right-click here and click Exclude to Exclude:

SQL > alter database alter database alter database alter database

It’s that simple, and the other modules are the same, so I won’t go through them all.

But there was a problem. Dubbo, as middleware, had to be removed and a new security version had to be introduced.

We can look at the PR Dubbo submitted for the log4j vulnerability this time:

Github.com/apache/dubb…

You can see that the exclusion of log4J-API also introduces a new version of log4J-API.

The version number is placed in the parent POM to achieve unified version management:

If you need to upgrade log4J-API later, just change the version number in the parent POM.

One more

Let me give you one more example, just to practice.

Here’s an example from this link:

Juejin. Cn/post / 694522…

First, Dubbo’s package was introduced in the pristine SpringBoot project, and then ZooKeeper was introduced as the registry:

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> < version > 2.7.9 < / version > < / dependency > < the dependency > < groupId > org. Apache. Dubbo < / groupId > < artifactId > dubbo - registry - zookeeper < / artifactId > < version > 2.7.9 < / version > < / dependency > < / dependencies >Copy the code

Also, remember to add this line to the application.properties file, otherwise it won’t start:

dubbo.application.name=xxx

When you start up, you’ll see this reminder log:

What do you say? Does that look familiar? In most projects, right?

The above reminder log can be divided into two groups, SLF4J and log4J.

Many people know that the problem is that dependencies conflict and the logging framework is messy.

So first we look at the logging dependencies in the project and see that there is a log4j dependency conflict:

In the poM file, it looks like this:

We need to bridge log4j to slf4J so that log4j is excluded but logs are still printed.

<! Log4j-slf4j --> <dependency> <groupId>org.slf4j</groupId> <artifactId>log4j-over-slf4j</artifactId> The < version > 1.7.30 < / version > < / dependency >Copy the code

Start the project again and you will find that SLF4J is the only problem left:

Open dependency analysis again:

You can see that the project has both SLf4J-log4j12 and log4j-to-slf4J, as well as the presence of a logback.

As a result, two slF4J implementations, Log4j and Logback, coexist in the project.

In fact, this point can also be seen from the log:

Class Path contains Multiple SLF4J Bindings.

Two sets of implementations, one loaded first at project launch and the other used, is a very unreliable thing.

The fundamental solution is to eliminate one of them.

For example, if we still use the default logback, we will exclude the slf4J-log4j dependency.

Start the project again, the previous conflict log is gone, comfortable:

Ok, so what if I don’t want to use logback, but I want to use the awesome log4j?

Docs. Spring. IO/spring – the boot…

Just modify maven:

As you can see from the log print, the current implementation is log4j.

Then, with regard to the log4j bug, I would like to say that logging is logging, and why all this complexity? Meet the KPI?

To be honest, I didn’t even know it had these advanced features until the bug broke, and I don’t think it would be useful.

It feels like someone left the back door behind, which is scary to think about, and imagine a big play.

Finally, see a paragraph, give you.

The New Year is coming, so don’t talk about log4j, CS, bypass, traffic detection and so on.

You bring your stupid computer home and it doesn’t do you any good. Your friends have a lot of money in their pockets to eat and drink while you sit around the house with your stupid RCE.

The relatives and friends to dinner to ask you reap what you say I installed a virtual machine, all the various tools to play again, meng made his relatives, are you still in my heart silently laughing at them, smile they don’t understand your automatic injection, don’t understand your 10 layer agent, don’t understand your traffic confusion, smiled, they even have a complex password to remember.

The son bought a house, the daughter bought a car, the girl got a promotion and a raise. Your parents say silently that my son got a stupid computer, which buzzes when it runs and the electricity meter goes faster and faster.

This article has been included in personal blog, welcome to play.

www.whywhy.vip/