SpringShell Vulnerability Explained: All You Need to Know

Shachar Menashe: Thanks! I’m so very happy! Thank you for everybody that joined today. First of all, we’re going to do a recap of Spring show just for bringing everybody up to speed. Very high-level recap, and then we’re going to talk about three subjects. The first of which is. Is this vulnerability as bad as Log4J. It has a similar name, but not for a very good reasons, maybe so we’ll talk about that. The second thing we’ll talk about is. Exactly in which scenario, the vulnerabilities exploitable, which was a bit iffy for the last few days, I will try to clear that up and the last thing is it’s very important for us to show you how to fix the vulnerability and what medications are currently available so we’ll talk about that and rank them a bit. Alright, let’s get started. SpringShell, if someone wasn’t aware of the critical severity remote code execution vulnerability in the Spring framework. Spring framework is basically an extremely popular. Framework in Java for building web applications. So similar to other frameworks from other languages, but for Java, this is the framework for building web applications and it’s just a very popular Java component in general and that’s why this vulnerability is problematic. And what this vulnerability allows is an attacker and exploits it can run a code on the job application server that serves. The vulnerable application, the application that’s built with the Spring. For example, the most common server is Apache Apache tomcat there’s also eclipse jetty and other application servers but whichever one of those services a vulnerable application this vulnerability can be used to run remote code on that server, which is a very high impact. It was an interesting vulnerability in similar to look for J, in a sense that it was dropped as a zero day on Twitter and GitHub so there was a blog that alluded to the ability on March 29th and nobody really knew, if this is a real vulnerability. And there was confusion because other vulnerabilities also popped up at the same time it’s Spring framework. We talked about that in our blog a bit. Then after it was leaked, people started running the zero-day, including ourselves and figured out that this is actually the real deal. And then the day after it was also confirmed officially by Spring, which is owned by VMware right now. Then everybody realized, “Okay, this is a real issue and it’s a problematic issue and we need to figure out how to solve it, who it affects etc.” So regarding our first question, “is it as bad as Log4Shell?” So the answer is probably not a bad vulnerability for sure. The reasons for that is that is very stable and easy to exploit there’s a public PLC which again was dropped, even before vulnerable sorry fixed versions were available of the Spring framework so. It was dropped as the order and Spring framework or specifically Spring mvc applications, which is what is vulnerable are very popular. So all that being said, it’s bad, but why is it not as bad as Log4Shell and we’ll dive into that. So, first of all, it got a lot of attention partially because of the name. Definitely, because it was dropped as a zero-day, which is also always a bad practice, and you know pat everybody’s on panic and don’t really realize what’s going on, but it was really artificially high by a blog called cyber kendra that said Oh, we have this zero-day and actually gave a lot of wrong details which also helps the hive and the confusion people thought it’s the serialization issue. But it’s not and we’ll talk about that, today, so it was really artificially higher than it was even called Spring4Shell in some places which doesn’t make any sense, because a Log4Shell is called Log4Shell, because it’s from Log4j. And SpringShell like Spring framework he doesn’t have a foreign and so it’s just the next, synthetic hyping. So that caused some of the bugs and we can see today. Though there’s much less public record of identified attacks so. We have a like a picture here that’s from my blog, for example, and this looked at five or five and six days after law for Jay was published and how many exploit attempts were per hour. And we can see that there’s like a peak exploitation attempts of 25 million attempts per hour, which is crazy and we haven’t heard such. Reports on SpringShell, yet, even though it’s been exactly the same amount of days it’s been five or six days since that was published so that that’s a bit of a real world information on, you know that it’s probably not as bad. And the coach, the question is, you know why isn’t it as bad so first of all, the Spring framework or specifically Spring model view controller applications. It’s just less common democracy, so we did a very high level but someone controls the check. If you’re searching GitHub for get Lager, for example, which is the API that initialize as a lot for day you get 23.4 million code result. Potentially like obviously not all of them, but in high level, potentially, these are all vulnerable. Why, because when you instantiate a Lager like 99% of the time they’re going to pass some user input into it, it might not be remote input in some cases, but in a vast majority, it is, and so basically in high level, you could say that you have 23 million code result that are exploitable. And when we look at, and when we search similar terms for SpringShell so, for example, we search for request mapping which we’ll talk about a bit later and get mapping post mapping, like all of those together give back 15 million results, which is again even compared to that it’s considered considerably less, but the next point is that, out of these 15 million results actually only a fraction of them are exploitable because, unlike block for Jay that’s our Log4Shell, which was de facto exploitable by default, because when you log something you’re probably going to log something that that is user control, because otherwise you’re just logging constant data. Spring4Shell isn’t exploitable by default, it does require. Specific prerequisites which I’ll go over. They’re just it doesn’t happen all the time, not all the Web applications that you build with Spring framework are exploitable they don’t they don’t feel all these prerequisites. That’s compounded by the fact that the currently leaked PLC Code, the proof-of-concept exploit. Currently, only works for Apache tomcat which we’ll talk about that as well and love for Shell PLC was just universal doesn’t matter where you’re hosting it on one machine windows Linux. It works for everything and now it’s free for shells PLC only works in a specific scenario so on top of the prerequisites which we’ll talk about there’s also exploit specific prerequisites. And these are also non-default so it’s not like oh it’s represented, but it happens all the time now so because of this PLC is limited it actually left more times more time to vendor for vendors to catch and mitigate this this issue. It’s just relevant for less machines so we’ll talk about that later as well. Another big thing with Log4Shell, which is very different from a lot of vulnerabilities it’s a vulnerability in a library and again the vulnerability is it’s in such a basic usage of the library that it’s basically always exploitable. And when it’s a library it’s what in CV terms we call it a change scope that type of vulnerability, for example on the right hand side, you can see that, for example, with the Log4Shell and attacker might send a malicious request to whatever some server that listens publicly outside of the dmz but that isn’t actually the server that’s vulnerable it’s a server that you know. Processes some data and then transfer that data into some login just or inside the dmz and then that login just or transfers that data again inside, you know, an internal server like inside your private network and only there, for example, that’s over would log it with the Log4J. The server that you send the initial request to the public server is usually not usually but doesn’t have to be the vulnerable server. That’s that makes Log4Shell very hard to detect because you’re not just going over your external assets you actually be to also go over your internal assets that can, for some reason, get big certainly can even be through a very niche channel. So it makes it very hard to detect and it makes it more impactful because. You might an attacker mind hack into a server in the internal network, which is much worse, of course, that hacking into a public server type of dmz etc. And with spiritual this is usually not the case that’s because, again, you need a vulnerable web application and that’s why mobile web application is. If it’s a tackle then it’s hosted on a vulnerable application server and that application server is either completely public or inside a DM DMZ. And that’s usually where the buck stops. You hack into that server and that’s it’s not going to be a server that you know, then transferring the data into some internal server that hosts the vulnerable APP it’s just not usually how these things are architected. So that’s also a big chain and it just made love for cell very hard to detect and more impactful. Okay, so for our second subject of what exactly is an exploitable so first of all like I said it’s not exploitable by default, there are few prerequisites, and these are the prerequisites that aren’t tied to the actual PLC exploit, so these are requisites for whatever future exploit also appears these will be the prerequisites as well, so, first of all, the Web application has to be built on the Spring framework which is that’s the basic prerequisite nothing very interesting there. An interesting prerequisite is that it had the web application has to be hosted on the machine that’s running Java nine or later version and that’s interesting because today. Basically, from surveys, it seemed that the two more most popular versions of Java 810 11 and they’re split 50/50. So, it means that, theoretically 50% of the Java versions out there aren’t vulnerable, and this is a very important prerequisite, because part of the bug is. In Java nine, not just in Spring framework so really if you’re running Java eight which apparently 50% of the people are doing, then you’re definitely not vulnerable to this issue, but again 1117 etc. vulnerable and probably the most restrictive prerequisite here is that the Web application has to use data binding, which is a feature of the Spring framework in order to bind request parameters to our job, so we have. Exact detail of how it looks and what it means in our blog as well, but I’ll go over. Some of the details here as well, of course. This is in the Spring framework applications in general. It’s somewhat common in Spring mvc applications it’s a more common than so it’s not like something that is super rare but it’s definitely not default like not all the Web applications are going to be doing this data binding to a Java object. So what this means the factor is. The request handler in your Java your Spring web application, it has to have request mapping annotation or get mapping post mapping process mapping, etc., again we have the full list in the blog so it has have one of these annotation, which means that handles he to be get post put etc. And the big thing here is again that it’s trying to take request parameters and feed them into some user defined class, so you. As a web application writer you write some user defined class and the request parameters are being fed right into that into the fields of this class and the way that it looks like in our in code is that you have a parameter that has the model attribute annotation. And then means Okay, this is how you’re feeding the request parameters into the model and here in this data binding process, this is where the vulnerability happens so, for example. Again, though this is vulnerable, but for a non-vulnerable example, we have the same type of endpoint but here. It’s taking, for example, a request parameter that’s called a my stream and it’s finding it as a string data type, so this isn’t vulnerable because, again, it has to bind it. To do what’s called ponyo plane or Java object, or just basically a user defined class if you’re buying the parameters to some well known classes that are show or primitive types or whatever it just it’s not horrible it’s a different path in the code and it’s not going to be vulnerable. So the kicker is you would say okay I’ll just look for code that has this model attribute temptation, but the annoying part is that actually this annotation is implicit. In several cases, so, for example here there’s exactly the same code and you can see it’s exactly the same code only I omitted the model attribute adaptation, but actually it works exactly the same in the background, so this is still vulnerable and that happens because. Spring framework just adds the model attribute annotation. To the web application if it doesn’t match well known times, which are these types also for reference again in the blog if it’s not a primitive types or if it would be like an interior, then it won’t trigger that specific data binding issue. And that it’s not a simple type, for example, strings like we saw before that’s not vulnerable enough number they arrive. Each of these, even though data binding attempt is happening it’s it doesn’t lead to this specific issue. So basically what you want to look out for you want to look out for a request handler so you find those with this get mapping request mapping post mapping annotation etc., we have that also in the blog. And you want to find that the first parameter is like a user defined flat it’s not one of these well-known classes it’s not a primitive time and it’s not some simple type like we said, like string etc., and then, even if it doesn’t have that model actually that notation. It is vulnerable so that’s how to look out for it and that’s what you should look for in your code base. We also have a tool that’s mentioned in the blog that automate this process, so if you have a lot of code to go over, we recommend checking that out just actually I started to get help for her for some examples of mappings, and these are the most common ones that I found that are not vulnerable, they were also vulnerable one. So, ones that aren’t vulnerable, for example, here, a lot of times there’s just no parameters at all, so in this case there’s no data binding there’s no parameters to bind. Many, many, many times there’s also again primitive types so, for example, or a well-known annotation or class so here there’s a request for annotation which already makes it not vulnerable and it’s with an integer primitive type, so this one won’t be vulnerable as well, because of the types, these are very common and that’s again why it’s not as common as Log4Shell because it’s not like all of the applications with Spring framework are exploitable. The third condition here, and when we didn’t mention it is the current PLC it actually adds an additional two conditions for your server to be exploitable and I’m talking about the public PLC again there might be private exploits and then this point is not accurate and then I’ll elaborate about that, but for the public, exploit in order to actually run the exploit successfully. The web application has to be served over Apache tomcat, which is the most popular dumb application server, but there are other ones and what’s more common here so what’s slightly uncommon here is that it has to be served as a war file, it means that you’re running tomcat as a standalone server and then you’re deploying a web archive to add the Web archive is the Web APP. But, for example, for Spring boot, which is what most people use in Spring framework it doesn’t work that way it creates a jar executable that contains an embedded Apache tomcat server in it, and then you run the JAR and everything runs. Like magic so it’s not a standalone server in that case, which is the default case where Springboot isn’t exploitable by the current one. But, again, there could be many that they could be private exploits or future exploits that don’t have these prerequisites they could just the root cause they would explain the records in a way that they don’t care if it’s on Apache tomcat or how the Web application is deployed. So why like, why does the exploit actually require these. The answer is that’s basically the vulnerability itself what it allows the attacker to do is change some internal attributes of the class that’s been constructed that user defined class that we talked about. The way that the attacker chose to exploit this for remote code execution is by changing specific attributes of tomcat access long, so this is the attribute I won’t go over it, but basically it’s the directory that the log file gets written to and by changing the directory that the log file gets written to and also you change the different attribute that says. The data of the log file, you can basically you get arbitrary file right, you can write a user supply file or attackers apply file anywhere on this and with whatever content, you want and the way that you explained it for remote code execution is you write a web show so small program, this is the whole code of the program JC program server page. The busy just gets a command from query query parameters and runs it so because you can write anywhere you want you write this. The server page to the web root and because you wrote it to the web root the attacker can surf to that page and activate and basically so you’re writing a backdoor Shell and then you’re using that backdoor Shell to run arbitrary commands, so this is how this exploit works, but again future and private exploit my work completely differently, they might right they might override some attributes, which is used with reflection to run code, you know, without writing anything on this and it might not rely on tomcat etc. So that’s just very important to understand because, again, there are a few workarounds which have to do something with a tomcat but that’s fine for this PLC exploit but it won’t solve for future years exploits. For example, for eclipse jetty if you’ll try the exact same exploited it just doesn’t work because it doesn’t have this attributes, so the vulnerability will try to rights to this attribute that this attribute doesn’t exist, so it won’t do anything. So the bottom line is that the exploits will have to be reworked for each application server and maybe even deployment scenario, and that gives us time the attackers will have to research and rewrite that and it’s not that easy. But again, we don’t recommend just switching from tomcat to a different server because who knows, maybe there’s a private exploit that works on all servers even today. So for the final point let’s talk about fixes investigations and I tried to rank them from what I saw. Just so you’ll have some idea on what to try and how to fix this issue. So, first of all, like always the best fix is just to upgrade so either upgrade Spring frameworks to these versions or Springboot if you’re using it directly to these versions. Since all these versions are update on maven you just have to change your POM xml or your bill grateful and just takes it from maven and that should be easy enough, of course, in some cases, it might be compatible with your current setup and then you can’t upgrade right now, or maybe you can tweak compile etc. But if you can, please do this and all the other mitigation that I’m going to show should only be considered if you can’t upgrade if you can do this. So the best mitigation in terms of this vulnerability, at least the point of the stress that if you can’t operate will be just a boundary to Java eight, of course, it might not be possible, because of compatibility issues from your side, but if it is like let’s say you’re running the Web application on a separate container and nothing else, runs on it. Then, this would be good, because it’s very easy to apply it applies global leaves or the entire machine or entire container will be safe, because of this, and it fixes the vulnerability root cause. Because in Java eight there isn’t a bypass that lets you write to that. To those specific class loader attributes then it’s not even future exploits won’t be able to bypass this mitigation, if you do it. So that’s what we specifically recommended again if it’s not a compatibility issue to you because it’s just very easy and it’s a good fit. The second base the second best mitigation would be to do some code base mitigation, that means you’re actually going to change the color of your web application there’s a few details here that’s why it could be error prone and that’s why we like it less than the previous mitigation. You can see Springs blog for exact details will share the URL as well, of course, and it’s pretty much a copy paste affair, but you need to make sure you’re copying it to all of the Web application. Because it’s not machine why. But once you do, that also it’s a good fix like it fixes the vulnerability root cause so anybody that’s trying to override one of these parameters like attributes that contained one of the sub strings it will be disallowed which at least closes down on loan exploit bass. But again it’s error prone and it does require a compilation of your web APP which may be problematic. The last mitigation and the least favorable one would be to upgrade tomcat or just replaced on cat with a, for example, eclipse jetty a different Java application server or deploy your web application as a jar so the common factor between all of these is that you’re blocking the current expert the known exploit the one that needs tomcat and the Web application as a war web archive. You’re blocking that you’re rocking this specific explanation, right now, there is no publicly known other exploit so that would work again tomcat just added code in these versions that blocks this specific attack vector. So this is easy to do and again its global will affect the entire machine or container but it doesn’t fix the vulnerability root cause so again like I said it might not be safe, like if there’s private exploits that can already work, regardless of the application server, it’s problematic. That’s it for today! That’s what we wanted to talk about. We’d be happy to answer any further questions in the Q/A. Thank you all for joining!