News Insights: The Log4j Disaster

The Log4j cyber threat is being compared to the notorious Equifax hack of 2017, which affected 147 million Americans. However, the Log4j exploit has far greater reach due to the software component’s widespread adoption. It was recently recognized as critical with reactive guidance for organizations to follow from CISA, the federal government’s cybersecurity arm.

News Insights:

Jeff Williams, Co-Founder and CTO at Contrast Security, does not believe that CISA’s reactive recommendations for organizations to protect themselves go far enough. He said, “There are a wide range of methods hackers can use to access personal information through Log4j’s vulnerability. The human effort required to detect and action each event is simply unrealistic. Install a web application firewall (WAF) with rules that automatically update, so that your SOC can concentrate on fewer alerts. Firewalls aren’t going to stop hackers. They still have plenty of other ways to break into organizations’ systems through Log4j, which are undetectable by the firewall. This includes malicious code embedded into JSON, XML, and other common data structures that power nearly every website and application.”

Enumerate any external facing devices that have Log4j installed: “The focus on ‘external facing’ devices is a mistake, as many internal systems also log data that originated from an untrusted source.”

Jeff believes that organizations must take a more proactive approach to truly mitigate the impact Log4j cyberattacks will have on businesses and consumer personal information. This means establishing the technology infrastructure needed to handle the next incident (which is surely coming), with real-time application detection and threat blocking.

Yana Blachman, a threat intelligence specialist at Venafi, said “The combination of Log4j being practically everywhere and the fact that it is trivial to exploit, with many exploits and PoCs already available, makes it extremely dangerous and highly lucrative for every type of malicious activity. An unauthenticated RCE vuln in such a popular library is every attacker’s dream. We already see that the vulnerability is massively exploited in the wild by crypto mining and DDoS groups, such as Mirai [trendmicro.com], Muhstik, and Kinsing [twitter.com], and commodity malware like StealthLoader [blog.checkpoint.com] as well as more sophisticated attacks mostly associated with APT groups using Cobalt Strike beacons and web shells.

Microsoft confirmed the vulnerability has been leveraged to gain initial access with intent to sell. This type of initial access can be then leveraged by whoever it is sold to for credential access, using dedicated malware modules for stealing credentials and machine identities from infected Unix and Windows machines to then perform lateral movement within the targeted network for further exploitation, downloading malware or ransomware, or cyberespionage and IP theft purposes, which we’ve seen before.

As of yesterday, Microsoft also reported that sophisticated state-backed actors and ransomware gangs from China, Iran and North Korea are leveraging the vulnerability, which is very worrying. North Korea-backed actors in particular are well-versed in exploiting zero-days and might use it to install ransomware and monetize victims for profit, alongside their cyberespionage activities.

Log4Shell can give all types of cybercrime gangs access to corporate networks. This is extremely worrying since access to sensitive assets may fall in the wrong hands and be used for destructive or damaging purposes – crippling down networks and great financial impact. I recommend companies to use the Log4Shell scanner [log4shell.huntress.com] to assess if they are vulnerable and patch the vuln as soon as possible, before becoming a victim.”

Andrew Howard, CEO of Kudelski Security, remarked, “Through the recently discovered Log4Shell vulnerability, organizations can learn a lot about both vulnerability management in general and the need for secure application development more specifically.

The main problem is not that the Log4j library comes from an open source project run by only one or two programmers as a part-time project. In fact, a similar number of zero-day gaps can be found in commercial software as in open source solutions. The real problem is a lack of security awareness on the part of programmers and companies, which is still prevalent in many cases.

The vulnerability highlights that developers often blindly use libraries without carefully considering all available options. A security-conscious developer would probably have disabled the JNDI query when reading the documentation if the software does not use this feature, thus reducing the attack surface.

I recommend that organizations maintain a repository of libraries that are deemed secure as part of a secure DevOps process and as part of the fundamental IT security strategy of the company. The standard for all development processes then includes programmers continuously checking all libraries used in a software development project for acceptability against this repository.”