Log4J is a logging library for Java. It is used to debug software during its development lifecycle and entails inserting log statements into code. It is developed and maintained by the open-source Apache Software Foundation and runs on all major platforms including Windows, Linux, and Apple's macOS.
On 24 November 2021, a member of Alibaba's cloud security team discovered a vulnerability in log4j 2. The vulnerability was given a CVE ID by November 26 and the first known exploit was detected by December 1. By December 13, Log4j version 2.16.0 was released.
The vulnerability, CVE-2021-44228, was given a rating of 10, the highest score, under the Common Vulnerability Scoring System (CVSS).
CVSS is used to assess the severity of a vulnerability so that security defenders can decide how to prioritize their response activities, considering the impact of the vulnerability and exploitability. But it doesn't really talk about risk.
The flaw is a remote code execution (RCE) vulnerability that lets an attacker run their code on the affected server. RCE does not require physical access to run code that can be used to take full control of the affected system, including theft of data.
Sean Gallagher, senior threat researcher at Sophos, warned that the Log4Shell vulnerability presents a different kind of challenge for defenders.
Many software vulnerabilities are limited to a specific product or platform, such as the ProxyLogon and ProxyShell vulnerabilities in Microsoft Exchange. Once defenders know what software is vulnerable, they can check for and patch it.
“Log4Shell is a library that is used by many products. It can therefore be present in the darkest corners of an organization’s infrastructure, for example, any software developed in-house. Finding all systems that are vulnerable because of Log4Shell should be a priority for IT security,” he explained.
James Carder, chief security officer at LogRhythm, suggested that organisations act fast to remediate this vulnerability. The known Indicators of Compromise (IOCs) relevant to this attack are comprised of IP addresses that have been observed attempting to exploit the vulnerability and contents of the requests being sent.
The log sources with the best visibility into these IOCs will be firewalls, intrusion detection systems, web application firewalls, and proxies. While these log sources can potentially provide detection for the initial exploit, keep in mind that IOCs change over time and there are many possible variations of this attack that can evade rules-based detection.
He added that it is also crucial that organisations look for abnormal behaviour on the servers using Log4j in their environment, including unusual process behaviour and unusual outbound network connections from the server.
“Endpoint logging, such as operating system logs and endpoint detection and response (EDR) observations, will significantly help round out behavioural detections,” he continued.
CyberArk offers six best practices to counter the vulnerability:
Apply patches. If you haven’t already, take immediate steps to apply the software update already released by Apache in Log4j. It’s also important to review vendor recommendations and updates for all enterprise software platforms in use, along with any underlying OS and enterprise integrations. Check-in with all your third-party vendors to make sure they’ve also patched the software you use.
Deploy peripheral defenses. Apply web application firewall (WAF) rules to mitigate common exploitation attempts as part of a comprehensive defense-in-depth strategy.
Protect the credentials served to servers. Restrict access to environment variables and local credentials stored in CI/CD pipelines to minimize immediate risks posed by opportunistic attackers. If an application requires a secret to be handed over in an environment variable, use a secrets manager to help ensure only authenticated users get access to the clear text secrets.
Protect Tier 0 assets. Only allow privileged access to specific bastion hosts to restrict access to Tier 0 assets like Active Directory and DevOps workflow orchestrators. This will make it exponentially more difficult for the attacker to escalate privileges and achieve a complete network compromise.
Implement least privilege for both services and users. This step is critical in mitigating the risk of a targeted attack. Restricting access to the minimum level needed — and taking it away as soon as it’s not needed — can go a long way in slowing down or halting an attacker’s progress by preventing lateral movement, and ultimately, minimizing the blast radius (or overall impact).
Enable Multi-Factor Authentication (MFA) whenever possible. Attackers are much more likely to succeed when they don’t have to provide a second authentication factor or another piece of approval to insert their code — so this is always a best practice.
Steven Ng, CIO and EVP of managed security services at Ensign InfoSecurity, warned that hackers are now actively scanning the internet for affected systems, and malicious tools are being developed to automatically attempt to exploit the vulnerability.
“The exploit targets the Java Naming and Directory Interface (JNDI) and the Lightweight Directory Access Protocol (LDAP), enabling attackers to load arbitrary Java code on a server, allowing them to take control. This makes it a highly attractive vulnerability for cyber perpetrators,” he continued.
He added that while not all services and products are susceptible to RCE exploits, they could be vulnerable to the information leakage attack associated with the vulnerability.
