Retrospective deep dive into the Log4j vulnerability

Not all hacks target the latest IoT devices or your connected car. The 2020 SolarWinds hack put the vulnerability of the “boring” tech underpinning modern civilisation squarely in the public eye. Perhaps that inspired the attackers who created Log4Shell just before the Christmas break.

Log4Shell is the exploit used to target Log4j, an open-source logging library commonly used by developers in the Java community, providing a framework for the logging of error messages, diagnostic information and more. Log4j is found in products used by companies all around the world, including many of Australia’s largest organisations.

The vulnerability has ultimately resulted in the leaking of private information as well as remote code execution (RCE), presenting a unique set of challenges for organisations and their customers. With a comprehensive set of features that make it an attractive library for developers to leverage such as its lookup, nesting and JNDI capabilities, we’ve witnessed a flood of exploit attempts that have been growing at a startling rate.

As the vulnerability continues to be a topic of conversation among individuals, large organisations and government bodies worldwide, we’ve come to unearth insights into how this vulnerability functions and evolves, as well as the unique considerations when it comes to mitigating its impact into the future.

Data exfiltration and remote code execution exploits

There have been a surging number of reports of servers performing internet-wide scans in attempts to locate vulnerable servers, allowing threat actors to exfiltrate information and execute malicious codes.

Data exfiltration is a technique used by these actors to target, copy and transfer sensitive data, which can be accessed through a Log4j lookup expression and easily coerced into arriving at an attacker-controlled system. Similarly, the execution of remote code can be achieved through carefully crafted log lines in order to run arbitrary commands inside a server.

Among the attack vectors we are noticing, web-based applications are being targeted far more than anything else, where interactions are logged with end users who are visiting the site. Another vector is against DNS. In an attempt to see if there are any vulnerable DNS resolvers, attackers are issuing DNS queries with exploitable payloads embedded.

VIEW ALL

However, the threat surface extends well beyond such cases. We must consider that Java runs on billions of devices around the world, in which case many don’t have the ability to be patched. Combining its large footprint with the amount of time devices will be exposed, leads us to think this vulnerability will be with us for years to come.

Evolution – payloads and attack diversification

As the vulnerability continues to be monitored, the threats are seen to be evolving in two distinct directions. The first is with respect to payloads. We are seeing enterprises increasingly relying on mitigations such as web application firewalls (WAF) for protection. Such systems search for the presence of exploitable strings in web requests and drop any they find.

The second evolution is around the diversification of attack targets and protocols. With web-based applications currently acting as the primary attack vector, there have been an increased number of attempts at DNS and other less obvious protocols as the web vector gains more protection and patching continues.

Given the vast extent of the different attack vectors that can be leveraged against this vulnerability, the only solution is to patch all vulnerable systems. However, in many instances, organisations don’t have the comprehensive visibility into which systems are vulnerable in the first place. As such, additional mitigations must be deployed to reduce the threat surface as much as possible.

To ensure the greatest level of protection, systems that can be patched should ensure Log4j is running on the latest version. In other cases, organisations must prioritise running systems such as WAF and DNS firewalls as well as zero-trust segmentation to gain visibility into possible exposure.

Lessons learned from Log4j

As the vulnerability grows and advances, we are starting to understand the ins and outs of how to eradicate its impact moving forward. In order to satisfy the needs of end users, developers must rely on a rapidly growing set of available libraries, language ecosystems and third-party infrastructure and services as the new normal.

Advanced organisations are beginning to not only assess the risk of a given library, but also the practices of that development community in order to examine their dependencies. Even with these risk assessments in place, vulnerabilities are going to occur. In this case, visibility is of utmost importance. With many organisations unable to identify vulnerable systems, there must be systems in place to react in a timely manner and prevent full exploitation.

Finally, organisations should embrace the principle of least privilege. This involves locking down servers, machines and software so these may only reach the systems they require to perform their tasks. This can greatly reduce the threat surface when a vulnerability arises.

The Log4j vulnerability presents a complex and high-risk situation for companies across the globe. With its widespread threat surface and sheer volume of unpatched systems, we will continue to see exploit attempts surface and impact many organisations in the process. However, companies that work to ensure the maturity of their security foundations will prove to bounce back faster than ever.

Charlie Gero is the chief technology officer at Akamai Technologies.