In December 2021, a major cybersecurity vulnerability identified as Apache Log4j was identified. Hundreds of millions of devices across the globe were at risk, potentially leading to devastating cyberattacks that could affect countless corporations, governments, and organizations as well as their supply chains.
Although it happened well over a year ago, its repercussions are still pertinent today.
Also known as Log4jShell, the broad scope of this issue and the difficulty of finding every instance or potential problem that can occur from it makes Log4j a target for exploitation for years to come.
Apache Log4j is an open-source change logging API that is bundled with IBM software products.
Developers use its framework to record user activity and the behavior of applications. Free from the Apache Software Foundation, Log4j has been downloaded millions of times and is among the most widely used tools to collect information across corporate computer networks, websites, and applications, according to the Wall Street Journal.
The original flaw discovered in December 2021 allows potential attackers to execute code remotely on a target computer, which could result in them stealing data, installing malware, or literally taking control of that computer.
Incidents have included hacking a system to mine cryptocurrency and building malware to hijack computers for large-scale assaults on internet infrastructure. This vulnerability also has the potential to give hackers a way to install ransomware.
After the vulnerability was first discovered, there were approximately 10 million attempts to exploit it per hour in the United States, with the retail sector being the most-targeted industry. Other sectors affected included technology, financial services, and manufacturing.
However, according to tech blog Venture Beat at the beginning of 2022, the number of attacks was lower than expected.
How was that possible?
Some attacks were halted midway through, “like with CrowdStrike, in which a state-sponsored group in China attempted to exploit the Log4j vulnerability and were disrupted by threat hunters,” writes Kyle Alspach in “China-based group used Log4j flaw in attack, CrowdStrike says.”
A massive response from the security community is credited for stopping the bleeding.
“Many of the early tools released to identify instances of Log4j within an environment were only found a proportion of the vulnerable software components because they were conducting a simple file path lookup” says Origina Head of Security Services Ben Lipczynski. “We utilized several other methods supporting our customers to detect Log4J within their environments, from validation with license documentation to application of context to understanding the exact install of our customers to enhanced ways to search for the vulnerable components.”
“The urgency of identifying where it is used and updating the software with the patch remains as critical as ever,” writes Chester Wisniewski in “Log4Shell: No Mass Abuse, But No Respite, What Happened?”
And he’s not the only one. Other cybersecurity experts have made similar comments saying the worst attacks might come many years later.
Lipczynski says threat actors can leverage Log4J to gain access, laterally move, and then establish a persistent presence in victims’ networks. This access can be either sold to other criminal organizations or used to launch an attack at a later date. Once a persistent presence has been set up undetected, even removing the vulnerable Log4J components will not be enough.
Clearly, the threat of vulnerabilities from the Log4j issue is not over.
Understanding your organization’s potential operational risks from a technological and operational context is the first step to determining your level of risk. This includes all technologies, people, processes, and objectives. Next is implementing a risk-management methodology.
For example, when Origina began receiving new support requests for the Log4j vulnerability, our global independent IBM experts were able to pinpoint which IBM software products that most likely contained the Log4j open-source component, which allowed them to follow a four-step process to help customers locate and mitigate the risk.
This four-step approach included the following:
“It was discovered that a vast majority of our customers did not require Log4j. Some were using alternative solutions, such as the native Java logging, and others none at all,” says Lipczynski. “We applied the principle of least functionality and through a careful process, our team confirmed Log4j was not required for some of our customers, so it was removed from their systems.”
By implementing this response, Origina was able to provide an average three-day resolution for our 115 customers that had Log4j issues. This includes securing customer environments and multiple mitigation actions as new versions of Log4j were released in rapid succession.
Our digital world requires IT decision-makers to have a complete understanding of the threat environment in which they operate, including further potential issues like the Log4j vulnerability. It’s crucial to access your company’s risk factors on a regular basis so you’ll be ready next time an issue of this magnitude occurs.
Gain insight into industry-only news, access to webinars, tips and tricks, blog posts, podcasts, and guides, surrounding topics like cybersecurity, reducing software support and maintenance costs and much more, all delivered to your inbox each month.LEARN MORE