Hello guys! Welcome to a new video where i
will explain the log4shell vulnerability. How it works. How it can damage and how to
prevent it. If you're ready, i will just ask you to subscribe to my channel and let's go. I think
everybody heard about the log4shell vulnerability. It was one of the most famous vulnerability
in the latest years. Almost in the java world. Nevertheless, it only impacts some libraries
and some configurations. Let's see it. Here is a small application, a Sprint Boot application.
Where i've excluded the default logging library to use the log4j. Yes, because the vulnerability
only impacts this library and only some versions. I will list them later. With this
application i only need a public endpoint. In my endpoint, i will get a header and log it.
Nothing more. I know this doesn't reflect the behavior of a real application, but i will come
into the details later. Let's run the application. In this header, i sent a JNDI command, a
Java Naming and Directory Interface command. And this command requests the LDAP server.
Let's see how my Spring Boot application reacts. I can see that it tries to connect to
the server i've indicated in the editor. Even if my header is printed, if my log is
printed, it handled the JNDI command before. Here is my log, at the end. But how does the JNDI
work? The JNDI is basically an api that provides access to remote code. My Java application, using
the JNDI API, can access through a variety of protocols some remote code to be executed locally.
In this case, i can use an LDAP connection, but i could have used RMI, CORBA or others. The logger
log4j reads first the content of the header. It will detect the dollar sign and the curly
brackets, which means that something interesting is inside that should be interpreted. In most
cases, the interpretation is safe. Which prevents any kind of malicious code to be injected. But
this time, log4j left this gap unattended. So log4j will see that it's a JNDI command
and we'll run it. Inside, i can see that an LDAP request, so log4j will request this URL,
nothing more. This seems benign, but let's see what can be done with this request. In a
malicious attack, the LDAP server is under the control of the attacker. Which means that the
attacker is making my application to request its LDAP server. It's an LDAP server that can respond
in multiple ways. It can use some Java codebase JNDI response. This means that the response
contains the location and necessary information to run a Java application that is located remotely.
And of course, this remote application won't make anything good. Another way the LDAP server
could respond is by running a basic base64 command. This means that the request itself is
a command encoded in base64. The request will be done against the LDAP server but the command
will be decoded and run directly on my server. This command could be to download some file and
run it. That was two of the most used attacks. So how can i prevent my application and my server
against those attacks? For the codebase attack, this only happens when this property is set to
true. This is set to true, by default, only in the Java versions lower than those versions of java 6,
7, 8 and 11. Greater versions have this value set to false by default. Unless i set it manually to
true, it shouldn't impact me. On the other side, for the basic base64 command, it can be harder
to protect. One way, of course, is to upgrade the log4j library to a version higher than 2.14.1,
which doesn't present the vulnerability. But this option sometimes isn't acceptable. As
an application upgrade is difficult or the applications is no more maintained. An alternative
is putting in front of my Spring Boot application a web server that filters the LDAP requests.
This way, i prevent any incoming requests against an untrusted LDAP server. In the example
i've shown, i've used a custom header which seems improbable that the attacker knows the name of my
custom header and that i'm logging the content of my header. But there are some other headers that
are printed by default. Let's say you use a Tomcat with relatively verbose options for logging. Some
headers will be printed by default, as the host, the location or the user agent. So, even if my
Spring Boot application is safe, my Tomcat server may be the problem. As i said, the best option is
to upgrade the log4j library to a version higher than 2.14.1. If the application uses another logging
library, as logback, there is no problem. That's all for this video. If you like it, please click
on the thumbs up and see you in another video. Bye
