Log4j vulnerability (noun)
Rick Howard: The word is: Log4j vulnerability.
Rick Howard: Spelled: L for ledger, O for observation, G for gigantic, 4 for the number 4, and J for Java.
Rick Howard: Definition: An open source Java-based software tool available from the Apache Software Foundation designed to log security and performance information.
Rick Howard: Example sentence: Log4j is code written in the Java computer language and created by volunteers within the Apache Software Foundation to run across a handful of operating systems: Apple's MacOS, Windows, and Linux
Rick Howard: Origin and context: The Apache Software Foundation released the general availability of the Log4j module, version one, in July of 2014. The next year, the Apache Logging Services Project Management Committee announced Log4j 2 as a replacement.
Rick Howard: Fast-forward to 24 November 2021, six years later, Alibaba Cloud Security Team's Chen Zhao Zhin disclosed to the Apache Software Foundation, a vulnerability in the module. On 9 December, Apache announced exploitation in the wild of the Log4j vulnerability and named it Log4shell. By the next day, 10 December, NIST classified the vulnerability as a critical issue in its National Vulnerability Database.
Rick Howard: The reason for the severity is the ubiquity of the Log4j code module and the simplicity of the Log4shell exploitation code. Its ubiquity stems from the fact that the code from the Apache open-source, cross-platform web server is the most popular web server software on the planet. If you're running web services somewhere, there's a good chance that you're running Apache. The simplicity results because any unauthenticated user of the Log4j service can send a 12-character code segment and take control of the server. Yikes.
Rick Howard: Log4shell leverages the third highest software vulnerability type from the OWASP Top 10, a reference document describing the most critical security concerns for web applications; in this case, injection. In other words, the unpatched Log4j module doesn't isolate its code from its data. It interprets log messages (data) as instructions (code). When hackers send a URL to the module, the service grabs the URL, fetches the data located there, and runs the executable payload with the full privileges of the Log4j main program.
Rick Howard: According to Microsoftâ€™s Jon Douglas, as of 4 November 2021, the percentage of public software repositories that use open source software is north of 80%. He says that what that means is that, "Thousands of strangers can effectively contribute directly to your production code. Your product, through your software supply chain, is affected by unpatched vulnerabilities, innocent mistakes, and even malicious attacks against dependencies." Most security professionals have no idea what code libraries our organizations are using directly and absolutely no clue about what code libraries the original open source developers nested within.
Rick Howard: One temporary mitigation measure is egress filtering. Blocking Log4j traffic from exiting the network until you can install a more permanent fix. The more permanent fix is to upgrade the bad software module with a patch or replace it with something else. When Log4j-type problems emerge though, 80% of the mitigation work is just finding all the running instances. One solution to that problem is the incorporation of a software bill of materials, or SBOM, a formal record containing the details and supply chain relationships of various components used in building software.
Rick Howard: The concept has been bouncing around the industry for at least a decade, but as gained little traction until now. With the 2021 supply chain attacks against SolarWinds, Accellion, and others, there seems to be movement to make SBOMs a best practice. U S President Biden's 2021 Executive Order on Cybersecurity mandates that all federal civilian executive branch agencies and key players will deploy a minimum SBOM program by the spring of 2022.
Rick Howard: For the rest of us, the concept is most likely, at least five years away from reality. Today, discovery of these kinds of injection vulnerabilities, and other OWASP categories, come from independent researchers like Chen Zhao Zhin, and from software scanning tools in the Software Composition Analysis Space. It's worth noting here that the Log4j module is over seven years old and neither group found this problem until now. It's also worth noting that the Log4j module vulnerability is probably just the tip of the iceberg. With 80% of public software repositories containing open source software, you know, white hat, black hat, and grey hat researchers will be rigorously mining that ground to find more problems in the near future.
Rick Howard: Nerd reference: On 20 December 2021 just before the holiday break, Eamon Javers from CNBC interviewed Jen Easterly, the U S Cybersecurity and Infrastructure Security Director about the impact of Log4j.
Eamon Javers: So the Log4j vulnerability became public just about a week ago. What do you guys know now that we didn't know last year?
Jen Easterly: Yeah. So first off, I should say that the Log4j vulnerability is the most serious vulnerability that I've seen in my decades long career. And three reasons why: ubiquity, simplicity and complexity.
Jen Easterly: So it is a piece of software, open source, that's in millions of devices from video games to hospital equipment, to industrial control systems, to cloud services.
Jen Easterly: It is trivial to exploit as a vulnerability, essentially 12 characters and a remote unauthenticated attacker can take over a system, can use it for stealing data, can use it for ransomware attacks, all manner of malicious activity. And it takes a very focused effort to be able to find and to fix the vulnerability because it's open source. So it is in all manner of vendor products.
Rick Howard: Word Notes is written by Nyla Gennaoui, executive produced by Peter Kilpe, and edited by John Petrik and me, Rick Howard. The mix, sound design, and original music have all been crafted by the ridiculously talented Elliott Peltzman. Thanks for listening.