Security researchers continue to look for real-world, “in the wild” applications that are exploitable using the remote code execution (RCE) vulnerability in Spring Core, known as Spring4Shell.
But as of this writing, VentureBeat is not aware of any public reports of real-world applications that are susceptible to the Spring4Shell exploit.
“Our research team has been looking into this, and we have not yet identified an exploitable application,” the Randori Attack Team said in comments provided by email to VentureBeat on Friday. The team, a part of attack surface management vendor Randori, on Wednesday released a script that can be used to test for susceptibility to the Spring4Shell vulnerability.
“A system must be using a specific combination of Tomcat, Java runtime, and Spring framework versions to be potentially vulnerable—it must have all the right ingredients. However, to be vulnerable, the ingredients have to be used the right way — aka, the code has to be implemented in a certain way,” the Randori team said in the comments to VentureBeat.
“It is difficult to remotely identify the Spring framework version,” the team said. “Even when it is known, an attacker must also know a valid endpoint that uses the vulnerable pattern in its code. All of the above makes it unlikely we will see anything similar to the scale of Log4j.”
The Randori team added that it remains actively monitoring for any changes, such as advisories from vendors. So far, several vendors have released advisories indicating they are investigating the possibility that their products are vulnerable to Spring4Shell — but none are known to have confirmed vulnerability to the RCE flaw.
In the wild
The security community has been having a “huge struggle to find vulnerable applications in the wild,” said security professional Chris Partridge, who has compiled details about the Spring4Shell vulnerability on GitHub, in a message to VentureBeat on Friday.
Partridge said he’s only aware of a single report of the Spring4Shell exploit working in the wild.
And that instance does not actually involve another vendor’s application, but instead, demonstrated that an exploit for the Spring4Shell flaw could work against sample code supplied by Spring. Colin Cowie, a threat analyst at Sophos, demonstrated this in a post on Wednesday, as did vulnerability analyst Will Dormann.
This proved that the Spring4Shell RCE vulnerability is viable in the wild — and suggested that it’s likely that real-world apps are vulnerable to the flaw, Dormann said in a tweet Wednesday.
Still, while exploitable real-world applications have not been disclosed, that doesn’t absolve organizations that use the popular Java framework Spring from the need to patch. Most should still patch when they can, according to experts who spoke with VentureBeat this week.
Other exploits possible
In part, that’s because a lot remains unknown about Spring4Shell, the details of which were leaked on Tuesday, and its potential risks. First and foremost, there’s a likelihood that attackers may find new ways to exploit the open source vulnerability.
Thus, anyone who uses Spring should consider deploying the patch — not just those who know they have a vulnerable configuration, said Praetorian CTO Richard Ford.
Because Spring4Shell is a “more general vulnerability” — as Spring noted in its blog on the vulnerability Thursday — the best advice is that all Spring users should patch if possible, Ford said. Over time, “there may be more general exploits available,” he said.
Even with the worst-case scenario for Spring4Shell, though, it is “very unlikely we will end up in a similar situation” as Log4Shell, Ford said.
Log4Shell — which was disclosed in December and affected the Apache Log4j logging software — was believed to have impacted the majority of organizations, due to the widespread use of Log4j.
Exploit requirements
On Thursday, Spring published a blog post with details about patches, exploit requirements and suggested workarounds for Spring4Shell. The RCE vulnerability, which is being tracked at CVE-2022-22965, affects JDK 9 or higher and has several additional requirements for it to be exploited, the Spring blog post says.
The initial exploit requires the application to run on Apache Tomcat as a WAR deployment, which is not the default way of deploying applications — limiting the scope of the vulnerability’s impact somewhat. The default, on the other hand, is not vulnerable to the initial exploit of Spring4Shell.
On Friday, new versions of Apache Tomcat were released that address the attack vector involved with the vulnerability.
The crucial thing to keep in mind, however, is that “even if the current exploit needs [a] specific configuration, the vulnerability is still general enough and can be exploited in different ways,” said Manasi Prabhavalkar, a product manager on the vulnerability response team at Aqua Security, in an email to VentureBeat.
As reported by Spring, the vulnerability involves ClassLoader access, Prabhavalkar noted. But even if the current exploit is Tomcat-specific, and needs some specific preconditions, “other attacks on other types of ClassLoader might be possible too,” she said. “There are probably other mutable objects accessible this way that could lead to exploitation of this vulnerability.”
VentureBeat’s mission is to be a digital town square for technical decision-makers to gain knowledge about transformative enterprise technology and transact. Learn more about membership.
Source: Read Full Article