If you’ve been online at all in the last week you’ll most likely have come across several articles about the log4j vulnerability. Companies around the world are still scrambling to assess whether they are vulnerable, and patching up their systems in an attempt to stay secure.
What is the log4j vulnerability?
Every software application produces logs that are used for various purposes including auditing, alerting about errors, checking that the system is working, etc. Making sense of this output and funnelling parts of it to different systems can become quite complex, especially if there’s a requirement to change these rules dynamically.
In 2013 a change was added to log4j, a popular logging library for Java systems, that allowed external systems to dynamically alter its behaviour. The side effect of this change was that this interface was now too permissive, allowing external systems to run any arbitrary code into the vulnerable system.
At first glance, it might seem that this is a network or web-based attack that could be trivially patched by a WAF (Web Application Firewall) rule. But the reality is that in today’s complex and interconnected systems there may well be several ways hackers can use to get to a vulnerable system.
Security analysts are finding attempts to exploit via filename, metadata and contents, usernames, cookies, and more. In summary, any type of input that could potentially be read and executed by a machine could leave your systems vulnerable
DMARC reports as another exploit attempt
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the modern email authentication standard used by all major email servers (Office 365, Google Workspace, and commercial secure email gateways) to authenticate outbound and inbound email. When implemented by an organization at the strongest policy of p=reject, it stops bad actors from impersonating its domain to send malicious emails. It’s an open standard and is used by organizations around the world to protect employees, customers, and supply chains from phishing attacks, and brand reputations from exploitation.
As part of auditing our own systems to ensure that we were not affected by this vulnerability, we at Red Sift spotted another creative exploit attempt. Given the nature of the DMARC protocol, the email address of the reports’ processor for a given domain is public knowledge, and there is also a standard describing the format of such a report. And for this reason, our processing of DMARC reports includes careful validation of the various input fields to make sure they conform to the standard.
Last week our validation engine flagged a few non-compliant reports and upon further investigation, we identified them to be attempts to exploit the log4j vulnerability. A malicious actor tried to compose a DMARC report that contained the JNDI exploit string as part of one of the fields:
Here, the hackers were hoping that one of our systems would somehow execute the <source_ip> line and trigger the exploit. However, in our case, we don’t use log4j as part of our software stack and have strong validation in place that would capture this attack even if we did. So, this record was rejected and this was an unsuccessful attempt.
Final considerations
The log4j vulnerability will still be around for some time and security teams will have a busy holiday season patching up systems. But our advice for organizations is to be thorough in their assessment. Don’t only look internally but also at your supply chain, given the number of ways this vulnerability can be exploited.
Ultimately this is another stark reminder that hackers will try all channels as a way to infiltrate a system, not only the obvious ones. But in light of such a serious issue, we’ll leave you with some (appropriate) humour about the nature of what we’re facing. Thank you internet creative hive.
To start protecting your business, brand, customers, and supply chain from impersonation attacks, why not sign up for a free trial of our award-winning product OnDMARC?
