5 ms·

I am still deeply skeptical that this exploit really exists, or if it does, it is extremely exaggerated. I can’t really articulate the reasons why. Part of it i

I am still deeply skeptical that this exploit really exists, or if it does, it is extremely exaggerated. I can’t really articulate the reasons why. Part of it is the fact that a lot of the people reporting on it self-admit that they are unfamiliar with Java and Spring. One “PoC” repo I’ve seen is just simple API misuse. API misuse is a CVE in the application that does the misusing, NOT the library that is misused (in this case spring). Something else is that very soon after there was a /hint/ of a log4j exploit, we saw rapid and evolving exploitation in the wild. We have nothing like that happening now, since this news first broke, what, 12 hours ago? Then there’s also the suspicion where I feel the LunaSec people, one of the first groups to report on this, are desperately trying to re-catch the fire they caught when they first reported log4j. I’m sure that was amazing for marketing their company. Problem is, I think reporting on this before there is really indication of a real issue reduces the credibility of them as competent security researchers. Of course, I may come back to eat my words.

freeqaz 5y ago
LunaSec founder here. I can understand the suspicion. It's the right mindset to have when looking at CVEs, in general, because 99% of them are overblown. The first title I wrote for the blog post was "There is no vuln" but I was wrong. Only after I spent a few hours digging did my gut change my mind. In this case I wrote the post to discuss 2 different vulns. One was a confirmed RCE with a CVE and the other was a WIP with only sketchy Twitter screenshots to go on. That alone was confusing many people and was the reason many people were posting about finding an "RCE POC" without realizing they were talking about the wrong vuln. That was the primary reason that we (LunaSec) wrote the original post -- to help people understand that there were 2 vulns and that they needed to be careful to confirm which they were discussing. There was too much unwarranted hype, too much confusion, and too little "real" information to prove/disprove if an exploit was possible. That said, at some point as researchers, we have to trust our gut about potential impact and exploitability without full knowledge of the vuln. With Log4Shell, when we wrote that post, we hadn't personally proven that the JNDI vulnerability could be exploited. It just felt like a matter of time before it would be figured out by somebody much smarter that us. And with this exploit and the people discussing it, it felt like there was likely something there (which has turned out to be true, retroactively). So that's the line, as researchers, that we have to balance by attempting to provide an "early warning" for companies/devs while also not just sitting for days with the vulnerable code (in this case Spring) to prove out an exploit until a bunch of blackhats already move on to mass exploitation. Anyway, at this point, people that I trust a lot have come forward to say that they were able to verify the exploit with a POC themselves. Specifically, @pwntester has tweeted about this[0][1] confirming that he's been able to get an exploit. He's a very good Java dev that is much, much faster than myself or anybody else on my team. -------- In this case, I noticed some people talking about it on Twitter and tried to put together info to help people "prove out" a POC with a "basic vulnerable app". Then I went to bed and looked at this again. That's when I realized that this was very confusing because there were multiple vulns being conflated in different libs. And then the Spring devs said that this wasn't an issue, but it very much still felt like there was the possibility for an exploit still. It turned out to be "Class Loader Manipulation" instead of "Deserialization injection" but the activity relating to this on Twitter was real. I sat with my engineers for several hours just poking at getting a POC working and we're very confident that, with a little more time, we'll be able to turn this into a POC like the Struts one. We're just not Java guys so it's slow. Getting a debugger takes time, understanding Spring takes time, etc. There are much more competent devs and researchers out there than us -- we're just trying to reduce the uncertainty and misinformation in a way that helps companies patch faster. Communicating clearly about hard technical subjects while also writing POCs on-the-fly is difficult, and I apologize if what I wrote came across as more "corporate shill" than "security researcher trying to reduce entropy". That's on me! 0: https://twitter.com/pwntester/status/1509240072301912074 https://twitter.com/pwntester/status/1509240072301912074 1: https://twitter.com/pwntester/status/1509248853614239747 https://twitter.com/pwntester/status/1509248853614239747 EDIT: Clarified some text
- sjones671 5y ago
  The exploit PoC that is doing the rounds works on full tomcat, not embedded tomcat, so if your example vulnerable application is using embedded tomcat that exploit won't work on it without being tweaked. I've looked at it today as well, for most of the day. Embedded tomcat doesn't have a webapps directory, whereas the full version of tomcat does, so the PoC writes the webshell to webapps/<APP>/tomcatwar.jsp and that is served up then. I'm on OSX and I found the temp directory that is created for the embedded tomcat at runtime but there's nothing deployed there, so I can't figure out where to write the webshell to or if it is even possible. I looked at the process with lsof and just followed the trail to find the directory but it's not working. Anyway, embedded tomcat IS vulnerable, just not sure if it is exploitable. To check if it is vulnerable you can do run the following curl command: curl "http://localhost:8080/?class.module.classLoader.URLs%5B0%5D=0 http://localhost:8080/?class.module.classLoader.URLs%5B0%5D=..." If this returns status:400 then it is vulnerable, if not then it is not. If you have an app deployed to a different context path (so /my-webapp) then you'd need to run: curl "http://localhost:8080/my-webapp?class.module.classLoader.URLs%5B0%5D=0 http://localhost:8080/my-webapp?class.module.classLoader.URL..." I don't think it is common to use @RequestMapping in java and take in a POJO as a parameter to the request, but that is needed in order to be vulnerable to this. I'm sure there's other gadgets that can be used to exploit this, the example we saw was using tomcat to write a webshell.
  - richbell 5y ago
    > I don't think it is common to use @RequestMapping in java and take in a POJO as a parameter to the request, but that is needed in order to be vulnerable to this. Wouldn't any method annotation like @PostMapping be vulnerable? The vulnerability is in how Spring loads the beans, so in theory any endpoint that loads a bean would trigger the exploit regardless of method.
  - tru3_power 5y ago
    I just came to the same conclusion after some debugging. On embedded tomcat there is no access to resources and thus the popular PoC floating around doesn’t work. I left off for the night exploring getters/setters on the URL object returned on the URLs[0] call. On Java 11 there were some interesting getters/setters I want to explore. Let me know if you find a working PoC. Fun stuff!
vips7L 5y ago
I'm skeptical as well because everyone is saying they've reproduced it, but there's no CVE and none of them want to post the source code to reproduce it. It's all "use this closed source docker image" or "it was in this now deleted github" or "it was in this now deleted twitter leak".
- freeqaz 5y ago
  Nobody wants to hand a bunch of blackhats a working exploit without there being a patch available. But yeah, at some point you have to accept that the blackhats have it and it's "more ethical" to just start handing out the exploit POC so that companies can start testing their ability to detect + remediate the issue. It's the whole "responsible disclosure" dance. Finding a 0-day is exciting as a researcher, but you have to keep your mouth shut while a fix gets built and tested. (Google's Project Zero gives a 90 day grace period, for example)
  - EE84M3i 5y ago
    The post says "there is a public proof-of-concept available." If that's true, just link to it. The cat's already out of the bag.
    - freeqaz 5y ago
      Thanks for pointing that out -- I didn't realize we missed adding the link! It's in a repo on GitHub, and we were banging on it to verify the exploit prerequisites. I'll go do that as soon as I sit down again.
      - cyberpunk 5y ago
        I still can't find it.. Got the link to the repo?
        freeqaz 5y ago
        I'll ask my engineers to post the one he wrote. He did put more details into the article, so go check that. Here is a repo with a POC though: https://github.com/TheGejr/SpringShell https://github.com/TheGejr/SpringShell
alexis2b 5y ago
According to this article [0] there are already signs of exploitation in-the-wild. 0: https://www.bleepingcomputer.com/news/security/new-spring-java-framework-zero-day-allows-remote-code-execution/ https://www.bleepingcomputer.com/news/security/new-spring-ja...
- EdwardDiego 5y ago
  I'm dubious because none of their sources saying so have names. Makes me wonder if their sources are trying to inspire fear to drum up business.
loginatnine 5y ago
I've spent most of my day on this and can confirm there is serious potential to this. It's not a log4shell but it's serious. You're potentially vulnerable if you use POJOs as request parameters[0] with Spring MVC and Java 9+. To support complex POJOs (like a POJO in a POJO), Spring uses the `.` separator. Therefore, you can have a request GET /somePath?innerPojo.field=foo that will get mapped properly [1]. Now, in [2], the `getCachedIntrospectionResults()` result has a `class` parameter that I believe should not be exposed. In this object, there's a bunch of parameters that can be set, that's where the problem is. In the POC seen across the web today, it was modifying the `AccessLogValve` of Tomcat. The exploit mentioned in [3] relies on passing a parameter like this : GET /somePath?class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp This will access the `class` object and uses the `getModule` method of the `Class` object to get the `Module` class. Now, this class has the `ClassLoader` exposed via a getter BUT it's exposed as opposed to the `Class` class[4]! In the POC, it's an instance of `WebAppClassLoaderBase` (when using Tomcat, under some circumstances). This class has a `getResources` method that is accessed here, along with `getContext`, `getParent`, etc. all the way up to the last delimiter which invoke the `setSuffix` method of the `AccessLogValve` instance [5]. Rinse and repeat this to set the tone for the JSP vulnerability and you have a RCE. Now, this needs some specific preconditions. However, there are probably hundred of other mutable objects accessible this way that could lead to pretty nasty bugs, vulnerability of information disclosures. Finally, I can confirm that the workaround with `@InitBinder` mentioned in [6] works. EDIT : Looks like a regression from CVE-2010-1622 that was fixed in [7]. [0] https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/mvc.html#mvc-ann-typeconversion https://docs.spring.io/spring-framework/docs/3.2.x/spring-fr... [1] https://gist.github.com/jebeaudet/127e6fb0b59e06c0642d2f362eac8d73 https://gist.github.com/jebeaudet/127e6fb0b59e06c0642d2f362e... [2] https://github.com/spring-projects/spring-framework/blob/main/spring-beans/src/main/java/org/springframework/beans/BeanWrapperImpl.java#L201 https://github.com/spring-projects/spring-framework/blob/mai... [3] https://www.cyberkendra.com/2022/03/spring4shell-details-and-exploit-code.html https://www.cyberkendra.com/2022/03/spring4shell-details-and... [4] https://github.com/spring-projects/spring-framework/blob/main/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java#L289 https://github.com/spring-projects/spring-framework/blob/mai... [5] https://github.com/Oreste-Luci/apache-tomcat-8.0.26-src/blob/master/java/org/apache/catalina/valves/AccessLogValve.java#L288 https://github.com/Oreste-Luci/apache-tomcat-8.0.26-src/blob... [6] https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vulnerability.html https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vu... [7] https://github.com/spring-projects/spring-framework/commit/3a5af35d37c79d0644d49b93f792a4c18fe8eb71 https://github.com/spring-projects/spring-framework/commit/3...
fulafel 5y ago
Are you referring to existence of the exploit they say they sent to the Spring team? I think in general it's a bad social standard that people get asked for proof by exploit about disclosed vulnerabilities. At most it should be a tool to convince the vendor if they're not competent enough to see the exploitability right away. In many cases developing it is more work than finding the hole, you're just doing work toward faster weaponisation by bad guys, and distracts from vulnerability research.
scrozart 5y ago
https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement https://spring.io/blog/2022/03/31/spring-framework-rce-early...

freeqaz 5y ago

LunaSec founder here. I can understand the suspicion. It's the right mindset to have when looking at CVEs, in general, because 99% of them are overblown. The first title I wrote for the blog post was "There is no vuln" but I was wrong. Only after I spent a few hours digging did my gut change my mind. In this case I wrote the post to discuss 2 different vulns. One was a confirmed RCE with a CVE and the other was a WIP with only sketchy Twitter screenshots to go on. That alone was confusing many people and was the reason many people were posting about finding an "RCE POC" without realizing they were talking about the wrong vuln. That was the primary reason that we (LunaSec) wrote the original post -- to help people understand that there were 2 vulns and that they needed to be careful to confirm which they were discussing. There was too much unwarranted hype, too much confusion, and too little "real" information to prove/disprove if an exploit was possible. That said, at some point as researchers, we have to trust our gut about potential impact and exploitability without full knowledge of the vuln. With Log4Shell, when we wrote that post, we hadn't personally proven that the JNDI vulnerability could be exploited. It just felt like a matter of time before it would be figured out by somebody much smarter that us. And with this exploit and the people discussing it, it felt like there was likely something there (which has turned out to be true, retroactively). So that's the line, as researchers, that we have to balance by attempting to provide an "early warning" for companies/devs while also not just sitting for days with the vulnerable code (in this case Spring) to prove out an exploit until a bunch of blackhats already move on to mass exploitation. Anyway, at this point, people that I trust a lot have come forward to say that they were able to verify the exploit with a POC themselves. Specifically, @pwntester has tweeted about this[0][1] confirming that he's been able to get an exploit. He's a very good Java dev that is much, much faster than myself or anybody else on my team. -------- In this case, I noticed some people talking about it on Twitter and tried to put together info to help people "prove out" a POC with a "basic vulnerable app". Then I went to bed and looked at this again. That's when I realized that this was very confusing because there were multiple vulns being conflated in different libs. And then the Spring devs said that this wasn't an issue, but it very much still felt like there was the possibility for an exploit still. It turned out to be "Class Loader Manipulation" instead of "Deserialization injection" but the activity relating to this on Twitter was real. I sat with my engineers for several hours just poking at getting a POC working and we're very confident that, with a little more time, we'll be able to turn this into a POC like the Struts one. We're just not Java guys so it's slow. Getting a debugger takes time, understanding Spring takes time, etc. There are much more competent devs and researchers out there than us -- we're just trying to reduce the uncertainty and misinformation in a way that helps companies patch faster. Communicating clearly about hard technical subjects while also writing POCs on-the-fly is difficult, and I apologize if what I wrote came across as more "corporate shill" than "security researcher trying to reduce entropy". That's on me! 0: https://twitter.com/pwntester/status/1509240072301912074 https://twitter.com/pwntester/status/1509240072301912074 1: https://twitter.com/pwntester/status/1509248853614239747 https://twitter.com/pwntester/status/1509248853614239747 EDIT: Clarified some text

sjones671 5y ago
The exploit PoC that is doing the rounds works on full tomcat, not embedded tomcat, so if your example vulnerable application is using embedded tomcat that exploit won't work on it without being tweaked. I've looked at it today as well, for most of the day. Embedded tomcat doesn't have a webapps directory, whereas the full version of tomcat does, so the PoC writes the webshell to webapps/<APP>/tomcatwar.jsp and that is served up then. I'm on OSX and I found the temp directory that is created for the embedded tomcat at runtime but there's nothing deployed there, so I can't figure out where to write the webshell to or if it is even possible. I looked at the process with lsof and just followed the trail to find the directory but it's not working. Anyway, embedded tomcat IS vulnerable, just not sure if it is exploitable. To check if it is vulnerable you can do run the following curl command: curl "http://localhost:8080/?class.module.classLoader.URLs%5B0%5D=0 http://localhost:8080/?class.module.classLoader.URLs%5B0%5D=..." If this returns status:400 then it is vulnerable, if not then it is not. If you have an app deployed to a different context path (so /my-webapp) then you'd need to run: curl "http://localhost:8080/my-webapp?class.module.classLoader.URLs%5B0%5D=0 http://localhost:8080/my-webapp?class.module.classLoader.URL..." I don't think it is common to use @RequestMapping in java and take in a POJO as a parameter to the request, but that is needed in order to be vulnerable to this. I'm sure there's other gadgets that can be used to exploit this, the example we saw was using tomcat to write a webshell.
- richbell 5y ago
  > I don't think it is common to use @RequestMapping in java and take in a POJO as a parameter to the request, but that is needed in order to be vulnerable to this. Wouldn't any method annotation like @PostMapping be vulnerable? The vulnerability is in how Spring loads the beans, so in theory any endpoint that loads a bean would trigger the exploit regardless of method.
- tru3_power 5y ago
  I just came to the same conclusion after some debugging. On embedded tomcat there is no access to resources and thus the popular PoC floating around doesn’t work. I left off for the night exploring getters/setters on the URL object returned on the URLs[0] call. On Java 11 there were some interesting getters/setters I want to explore. Let me know if you find a working PoC. Fun stuff!

vips7L 5y ago

I'm skeptical as well because everyone is saying they've reproduced it, but there's no CVE and none of them want to post the source code to reproduce it. It's all "use this closed source docker image" or "it was in this now deleted github" or "it was in this now deleted twitter leak".

freeqaz 5y ago
Nobody wants to hand a bunch of blackhats a working exploit without there being a patch available. But yeah, at some point you have to accept that the blackhats have it and it's "more ethical" to just start handing out the exploit POC so that companies can start testing their ability to detect + remediate the issue. It's the whole "responsible disclosure" dance. Finding a 0-day is exciting as a researcher, but you have to keep your mouth shut while a fix gets built and tested. (Google's Project Zero gives a 90 day grace period, for example)
- EE84M3i 5y ago
  The post says "there is a public proof-of-concept available." If that's true, just link to it. The cat's already out of the bag.
  - freeqaz 5y ago
    Thanks for pointing that out -- I didn't realize we missed adding the link! It's in a repo on GitHub, and we were banging on it to verify the exploit prerequisites. I'll go do that as soon as I sit down again.
    - cyberpunk 5y ago
      I still can't find it.. Got the link to the repo?
      - freeqaz 5y ago
        I'll ask my engineers to post the one he wrote. He did put more details into the article, so go check that. Here is a repo with a POC though: https://github.com/TheGejr/SpringShell https://github.com/TheGejr/SpringShell

alexis2b 5y ago

According to this article [0] there are already signs of exploitation in-the-wild. 0: https://www.bleepingcomputer.com/news/security/new-spring-java-framework-zero-day-allows-remote-code-execution/ https://www.bleepingcomputer.com/news/security/new-spring-ja...

EdwardDiego 5y ago
I'm dubious because none of their sources saying so have names. Makes me wonder if their sources are trying to inspire fear to drum up business.

loginatnine 5y ago

I've spent most of my day on this and can confirm there is serious potential to this. It's not a log4shell but it's serious. You're potentially vulnerable if you use POJOs as request parameters[0] with Spring MVC and Java 9+. To support complex POJOs (like a POJO in a POJO), Spring uses the `.` separator. Therefore, you can have a request GET /somePath?innerPojo.field=foo that will get mapped properly [1]. Now, in [2], the `getCachedIntrospectionResults()` result has a `class` parameter that I believe should not be exposed. In this object, there's a bunch of parameters that can be set, that's where the problem is. In the POC seen across the web today, it was modifying the `AccessLogValve` of Tomcat. The exploit mentioned in [3] relies on passing a parameter like this : GET /somePath?class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp This will access the `class` object and uses the `getModule` method of the `Class` object to get the `Module` class. Now, this class has the `ClassLoader` exposed via a getter BUT it's exposed as opposed to the `Class` class[4]! In the POC, it's an instance of `WebAppClassLoaderBase` (when using Tomcat, under some circumstances). This class has a `getResources` method that is accessed here, along with `getContext`, `getParent`, etc. all the way up to the last delimiter which invoke the `setSuffix` method of the `AccessLogValve` instance [5]. Rinse and repeat this to set the tone for the JSP vulnerability and you have a RCE. Now, this needs some specific preconditions. However, there are probably hundred of other mutable objects accessible this way that could lead to pretty nasty bugs, vulnerability of information disclosures. Finally, I can confirm that the workaround with `@InitBinder` mentioned in [6] works. EDIT : Looks like a regression from CVE-2010-1622 that was fixed in [7]. [0] https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/mvc.html#mvc-ann-typeconversion https://docs.spring.io/spring-framework/docs/3.2.x/spring-fr... [1] https://gist.github.com/jebeaudet/127e6fb0b59e06c0642d2f362eac8d73 https://gist.github.com/jebeaudet/127e6fb0b59e06c0642d2f362e... [2] https://github.com/spring-projects/spring-framework/blob/main/spring-beans/src/main/java/org/springframework/beans/BeanWrapperImpl.java#L201 https://github.com/spring-projects/spring-framework/blob/mai... [3] https://www.cyberkendra.com/2022/03/spring4shell-details-and-exploit-code.html https://www.cyberkendra.com/2022/03/spring4shell-details-and... [4] https://github.com/spring-projects/spring-framework/blob/main/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java#L289 https://github.com/spring-projects/spring-framework/blob/mai... [5] https://github.com/Oreste-Luci/apache-tomcat-8.0.26-src/blob/master/java/org/apache/catalina/valves/AccessLogValve.java#L288 https://github.com/Oreste-Luci/apache-tomcat-8.0.26-src/blob... [6] https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vulnerability.html https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vu... [7] https://github.com/spring-projects/spring-framework/commit/3a5af35d37c79d0644d49b93f792a4c18fe8eb71 https://github.com/spring-projects/spring-framework/commit/3...

fulafel 5y ago

Are you referring to existence of the exploit they say they sent to the Spring team? I think in general it's a bad social standard that people get asked for proof by exploit about disclosed vulnerabilities. At most it should be a tool to convince the vendor if they're not competent enough to see the exploitability right away. In many cases developing it is more work than finding the hole, you're just doing work toward faster weaponisation by bad guys, and distracts from vulnerability research.

scrozart 5y ago

https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement https://spring.io/blog/2022/03/31/spring-framework-rce-early...