00:00:00.000,00:00:06.667 >> Hi DEF CON, um, I'm Alvaro, a Pentester, uh, this is Oleksandr with sale. Uh, we both work for 00:00:06.667,00:00:13.583 the HPE Fortify team. Um, but we have a lot of things to cover today, so enough about us, um, 00:00:13.583,00:00:18.167 so last year was the year of Java deserialization apocalypse as we like to call it. Like 00:00:18.167,00:00:23.417 literally, uh dozens or even hundreds of new CVEs were reported around Java 00:00:23.417,00:00:28.667 deserialization. And around those CVEs like thousands of vulnerable applications and 00:00:28.667,00:00:33.667 appliances. Uh, it was like a bad problem. So this was a very well known, since at least 2011. 00:00:35.792,00:00:41.583 Um, probably it was not, um, so the community was not paying, uh, really a-attention, because 00:00:41.583,00:00:47.625 there were no, uh, really good gadget a really good remote execution gadget until 2015 when 00:00:47.625,00:00:52.667 the Apache Commons Collection gadget was published. So this was the same problem with um dot 00:00:52.667,00:00:59.208 NET. The third a-attack was published in 2012 for both binary formatted and the net 00:00:59.208,00:01:05.625 data deserializer. But there was no, uh, remote execution gadget published until now. So at that 00:01:05.625,00:01:10.667 time the solution was like, ok, stop using deserialization altogether and developers were 00:01:10.667,00:01:15.667 like, well yeah, I would like to do so, but I need to serialize my object, uh and store them 00:01:15.667,00:01:20.708 into a database or maybe I don't know. Uh, send them across a wire or send them in a socket or 00:01:20.708,00:01:26.083 whatever. So I need to serialize my object. And deve- um, the security guys were like, ok, 00:01:26.083,00:01:32.667 then use a secure JSON or XML parser and library instead. So our goal with this, um, talk, is 00:01:32.667,00:01:36.750 to fault. First of all, we want to verify if those JSON libraries are any better than 00:01:36.750,00:01:41.625 Java deserialization or dot NET uh deserialization and then raise some awareness around dot 00:01:41.625,00:01:46.417 NET deserialization and stuff. Uh, we said with Java it took like four or four or five years 00:01:46.417,00:01:51.208 for the community to start looking into, um, you know vulnerable end points and so on. 00:01:51.208,00:01:56.333 Uh, we don't want to the history to repeat itself so we will be presenting new remote execution 00:01:56.333,00:02:01.333 guide to attack this for um, serializers. So. The first section will focus on JSON. We 00:02:03.333,00:02:07.708 will present some of the um libraries that we found to be vulnerable. Gadgets to attack 00:02:07.708,00:02:12.250 them and then uh, demo on a web application framework leading to arbitrary code execution and 00:02:12.250,00:02:14.250 then we will focus on the dot NET serializers. The completely uh different subject. And then 00:02:14.250,00:02:19.250 we will try to generalize the talk and we will provide some demos as well. So let's jump 00:02:23.167,00:02:28.167 into the JSON part. So just uh to set expectations here. We're not talking about JSON, uh, when 00:02:30.833,00:02:37.042 uh sending simple data or simple JavaScript objects between, uh Java um JavaScript front and and 00:02:37.042,00:02:41.250 I control it like, I don't know for example I spring control it. We are talking about replacing 00:02:41.250,00:02:46.208 Java or dot NET serialization with uh JSON which means that you need to serialize Java or 00:02:46.208,00:02:50.875 dot NET objects. Which means that you need to support some of the objects in the programming 00:02:50.875,00:02:55.500 features like how I'm going to deal with the Java line object, how I'm going to deal with the 00:02:55.500,00:03:00.667 system object in dot NET, how I'm going to deal with generic parameter types, polymorphism, 00:03:00.667,00:03:05.667 interfaces and so on. So we will be abusing the um, the features that these libraries include to 00:03:08.458,00:03:14.875 support these OOP stuff. Uh, very quick recap on how Java deserialization or how the 00:03:14.875,00:03:19.500 attackers were able to get a arbitrary code execution on Java deserialization. Um, basically 00:03:19.500,00:03:23.125 they were able to provide untrusted data to the serializer. In this case the 00:03:23.125,00:03:28.708 object input stream in in Java. And this untrusted data contains, um, types, some class 00:03:28.708,00:03:34.958 names that were instantiated by the deserializer. And then some um deserialization call box. 00:03:34.958,00:03:41.292 Like read object or re- read result were invoked and then the attackers were able to uh start 00:03:41.292,00:03:46.458 a gadget chain that is nothing else that connect in different classes um together. Something 00:03:46.458,00:03:51.458 like a gadget chain leading to an arbitrary execution, but starting from this read object 00:03:51.458,00:03:55.833 or read result of deserialization callbacks. However, JSON does not invoke 00:03:55.833,00:03:59.750 any of these deserialization callbacks normally or at least some of the, most of the 00:03:59.750,00:04:05.917 libraries. So we need to find some, um, some other ways to start our gadget chain leading 00:04:05.917,00:04:10.917 to these code execution. So um most of the, um, JSON libraries will work and will uh, will try 00:04:13.458,00:04:18.000 to reconstruct the object in any of these ways. So basically they will invoke the default 00:04:18.000,00:04:23.542 constructor in order to uh instantiate the object and allocate the memory and then use 00:04:23.542,00:04:30.000 either reflection or setters in order to populate the fields properties of of the uh of the 00:04:30.000,00:04:35.542 instance. Some of them will invoke some special constructors or deserialization callbacks or 00:04:35.542,00:04:40.208 or type converters. We don't have time in this talk to cover all of them. Um but these are 00:04:40.208,00:04:44.167 also vectors that lead to arbitrary code execution. We have um, we have uh covered in 00:04:44.167,00:04:49.292 our white paper that will be published in the DEF CON Community server. And then most 00:04:49.292,00:04:54.625 of these libraries also invoke some um common methods, like for example, hashcode or equals 00:04:54.625,00:05:00.083 normally get invoked. Uh when deserializing hash tables to a string normally get invoked when 00:05:00.083,00:05:05.333 um raising exceptions. Finalize is always invoked by the garbage collector when when claiming the 00:05:05.333,00:05:11.167 memory for the objects. But uh, by far the most common one is uh the setters. Setters are 00:05:11.167,00:05:17.500 normally invoked by most if not all of the libraries. So if we are able to find arbitrary code 00:05:17.500,00:05:22.292 execution gadget chains starting with setters, we will be able to use them to attack these 00:05:22.292,00:05:27.292 libraries. >> Let's have a look at a few setter gadgets in dot NET. All of them can lead to 00:05:29.833,00:05:35.208 arbitrary code execution. Some of them has own requirements and limitations, but do believe that 00:05:35.208,00:05:40.208 it's not very difficult to pick up proper one for specific case. So our first gadget is uh setter 00:05:42.250,00:05:48.167 of path property in assembly installer class. It allows code execution during uh library 00:05:48.167,00:05:53.167 loading from path controlled by an attacker. Uh, there is no additional requirements if uh 00:05:56.333,00:06:02.292 assembly payload is on local machine. But in case of remote services dot NET framework may 00:06:02.292,00:06:07.292 have some additional security checks. The next two gadget use use uh uh XML parser. Uh we will 00:06:09.417,00:06:15.250 show a bit later how it can be used for arbitrary matters in location. So, uh setter of 00:06:15.250,00:06:21.083 property inspector font and color data in workflow design and type requires single 00:06:21.083,00:06:27.542 threaded apartment set. It's quite strong requirement, but if your target ha-has such 00:06:27.542,00:06:33.167 configuration, you will get remote code execution. The next gadget is source setter of 00:06:33.167,00:06:38.167 resource dictionary type. Uh it has a few requirements to, mmmm, JSON unmatched. It should call 00:06:41.250,00:06:46.250 setters for types uh that implement a dictionary interface and often in such cases, uh, 00:06:48.958,00:06:55.333 unmarshaller are just populating key valued pairs. Also it should be able to reconstruct system 00:06:55.333,00:07:00.333 overwrite object as this type doesn't have default constructor. But often uh, 00:07:02.458,00:07:07.458 un-unmarshallers can do this. And our final gadget is uh object data provided type. It's 00:07:09.625,00:07:14.625 quite flexible and allows um a lot of ways to for attack. [inaudible] we were able to use 00:07:17.000,00:07:22.792 it in almost all our unmarshallers and formatters. So let's have a look on uh code 00:07:22.792,00:07:28.042 diagram of this gadget. Setter will call refresh method, it will invoke begin query, it will 00:07:28.042,00:07:35.000 call query worker and finally invoke method and instance. We can see the line that will call 00:07:35.000,00:07:40.000 our arbitrary method. Uh here we can see example of JSON payload that we uh popup calculator for 00:07:42.958,00:07:49.750 a second configuration of JSON dot NET parser. Actually this set uh, gadget, allows the next 00:07:49.750,00:07:54.750 main ve-vectors. We can call non default constructor with it's own arguments or can invoke uh 00:07:57.500,00:08:04.083 public method to unmarshaller object. Or we can call any public method including static 00:08:04.083,00:08:09.083 ones with our own parameters. Uh, Java has own uh setter gadget as well. After our our 00:08:12.500,00:08:18.792 last year research and JNDI injection attack, we have found a few setters with JNDI look up 00:08:18.792,00:08:25.000 codes. By the way Oracle recently disabled uh [inaudible] vectors in default configuration 00:08:25.000,00:08:30.000 of Java. But [inaudible] still works, so our gadget sets session factory JNDI in 00:08:33.208,00:08:38.500 statistic service. We already mentioned about this in our last year talk at Black Hat 2016. 00:08:38.500,00:08:44.625 Very similar to it is two string gadget from remote client user transaction class. And finally 00:08:44.625,00:08:49.625 set of the commuter gadget from already known uh class G B zero set input. Let's have a look on 00:08:52.000,00:08:57.000 it. It, this uh class is from GRE library so doesn't doesn't require any external 00:08:59.167,00:09:06.000 dependencies. Setter code connect function and here we can see uh the typical code in the 00:09:06.000,00:09:11.833 initial context lookup method with our value from uh data source main properties. So we 00:09:11.833,00:09:16.833 will get remote code execution. A part from our gadget that allows code execution by 00:09:19.000,00:09:24.667 themself, we have a couple other interesting gadgets. Some of them can be used as building 00:09:24.667,00:09:31.292 blocks for a gadget chain like um, BindingSource set data number in dot NET or string 00:09:31.292,00:09:37.792 template to string in Java can be used for arbitrary ga- uh gadget calls. Other configured 00:09:37.792,00:09:42.792 non as see attacks for example inner XML in XML data document or um setter of data view setter 00:09:46.667,00:09:52.708 collections in data view manager can be used for uh XML external enteties attack in some version 00:09:52.708,00:09:58.167 of dot NET framework. Now we will back to Alvaro, he will show where we can use this uh 00:09:58.167,00:10:03.167 gadgets. >> So we analyzed like multiple Java and dot NET additional libraries and uh we 00:10:05.167,00:10:09.000 found that most of them were vulnerable arbitrary code executions, some of them in the 00:10:09.000,00:10:13.583 full configuration and some of them um developers need to enable or configure them and a 00:10:13.583,00:10:18.333 special way. So we came up with this uh simple high level requirements for uh library to 00:10:18.333,00:10:23.333 be vulnerable to this attack. Basically the attacker needs to be able to control the type or 00:10:23.333,00:10:27.875 the class that is going to be instantiated in the server. Um that normally means that the 00:10:27.875,00:10:33.458 JSON that dr- um intercepted for example, there will be an attribute called something like 00:10:33.458,00:10:39.583 underscore type or direct type class object, class name that uh contains a value that looks like 00:10:39.583,00:10:45.167 a dot NET or a Java class name. Then the library will instantiate that uh type and 00:10:45.167,00:10:50.333 then the second requirement is that the attacker or in this case the library needs to invoke 00:10:50.333,00:10:54.708 some methods on these reconstructed object. And finally the third requirement is 00:10:54.708,00:11:00.792 that the attacker needs to be able to assemble the remote execution gadget chain. Um and 00:11:00.792,00:11:05.875 starting from those methods that I invoke by the boy the library. As I said said before, setters 00:11:05.875,00:11:10.458 are normally invoke in most of the libraries, so the the caveat is that Oleks just presented are 00:11:10.458,00:11:16.750 normally can be normally used for any library. So we can analyze these libraries um 00:11:16.750,00:11:22.125 according to the likelihood of them being vulnerable and for that we uh choose two different 00:11:22.125,00:11:27.167 factors. The first one is whether the library includes the type discriminator that is 00:11:27.167,00:11:31.542 nothing else that the class name in the analyzed data like we are seeing uh here for example in 00:11:31.542,00:11:37.833 JSON dot NET. And uh so that can be done like by default by the co- by the library or developers 00:11:37.833,00:11:42.667 may need to enable um a configuration setting. And then the second factor is how this 00:11:42.667,00:11:47.667 library prevent uh malicious types from being instantiated um, and loaded. So we found that 00:11:50.542,00:11:55.667 some of this libraries perform a post deserialization from cast. Which uh offers no security at 00:11:55.667,00:12:00.500 all because basically by the time that you get the uh cast exception the payload has 00:12:00.500,00:12:05.625 already been executed and you're already been compromised. And the second type control is what 00:12:05.625,00:12:10.583 we call the inspection of the expected type object craft. Which sounds like a little bit 00:12:10.583,00:12:15.708 complex, but its nothing else that the library will take the expected types so for example a 00:12:15.708,00:12:20.833 use of the library may be expecting a user or account or whatever and then analyzing the 00:12:20.833,00:12:26.500 object craft and checking what that the user is sending and the um in the JSON data is 00:12:26.500,00:12:32.708 acceptable to the types defined in the object craft. So some libraries go farther and also 00:12:32.708,00:12:37.417 build a white list of construction time and apply this list at one time using the 00:12:37.417,00:12:41.792 deserialization. We found that these um these libraries the libraries performing this type 00:12:41.792,00:12:45.333 control and also vulnerable if the attacker can control the expected type. That is more 00:12:45.333,00:12:50.167 common than you may think and we will see an example an example later. And also if the attacker 00:12:50.167,00:12:54.792 can find an injection point an entry point in the object craft. So for example as you can see 00:12:54.792,00:13:01.375 here in this um example object craft here all the properties in red may be a good examples of 00:13:01.375,00:13:05.583 entries points. Like for example a system object property and non-genetic collection property 00:13:05.583,00:13:09.958 like hash table, are really substantial one. So again we don't have time to cover um how 00:13:09.958,00:13:15.000 to cover entry points but this is also covered in the.. in the white paper. So this is the list 00:13:15.000,00:13:19.875 of the additional libraries that we analyzed. The ones in red are vulnerable by default, so fast 00:13:19.875,00:13:24.750 JSON, sweet JSON, JSON i01 presentation should never be used with untrusted data. 00:13:24.750,00:13:30.333 Basically they include the type information by default and they perform no um type control at 00:13:30.333,00:13:35.375 all. Then they invoke setter so we can use our setters to get arbitrary code execution. The 00:13:35.375,00:13:40.000 ones in yellow and orange depends on the developers and how they are using the library. 00:13:40.000,00:13:45.000 So most of them uh that do not include the type information by default in the JSON data. But 00:13:47.083,00:13:52.083 there is this uh configuration setting that can be enabled a to do exactly that. And then they 00:13:52.083,00:13:56.292 perform this inspection of the object craft so you need to find an entry point. You may think 00:13:56.292,00:14:00.500 that uh finding an application that satisfies both requirements is difficult, but its kind of 00:14:00.500,00:14:04.167 the opposite because if developers has a property of for example of system object, they 00:14:04.167,00:14:08.958 will be forced to uh enable this configuration setting to include the type information and then 00:14:08.958,00:14:14.917 make this class uh or these types serializable. So uh we uh JSON um is the only one in 00:14:14.917,00:14:20.750 green. We found that is very difficult to make it vulnerable. You can also uh implement a type 00:14:20.750,00:14:26.292 a make it a vulnerable, but, I mean, you need to ha- to do it on purpose. And in addition it 00:14:26.292,00:14:30.875 does not invoke any setter, it does use reflection, so you need to use or to find gadgets and 00:14:30.875,00:14:35.125 starting for example with finalize method, which is um more difficult than, than the 00:14:35.125,00:14:41.292 setter one. So let's see some of these examples, for example fast JSON is one of the ones in red. 00:14:41.292,00:14:44.958 Should never use this with untrusted data and basically yeah, it includes the type 00:14:44.958,00:14:50.833 information by default it does not offer any type content uh type protection or type control 00:14:50.833,00:14:54.500 and then it will invoke the setter, so we will be able to use for example our object data 00:14:54.500,00:15:00.333 provided gadget to get arbitrary code execution like we did in this KalikoCMS that is um dot 00:15:00.333,00:15:04.333 NET content match system. Then we have uh, Java script serializer that is one of the 00:15:04.333,00:15:09.333 dot NET native libraries in the dot NET framework. By default it doesn't really include the type 00:15:09.333,00:15:15.667 information, but uh developers can do that by uh passing this simple type resolver or any 00:15:15.667,00:15:19.750 other type resolver to the constructor of the Java script serializer and the deserialize 00:15:19.750,00:15:25.000 untrusted data. So by the way all these examples are from GitHub so this is real code. Um 00:15:25.000,00:15:28.667 basically this Java Script serializer does not offer any type controller, it performs a 00:15:28.667,00:15:33.292 post deserialization cast operation so it uh its vulnerable by default if 00:15:33.292,00:15:39.042 developers are uh configuring it with type controller. Then we have the data contract JSON 00:15:39.042,00:15:44.333 serializer that is probably one of the most secure ones um but um well it performs accessing 00:15:44.333,00:15:49.375 ability check that we talked before, but also this creation of a white list at a 00:15:49.375,00:15:56.000 construction type that is then applied at run time time. So with that, the only way a devel- 00:15:56.000,00:16:00.875 uh an attacker can get arbitrary code execution on this library is if they can control the 00:16:00.875,00:16:06.625 expected type. Um again this is from GitHub it is an example of how the type can be controlled 00:16:06.625,00:16:10.792 by the attacker in this case coming from a cookie. We will see an example in DNN that is 00:16:10.792,00:16:17.458 one of the most popular CMS for dot NET where they're doing exactly this. And then we have 00:16:17.458,00:16:22.542 JSON dot NET that is um probably the most popular library, it's even recommended by Microsoft 00:16:22.542,00:16:27.375 over their own native libraries. Uh again by the default it doesn't include type information 00:16:27.375,00:16:32.458 but if developers enable this state name handling setting then they will include this 00:16:32.458,00:16:37.625 information. Um this is another example for GitHub as you can see because it contains this 00:16:37.625,00:16:43.667 class called message because it contains uh body property which is a system object type, then 00:16:43.667,00:16:47.500 developers are forced as I said before to enable these uh configuration settings to 00:16:47.500,00:16:51.708 include the type of information. And then the library will invoke setters, deserialization 00:16:51.708,00:16:58.292 constructors, code box and even some a narrow custom code box. So um basically the attacker has 00:16:58.292,00:17:03.667 like a very large um gadget and space to get arbitrary code execution. So lets see an 00:17:03.667,00:17:09.083 example uh, demo. Uh this is Breeze, it's a web application framework. Uh, which basically 00:17:09.083,00:17:13.875 was not really a web application framework. It's more a data management framework. So it 00:17:13.875,00:17:20.125 offers a rest API for both a Java Script and dot NET clients to connect to the API and 00:17:20.125,00:17:25.000 perform like entity management operation like adding a new record, uh deleting a record, 00:17:25.000,00:17:30.000 updating record and so on. So we found that this framework was using JSON dot NET which is like 00:17:33.000,00:17:37.417 as I said the the most popular JSON library for dot NET and its configured include the type 00:17:37.417,00:17:42.417 information when serializing the um system object properties. So at some point, uh this code here 00:17:46.167,00:17:51.667 will deserialize untrusted data coming from the request and then as you can see here basically 00:17:51.667,00:17:57.875 this um safe option used um type here is the expected type. So I said that we have to do the 00:17:57.875,00:18:02.292 expected type object craft inspection which is quite simple in this case because the safe 00:18:02.292,00:18:08.125 option type only contains two properties. The second one is um main attack and a system object 00:18:08.125,00:18:14.167 property so we can, this is our injection point, our entry point to place the payload. So with 00:18:14.167,00:18:18.375 that let's see an example, this is Car Bones, it is one of the sample application, that come 00:18:18.375,00:18:23.292 from, with the with the framework. Um for Developers to learn..learn the framework. And 00:18:23.292,00:18:28.292 basically um in this example we can just um new um car models or rename the models and so on so 00:18:31.083,00:18:36.083 if we change the name of this model and we um intercept the request with burp, we will see 00:18:39.292,00:18:45.000 that um well we have all the expected data, like for example the new model name is appearing 00:18:45.000,00:18:50.167 in the JSON data that is submitted to the rest API. And then we have this anti-safe 00:18:50.167,00:18:56.167 options dictionary. If we send this request to the server, we will see that there is in the 00:18:56.167,00:19:00.167 response, there is this dollar type attribute which is our indicator that this is just in 00:19:00.167,00:19:05.000 JSON dot NET and that is including type information. So that's those are the ingredients 00:19:05.000,00:19:10.583 um for our arbitrary code execution. We will be using our object data provider gadget 00:19:10.583,00:19:16.083 basically to invoke the process data start and pop up uh calculator when the framework 00:19:16.083,00:19:21.083 process these uh requests. So we will just replace this empty dictionary with the payload and 00:19:23.917,00:19:29.583 then let's check that in the victim server there is no calculators running and now as 00:19:29.583,00:19:34.583 soon as we submit the request, they will get deserialized and we will get arbitrary code 00:19:38.000,00:19:43.000 execution. [Clapping] So thank you uh so this is a popular, a very popular a framework in dot 00:19:45.375,00:19:50.875 NET and has been sent out to the developers because they fixed the issue in just one day. Um 00:19:50.875,00:19:57.208 also a big shout out to Moritz Bechler that is uh Java executed researcher um um May twenty-two, 00:19:57.208,00:20:02.792 he published this Java master security paper which basically similar to our research um 00:20:02.792,00:20:07.500 serves the same premises and conclusions uh well uh he overlaps with our research in 00:20:07.500,00:20:12.250 the Jackson and JSON-IO library so for the JSON one he found like a completely different 00:20:12.250,00:20:17.250 vector and he also overlaps with us in our JDVC rule set import class or gadget. But this was 00:20:19.375,00:20:24.333 like a kind of um like obvious choice because it was previously used in the java deserialization 00:20:24.333,00:20:29.417 work. Uh also he found other interesting gadgets for Java. In third party libraries like 00:20:29.417,00:20:34.625 Spring so if you are interested in a more Java focused version of this talk go and check his 00:20:34.625,00:20:39.625 his work. So now we will change um gears and focus in dot NET serializers. >> Let's back to 00:20:43.333,00:20:50.000 the dot NET world. Potential security problems with binary format and net data controlled 00:20:50.000,00:20:56.625 contract serializer were known for lean. For example the great work of James Forshaw about 00:20:56.625,00:21:01.625 weaknesses and main attacks in uh in this um main dot NET formatters was presented at 00:21:07.333,00:21:12.333 Black Hat 2012. So 5 years ago unfortunately we could not find um good um available remote code 00:21:18.250,00:21:23.250 execution gadget chain. There was one published by Florian Coldea but it uses memory 00:21:25.667,00:21:32.208 corruption so it's not very easy to build universe exploit for different version of Windows. 00:21:32.208,00:21:37.833 But we were sure that should be a lot of ways um to get code execution during dot NET 00:21:37.833,00:21:44.333 deserialization so we spent some of our time and have found one that can be used in binary 00:21:44.333,00:21:49.333 formatter and some other dot NET formatters. But after our work was ready and accepted by Black 00:21:51.417,00:21:57.167 Hat, the same James Forshaw published a couple remote code execution gadgets as part of his 00:21:57.167,00:22:03.750 own research, but they are not connected with our topic. Anyway you can find details about this 00:22:03.750,00:22:08.750 gadget on the on his post uh on google projects data book. Here we will focus on our own. We 00:22:12.542,00:22:18.167 will use PS object type it is part of publisher libraries so should be available in almost 00:22:18.167,00:22:23.333 all Windows machine. Before we go further there are a couple remarks about this gadget. Uh in 00:22:23.333,00:22:28.333 publisher uh version one, these type is not serializable so is not suitable for attack. But all 00:22:30.750,00:22:37.500 modern version of windows attack from windows site and windows server 2012 are shipped as newer 00:22:37.500,00:22:42.500 and vulnerable version. Uh, the next remark, we reported this issue to Microsoft and two weeks 00:22:45.083,00:22:51.583 ago uh they released a fix, so if you are not if you are not ignoring their updates, you 00:22:51.583,00:22:58.167 should be safe. So PS object. Uh for deserialization it used custom deserializer and in case 00:22:58.167,00:23:03.167 of TIM instance it will call TI invariant rate, TIM instance property matter. Here we can see 00:23:06.542,00:23:12.667 that attacker is able to specify own type as element type of array and um deserializer will 00:23:12.667,00:23:17.667 try to reconstruct object of this type. To find proper way to do this it will use figure 00:23:20.958,00:23:24.875 conversation matter. It's quite interesting matter for an attacker as there are a lot of 00:23:24.875,00:23:30.875 options for an attack. We highlighted only the most obvious ones. So we can call non 00:23:30.875,00:23:36.833 default constructor with one argument and we can control it's value. Um also we can invoke 00:23:36.833,00:23:41.833 setters on public properties, so we can use our gadgets, earlier gadgets. And also we can use 00:23:45.292,00:23:50.292 static parse method uh of arbitrary type. Lets try to use this one. Sorry. As we said 00:23:55.708,00:24:01.500 earlier, some reader parse can use can be used arbitrary matters and location. Here we 00:24:01.500,00:24:06.500 can see examples of payload that will call code to start with our argument. Here we can notice uh 00:24:10.125,00:24:15.125 namespace, assembly, type, method name and finally, call custom argument. And we've 00:24:17.833,00:24:23.208 mentioned it a binary net data contract serializer, um formatters, dot NET offers a lot 00:24:23.208,00:24:28.375 of others. Unfortunately we don't have enough time for a detail view of each of them so 00:24:28.375,00:24:33.917 we will briefly cover uh them in our today uh talk and if you're interested in different 00:24:33.917,00:24:40.125 analysis, we can offer our white paper as good source. So we can group them in two big group. 00:24:40.125,00:24:44.208 Formatters that are vulnerable in the full configuration, like binary formatters, sub 00:24:44.208,00:24:49.333 formatters and data contract serializers. Also we can add here uh formatters that 00:24:49.333,00:24:54.375 interminably use them like object state formatter, loss formatter, binary message 00:24:54.375,00:25:01.000 formatter. They should not be used with untrusted data or you have to proper configure them to 00:25:01.000,00:25:06.292 limit available types. For example use uh restricted type resolver with white listed 00:25:06.292,00:25:13.000 types. Other group, uh formatters that are safe in default configuration like xml 00:25:13.000,00:25:18.667 serializer, data contract serializer, data contract JSON serializer, but if you're using 00:25:18.667,00:25:23.667 quick data contractors over by the way we have met such examples even on official uh 00:25:25.708,00:25:31.917 Microsoft documentation or attacker is able to control control expected type. You will 00:25:31.917,00:25:38.917 have very serious security problem. We will show a bit later that in this cause uh code 00:25:38.917,00:25:45.792 execution is real even for the for the most limited formatters. For example, xml serializer. Now 00:25:45.792,00:25:52.750 we'll switch back to Alvaro, he will show our next demo. >> So because our demos probably worth 00:25:52.750,00:25:57.792 a thousand slides uh we will show you how to get arbitrary code execution on some dot NET 00:25:57.792,00:26:03.000 framework in this case Nancy that is uh web application framework. That is very similar 00:26:03.000,00:26:08.667 to the Ruby's um Sinatra framework, but for dot NET and well basically they care about 00:26:08.667,00:26:14.833 security which is good. And they implemented CSRF protection. The only thing is that by protecting 00:26:14.833,00:26:19.958 against CSRF they opened the doors for remote code execution, but yeah. So ah instead of 00:26:19.958,00:26:25.375 putting this unique token into the cookie like most of the frameworks do. Um they created 00:26:25.375,00:26:31.667 like a uh, type code CSRF instance where they put this token and then they serialized 00:26:31.667,00:26:36.792 this uh instance of CSRF token and then they based the bay 64 code the payload, the payload, 00:26:36.792,00:26:41.792 the the cookie into the cookie. Anyway you do find this AAEAAD magic number in any of your bin 00:26:47.042,00:26:51.125 tests, then uh you will get uh you will be able to get that arbitrary code execution. So 00:26:51.125,00:26:55.500 let's see that in action in one application, so this is an application we build you see in 00:26:55.500,00:27:00.500 Nancy and we were able to get arbitrary code execution uh pre-authentication by basically 00:27:03.167,00:27:07.375 replacing the cookie. So uh this is the cookie that the framework injects the and this is half 00:27:07.375,00:27:13.542 cookie as you can see contains this magic number ah then this bay 64 encoded block uh if we 00:27:13.542,00:27:19.667 check the page they also include the same value as a hidden um field in in the form, so they 00:27:19.667,00:27:25.583 are doing like a double submission, which is good. But since they are using binary 00:27:25.583,00:27:31.542 format deserialization then um well its not that good. Anyway, uh we serialize our PS object 00:27:31.542,00:27:36.833 gadget, um in order to populate our calculator with a calculator payload and then we are just 00:27:36.833,00:27:42.458 basically replacing the cookie with our payload. You can use our payload or any of James 00:27:42.458,00:27:48.542 Forshaw published payload and now if we go back to the server there are no calculators running 00:27:48.542,00:27:53.667 and as soon as we submit the form we so- we- we will get an exception but we will get our 00:27:53.667,00:27:58.667 payload executed. [Applause] Thank you. So um we just wanted to highlight that this is not 00:28:07.042,00:28:12.125 really a problem in JSON or XML parcers or I don't know Java deserialization or the binary 00:28:12.125,00:28:17.042 formatter for dot NET, this is a problem for serializers themselves because all of them 00:28:17.042,00:28:22.333 need uh to reconstruct the object using the deserialization process and that means instant 00:28:22.333,00:28:27.667 hidden types that normally can be controlled by attackers and then invoking methods. So as we 00:28:27.667,00:28:31.542 said before, this simple three high level requirements like the attacker being able to control 00:28:31.542,00:28:37.458 the type, then the um some methods being called on this reconstructed type and then a 00:28:37.458,00:28:41.917 large enough guarded space for the attacker to find um arbitrary code executed gadget 00:28:41.917,00:28:46.917 chain will normally apply to any serializer in any language. Uh as we said before, most of the 00:28:49.250,00:28:53.458 times setters will be invoked so the gadgets that we presented here today the object data 00:28:53.458,00:29:00.167 provided gadget and the JDBC [inaudible] gadgets will normally be um good gadgets to 00:29:00.167,00:29:05.167 attack any other libraries. We found like many other libraries being vulnerable or being um 00:29:08.167,00:29:14.083 susceptible to arbitrary code execution um but we don't have space in the slide or time to 00:29:14.083,00:29:18.333 cover all of them. So these are good examples of them, for example FS Speak Clear or Sub 00:29:18.333,00:29:23.125 serializer are dot NET serializers. They work not just in the dot NET framework but 00:29:23.125,00:29:27.500 also in dot NET core uh Silverlight uh windows mobile phone for example. So the 00:29:27.500,00:29:32.375 developers may choose them instead of the native one because they are more suitable 00:29:32.375,00:29:37.625 for their needs. And while all of them include type information by default. They invoke setters 00:29:37.625,00:29:42.167 and they perform either no type control at all or just the object craft inspection so 00:29:42.167,00:29:47.458 attacker may need to find these entry points. Also we have wire that is now known as Hyperion 00:29:47.458,00:29:53.083 that is the serializer for Akka dot Net if you're familiar with the Eskala or Java version of 00:29:53.083,00:29:58.333 the libraries um framework for concurrency based on inactive. So you have like different 00:29:58.333,00:30:04.250 actives that sending messages and these messages were serialized with uh JSON dot NET 00:30:04.250,00:30:08.875 using this type name handling setting it was to us it was vulnerable but then they 00:30:08.875,00:30:14.333 replaced this JSON dot NET serializer with Hyperion that is that there custom serializer and 00:30:14.333,00:30:20.458 uh well this Hyperion includes type discriminators, invokes setters and then uh perform no 00:30:20.458,00:30:25.833 type controls so again this another vulnerability. Also uh be aware of running your own 00:30:25.833,00:30:30.833 format, for example this Nancy framework that we talked about before, they moved away from 00:30:30.833,00:30:36.333 binary formatter because um well it was not included in the first version of dot NET core and they 00:30:36.333,00:30:41.250 want uh their framework to be compatible with dot NET core. So they moved away from binary 00:30:41.250,00:30:47.083 formatter and then they created their own JSON library. And as you can see here it includes a 00:30:47.083,00:30:51.167 type discriminator that is called type object in this case and then it will invoke the 00:30:51.167,00:30:56.250 setter so we were also able to get arbitrary code execution on the pre-release to the text 00:30:56.250,00:31:02.875 branch of this framework. Uh we also found uh very interesting CMS is one of the most popular 00:31:02.875,00:31:07.875 CMS for for the net if not the most. But it's called dot NET Nuke and they use xml serializer 00:31:09.875,00:31:16.667 to serialize arbitrary types. Since xml serializer need to know the type ahead of time then 00:31:16.667,00:31:23.375 they created this wrap around xml serializer where um they would in a cookie, now a cookie, 00:31:23.375,00:31:28.792 they would yeah set the type that was going to be used for the dot NET xml serializer and 00:31:28.792,00:31:34.792 then the payload for the xml serializer. So um this was like a challenge for us because xml 00:31:34.792,00:31:39.917 serializer as Aleks said is the most limited serializer in dot NET. Basically doesn't allows 00:31:39.917,00:31:45.083 you to do many things like serializing um system type property or serializing uh a 00:31:45.083,00:31:49.667 type for example with interface members. So if we were able to get arbitrary code execution on 00:31:49.667,00:31:54.333 an xml serializer we were like confident that we were going to be able to do that for any other 00:31:54.333,00:32:00.792 libraries. So uh we tried with our object data provider gadget and so far so good it was like 00:32:00.792,00:32:06.208 xml serializer friendly no problem so far. Now if we try to use that gadget to invoke 00:32:06.208,00:32:11.167 process data start then we have a problem because the process type contains interface members 00:32:11.167,00:32:17.167 so um xml serializer doesn't like it. That problem was easily solved because you can choose 00:32:17.167,00:32:22.333 gadgets from anywhere else like for example the Xamlreader load method, the obvious state 00:32:22.333,00:32:29.125 formatter deserialize method, or you can even look for gadgets in your target um class class path 00:32:29.125,00:32:34.292 or type. So for example since we are talking dot NET nuke we search for gadgets in dot NET 00:32:34.292,00:32:40.500 Nuke and we found that they have this file system utils type which is very handy for hackers 00:32:40.500,00:32:45.917 because they contain methods to deploy web cells and methods to read any arbitrary files into 00:32:45.917,00:32:51.333 the expected response. So very convenient for us. So now the next uh problem was that xml 00:32:51.333,00:32:56.167 deserializers builds uh white list of allowed types at construction type and then it 00:32:56.167,00:33:01.167 applies the white list at run time run time time. So that was a problem because um we need to 00:33:03.375,00:33:09.375 send an instance for example of our Xamlreader or the file system utils type as the payload 00:33:09.375,00:33:14.750 and these types are not going to be included in the white list. So we needed to find some way to 00:33:14.750,00:33:20.583 fool xml deserializer to include our arbitrary types into the white list and within do 00:33:20.583,00:33:24.500 basically by using a parameterized type as the expected type as you can see 00:33:24.500,00:33:30.625 down there and then we used the forced parameterized type to place our payload type like five 00:33:30.625,00:33:36.500 system utils. And then the second type to put our object data provider type. So with that 00:33:36.500,00:33:39.917 uh we were able to get arbitrary code execution pre-authentication on dot NET 00:33:39.917,00:33:46.667 Nuke. Um at first these uh guys from dot NET Nuke uh assigned it like a low severity, which was 00:33:46.667,00:33:52.292 like weird because it's pre authentication RC. And they said that this uh severity was 00:33:52.292,00:33:58.083 assigned because um attacker needs to be able to understand how the cookie works. And we 00:33:58.083,00:34:03.750 were like, ok dude, do you know that framework is opens source, right? Right so. Anyway, they 00:34:03.750,00:34:10.500 change it that to critical at the end. So this is the source code the relevant part at some 00:34:10.500,00:34:16.958 point um it reads for example when you visit the 404 Error page it uh executes this code as 00:34:16.958,00:34:23.333 as you can see here, I was uh reading the cookie with uh DNN personalization and then passing 00:34:23.333,00:34:28.333 this xml cookie into this this deserialized hash table xml method. If we check this method 00:34:30.417,00:34:37.208 is basically extracting the data from the xml cookie like here and then using this type name to 00:34:37.208,00:34:42.333 construct the xml deserializers. So the attacker can control the expected type as we said before. 00:34:42.333,00:34:48.625 Now is uh is deserializing the rest of the cookie. So uh this is what uh DNN personalization 00:34:48.625,00:34:53.625 cookie looks like in a real DNN application. As you can see here it contains the type and then 00:34:55.708,00:35:01.000 the inner blue box is basically the payload for the xml serializer. And this is what our 00:35:01.000,00:35:05.792 payload looks like. So the expected type contains this parameterized type which 00:35:05.792,00:35:11.583 contains uh our run time payload types and then the inner blue box is our payload for the 00:35:11.583,00:35:17.375 object data provided. So in this case instead of popping up a calculator, we um are using the 00:35:17.375,00:35:23.333 file system utils class in dot NET nuke to basically download our web cell and deploy it into 00:35:23.333,00:35:30.042 the IIS root folder. So let's see that in action. So this is the out of the box installation 00:35:30.042,00:35:35.042 of DNN. If you run it um visit a non existent page, you will get your 404 error page. Sorry this 00:35:39.375,00:35:44.375 page you are looking for is not here. And if we send that to burp, well the request does not 00:35:47.917,00:35:53.583 contain the DNN personalization cookie but by reading the code we know that its processed in 00:35:53.583,00:36:00.500 this cookie, so we will just include it manually. Like DNN personalization and then we will 00:36:00.500,00:36:05.500 basically paste the xml payload that is showed you before which as I said issuing the pull file 00:36:07.667,00:36:12.667 method in the file system utils class that is provided by DNN to deploy the web shell. So let's 00:36:16.583,00:36:21.583 paste this into the request format this a little bit. And now in the victim server, we 00:36:24.917,00:36:29.917 will check that well we don't have these cell ASPX web cell that we are downloading so now 00:36:32.458,00:36:37.750 as soon as we execute their request the cell ASPX will appear as you can see there. 00:36:37.750,00:36:42.750 [Applause] And well we'll, be able to basically uh interact with the system um basically by 00:36:45.500,00:36:50.500 visiting the web page and install whatever we want to do. [Applause] Thank you. So with 00:36:57.167,00:37:02.167 that uh just to wrap up, just um remember that this is not a problem JSON or XML or I don't 00:37:04.333,00:37:09.500 know, any of the serializers. So try to avoid deserializing untrusted data with this is also 00:37:09.500,00:37:15.000 a problem in Ruby, Python, PHP so um do not deserialize untrusted data and if you have 00:37:15.000,00:37:20.833 to, um get your library evaluated by some security guys um try to avoid libraries that 00:37:20.833,00:37:25.583 performs no types controls so they are just doing the post deserialization cast. Try to 00:37:25.583,00:37:30.500 avoid libraries that include type discriminators. It's not like uh, its not actual physical 00:37:30.500,00:37:34.167 requirement for arbitrary code execution but it's a good indicator that you will be able 00:37:34.167,00:37:39.708 to get arbitrary code execution. And also don't allow developers to let users control expected 00:37:39.708,00:37:46.375 type like we saw in DNN and last but not least try to not roll your own format because you can 00:37:46.375,00:37:51.375 just f**k it up so with that thank you very much and if you have any questions. Here's our 00:37:55.083,00:37:58.583 e-mails. [Applause]