In December 2020, a series of network breaches was reported in rapid succession — the beginning of what soon became known as the cyber attack that changed everything. By compromising identities and abusing privileges to take advantage of a routine software update, the sophisticated adversaries behind the landmark SolarWinds attack reached into more than 18,000 organizations, showing the world just how devastating a supply chain attack could be. Almost exactly a year later, the world faces a new threat of potentially equal — or even greater — proportions: the Log4j vulnerability that is putting “hundreds of millions of devices” at risk, according to U.S. CISA officials.
Here’s what you need to know about Log4j and six Identity Security best practices your organization should follow to reduce risk.
The Lowdown on Log4j: What You Need to Know About the Zero Day
On December 10, 2021, a critical security vulnerability in a widely used open-source software development library called Log4j (also referred to as “Log4Shell”) was published in CVE-2021-44228. Affecting Log4j versions 2.0-beta9 to 2.14.1, the flaw has the potential to cause data exfiltration and/or remote code execution on servers using this component for their logging functionality.
Log4Shell has quickly gained global attention because of its potential for far-reaching impact. The Log4j open-source software is ubiquitous, used either directly or indirectly (via third-party code) in the world’s most popular consumer applications and enterprise services. When left unmitigated, the remote code execution (RCE) vulnerability can enable an attacker to execute arbitrary Java code and take control of a target server.
Attackers reportedly began exploiting the vulnerability at the beginning of December 2021 (though it was inserted into the code in July 2017) and have ramped up efforts since the CVE’s publication — efforts include those by known ransomware groups.
Six Identity Security Best Practices to Reduce Log4Shell Risk
There are many ways in which attackers can leverage the Log4j vulnerability for nefarious purposes. And while there is no one vendor or tool that can completely prevent every arbitrary code execution attempt every time, these are steps organizations can take to protect identities, secure privileged access and minimize risk:
- 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 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.
For additional details and mitigation guidance, watch our on demand webinar hosted by CyberArk Research Evangelist Andy Thompson.
For more information on how CyberArk is securing our own products against Log4j and other threats, please visit our Knowledge Base here or our Trust Center here.
