 Hi, DevCon. I'm Alvaro Pontester. This is Alex. We both work for the HP45 team, but we have a lot of things to cover today, so enough about us. So last year was the year of Java digitalization apocalypse, as we like to call it. Like literally, dozens or even hundreds of new CVs were reported around Java digitalization. And around those CVs, like thousands of vulnerable applications and appliances, it was like a bad problem. So this was a very well known vector since at least 2011. Probably it was not, so the community was not paying really attention because there was no 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 .NET. The theoretical attack was published in 2012 for both binary formatter and the net data contract serializer, but there was no remote execution gadget published until now. So at that time, the solution was like, okay, stop using Java digitalization altogether, and developers were like, well, yeah, I would like to do so, but I need to serialize my objects, store them into a database, or maybe, I don't know, send them across a wire or send them in a socket or whatever. So I need to serialize my objects. And the security guys were like, okay, then use a secure JSON or XML parser or library instead. So our goal with this talk is to fold. First of all, we want to verify if those JSON libraries are any better than Java digitalization or .NET digitalization, and then raise some awareness around .NET digitalization stuff. As we said, Java took like four or five years for the community to start looking into vulnerable endpoints and so on. And we don't want the history to repeat itself, so we will be presenting new remote execution gadgets to attack these serializers. So the first section will focus on JSON. We will present some of the libraries that we found to be vulnerable, gadgets to attack them, and then a demo on a web application framework leading to arbitrary code execution. And then we will focus on the .NET serializers, completely different subject. And then we will try to generate the attack and we will provide some demos as well. So let's jump into the JSON part. So just to set the expectations here, we are not talking about JSON when sending simple data or simple JavaScript objects between a JavaScript front end and a controller like, I don't know, for example, a spring controller. We are talking about replacing Java or .NET serialization with a JSON, which means that you need to serialize Java or .NET objects, which means that you need to support some of the object-oriented programming features like how I'm going to deal with the Java-lang object, how I'm going to deal with a system object in .NET, how I'm going to deal with generic, parameterized types, polymorphism interfaces and so on. So we will be abusing the features that these libraries include to support these OOP staff. Very quick recap on how Java serialization or how the attackers were able to get arbitrary code execution on Java serialization. Basically they were able to provide untrusted data to the serializer, in this case the object input stream in Java. And this untrusted data contains some type, some class names that were instantiated by the serializer. And then some digitalization callbacks like read object or read resolve were invoked. And then the attackers were able to start a gadget chain that is nothing else that connecting different classes together, assembling like a gadget chain leading to arbitrary code execution, but starting from this read object or read resolve at digitalization callbacks. However, JSON does not invoke any of these digitalization callbacks normally or at least some of the most of the libraries. So we need to find some other ways to start a gadget chain leading to this code execution. So most of the JSON libraries will work in, well, we'll try to reconstruct the object in any of these ways. So basically they will invoke the default constructor in order to instantiate the object and allocate the memory and then use either reflection or setters in order to populate the fields and properties of the instance. Some of them will invoke some special constructors or digitalization callbacks or type converters. We don't have time in this talk to cover all of them, but these are also vectors that lead to arbitrary code execution. We have them covered in our white paper that will be published in the DevCon Media server. And then most of these libraries also invoke some common methods like, for example, hash code or AQUAS normally get invoked when digitalizing hash tables to string normally get invoked when raising exceptions. Finally, it's always invoked by the garbage collector when claiming the memory for the objects. But by far the most common one is the setters. Setters are normally invoked by most if not all of the libraries. So if we are able to find arbitrary code execution chains starting with setters, we will be able to use them to attack these libraries. Let's have a look on a few setter gadgets in .NET. All of them can lead to arbitrary code execution. Some of them have own requirements and limitations, but we believe that it's not very difficult to pick up proper one for specific case. So our first gadget is a setter of pass property in assembly installer class. It allows code execution during library loading from pass controlled by an attacker. There is no additional requirements if assembly this payload is on local machine. But in case of remote resources .NET framework may have some additional security checks. The next two gadgets use XAML parser. We will show a bit later how it can be used for arbitrary method invocation. So a setter of property in spectro font and color data in workflow designer type requires single threaded apartment thread. It's quite strong requirement, but if your target has such configuration, you will get remote code execution. The next gadget is source setter of resource dictionary type. It has a few requirements to JSON on marshaler. It should call setters for types that implement IDiction interface. Often in such cases on marshalers are just populating key value pairs. Also it should be able to reconstruct system override object. This type doesn't have a default constructor. But often marshalers can do this. And our final gadget is object data provider type. It's quite flexible and allows a lot of ways to for attack. As a result we were able to use it in almost all our marshalers and formatters. So let's have a look on call diagram of this gadget. Setter will call refresh method. It will invoke begin query. It will call query worker. And finally in invoke method on instance, we can see the line that will call our arbitrary method. Here we can see example of JSON payload that will pop up calculator for unsafe configuration of JSON dot net parser. Actually this gadget allows the next main attack vectors. We can call non default constructor with own arguments or can invoke public method on marshaler object. Or we can call any public method including static ones with our own parameters. Java has own setter gadget as well. After our last year research in JNDI injection attack, we have found a few setters with JNDI lookup calls. By the way Oracle recently disabled Arama and Corba vectors in default configuration of Java. But LDAP vectors still works. So our gadget set session factory JNDI name in statistic service. We already mentioned about this in our last year talk at blackhead 2016. Very similar to it, it's two string gadget from remote client user transaction class. And finally set auto commit gadget from already known class gdbc row set impo. Let's have a look on it. This class is from GRE library so doesn't require any external dependencies. Setter will call connect function. And here we can see that we will call initial context lookup method with our value from data source name property. So we will get remote code execution. Apart from my short gadget that allows code execution by themselves, we have a couple other interesting gadgets. Some of them can be used as building blocks for gadget chain like binding source set data member in dot net or string template to string in Java can be used for arbitrary gather calls. Other can trigger non RCE attacks. For example, inner XML in XML data document or setter of data view setting collection stream in data view manager can be used for XML external entities attack in some version of dot net framework. Now we will back to Alvaro. He will show where we can use these old gadgets. So we analyzed like multiple Java and dot net library and we found that most of them were vulnerable to arbitrary code execution. Some of them in the full configuration and some of them developers need to enable or configure them in a special way. So we came up with these simple high level requirements for 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. That normally means that in the JSON that you are intercepting, for example, there will be an attribute called something like underscore type or dollar type class type object class name that contains a value that looks like a dot net or a Java class name. Then the library will instantiate that type and then the second requirement is that the attacker or well in this case the library needs to invoke some methods on this reconstructed object. And finally the third requirement is that the attacker needs to be able to assembly a remote code execution gadget chain starting from those methods that are invoked by the library. As I said before, setters are normally invoked in most of the libraries. So the gadgets that Alex just presented can be normally used for any library. So we categorize these libraries according to the likelihood of them being vulnerable and for that we choose two different factors. The first one is whether the library includes the type discriminator that is nothing else than the class name in the serialized data like we have seen here, for example, in JSON dot net. And so that can be done like by default by the library or developers may need to enable a configuration setting. And then the second factor is how this library prevent malicious types from being instantiated and loaded. So we found that some of these libraries perform a post-desialization cast which offers no security at all because basically by the time that you get the cast exception the payload has already been executed and you're already being compromised. And the second type control is what we call the inspection of the expected type object graph. Which sounds like a little bit complex but it's nothing else that the library will take the expected type. So for example, a user, the library may be expecting a user or a cart or whatever and then analyzing the object graph and checking if what the user is sending in the JSON data is assignable to the types defined in the object graph. So some libraries go farther and also build a wide list at construction time and apply this list at run time during the digitalization. We found that these libraries, the libraries performing this type control are also vulnerable if the attacker can control the expected type. That is more common that you may think and we will see an example later. And also if the attacker can find an injection point, an entry point in the object graph. So for example, as we can see here in this sample object graph here, all the properties in red may be good examples of entry points. Like for example, a system object property, a non- generic collection property like hash table, a rail list and so on. So again, we don't have time to cover how to find entry points but this is also covered in the white paper. So this is the list of the JSON libraries that we analyzed. The ones in red are vulnerable by default. So fast JSON, sweet JSON, JSON IO and flex JSON should never be used with entrusted data. Basically, they include the type information by default and they perform no type control at all. Then they invoke setters 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 do not include the type information by default in the JSON data but there is this configuration setting that can be enabled to do exactly that. And then they perform this inspection of the object graph so you need to find an entry point. You may think that finding an application that satisfies both requirements is difficult but it's kind of the opposite because if the developer has a property of, for example, a system object, they will be forced to enable this configuration setting to include the type information and then make this class or this type serializable. So, well, JSON is the only one in green. We found that it's very difficult to make it vulnerable. You can also implement a type adapter and make it vulnerable but I mean, you need to do it like in purpose. And in addition, it does not invoke any setters. It just uses reflection so you need to use or to find gadgets starting, for example, with a finalized method which is more difficult than the setter one. So, let's see some of these examples. For example, FastJSON is one of the ones in red. It should never be used with untrusted data. And basically, yeah, it includes the type information by default. It does not offer any type protection or type control and then it will invoke the setter so we will be able to use, for example, our object data provider gadget to get arbitrary code execution like we did in this Calico CMS that is a .NET content management system. Then we have a JavaScript serializer that is one of the .NET native libraries in the .NET framework. By default, it does not include the type information but developers can do that by passing this simple type resolver or any other type resolver to the constructor of the JavaScript serializer and then desalizing untrusted data. So, by the way, all these examples are from GitHub so this is real code. Basically, this JavaScript serializer does not offer any type control. It performs a post-desalization cast operation so it's vulnerable by default if developers are configuring it with a type resolver. Then we have the data contract JSON serializer that is probably one of the most secure ones. But, well, it performs this assignability check that we talked before but also this creation of a wide list at construction time that is then applied at runtime time. So, with that, the only way an attacker can get arbitrary code execution on this library is if they can control the expected type. Again, this is from GitHub. It's an example of how the type can be controlled by the attacker. In this case, it's coming from a cookie. We will see an example in DNN that is one of the most popular CMS for .NET where they're doing exactly this. Then we have JSON.NET that is probably the most popular library. It's even recommended by Microsoft over their own native libraries. Again, by default, it does not include type information but if developers enable this tape name handling setting, then they will include this information. This is another example from GitHub, as you can see, because it contains this class called message because it contains a body property which is a system object type. Then developers are forced, as I said before, to enable these configuration settings to include the type information. And then the library will invoke setters, serializable constructor, callbacks, and even some onerror custom callbacks. So, basically, the attacker has like a very large gadget space to get arbitrary code execution. So, let's see an example, a demo. This is a web application framework which basically, well, it's not really a web application framework. It's more a data management framework. So, it offers a REST API for both JavaScript and .NET clients to connect to the API and perform like entity management operations like adding a new record, deleting a record, updating a record, and so on. So, we found that this framework was using JSON.NET, which is, as I said, the most popular JSON library for .NET, and it's configured to include the type information when serializing the system object properties. So, at some point, this code here will deserialize untrusted data coming from the request. And then, as you can see here, basically, these safe options type here is the expected type. So, as I said that we have to do this expected type, object graph inspection, which is quite simple in this case because the safe option type only contains two properties. The second one is a name tag and it's 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 Carbon that is one of the sample applications that come with the framework for developers to learn the framework. And basically, in this example, we can just add new car models or rename the models and so on. So, if we change the name of this model and we intercept the request with verb, we will see that, well, we have all the expected data, like, for example, the new model name is appearing in the JSON data that has been submitted to the REST API, and then we have this empty 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 using JSON.NET and that is including type information. So, that's, those are the ingredients for our arbitrary code execution. We will be using our object data provider gadget basically to invoke the process.start and pop up a calculator when the framework process these 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, this will get deserialized and we will get arbitrary code execution. So, thank you. So, this is a popular, rather popular framework in .NET and a big set out to the developers because they fixed the issue in just one day. Also, a big set out to Moritz-Betzler, there is a Java security researcher on May 22. He published this Java Marshaler security paper, which basically is similar to our research, serves the same premises and conclusions. Well, he overlaps with our research in the Jackson and JSON I.O. libraries, although for the JSON one, he found like a completely different vector and he also overlaps with us in our JDBC, Roset, Impole class or gadget. But this was like a kind of like obvious choice because it was previously used in the Java desalization world. 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 work. So, now we will change gears and focus in .NET realizers. Let's back to the .NET world. Potential security problems with binary format and .NET data contract serializer were known for the year. For example, the great work of James Forshu about weaknesses and main attacks in this main .NET format was presented at Black Hat 2012. So, five years ago, unfortunately, we could not find good available remote code execution gadget chain. There was one published by Florian Goldier, but it uses memory corruption, so it's not very easy to build universal exploit for different version of Windows. But we were sure that there should be a lot of ways to get code execution during .NET desalization. So, we spent some of our time and have found one that can be used in binary format and some other .NET format. But after our work was ready and acceptable Black Hat, the same James Forshu published a couple remote code execution gadget as part of his own research. By the way, not connected with our topic. Anyway, you can find details about this gadget on his post on Google Project ZeroBlock. Here we will focus on our own. We will use PS object type. It is part of PowerShell libraries, so should be available in almost all Windows machine. Before we go further, there are a couple remarks about this gadget. In PowerShell version one, this type is not serializable, so is not suitable for attack. But all modern version of Windows, starting from Windows 8 and Windows Server 2012 are shipped with newer and vulnerable version. The next remark, we reported this issue to Microsoft and two weeks ago, they released a fix. So if you are not ignoring their updates, you should be safe. So PS object. For the serialization, it uses custom serializer. And in case of TIM instance, it will call TIRegidrate, TIM instance property method. Here we can see that attacker is able to specify own type as element type of array. And serializer, we try to reconstruct object of this type. To find proper way to do this, it will use figure conversion method. It's quite interesting method for an attacker, as there are a lot of options for the attack. We highlighted only the most obvious one. So we can call non-default constructor with one argument and we can control its value. Also we can invoke setters on public properties, so we can use our gadgets, earlier gadgets. And also we can use static parse method of arbitrary type. Let's try to use this one. Sorry. As we said earlier, some reader parse can be used for arbitrary method invocation. Here we can see examples of payload that will call process and start with our argument. Here we can notice namespace, assembly, type, method name and finally calc as an argument. Along with mentioned binary and net data contracts, serializer formators.net offers a lot of others. Unfortunately, we don't have enough time for detailed review of each of them, so we will briefly cover them in our today talk. And if you're interested in deeper analysis, we can offer outweighed paper as good source. So we can group them into big group. Formatter, there are vulnerable interval configuration like binary formator, sub formator, net data contracts serializer. Also we can add here formator that internally use them. Like object state formator, loss formator, binary message formator. They should not be used with untrusted data. Or you have to proper configure them to limit available types. For example, use restricted type resolver with wide list of the types. Other group formators that are safe in default configuration like XML serializer, data contract serializer, data contract JSON serializer. But if you are using quick data contract resolver, by the way, we have met such examples even on official Microsoft documentation. Or attacker is able to control expected type. You will have very serious security problem. We will show a bit later that in this case code execution is real even for the most limited formators. For example, XML serializer. Now we will switch back to Alvaro. He will show our next demo. So because demo is probably worth a thousand slides, we will show you how to get arbitrary code execution on some .NET framework. In this case, NENSI, that is a web application framework that is very similar to the Ruby's Sinatra framework, but for .NET. And well, basically they care about security, which is good. And they implemented CISARF protection. The only thing is that by protecting against CISARF, they opened the doors for remote code execution. But yeah. So instead of putting this unique token into the cookie like most of the frameworks do, they created a type called CISARF instance where they put this token and then they serialized this instance of CISARF token and then they basically foreign code the payload into the cookie into the cookie. Anyway, if you find this A, A, E, A, A, D magic number in any of your pen tests, then you will be able to get arbitrary code execution. So let's see that in action in one application. So this is an application we build using NC. And we were able to get arbitrary code execution, pre-authentication, by basically replacing the cookie. So this is the cookie that the framework injects, the N-CISARF cookie. As you can see, it contains this magic number and then this base 64 encoded block. If we check the page, they also include the same value as a hidden field in the form. So they are doing like a double submission, which is good. But since they are using binary format serialization, then it's not that good. Anyway, we serialize our PS object gadget in order to pop up a calculator with the calculator payload. And then we are just basically replacing the cookie with our payload. You can use our payload or any of James Forso 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 will get an exception, but we will get our payload executed. Thank you. So, um, we just wanted to highlight that this is not really a problem in JSON or XML parsers or, I don't know, Java digitalization or the binary formatted for .NET. This is a problem in serializers themselves because all of them need to reconstruct the objects during the digitalization process. And that means instantiating types that normally can be controlled by attackers and then invoking methods. So, as we said before, these 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 gadget space for the attacker to find, um, arbitrary code execution gadget chain will normally apply to any serializer or any language. As we said before, most of the times, the setters will be invoked. So, the gadget that we presented here today, the object data provider gadget and the JDBC Rossell Imple gadget will normally be good gadgets to attack any other libraries. So, um, we found like many other libraries being vulnerable or being, uh, as 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 Pickler or self-serializer are .NET serializers that work not just in the .NET framework, but also in .NET Core, uh, Silver Light or Windows mobile phone, for example. So, developers may choose them instead of the native one, because they are suitable for their needs. And, well, all of them include type information by default. They invoke setters and they perform either no type control at all or just the object graph injection. So, attacker may need to find these entry points. Also, we have wire that is now known as Hyperion. That is the serializer for .NET. If you are familiar with the Scala or Java version of the libraries, um, framework for concurrency based on actors. So, you have, like, different actors exchanging messages. And these messages were serialized with JSON.NET using this type name handling setting equals to also it was vulnerable. But then they replaced this JSON.NET serializer with Hyperion. That is their custom serializer. And, well, this Hyperion includes type discriminators, invoke setters, and then perform no type control. So, again, it's another vulnerable library. Also, be aware of rolling 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 .NET Core and they want the framework to be compatible with .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 setters. So, we were also able to get arbitrary code execution on the pre-release 2.x branch of this framework. We also found a very interesting CMS. That is one of the most popular CMS for .NET, if not the most. That is called .NET Nuke. And they use XMR serializer to serialize arbitrary types. Since XMR serializer need to know the type ahead of time, then they created this wrapper around XMR serializer where they would, in a cookie, in a web cookie, they were setting the type that was going to be used for the .NET XMR serializer and then the payload for the XMR serializer. So, this was like a challenge for us because XMR serializer, as Alex said, is the most limited serializer in .NET. It basically doesn't allow you to do many things like serializing a system type property or serializing a type, for example, with interface members. So, if we were able to get arbitrary code execution on XMR serializer, we were like confident that we were going to be able to do that for any other libraries. So, we tried with our object data provider, Gadget. And so far so good. It was like XMR serializer friendly. No problem so far. Now, if we tried to use that Gadget to invoke process.start, then we had a problem because the process type contains interface members. So, XMR serializer doesn't like it. That problem was easily solved because you can choose Gadgets from anywhere else, like, for example, the summit reader load method. The object state formatted the serialized method. Or you can even look for Gadgets in your target class path or type. So, for example, since we are attacking .NET Nuke, we search for Gadgets in .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 STTP response. So, very convenient for us. So, now the next problem was that XMR serializer builds a whitelist of allowed types at construction time, and then it applies the whitelist at runtime time. So, that was a problem because we need to send an instance, for example, of our summit reader or the file system utils types as the payload, and these types are not going to be included in the whitelist. So, we needed to find some way to full XMR serializer to include our arbitrary types into the whitelist. And we did that, basically, by using a parameterized type as the expected type, as you can see down there. And then we used the first parameterized type to place our payload type, like file system utils, and then the second type to put our object data provider type. So, with that, we were able to get arbitrary code execution pre-authentication on .NET Nuke. At first, these guys from .NET Nuke assigned it like a low severity, which was like weird because it's pre-authentication RCE. And they said that this severity was assigned because attacker needs to be able to understand how the cookie works. And we were like, okay, do you know your framework is open source, right? So, anyway, they changed that to critical at the end. So, this is the source code for the relevant part. At some point, it reads, for example, when you visit the 404 error page, it executes this code. And as you can see here, it's reading the cookie with that is named DNM personalization and then passing this XML cookie into this serialized hash table XML method. If we check this method, it's basically extracting the type from the XML cookie, like here, and then using this type name to construct the XML serializer. So, the attacker can control the expected type as we said before. Now, it's deserializing the rest of the cookie. So, this is what DNM personalization cookie looks like in a real DNM 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 our runtime payload types. And then the inner blue box is our payload for the object data provider. So, in this case, instead of popping up a calculator, we are using the file system beauty class in .NET NUC 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 DNM. If you run it, 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 verb, well, the request does not contain the DNM personalization cookie, but by reading the code, we know that it's processing this cookie. So, we will just include it manually, like DNM personalization, and then we will basically paste the XML payload that I showed you before, which as I said is using the pull file method in the file system beauty class that is provided by DNM 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 this cell ASPX web cell that we are downloading. So now, as soon as we execute the request, the cell ASPX will appear, as you can see there. And, well, we'll be able to basically interact with the system basically by visiting the web page and install whatever we want to do. Thank you. So, with that, just to wrap up, just remember that this is not a problem in JSON or XML or, I don't know, any of the serializers. So, try to avoid digitalizing entrusted data. We saw this is also a problem in Ruby, Python, PHP, so do not digitalize entrusted data, and if you have to, get your library evaluated by some security guys, try to avoid libraries that perform no type control, so they are just doing the post-dialization cast. Try to avoid libraries that include type discriminators. It's not a sufficient 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 the type like we saw in DNN. And last but not least, try to not roll your own format because you can just fuck it up. So, with that, thank you very much. And if you have any questions, please send them over to our emails.