An Army of Smart Fridges and the End of Open-Source: Log4j’s Legacy

Months on from the initial Log4j rampage, the exploit is still very much alive. Alongside the definitive guide to DDoS mitigation, this piece will help you prevent your devices becoming a part of future DDoS attacks.

Javascript makes a fantastic basis for apps: the language actively promotes cross-device compatibility, and excels at dynamic programming. Within the bustling Java development space, Apache is a giant: currently the world’s largest source of open foundation code, it forms the basis of Java apps built by both enterprises and hobbyists alike.

One necessary aspect of developing and maintaining an app is Apache’s logging capabilities. This allows an app’s performance to be monitored.

Anything from user input, to failed login attempts and resource consumption are all accessible through these log files. This allows real-time performance tracking: the developer can access these log files through LogManager and look on in bewilderment at how often you forget your password.

Log4j: Allowing your Apps to Download Anything

Companies handle a lot of data. Within a network, all of this information is stored in different areas. User information will be stored in a different directory than email servers, for example. However, an app often needs to retrieve information from multiple places. It does this through The Lightweight Directory Access Protocol (LDAP). An app finds the necessary LDAP through the Java Naming and Directory Interface, which signposts it to the correct server.

So when a user requests a page through an app, log4j reads and logs the HTML code, then returns the relevant web page. However – when an attacker wishes to make a vulnerable app download a malicious payload to a device – they make a malicious HTML request. This time, however, the HTML header tells the app to query a new, unseen directory. When this HTML request is passed through log4j, log4j processes this and queries this unfamiliar server.

This external server is attacker-controlled. The malicious HTML goes further, too: if the header contains a request to find and download a file, the app will search the malicious server for precisely that. This gives the app a direct path to any form of payload. 

Also, Check – What Skills Does an iOS Programmer Need?

Quick Fixes

This critical issue was released on December 9th, 2021. Naturally, the cybersecurity community was alarmed. The initial exploit affected industry giants such as Microsoft, Cloudflare, and Adobe. Given the magnitude of the problem – potentially affecting millions of clients’ Java apps – Apache was quick to attempt a first patch. However, versions 2.15 and 2.16 were both shipped with other exploits.

As the Apache team scrambled to fix their code, attackers rapidly gained more casualties. 

Victims could become unwitting crypto-miners, churning out Monero profits for the criminals as their computer chugged. Some attackers hit back at the cybersecurity industry, installing malicious code through the industry tool VMware. Finally, Apache released version 2.17 – and though it stemmed the flow of malicious HTML traffic, it certainly didn’t stop for good.

Botnet Recruiter

Thanks to Java’s widespread use in Internet of Things devices, the log4j vulnerability has helped to dramatically swell the ranks of the Mirai botnet. 

Whereas traditional botnets are collections of compromised computers, Mirai takes advantage of lackluster security on smaller devices connected to the internet. These include baby monitors, network routers, agricultural devices, medical devices, home appliances, CCTV cameras, headsets, and even smoke detectors.

These devices become DDoS tools for cybercriminals. Once they’ve accessed the device via log4j, a script is silently downloaded in the background. When activated, this script pings web page requests to servers that the criminals wish to take down. That means that your doorbell or smart fridge could have contributed to bringing down internet access to most of the East Coast in 2016. 

Log4j Now

With the new patch released, the pool of log4j victims is now restricted to those that haven’t patched up to 2.17. That’s still a surprisingly large number: there’s still more than 100 log4j attacks committed per minute. More recently at the beginning of 2022, log4j has found persistence in the Night Sky ransomware attacks. An unknown threat group is distributing Night Sky crypto-locking malware, which ransoms and siphons off company data. One victim received a demand of $800,000. 

Protecting yourself may appear as simple as updating your Java-based apps, but the truth of the matter is log4j runs deeper than that.

The time between a zero-day exploit being found and being patched is a critically vulnerable stage. Thankfully, virtual patches can offer a degree of protection: this primarily refers to Web Application Firewall-specific procedures. Here, a WAF can be customized to analyze HTML requests and intercept attacks before they reach the app itself.

Note that the code of the application itself is not changed: the WAF simply provides a stop-gap between the attacker and the vulnerable app.

While The official patch for Log4j has now been released and stress-tested, the major challenge to stomping out the log4j vulnerability is its hidden usage. Thankfully, cloud-based hot patches can monitor for vulnerable Java applications and rapidly implement the latest patch.

The End of Open Source?

Given the damage that was inflicted, and the degree to which major companies’ security was compromised, the log4j exploit has significantly degraded trust in open-source code.

Promoted as a bastion of collaboration, massively open-source projects such as Apache have borne the brunt of increased attacks in the last decade. One major contributor to this is the fact that open-source vulnerabilities are posted publicly shortly after discovery; handing that information over to both legitimate users and attackers alike. This is compounded by the fact that open-source devs are typically working voluntarily – meaning there’s no obligation to patch at all – and open-source code has quietly infiltrated most of the software supply chain.

In a recent study, 87% of cybersecurity professionals stated that the level of risk inherent to open-source software merits government regulation.

As attackers continue to leverage any sliver of attack surface, it remains to be seen whether open-source becomes simply too dangerous to depend upon.