One year has passed since the Log4Shell vulnerability was exposed, and most companies still aren’t taking the steps they need to protect themselves. The risk of attacks is higher than ever before.
The noise, tools, and warnings about the Log4Shell vulnerability have gotten lost in the shuffle of other alerts. This means that many companies are still at risk—more so than ever before.
It is far from being over
Although the number of publicly disclosed attacks targeting the Log4j vulnerability has been less than many might have initially expected, one year after Apache Software Foundation disclosures last November this major threat continues to present a threat to enterprise organizations.
There are many reasons why this risk isn’t decreasing but rather growing worse:
– The number of companies that have been attacked has increased
– The number of companies that have been successfully attacked has also increased
– There are more tools available now than ever before which means there are more ways to exploit this vulnerability
It’s time for a change: we need to start paying attention to the warnings about this vulnerability and take action now so that we’re not caught off guard by an attack later on.
https://medium.com/@prabhash.code/log4j-vulnerability-explanation-2b9d9b2c2574
It is very likely that we will see more attacks exploiting this vulnerability in the future. Companies should take action now so that they do not become victims of these attacks or suffer from their consequences.
We’re urging all organizations to patch their systems immediately so they can protect themselves from future attacks against this vulnerability.
“The fact that Log4j is used in about 64% of Java applications and only 50% of those have updated to a fully fixed version means attackers will continue to target it,” says David Lindner, CISO at Contrast Security. “At least, for now, attackers continue to have a field day in finding paths to exploit through Log4j.”
Multiple Attacks But Fewer Than Expected
The Log4J function referred to as L4S (Logging for Shell) exists in Log4j’s Java Naming and Directory Interface (JNDI) function. The vulnerability gives remote attackers a trivially easy way to control vulnerable systems because—in addition to being used by virtually every application environment that uses log files—L4S is often the only logging mechanism available on embedded devices like routers, security cameras, or database servers.
Because of its widespread use and the relative ease with which hackers can exploit it, security researchers consider Heartbleed to be one of the most significant vulnerabilities in recent memory.
In recent months, a number of security researchers have pointed out that threat actors are using the vulnerability to gain access into target networks. Many attacks involving nation-state APTs from China, North Korea and Iran seem to be related—if not directly perpetrated by those countries themselves!
Among other examples, CISA warned in November that an Iran-government-backed APT group exploited the Log4j vulnerability to deploy crypto mining software on a federal network.
The Unabated Threat Must Be Countered
While there has been a decrease in the number of Log4j attacks, security researchers warn that this does not mean the threat is gone.
In a recent study, 72% of organizations were vulnerable to Log4j. But it found that only 28% had fixed the bug completely. Further, it was found that, as organizations added new assets to their environments, they often encountered Log4j again and again. Up to 29 percent of servers, Web applications, containers, and other assets became vulnerable again after being fixed by the original fix.
“Assuming organizations build the fix into the left side of the equation — during the build pipeline for software — rates of reintroduction should diminish,” said Bob Huber, chief security officer at Tenable which did the survey. “Much of the rate of reintroduction and change depends greatly on an organization’s software release cycle.”
“Since transitive dependencies are introduced from your direct dependency choices, they may not always be known or directly visible to your developers,” Brian Fox, CTO at Sonatype says.
There is still time to act
All the investigations into the Log4J issue have demonstrated that better software supply chain attestation is needed, in addition to SBOMs that keep up with the speed of DevOps and cannot be manipulated.
Application security and architecture teams have learned that they need to look beyond the source code, APIs, or open-source packages if they want to find every possible risk.
You cannot scan your way out of the problem.
A complete and always updated understanding of the application’s architecture is just as important as finding vulnerabilities.
Codenotary Trustcenter delivers a complete solution from source code to production runtime, that covers code signing, vulnerability scanning, SBOM generation, and management, as well as software and software component approval and enforcement.
Contact us for a free Trial of Trustcenter
