>> Hi DEF CON, um, I’m Alvaro, a Pentester, uh, this is Oleksandr with sale. Uh, we both work for the HPE Fortify team. Um, but we have a lot of things to cover today, so enough about us, um, so last year was the year of Java deserialization apocalypse as we like to call it. Like literally, uh dozens or even hundreds of new CVEs were reported around Java deserialization. And around those CVEs like thousands of vulnerable applications and appliances. Uh, it was like a bad problem.

So this was a very well known, since at least 2011. Um, probably it was not, um, so the community was not paying, uh, really a-attention, because there were no, uh, really good gadget a really good remote execution gadget until 2015 when the Apache Commons Collection gadget was published.

So this was the same problem with um dot NET. The third a-attack was published in 2012 for both binary formatted and the net data deserializer. But there was no, uh, remote execution gadget published until now.

So at that time the solution was like, ok, stop using deserialization altogether and developers were like, well yeah, I would like to do so, but I need to serialize my object, uh and store them into a database or maybe I don’t know. Uh, send them across a wire or send them in a socket or whatever. So I need to serialize my object. And deve- um, the security guys were like, ok, then use a secure JSON or XML parser and library instead. 

So our goal with this, um, talk, is to fault. First of all, we want to verify if those JSON libraries are any better than Java deserialization or dot NET uh deserialization and then raise some awareness around dot NET deserialization and stuff. Uh, we said with Java it took like four or four or five years for the community to start looking into, um, you know vulnerable end points and so on. Uh, we don’t want to the history to repeat itself so we will be presenting new remote execution guide to attack this for um, serializers.

So. The first section will focus on JSON. We will present some of the um libraries that we found to be vulnerable. Gadgets to attack them and then uh, demo on a web application framework leading to arbitrary code execution and then we will focus on the dot NET serializers. The completely uh different subject. And then we will try to generalize the talk and we will provide some demos as well.

So let’s jump into the JSON part. So just uh to set expectations here. We’re not talking about JSON, uh, when uh sending simple data or simple JavaScript objects between, uh Java um JavaScript front and and I control it like, I don’t know for example I spring control it. We are talking about replacing Java or dot NET serialization with uh JSON which means that you need to serialize Java or dot NET objects. Which means that you need to support some of the objects in the programming features like how I’m going to deal with the Java line object, how I’m going to deal with the system object in dot NET, how I’m going to deal with generic parameter types, polymorphism, interfaces and so on.

So we will be abusing the um, the features that these libraries include to support these OOP stuff.

Uh, very quick recap on how Java deserialization or how the attackers were able to get a arbitrary code execution on Java deserialization. Um, basically they were able to provide untrusted data to the serializer. In this case the object input stream in in Java. And this untrusted data contains, um, types, some class names that were instantiated by the deserializer. And then some um deserialization call box. Like read object or re- read result were invoked and then the attackers were able to uh start a gadget chain that is nothing else that connect in different classes um together. Something like a gadget chain leading to an arbitrary execution, but starting from this read object or read result of deserialization callbacks. However, JSON does not invoke any of these deserialization callbacks normally or at least some of the, most of the libraries. So we need to find some, um, some other ways to start our gadget chain leading to these code execution.

So um most of the, um, JSON libraries will work and will uh, will try to reconstruct the object in any of these ways. So basically they will invoke the default constructor in order to uh instantiate the object and allocate the memory and then use either reflection or setters in order to populate the fields properties of of the uh of the instance.

Some of them will invoke some special constructors or deserialization callbacks or or type converters. We don’t have time in this talk to cover all of them. Um but these are also vectors that lead to arbitrary code execution. We have um, we have uh covered in our white paper that will be published in the DEF CON Community server. And then most of these libraries also invoke some um common methods, like for example, hashcode or equals normally get invoked. Uh when deserializing hash tables to a string normally get invoked when um raising exceptions. Finalize is always invoked by the garbage collector when when claiming the memory for the objects. But uh, by far the most common one is uh the setters. Setters are normally invoked by most if not all of the libraries. So if we are able to find arbitrary code execution gadget chains starting with setters, we will be able to use them to attack these libraries.

>> Let’s have a look at a few setter gadgets in dot NET. All of them can lead to arbitrary code execution. Some of them has own requirements and limitations, but do believe that it’s not very difficult to pick up proper one for specific case. So our first gadget is uh setter of path property in assembly installer class. It allows code execution during uh library loading from path controlled by an attacker. Uh, there is no additional requirements if uh assembly payload is on local machine. But in case of remote services dot NET framework may have some additional security checks.

The next two gadget use use uh uh XML parser. Uh we will show a bit later how it can be used for arbitrary matters in location.

So, uh setter of property inspector font and color data in workflow design and type requires single threaded apartment set. It’s quite strong requirement, but if your target ha-has such configuration, you will get remote code execution.

The next gadget is source setter of resource dictionary type. Uh it has a few requirements to, mmmm, JSON unmatched. It should call setters for types uh that implement a dictionary interface and often in such cases, uh, unmarshaller are just populating key valued pairs. Also it should be able to reconstruct system overwrite object as this type doesn’t have default constructor. But often uh, un-unmarshallers can do this. 

And our final gadget is uh object data provided type. It’s quite flexible and allows um a lot of ways to for attack. [inaudible] we were able to use it in almost all our unmarshallers and formatters. So let’s have a look on uh code diagram of this gadget. Setter will call refresh method, it will invoke begin query, it will call query worker and finally invoke method and instance. We can see the line that will call our arbitrary method. 

Uh here we can see example of JSON payload that we uh popup calculator for a second configuration of JSON dot NET parser. Actually this set uh, gadget, allows the next main ve-vectors. We can call non default constructor with it’s own arguments or can invoke uh public method to unmarshaller object. Or we can call any public method including static ones with our own parameters.

Uh, Java has own uh setter gadget as well. After our our last year research and JNDI injection attack, we have found a few setters with JNDI look up codes. By the way Oracle recently disabled uh [inaudible] vectors in default configuration of Java. But [inaudible] still works, so our gadget sets session factory JNDI in statistic service.

We already mentioned about this in our last year talk at Black Hat 2016. Very similar to it is two string gadget from remote client user transaction class. And finally set of the commuter gadget from already known uh class G B zero set input. Let’s have a look on it. It, this uh class is from GRE library so doesn’t doesn’t require any external dependencies. Setter code connect function and here we can see uh the typical code in the initial context lookup method with our value from uh data source main properties. So we will get remote code execution.

A part from our gadget that allows code execution by themself, we have a couple other interesting gadgets. Some of them can be used as building blocks for a gadget chain like um, BindingSource set data number in dot NET or string template to string in Java can be used for arbitrary ga- uh gadget calls. Other configured non as see attacks for example inner XML in XML data document or um setter of data view setter collections in data view manager can be used for uh XML external enteties attack in some version of dot NET framework.

Now we will back to Alvaro, he will show where we can use this uh gadgets.

>> So we analyzed like multiple Java and dot NET additional libraries and uh we found that most of them were vulnerable arbitrary code executions, some of them in the full configuration and some of them um developers need to enable or configure them and a special way. So we came up with this uh simple high level requirements for uh library to be vulnerable to this attack. Basically the attacker needs to be able to control the type or the class that is going to be instantiated in the server. Um that normally means that the JSON that dr- um intercepted for example, there will be an attribute called something like underscore type or direct type class object, class name that uh contains a value that looks like a dot NET or a Java class name.

Then the library will instantiate that uh type and then the second requirement is that the attacker or in this case the library needs to invoke some methods on these reconstructed object. And finally the third requirement is that the attacker needs to be able to assemble the remote execution gadget chain. Um and starting from those methods that I invoke by the boy the library. As I said said before, setters are normally invoke in most of the libraries, so the the caveat is that Oleks just presented are normally can be normally used for any library.

So we can analyze these libraries um according to the likelihood of them being vulnerable and for that we uh choose two different factors. The first one is whether the library includes the type discriminator that is nothing else that the class name in the analyzed data like we are seeing uh here for example in JSON dot NET. And uh so that can be done like by default by the co- by the library or developers may need to enable um a configuration setting. And then the second factor is how this library prevent uh malicious types from being instantiated um, and loaded. So we found that some of this libraries perform a post deserialization from cast. Which uh offers no security at all because basically by the time that you get the uh cast exception the payload has already been executed and you’re already been compromised. And the second type control is what we call the inspection of the expected type object craft. Which sounds like a little bit complex, but its nothing else that the library will take the expected types so for example a use of the library may be expecting a user or account or whatever and then analyzing the object craft and checking what that the user is sending and the um in the JSON data is acceptable to the types defined in the object craft.

So some libraries go farther and also build a white list of construction time and apply this list at one time using the deserialization. We found that these um these libraries the libraries performing this type control and also vulnerable if the attacker can control the expected type. That is more common than you may think and we will see an example an example later. And also if the attacker can find an injection point an entry point in the object craft. So for example as you can see here in this um example object craft here all the properties in red may be a good examples of entries points. Like for example a system object property and non-genetic collection property like hash table, are really substantial one. So again we don’t have time to cover um how to cover entry points but this is also covered in the.. in the white paper.

So this is the list of the additional libraries that we analyzed. The ones in red are vulnerable by default, so fast JSON, sweet JSON, JSON i01 presentation should never be used with untrusted data. Basically they include the type information by default and they perform no um type control at all. Then they invoke setter so we can use our setters to get arbitrary code execution. The ones in yellow and orange depends on the developers and how they are using the library. So most of them uh that do not include the type information by default in the JSON data. But there is this uh configuration setting that can be enabled a to do exactly that. And then they perform this inspection of the object craft so you need to find an entry point. You may think that uh finding an application that satisfies both requirements is difficult, but its kind of the opposite because if developers has a property of for example of system object, they will be forced to uh enable this configuration setting to include the type information and then make this class uh or these types serializable. 

So uh we uh JSON um is the only one in green. We found that is very difficult to make it vulnerable. You can also uh implement a type a make it a vulnerable, but, I mean, you need to ha- to do it on purpose. And in addition it does not invoke any setter, it does use reflection, so you need to use or to find gadgets and starting for example with finalize method, which is um more difficult than, than the setter one.

So let’s see some of these examples, for example fast JSON is one of the ones in red. Should never use this with untrusted data and basically yeah, it includes the type information by default it does not offer any type content uh type protection or type control and then it will invoke the setter, so we will be able to use for example our object data provided gadget to get arbitrary code execution like we did in this KalikoCMS that is um dot NET content match system.

Then we have uh, Java script serializer that is one of the dot NET native libraries in the dot NET framework. By default it doesn’t really include the type information, but uh developers can do that by uh passing this simple type resolver or any other type resolver to the constructor of the Java script serializer and the deserialize untrusted data. So by the way all these examples are from GitHub so this is real code. Um basically this Java Script serializer does not offer any type controller, it performs a post deserialization cast operation so it uh its vulnerable by default if developers are uh configuring it with type controller.

Then we have the data contract JSON serializer that is probably one of the most secure ones um but um well it performs accessing ability check that we talked before, but also this creation of a white list at a construction type that is then applied at run time time. So with that, the only way a devel- uh an attacker can get arbitrary code execution on this library is if they can control the expected type. Um again this is from GitHub it is an example of how the type can be controlled by the attacker in this case coming from a cookie.

We will see an example in DNN that is one of the most popular CMS for dot NET where they’re doing exactly this. And then we have JSON dot NET that is um probably the most popular library, it’s even recommended by Microsoft over their own native libraries. Uh again by the default it doesn’t include type information but if developers enable this state name handling setting then they will include this information. Um this is another example for GitHub as you can see because it contains this class called message because it contains uh body property which is a system object type, then developers are forced as I said before to enable these uh configuration settings to include the type of information. And then the library will invoke setters, deserialization constructors, code box and even some a narrow custom code box. So um basically the attacker has like a very large um gadget and space to get arbitrary code execution. 

So lets see an example uh, demo. Uh this is Breeze, it’s a web application framework. Uh, which basically was not really a web application framework. It’s more a data management framework. So it offers a rest API for both a Java Script and dot NET clients to connect to the API and perform like entity management operation like adding a new record, uh deleting a record, updating record and so on. So we found that this framework was using JSON dot NET which is like as I said the the most popular JSON library for  dot NET and its configured include the type information when serializing the um system object properties.

So at some point, uh this code here will deserialize untrusted data coming from the request and then as you can see here basically this um safe option used um type here is the expected type. So I said that we have to do the expected type object craft inspection which is quite simple in this case because the safe option type only contains two properties. The second one is um main attack and a system object property so we can, this is our injection point, our entry point to place the payload.

So with that let’s see an example, this is Car Bones, it is one of the sample application, that come from, with the with the framework. Um for Developers to learn..learn the framework. And basically um in this example we can just um new um car models or rename the models and so on so if we change the name of this model and we um intercept the request with burp, we will see that um well we have all the expected data, like for example the new model name is appearing in the JSON data that is submitted to the rest API. And then we have this anti-safe options dictionary. If we send this request to the server, we will see that there is in the response, there is this dollar type attribute which is our indicator that this is just in JSON dot NET and that is including type information. So that’s those are the ingredients um for our arbitrary code execution. We will be using our object data provider gadget basically to invoke the process data start and pop up uh calculator when the framework process these uh requests. So we will just replace this empty dictionary with the payload and then let’s check that in the victim server there is no calculators running and now as soon as we submit the request, they will get deserialized and we will get arbitrary code execution.

[Clapping]

So thank you uh so this is a popular, a very popular a framework in  dot NET and has been sent out to the developers because they fixed the issue in just one day. Um also a big shout out to Moritz Bechler that is uh Java executed researcher um um May twenty-two, he published this Java master security paper which basically similar to our research um serves the same premises and conclusions uh well uh he overlaps with our research in the Jackson and JSON-IO library so for the JSON one he found like a completely different vector and he also overlaps with us in our JDVC rule set import class or gadget. But this was like a kind of um like obvious choice because it was previously used in the java deserialization work. Uh also he found other interesting gadgets for Java. In third party libraries like Spring so if you are interested in a more Java focused version of this talk go and check his his work.

So now we will change um gears and focus in dot NET serializers.

>> Let’s back to the dot NET world. Potential security problems with binary format and net data controlled contract serializer were known for lean. For example the great work of James Forshaw about weaknesses and main attacks in uh in this um main dot NET formatters was presented at Black Hat 2012. So 5 years ago unfortunately we could not find um good um available remote code execution gadget chain. There was one published by Florian Coldea but it uses memory corruption so it’s not very easy to build universe exploit for different version of Windows. But we were sure that should be a lot of ways um to get code execution during dot NET deserialization so we spent some of our time and have found one that can be used in binary formatter and some other dot NET formatters. But after our work was ready and accepted by Black Hat, the same James Forshaw published a couple remote code execution gadgets as part of his own research, but they are not connected with our topic.

Anyway you can find details about this gadget on the on his post uh on google projects data book. Here we will focus on our own. We will use PS object type it is part of publisher libraries so should be available in almost all Windows machine. Before we go further there are a couple remarks about this gadget. Uh in publisher uh version one, these type is not serializable so is not suitable for attack. But all modern version of windows attack from windows site and windows server 2012 are shipped as newer and vulnerable version. Uh, the next remark, we reported this issue to Microsoft and two weeks ago uh they released a fix, so if you are not if you are not ignoring their updates, you should be safe. 

So PS object. Uh for deserialization it used custom deserializer and in case of TIM instance it will call TI invariant rate, TIM instance property matter. Here we can see that attacker is able to specify own type as element type of array and um deserializer will try to reconstruct object of this type. To find proper way to do this it will use figure conversation matter. It’s quite interesting matter for an attacker as there are a lot of options for an attack. We highlighted only the most obvious ones. So we can call non default constructor with one argument and we can control it’s value. Um also we can invoke setters on public properties, so we can use our gadgets, earlier gadgets. And also we can use static parse method uh of arbitrary type. Lets try to use this one. Sorry.

As we said earlier, some reader parse can use can be used arbitrary matters and location. Here we can see examples of payload that will call code to start with our argument. Here we can notice uh namespace, assembly, type, method name and finally, call custom argument. And we’ve mentioned it a binary net data contract serializer, um formatters, dot NET offers a lot of others. Unfortunately we don’t have enough time for a detail view of each of them so we will briefly cover uh them in our today uh talk and if you’re interested in different analysis, we can offer our white paper as good source. So we can group them in two big group. Formatters that are vulnerable in the full configuration, like binary formatters, sub formatters and data contract serializers. Also we can add here uh formatters that interminably use them like object state formatter, loss formatter, binary message formatter. They should not be used with untrusted data or you have to proper configure them to limit available types. For example use uh restricted type resolver with white listed types. Other group, uh formatters that are safe in default configuration like xml serializer, data contract serializer, data contract JSON serializer, but if you’re using quick data contractors over by the way we have met such examples even on official uh Microsoft documentation or attacker is able to control control expected type. You will have very serious security problem. We will show a bit later that in this cause uh code execution is real even for the for the most limited formatters. For example, xml serializer. Now we’ll switch back to Alvaro, he will show our next demo.

>> So because our demos probably worth a thousand slides uh we will show you how to get arbitrary code execution on some dot NET framework in this case Nancy that is uh web application framework. That is very similar to the Ruby’s um Sinatra framework, but for dot NET and well basically they care about security which is good. And they implemented CSRF protection. The only thing is that by protecting against CSRF they opened the doors for remote code execution, but yeah.

So ah instead of putting this unique token into the cookie like most of the frameworks do. Um they created like a uh, type code CSRF instance where they put this token and then they serialized  this uh instance of CSRF token and then they based the bay 64 code the payload, the payload, the the cookie into the cookie. Anyway you do find this AAEAAD magic number in any of your bin tests, then uh you will get uh you will be able to get that arbitrary code execution.

So let’s see that in action in one application, so this is an application we build you see in Nancy and we were able to get arbitrary code execution uh pre-authentication by basically replacing the cookie. So uh this is the cookie that the framework injects the and this is half cookie as you can see contains this magic number ah then this bay 64 encoded block uh if we check the page they also include the same value as a hidden um field in in the form, so they are doing like a double submission, which is good. But since they are using binary format deserialization then um well its not that good. Anyway, uh we serialize our PS object gadget, um in order to populate our calculator with a calculator payload and then we are just basically replacing the cookie with our payload. You can use our payload or any of James Forshaw published payload and now if we go back to the server there are no calculators running and as soon as we submit the form we so- we- we will get an exception but we will get our payload executed.

[Applause]

Thank you. So um we just wanted to highlight that this is not really a problem in JSON or XML parcers or I don’t know Java deserialization or the binary formatter for dot NET, this is a problem for serializers themselves because all of them need uh to reconstruct the object using the deserialization process and that means instant hidden types that normally can be controlled by attackers and then invoking methods. So as we said before, this simple three high level requirements like the attacker being able to control the type, then the um some methods being called on this reconstructed type and then a large enough guarded space for the attacker to find um arbitrary code executed gadget chain will normally apply to any serializer in any language. Uh as we said before, most of the times setters will be invoked so the gadgets that we presented here today the object data provided gadget and the JDBC [inaudible] gadgets will normally be um good gadgets to attack any other libraries. We found like many other libraries being vulnerable or being um susceptible to arbitrary code execution um but we don’t have space in the slide or time to cover all of them. So these are good examples of them, for example FS Speak Clear or Sub serializer are dot NET serializers. They work not just in the dot NET framework but also in dot NET core uh Silverlight uh windows mobile phone for example. So the developers may choose them instead of the native one because they are more suitable for their needs. And while all of them include type information by default. They invoke setters and they perform either no type control at all or just the object craft inspection so attacker may need to find these entry points.

Also we have wire that is now known as Hyperion that is the serializer for Akka dot Net if you’re familiar with the Eskala or Java version of the libraries um framework for concurrency based on inactive. So you have like different actives that sending messages and these messages were serialized with uh JSON dot NET using this type name handling setting it was to us it was vulnerable but then they replaced this JSON dot NET serializer with Hyperion that is that there custom serializer and uh well this Hyperion includes type discriminators, invokes setters and then uh perform no type controls so again this another vulnerability.

Also uh be aware of running your own format, for example this Nancy framework that we talked about before, they moved away from binary formatter because um well it was not included in the first version of dot NET core and they want uh their framework to be compatible with dot NET core. So they moved away from binary formatter and then they created their own JSON library. And as you can see here it includes a type discriminator that is called type object in this case and then it will invoke the setter so we were also able to get arbitrary code execution on the pre-release to the text branch of this framework.

Uh we also found uh very interesting CMS is one of the most popular CMS for for the net if not the most. But it’s called dot NET Nuke and they use xml serializer to serialize arbitrary types. Since xml serializer need to know the type ahead of time then they created this wrap around xml serializer where um they would in a cookie, now a cookie, they would yeah set the type that was going to be used for the dot NET xml serializer and then the payload for the xml serializer. So um this was like a challenge for us because xml serializer as Aleks said is the most limited serializer in dot NET. Basically doesn’t allows you to do many things like serializing um system type property or serializing uh a type for example with interface members. So if we were able to get arbitrary code execution on an xml serializer we were like confident that we were going to be able to do that for any other libraries.

So uh we tried with our object data provider gadget and so far so good it was like xml serializer friendly no problem so far. Now if we try to use that gadget to invoke process data start then we have a problem because the process type contains interface members so um xml serializer doesn’t like it.

That problem was easily solved because you can choose gadgets from anywhere else like for example the Xamlreader load method, the obvious state formatter deserialize method, or you can even look for gadgets in your target um class class path or type. So for example since we are talking dot NET nuke we search for gadgets in dot NET Nuke and we found that they have this file system utils type which is very handy for hackers because they contain methods to deploy web cells and methods to read any arbitrary files into the expected response. So very convenient for us. So now the next uh problem was that xml deserializers builds uh white list of allowed types at construction type and then it applies the white list at run time run time time. So that was a problem because um we need to send an instance for example of our Xamlreader or the file system utils type as the payload and these types are not going to be included in the white list. So we needed to find some way to fool xml deserializer to include our arbitrary types into the white list and within do basically by using a parameterized type as the expected type as you can see down there and then we used the forced parameterized type to place our payload type like five system utils. And then the second type to put our object data provider type.

So with that uh we were able to get arbitrary code execution pre-authentication on dot NET Nuke. Um at first these uh guys from dot NET Nuke uh assigned it like a low severity, which was like weird because it’s pre authentication RC. And they said that this uh severity was assigned because um attacker needs to be able to understand how the cookie works. And we were like, ok dude, do you know that framework is opens source, right? Right so. Anyway, they change it that to critical at the end. 

So this is the source code the relevant part at some point um it reads for example when you visit the 404 Error page it uh executes this code as as you can see here, I was uh reading the cookie with uh DNN personalization and then passing this xml cookie into this this deserialized hash table xml method. If we check this method is basically extracting the data from the xml cookie like here and then using this type name to construct the xml deserializers. So the attacker can control the expected type as we said before. Now is uh is deserializing the rest of the cookie. So uh this is what uh DNN personalization cookie looks like in a real DNN application. As you can see here it contains the type and then the inner blue box is basically the payload for the xml serializer. And this is what our payload looks like. So the expected type contains this parameterized type which contains uh our run time payload types and then the inner blue box is our payload for the object data provided. So in this case instead of popping up a calculator, we um are using the file system utils class in dot NET nuke to basically download our web cell and deploy it into the IIS root folder.

So let’s see that in action. So this is the out of the box installation of DNN. If you run it um visit a non existent page, you will get your 404 error page. Sorry this page you are looking for is not here. And if we send that to burp, well the request does not contain the DNN personalization cookie but by reading the code we know that its processed in this cookie, so we will just include it manually. Like DNN personalization and then we will basically paste the xml payload that is showed you before which as I said issuing the pull file method in the file system utils class that is provided by DNN to deploy the web shell. So let’s paste this into the request format this a little bit. And now in the victim server, we will check that well we don’t have these cell ASPX web cell that we are downloading so now as soon as we execute their request the cell ASPX will appear as you can see there. 

[Applause]

And well we’ll, be able to basically uh interact with the system um basically by visiting the web page and install whatever we want to do.

[Applause]

Thank you. So with that uh just to wrap up, just um remember that this is not a problem JSON or XML or I don’t know, any of the serializers. So try to avoid deserializing untrusted data with this is also a problem in Ruby, Python, PHP so um do not deserialize untrusted data and if you have to, um get your library evaluated by some security guys um try to avoid libraries that performs no types controls so they are just doing the post deserialization cast. Try to avoid libraries that include type discriminators. It’s not like uh, its not actual physical requirement for arbitrary code execution but it’s a good indicator that you will be able to get arbitrary code execution. And also don’t allow developers to let users control expected type like we saw in DNN and last but not least try to not roll your own format because you can just f**k it up so with that thank you very much and if you have any questions. Here’s our e-mails.

[Applause]