ASW Episode 177
Vulnerability Phone
(phone dialing)
Hello! And welcome to vulnerability phone.
If you know the name of the vuln you’d like to see, press one.
(beep)
Please enter the CVE now
(2021-44228)
You have selected log4j. If that is correct, press one.
(beep)
Log4j is playing at Minecraft, cloud services, security vendors, iCloud, Amazon, Apache Struts, your toaster, small children, puppies, and –
Well, you get the point.
If you also get the reference to moviefone, then not only do you have to update log4j, it’s probably time to move out of the past and update your JVM to a version that was released this decade as well.
This was a fun intro to come up with. Of course, I had to use the correct DTMF tones for all of the numbers. I’ll leave the opening phone number as a puzzle to solve. (A puzzle that’s neither difficult nor all that mysterious, but one who’s attention to detail will hopefully generate a smile.)
I wanted to find some humor in the topic that didn’t involve mocking developers or making light of the work that security and DevOps teams are putting into addressing the vuln – that’s the lazy path. Being smug about software design or programming languages never helped anyone in the first few decades of appsec. It’s certainly not going to be productive now. And it’s not very entertaining.
Log4j will be an infosec topic for the next several years. It’ll also highlight – once again – the importance of maintaining an asset inventory and having a process for identifying supply chain issues. If 2021 was the year everyone used the incident that rhymes with Polar Fins to talk about why supply chain security is so important, 2022 will be the year of Log4Shell.
The show notes have more details on how this specific vuln fits into the larger picture of application security. One thing I didn’t include was a timeline to put this into more context (see below). I find it interesting to think of this vuln as a type of recurring event as opposed to a single fire to extinguish. Chasing zero-days isn’t a strategy – creating hardened software architectures and layered security controls is. It’s easy to recommend asset inventories and egress proxies; it’s harder to implement them effectively. But that’s one of the goals of modern appsec, to shift from the burn-out of BugOps to the emergent security of DevOps.
My presentation from DevSecCon London 2017 talks more about the idea of BugOps vs. DevOps.
Finally, here’s a rough timeline of the Log4j vuln, with Hearbleed and Shellshock noted for reference:
- Shellshock bug introduced to Bash in August 1989, appears in 1.03 release in September 1989.
- Heartbleed bug introduced to OpenSSL in December 2011, appears in 1.0.1 release in March 2012.
- Log4j devs add the JNDILookup plugin to Log4j 2.0-beta9, which appears in September 2013.
- Heartbleed (CVE-2014-0160) disclosed in April 2014 (~2 years after bug introduced to code).
- Shellshock (CVE-2014-6271) disclosed a few months later in September 2014 (~25 years after bug introduced to code).
- Researchers discuss JNDI LDAP manipulation that leads to RCE at BlackHat in August 2016.
- Researcher Chen Zhaojun of Alibaba Cloud Security Team discloses log4j flaw in December 2021 (~8 years after bug introduced to code).