What’s Log4j? What is it used for?

Log4j is a widely used Java logging library used in many Java enterprise applications. Because logging is so fundamental to every application, the impact of the Log4j vulnerability is quite broad. More likely than not, if you have java code embedded in your software stack, you are impacted by it.

CVE-2021-44228(Apache Log4j Remote Code Execution)

The Log4j vulnerability allows attackers to perform a remote code execution attack and compromise the affected systems. More information can be found at the NIST website – https://nvd.nist.gov/vuln/detail/CVE-2021-44228

A detailed proof of concept is also available at the following git repository for our interested readers – https://www.lunasec.io/docs/blog/log4j-zero-day/

Running a vulnerable application

We are going to run the above application proof of concept that is vulnerable to the log4j attack as a docker container. Please refer to our previous post on how to scan a container image for the log4j vulnerability as well as it will help you catch vulnerable containers before these containers make it to your runtime environments.

We are now going to launch the docker container and configure it to automatically send logs to apica.io’s LogFlow instance. The docker container is run with the docker logging driver configured to send logs to LogFlow via syslog protocol.

docker run --log-driver syslog --log-opt syslog-address=tcp://logflow.demo:514 --log-opt syslog-format=rfc3164 --log-opt tag=log4j --name log4j-poc-test -d --rm -p8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app

Triggering the vulnerability and a remote command execution

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://127.0.0.1/a}'

We can now see that the log4j vulnerability has triggered and a remote lookup will be attempted which fails as we do not have a listener or service at 127.0.0.1

2021-12-16 06:26:58,726 http-nio-8080-exec-1 WARN Error looking up JNDI resource [ldap://127.0.0.1/a]. javax.naming.CommunicationException: 127.0.0.1:389 [Root exception is java.net.ConnectException: Connection refused (Connection refused)]

Using LogFlow Java rule pack with Log4j exploit detection

Let’s head over to our LogFlow console and check our Java rule pack and add a log4j detection SIEM rule so logs that match the exploit pattern are automatically tagged. The Java rule pack already comes built-in with many rules to detect Java exceptions, extract exception information, drop unwanted java logs that cause an increase in log data volume.

While adding the new rule, we will also create a metric to track the occurrence as a time series. Below the log4j SIEM rule is created and is called CVE_2021_44228. When the Rule is created as a metric, LogFlow automatically marks it with a suffix to treat it as an index – CVE_2021_44228__e3472e

Searching for the log4j events

Now that the Java pack rule for detecting the CVE is added, we can go to the LogFlow search view and find matches that are detected. We can search by the rule index name and find matching log lines which can now tell us when these RCE attempts are happening.

Visualizing the CVE occurence in your logs

When we created the rule, we also added the visualization to a dashboard. This enables an easy timeline view of when the RCE events are happening. The time series metric can also be configured to trigger an alert so prompt action can be taken.

Creating alerts

Creating an alert can be easily done by configuring an alert rule on the time series metric. An alert can be configured to be delivered to multiple destinations including E-Mail, Slack, ServiceNow, PagerDuty, OpsGenie, Webhooks, etc.