Log4j 2 Vulnerability – Practical Advice and What’s Next for Software Supply Chain Security

December 14, 2021 Christian Simko

If you are a cybersecurity or DevOps professional, you have probably had a very hectic 96 hours and probably many more to come. The critical Zero-Day vulnerability (CVE-2021-44228, CVssv3 10.0) in Apache Log4j 2, a popular open source Java-based logging library that is part of many widely used Internet, enterprise and embedded software applications, is putting everyone at risk from large corporations to small and mid-sized business to even technology consumers.

Unfortunately, the cybercriminals are now just as active as the defenders. According to cybersecurity researchers, they are seeing thousands of exploit attempts. This blog will shed some light on the problem and provide cyber defenders with information they can use today and in the future.

The Bad News

This flaw is serving up the perfect storm of severity because of the prevalent use of the Apache Log4j 2 library in thousands of applications, the public availability of known exploit code and the simplicity to execute an attack. This vulnerability allows unauthenticated remote code execution, which means a successful attack can be carried out with no need for use credentials. Through this attack method, attackers can gain remote access to computers and devices through vulnerable servers that they log into. Sensitive data, including financials, personal identifiable information (PII), intellectual property and more are at risk. Additionally, personal safety of users of Internet connected devices and equipment could also be at risk from a malicious attack.

With exploits already being observed in the wild, enterprise organizations should assume they have already been compromised and start forensic efforts immediately.

Immediate Action – Arm the Defenders

The cyber defender community is strong and well connected. Collectively, we all come together to find flaws, report them and share information about how we can best protect applications and systems from cyber threats. The security engineers behind LunaSec, an open source data security framework, dubbed the vulnerability Log4Shell and provided early intelligence with continued updates in its Log4Shell blog post.

GitHub has published Log4Shell hashes that if found in your software inventory means you have vulnerable Log4j systems. If you detect these, it is recommended that you review log files for anomalies to identify impacted applications and take defensive action.

Industry analyst, Forrester has published a great blog with advice for Prevention and Detection, Vendor Risk Management and Internal and External Comms. The analyst team suggest that the security operations center (SOC) should implement detection and response rules to alert on malicious activity targeting critical devices and applications. Web application firewalls (WAFs) should be also be updated to begin blocking malicious traffic and exploit attempts. More prescriptive details can be found in the Forrester blog.

Companies like Cloudflare, a web performance and security provider, are not only helping to protect their customer, but also sharing the WAF rules they’ve deployed to mitigate exploit attempts. Check out Cloudflare’s blog post on how to configure the WAF rules.

And, CISA (Cybersecurity & Infrastructure Security Agency) issued an alert on December 10, 2021 that the Apache Software Foundation has released a security advisory providing remediation steps for CVE-2021-44228. CISA is advising all users and administrators to apply the recommended mitigations immediately.

The Apache Software Foundation has released Loj4j 2.15.0 is recommending organizations update to this latest version or implement the mitigation steps outlined in this document (https://logging.apache.org/log4j/2.x/security.html) if they are unable to do the update.

For many organizations who are either waiting for their software vendors to provide updated software versions or applying the patch themselves may not be possible, cybersecurity firm, Randori provides temporary mitigation steps in its Log4j 2 Vulnerability Analysis.

When Life Give You Lemons, Make Lemonade

The Log4j 2 vulnerability is yet another massive software supply chain blunder. We already know the impact from the SolarWinds software supply chain attacks. With attacks on the Log4j 2 vulnerability just beginning, we’ll have to wait to see what the full impact will be. What we do know is that the software supply chain is broken. We as software developers and cybersecurity pros must learn from these misfortunes and use this an opportunity to improve the state of cybersecurity.

Early this year, the Presidential Order on Cybersecurity highlighted the need to improve software supply chain security. One of the mandates is that all software vendors doing business with the federal government will need to supply a software bill of materials (SBOM) with the software they are providing.

As mentioned above, Apache Log4j 2 is a popular open source library used to provided logging functionality in thousands of widely used software applications. If each application had an SBOM, finding the open source components that make up the software would not be like finding a needle in a haystack. Knowing what is in the software and what is potentially vulnerable would significantly reduce response and remediation times.

The good news is that newer software composition analysis (SCA) solutions that can scan source code and binaries can provide this visibility. Software vendors can produce SBOMs to check the final make up of the software and detect Zero-Day and N-Day vulnerabilities of the identified components before shipping their software. Additionally, a SBOM will provide a record of what is in the software to quickly alert customers and allow them to take action when a new Zero-Day vulnerability is identified. And, with binary SCA, enterprise organizations can quickly scan commercial off the shelf software (COTS) without access to source code to create their own SBOMs – allowing them to trust, but verify their vendors.

New directives and new technologies can help us improve software supply chain security. To get there, we need to do our part, adopt these new technologies and think differently. This is our opportunity to stay ahead of the cybercriminals.

 

Previous Article
GrammaTech Releases CodeSonar Version 6.2 Focused on Enabling DevSecOps
GrammaTech Releases CodeSonar Version 6.2 Focused on Enabling DevSecOps

Ready for DevSecOps GrammaTech’s CodeSonar static application security testing (SAST) solution ...

Next Article
Software supply chain exploits are exploding–How to proactively prevent threats
Software supply chain exploits are exploding–How to proactively prevent threats

Your software supply chain is increasingly coming under attack - straining your existing cyberse...