Log4j feels like a decade ago, but we’re still getting asked about it, months later. The industry rallied as fast as it could to apply patches and remediation strategies, but undoubtedly vulnerable code still runs and is part of many established software platforms. We’ve already seen attacks in the wild against several of the applications on the list (ahem, VMWare Horizon), and our team wouldn’t be surprised to see more exploitation later this year.
To bring some clarity to an extremely murky area of security, the Randori Attack team analyzed which were the top ten most attackable Log4j applications. We also looked at the top ten most common Log4j impacted softwares to see where there was crossover and differences—great key learnings for practitioners. Download the Top Ten Most Attackable Log4 Apps Report.
You see, just because something is commonplace, doesn’t mean it’s extremely attackable. At Randori, our mission is to arm defenders with the attacker’s perspective. As such, we compiled a report that outlines the most “attackable” targets that emerged from Log4j. While some felt massive blowback from Log4j exposures on their attack surfaces, others managed to weather the storm without major incident. By understanding how attackers choose their targets during such exposures, defenders can help put their company in the latter category.
Before we get into the most attackable targets, let us take a moment to understand what “attackability” means to an adversary. Attackers cannot afford to be caught or sent on wild goose chases. As such, the most attackable assets are determined based on where the most initial damage (access) would likely occur. When prioritizing assets, ask the following questions:
- How important is software to the business?
- If an attacker exploits it, will it give them privileged access?
- How hospitable is the asset once a bad actor is on the inside?
- Will there be security software on the asset that could detect them? (Assets that don’t have a lot of security software are much more interesting and tempting to an attacker.)
This is to say that the most intriguing types of software from an attacker’s perspective are those that are 100% confirmed to be vulnerable to Log4j and provide additional “downstream” access.
Impact of Log4j
As you can see from the lists, what’s most widespread on the internet isn’t always what’s most attackable. VMWare Horizon is extremely common, with 10% of large enterprises having an internet-exposed instance. If hacked, it gives a hacker downstream access. It’s no wonder VMware Horizon was hit within a couple weeks of Log4j —access brokers are selling access via Log4j exploits, and there are reports of it being used by Iranian hackers.
Jamf and PingFederate make both lists—being used by 1-2% of the enterprise market. Like VMware, they provide an attacker with additional downstream access to other systems: authentication (Ping), automation (Jamf) mechanisms, which provide an excellent opportunity for attackers to pivot and expand operations (which is why they make the most attackable list).
Jenkins is an interesting one, while it does not include Log4j dependencies in its core, in some instances Log4j is used, and if successfully hacked it could give an attacker the “keys to the kingdom” because it’s regularly used for automation. Our attack team wouldn’t be surprised to attacks in the wild abusing Log4j in Jenkins.
cPanel was the most commonly exposed Log4j application by a lot. 37% of organizations have multiple instances of cPanel visible on the internet. However, not every version of cPanel uses log4j, putting it lower on an attacker’s list to attempt exploitations. cPanel is an interesting example because the core cPanel is not vulnerable, but the cPanel ecosystem leverages things like Apache SOLR (search functions) and the dovecote (IMAP and SMTP email functions). This drives the point of organizations needing to understand the whole stack of software that underlies their platforms. The dependencies of large Enterprise software deployments are frequently “opaque” – hard for the administrator looking for bugs to know what is in their stack.
What Defenders Can Do
Log4j is here to stay, we will see attackers leveraging it again and again. Log4j buried deep into layers and layers of shared third-party code, leading us to the conclusion that we’ll see instances of the Log4j vulnerability being exploited in services used by organizations that use a lot of open source. If you are a defender looking to get ahead of the next Log4j, here are some actionable steps which will harden your attack surface and reduce attackability overnight.
Treat assets with a lot of access as most attackable. You don’t know where an attacker might look first, so start at what you most want to protect and work back from there. This means adding logging and monitoring around your crown jewels as well as assets with a lot of access such as VPNs and remote access tools.
Additionally, install your WAF with rules that automatically update so your SOC is able to concentrate on fewer alerts.
In the event of a truly consequential exposure, such as Log4j, the easiest and most effective way to mitigate risk is to turn off outbound communications from your network. It may make employees struggle to download a couple PDFs, but in the meantime it will keep any attackers in your system from exfiltrating any sensitive information.
Finally, get a hold on your attack surface. You can do this quickly and easily by adding an attack surface management solution to your arsenal of cyber tools. By automatically and continuously auditing and prioritizing the targets on your attack surface, you can manage and mitigate exposures easily in crunch time.
For more information on the industry’s fallout from Log4j, download the full report here.
