1 minute read

What is Log4j vulnerability ?

“An exploit for a critical zero-day vulnerability affecting Apache Log4j2 known as Log4Shell was disclosed on December 9, 2021. All versions of Log4j2 versions >= 2.0-beta9 and <= 2.14.1 are affected by this vulnerability. This vulnerability is actively being exploited in the wild.

Log4j2 is a ubiquitous library used by millions for Java applications. Created by Ceki Gülcü, the library is part of the Apache Software Foundation’s Apache Logging Services project.

The vulnerability, when exploited, results in remote code execution on the vulnerable server with system-level privileges. As a result, it is rated at CVSS v3 score of 10.0.” ~ blog.qualys.com


I am a Security Engineer and I am aware about Log4j Zero-Day, What should I do to save my Org?????

Well two initial steps which you should take:

  1. Identify Softwares or third party services used in your organisation which may be using Log4j

  2. To achieve step 1, you may talk to Backend/DevOps teams and understand what projects are using Java

Detecting Log4j vulernability in your apps

How to test your apps for #log4shell vulnerability

  1. Generate a DNS token https://canarytokens.org/generate# or https://log4shell.huntress.com/ or host some internal collaborator waiting for hits

  2. Wrap that token in Prefix: ${jndi:ldap:// Suffix: /a} For example - ${jndi:ldap://isdxyr3qeo5zs3l5n9rql8ls8.canarytokens.com/a}. Note canarytokens now have Log4j token(Updated)

  3. Use that value in search forms, profile data, settings etc. of your apps

  4. Get notified when you triggered a reaction

Detecting If you Org has already been Attacked or under attack:

Bash Scripts

https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Semgrep

https://github.com/returntocorp/semgrep-rules/pull/1650/commits/ecfc32623eec718d61ec83b9196574f333191008

List of software/services vulnerable

https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/#remediation

How to Mitigate CVE-2021-44228

To mitigate the following options are available (see the advisory from Apache here):

  1. Upgrade to Log4j v2.15.0

  2. If you are using Log4j v2.10 or above, and cannot upgrade, then set the property:

log4j2.formatMsgNoLookups=true

Additionally, an environment variable can be set for these same affected versions:

LOG4J_FORMAT_MSG_NO_LOOKUPS=true

  1. Or remove the JndiLookup class from the classpath. For example, you can run a command like

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

to remove the class from the log4j-core.

References(Payloads+Blogs)

https://www.lunasec.io/docs/blog/log4j-zero-day/.

https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890

https://log4shell.huntress.com/

https://github.com/apache/logging-log4j2/pull/608

https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/

https://github.com/returntocorp/semgrep-rules

https://github.com/christophetd/log4shell-vulnerable-app

https://github.com/Neo23x0/log4shell-detector (Not Trusted - need to verify if its safe to use)

https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

https://logging.apache.org/log4j/2.x/security.html

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

https://github.com/NCSC-NL/log4shell/blob/main/software/README.md