It’s been four months since the Log4j issue exploded onto the internet. All the major software vendors affected by it have by now released patches – but even where companies have patched, it would be wrong to relax.
Log4j is the name of a logging software library used by many different applications. It has also become the name of an attack using the Log4j library (the attack is also known as Log4Shell). The attack is not so much a vulnerability but the manipulation of a feature of the library – and because ‘exploitation’ is merely the effect of using this feature in a malicious manner, widescale exploitation began within 48 hours of the possibility becoming public knowledge.
All that is required by an attacker is getting the log to contain a specific text message. If the library has internet access, that message effectively beacons out to a server controlled by the attacker, and the attacker can gain access.
There are two solutions: one is waiting for software vendors to release patches and implementing those patches as quickly as possible; and the other is to use basic cyber resilience (in this case blocking and tackling, or ‘default deny’ on firewalls) to prevent Log4j beaconing out to the malicious server. The problem is that many companies do not have default deny properly implemented, while in the best patching scenario there was most likely a delay of several weeks before the patch was tested, delivered and implemented.
For example, VMware released its first patch for Horizon in December 2021, and has updated this several times. However, in late January 2022, the company still felt it necessary to issue an alert urging customers to implement the patch.
“Customers who have not applied either the patch or the latest workaround provided in VMware’s security advisory are at risk of being compromised—or may have already been compromised—by threat actors…” the company said in a critical-level advisory.
Patching or blocking outgoing internet communications solves Log4j – but the fact remains that many companies were exposed during a period of widespread malicious exploitation, and could have been compromised during this time.
David Wolpoff, CTO and cofounder at Randori, explains the implications: “The good news about log4j being a vulnerability in a logging system,” he told SecurityWeek, “means that there’s a good chance that some evidence exists of attempts at or actual exploitation within those logs. Unfortunately, once a system is exploited, the data on that system becomes less trustable – it’s not uncommon for attackers to tamper with logs or try to cover-up activities.”
It is consequently feasible for an attacker to have gained access and covered his tracks before the vulnerability was cut off through blocking outgoing communications or implementing patches. Even for companies who are now safe, it is possible that they may already be compromised.
Randori provides a continuous red team platform. It understands how hackers think, and therefore how they choose their targets. It has applied this knowledge to the Log4j threat scenario to highlight the areas that are most attractive to hackers and therefore should be of most concern to defenders. In a report titled Top Ten Most Attackable Log4j Affected Applications (PDF), it provides two lists: the most populous applications, and the most attractive applications.
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. “This includes factors,” notes the report, “such as whether the application will be hospitable to them once exploited (known as the post exploitation environment), and what other components will be accessible (known as reachable surface area) once hacked.”
Based on this analysis, Randori concludes that VMware Horizon (the third most populous vulnerable application) is the top most attractive target. It is followed by Jamf and Mobiliron.
Any company that has not yet patched their vulnerable applications should do so as quickly as possible, perhaps guided in urgency by this list. That will protect them from future Log4j exploits – but will not guarantee that they haven’t already been compromised. It would be good practice for these companies to assume they have been compromised, and to be extra vigilant for any sign of an intruder. There have been indications that backdoors have been dropped and access brokers have taken an interest – so there is no telling from where, when or by whom a current compromise could be turned into a full-blown breach.
The irony of Log4j is that it is a fire that in theory should never have happened. Theory, of course, is different to practice, and there are often very good reasons for theory not to have been put into practice. Nevertheless, standard good security practices would have stopped the Log4j feature becoming a widespread threat vector.
“The full attack requires a couple of round trips in and out of the attacked environment,” Wolpoff told SecurityWeek. “Old school ‘default deny’ in the firewall stops the progress of these round trips. If the app doesn’t need to talk to the internet, you don’t let it talk to the internet.”
He continued, “In the case of Log4j, in order to exploit the condition, an attacker needs to have a log message printed. So, I would need to get some message into the environment where the input would be printed out through the logging system. I send a ‘hail Mary’ into the environment and the log message gets printed, and the underlying code does a bad thing.
“But in order to access the computer to do something bad, that underlying code needs to call back out to a computer that I control, and retrieve the additional data for my purposes. So, if the initial outbound connection to my computer gets blocked by a firewall set to ‘default deny’, then the total attack will fail even though the exploitable condition was available and used.”
The Log4j threat is very much present today, even though it is four months old. There are still unpatched systems without default deny. There are other applications that have been developed, perhaps in-house proprietary apps, using the Log4j library. These will never be patched by a third-party provider. And, of course, you may unknowingly already be compromised.
But perhaps the biggest takeaway is that the threat would never happen where the target has implemented good resilience practice – defense in depth including the blocking of out-bound traffic. In many cases, doing so now will not solve Log4j, but may neuter the next internet wide ‘Log4j’. Resilience needs to be built into defenses.