BSidesIowa 2019 RCEvilNet

oh thank you thank you I hope this isn't so bad that everyone falls asleep after lunch but hey I understand if you do no big deal I won't take offense too much all right so kind of kicking this off so the title of the talk RC evil dotnet we're gonna talk about some stuff in IAS and deserialization and eventually lead to an answer to the capture the flag today if anyone is still playing that and looking for that so stay tuned to the end so about me a little bit getting into the professional side started out in intrusion detection vulnerability assessments working up through penetration testing and some application security and now I'm the managing

principal at secure works adversary group so do the technical lead of our application security testing so work a lot with web applications api's mobile code review things like that help set a lot of the process and procedure shout-out to my other secure works fellow in the room here a couple more wandering around you know spend a lot of time in defense of security now I get to focus on offensive all the time which is a lot of fun so it's kind of a fun change that have gone into walking around with alphabet soup of certifications along the way on stuff that you pick up on the defensive in the offensive side as well personal side

husband and a father I'm a biker recovering triathlete so pray for me there and still still doing my best to not do those do a do a sleeve or Duathlon every once in a while I love my beer German Belgian whatever talk beer let's let's crack one so enough about me so a wordy warning here I'm I'm gonna have a lot of detail on these slides and a lot of it is meant that you can take it offline ingest it go over a few things at home I have a few other things that you can do hands on that obviously no one's gonna be doing during the talk if you do you'll be missing the stuff on

the slides but whatever download it later take a look at it and yeah it would be easy to spend a lot of time on a number of individual slides throughout this and a number of individual topics so we've got a lot to cover and that's why I once again made them a little Woori so you can take it offline and ingest this after the fact so starting off with some foundational concepts here we're going to get into what is just in general serialization and deserialization and kind of in its simplest form it's a way of basically packaging data so that someone can consume that data and unpackage it and get the data in its intended formats so

a couple really easy examples XML so I made just a simple XML object up there apologies for the small text but if you have a person object and first name John last name Doe age 35 XML is a really easy example of here a couple words and here's a number the person on the other end that ingests that data can easily parse it out and say okay these are these are words and this is a number it's really easy to keep that data intact or either you know transfer across the while wire or long-term storage and pull it out of a database later JSON same type of thing just a way of basically serializing data into a

transportable format that can either be transferred on the spot or star stored for long-term storage and usage so in the real world we we have a lot more than just simple XML or JSON for formatting data and ingesting it a lot of times you see binary formats or serializers it's the exact same concept you just use binary wrappers instead and it doesn't appear quite as plain text so this is true in dotnet and it's also true in Java Java D serialization vulnerabilities have gotten a lot of attention there's a lot of information out there on them dotnet is kind of the same way the way we see a lot of things serialized you know it's not necessarily

plain text so when one important concept is that we don't use serialization to just transfer scalar data integer strings things like that we can use that to transfer objects across across the wire if you've ever looked at a thick client application you've on the network you've probably seen a lot of binary data going back and forth and a lot of times that's serialized data that you know the the sender and the consumer know what that format is so they deserialize it on the consuming side grab out the data they need and process it so a lot of those are objects being sent across the wire and one interesting thing about when you start sending custom objects across the

wire the D serializer needs to know what type of object you are going to instantiate it into when you extract that data and that's referenced as a type a type is basically the type of object this serialized data is going to become once deserialized so we get into some really interesting stuff when we start talking about a type that is packaged up with a serialization of that date first one being can you trust the type of object that serialized data says lies within serializers in dotnet by default don't have anti tampering checks if I were to be a malicious person package up some data and tell it you know this is a process type there's

nothing in the serializer that says oh I see that's been tampered with I know this is not a processor type there are binders and whatnot that you can make that tell your serializer to only deserialize certain types but by default it's not necessarily an anti tampering check so another problem with D serialization in in dotnet there are certain standard objects that exist in microsoft.net that will perform actions upon instantiation so if I were to deserialize give an object I would instantiate it once it was deserialized and some of these objects and dotnet can then invoke commands once they're instantiate it so it kind of it kind of makes for a really interesting scenario here if I'm a malicious user and I know

what type of East serializing library is being used on the server and I can modify an object that's serialized and I send it to the server I know that I can tell it to instantiate any type of object I want to and if I use one of the known types in dotnet that will invoke commands upon D serialization I have a method of potential command execution basically in my hands because serializers don't don't have anti tampering checks built-in so there are a few of these known paths that exist in dotnet today they aren't fixed they aren't patched and these are referred to as gadgets how can I serialize an object and know that when it's unpackaged on the other side it'll

actually execute code so gadgets is a key term to keep in mind here so like I said some of these exist in net have a link at the bottom of the page but the tool that you use for generating these malicious serialized objects and dotnet is why so serial net got a reference link to it down there and like I say these these slides will be published they might already be up right now I'll have a link at the end and you can go back and take a look at some of these pardon me so one gadget that exists in dotnet today an example type confused delegate if you were to use the program why so serial it has some gadgets

built-in that will execute code for you if you can get a server-side library to deserialize it and gadgets can be implemented in various for matters when you see the word formatter in reference to dotnet it's basically basically a serializer it might be an XML serializer a JSON serializer in the case of what we're gonna talk about in a little bit an object state formatter that's the object in particular that we're gonna get into and it's it's actually really difficult to patch some of these gadget code execution paths and dotnet because the dotnet framework was made to be extremely versatile so that you know you could support anything that a developer might be able to dream up

that they want to do so it's really tough to patch some of these because if Microsoft were to come out to a patch that you know closed the hole in a certain gadget it may break a lot of functionality in existing applications that have been deployed over the last few years so mentioning again why so serial net is the program that I use to make malicious serialized objects it's kind of the de facto standard in dotnet deserialization attacks so yeah TLDR if you can modify a serialized object that you know the server is going to deserialize got a really good chance of getting code execution if there's a supported gadget and formatter in Y so

serial and and final takeaway there H Mac validation is important so H Mac is basically a hashing algorithm with a server-side secret key so we'll get into this in just a minute but if you can basically wrap some crypto validation around the serial a serialized object that you're about to deserialize you can tell if it's been tampered with and know that you should throw it away rather than deserialize an untrusted tampered object yes question

though the question was the type of object you're sending doesn't necessarily have to be the type of object that the application is expecting and that's entirely true that's that's exactly the path we're heading down here and the cool thing is yeah if if you can either bypass their anti tampering checks whatever's taking place on server side or find a way to jive with them you can serialize an object that the server may not be expecting and there are only a few ways that they can stop it from happening it's kind of a scary process and we're gonna jump right into a really interesting scenario for this so the target of my research that I wanted to

go after was the microsoft.net view state so it's it's still commonly used today if you're browsing web applications that are you know aspx pages and whatnot you may see underscore underscore all in caps of view State it's kind of a state object that's passed between the server and the client and the thing that keeps the integrity so that the server knows you haven't modified that object it attacks on an H Mac to the end of the view state object this is a cryptographic basically a cryptographic hash using a private server side key the client doesn't know the key so the client can't tamper it and make it valid H Mac and have the server accept it then if the server sees

that has been tampered with in the H Mac it doesn't match the packet it throws it away doesn't process it so this was really interesting to me because the view state itself is actually a serialized object it uses object State formatter on the backend server side and and if we looked back at a why so serial net we'd see that it supports making malicious serialized object in object state formatter format so it made it really interesting to me from from an attack standpoint so I wanted to take a look at this a little bit further so another thing about view state it's commonly a EES encrypted as well sometimes triple des encrypted and I believe it also supports DES

which I don't know who's using that maybe it's for export functionality or whatnot but you can't encrypt it as well so that's it's relatively common to see it out there in the wild an encrypted format as well so and if anyone has managed an iis server or plays around with Windows servers or anything basically that's what it looks like from the iis standpoint when you're protecting the view state with the H Mac algorithm and optionally an encryption algorithm that's just basically the screen you would see on the IAS side of things you can choose a validation method which is basically sha-1 h max sha 256 384 and 512 and you can choose an encryption method which is auto or

des ripple DES or AES and the interesting thing that I'm really gonna get into here that I focused on was if you're in a load-balanced environment on a web server let's say you have a view state packet coming in and you have five servers behind a load balancer if they all have different crypto keys that view state that was just sent is only gonna be valid on one server to pass the H Mac check so what you do in a load-balanced environment is you hard-code those encryption keys the validation key and the encryption key you hard-code those in a file called web config and you deploy web config across all the web servers sitting behind the load balancer

that way whatever server generated the outgoing view state that was sent to the client when it comes back in if it hits any of those five servers in the cluster they now all have the same encryption keys and they will all be able to prove that that was a valid h max signature so that piece in particular was also a very focused area that I used for my research here now to get just a little bit under the hood this is a little bit more that you can follow up after the fact get your hands dirty on it a little bit and take a look at the code but the dotnet page object is the object that's used

when an SPX page is loaded so it invokes the page object underneath the hood and net and page objects automatically load view state content if it's posted to the page so that's a really important concept to build upon here so once view state is loaded beus eight is a state bag object and the state bag object is serialized by Loes formatter and loss for matter is just a wrapper for object state formatter so that's a lot of information to flow down here but this is kind of the thought pattern I used when when going over this so the gist of it is if you load an aspx page it flows down the line and in in the view state ingests an

object state formatter object and if we remember back Wiseau cereal net creates payloads in object state formatter format so our attack patterns still has some valid paths here from from what's out there and supported so like I say those that was a lot of info that I jumped over there really quick but if you want to do hands-on after the fact download dn spy that's the tool that I use for or doing analysis of dotnet libraries basically just open up system web DLL that's where all these objects live that have kind of briefly discussed here so far they all live there expand the system web UI branch and you'll find you the key objects right underneath

that and it'll basically D compile the code for you right there in line in to really clean C sharp data

though diving in here a little bit further so the goal is still I want to go after I is I want to attack the viewstate object because I know that's a serialized object I want to see if I can get the server to deserialize it and execute a gadget so the goal is create an object in Y so serial net using the objects object state for matter payload why so serial done that generates them that's the underlying format of the view state object the goal is just to somehow sign it with a valid H Mac because if the server sees that it was tampered with and the H Mac doesn't match it's just gonna discard it it's not gonna

process it so we'll submit this malicious payload if we can get past that hurdle we'll submit this payload as a view state and hope that the server processes it and if it does the server will validate our H Mac say yep everything checks out and then it'll deserialize our malicious payload if the H Mac checks out and reward us with riches because it'll do whatever we want it to at that point if we can jump through these steps so these were kind of the goals of the exploitation path I had when I started down so if we're gonna just kind of a general question here if you think think about this process so far so if we're gonna assign

payload with a valid H max what's the what's the one thing we're gonna need to create a valid H Mak new the web.config and what's in the web.config that we need the machine keys excellent so once again kind of revisiting H Mak is a hashing algorithm that uses a private key so that it's not like md5 I couldn't just make an md5 signature because there's no private key to it anyone can make the same md5 so it depends on that private that private key that's in the web.config

awesome so the big prerequisite to the attack pattern that I used cuz there's always a catch the catch is you have to somehow you have to somehow know the validation key that's in the web.config that's in the machine key section of the web.config if you have that validation key you can generate a valid H Mac or any viewstate packet that you send to the server so how are we gonna get those keys out of the web config file this is kind of the tricky part of this one and it and it takes a you know an existing attack pattern or some other out-of-band methods to try and get this but you know how many times as a penetration tester

may have run across a server you hit iis you have a local file read but there's nothing you can do with it you think to yourself okay great maybe I can find an old Sam dump out there and maybe there's a password that's still valid or maybe I can read the web config and see a username and a password to a database on the back end but big deal I can't get to it I'm still out here on the internet it means nothing to me it's just an information disclosure well the cool thing is the attack I'm going to show you turns that information disclosure into remote code execution so whether you're a bug bounty guy or a penetration

tester you know this this is the type of thing that starts to truly weaponize what was once just an information disclosure another thing that we see really commonly external XML external entity injection if you're able to coerce that web config out through a flaw and an XML parser library there's another way you might be able to get your hands on those keys that are in the web config we just had that happen last just last week on an engagement using the same type of technique through open-source intelligence is it are you penetration testing a project that's public on github if so is it an IAS project that has hard-coded YZ in the github project you may be able to

tell right then and there what the validation keys are and have a valid path in to do a valid H max signature on a view state and go after a deserialization flaw you know pastebin Stack Overflow you name it there there's a chance that you may get lucky and find your target disclosed their keys somewhere other things that you may run across if you're doing a holistic network penetration test maybe you have access to the file system or a file share or a code repository internally anything like that there may be other ways that you've run across what's in that web dot config just trying to get the point across that yes we need to know the server-side key

but there are ways that you can get that that turns us into a viable attack so to get into the a little bit of the nitty-gritty here this is another one if you follow up on the slide deck I have the exact location where you can go over some of this and get your hands dirty with it on your own and take a look at the code but basically in the in the object state formatter deserialization routine I've got a highlighted piece of code there so when so when the H Mac is generated it basically invokes the machine key section library and runs the get decoded data function and the long and short of it is this is the function

that takes the entire view state H Mac included validates that the H Mac was the proper calculated H Mac for this view state data that's kind of the gist of what this function does so if we see it running here we see this is this is a view from DNS PI basically net decompiler that'll show you the code on screen so it's basically taking an array that's the entire view state it runs this dot get Mac key modifier so the modifiers something really interesting we're gonna talk about in a minute it's basically a salt that's added to the payload before being H MACT because Microsoft will always throw in a little little of their own secret sauce

and this is one of them for generating the H Mac that's a little unique to them and then some some length fields after that that are kind of moved to the point of this conversation so next thing we're gonna look at is what is that get mac key modifier what is the modifier and how is it calculated because that ended up being a really key piece to knowing how to generate a valid H Mac that would bypass server-side controls so once again if you're following along on this one after the fact we want to take a look at the code we're looking at object state formatter get Mac key modifier that's the function that we're kind of you know talking

about its functionality here so there are a couple key things that take place when dotnet generates the modifier which once again the modifiers kind of the salt that it throws on the the payload before running the H Mac so first things first the URL is very is pivotal in generating the modifier the salt for the for the H Mac calculation you basically take the entire URI convert it to uppercase and then you split it into the directory and the file name and in the file name like default dot aspx for example it converts that all to uppercase and replaces the dot with an underscore so it would basically turn it into default underscore aspx and then the directory let's say it just

say it's temp default excuse me temp slash default.aspx it would be a uppercase temp and then upper upper case default underscore aspx it takes a hash code of the directory name and hashcode of the file name itself adds the two together then reverses the byte order and that's the salt that it uses it adds that salt to the payload and then h max it with a server-side validation key so this took a little bit to walk through it's not quite as straightforward as it sounds on this slide there are a lot of hoops that you had to jump through to try and figure out what it did and where and tie it all back together last question so the

question was does this salt add any security to the viewstate the only thing that it really adds is collisions across pages so if you were to have the exact same viewstate going to the exact same page you would always remain the same but because of that salt being uri dependent if i had that exact same viewstate to a different page be a little different the security itself once we get into the details of this exploit really doesn't add much other than I hate to use the word obscurity but other than a little bit of complication to being able to reverse this out a little bit quicker it just basically was a speed bump in the road

that's all it came down to so a couple key points about this page - so when it breaks up the directory name and the file name and runs hash codes against it and adds them together those hash codes are specific to the dotnet framework that is an absolute dependency on dotnet it's get hash code function is different than Javas get hash code function or other programming libraries get hash code functions so that's a complete dependency on dotnet all the other stuff you know you can do in any language you wanted to Python Ruby whatever and then the second one if you state user key is enabled there's an additional step that's tossed into making the modifier

but for the purposes of this presentation we're just kind of letting letting that one go by the wayside for now to just stick with the main core of the functionality here so this is kind of a this was the code that I tossed together to basically do it after the fact some of this was just taken directly from dotnet so the gist of it is you you take the hash code once again walking top to bottom here you take the hash code of the page name you take a hash code of the directory you add it together turn it into an unsigned integer and then reverse the byte order and that's your salt so this was the

code that that I tossed together and in the tool release that I'll be doing in a bit so once again hands on with the inspire if you want to dig into some of the details here on your own after the fact that's the that's the function we were looking at gets a decoded data so now that we have the modifier we know the viewstate payload we're in control of that as a user we submit that to the server now we know how to generate the modifier that's the salt now we basically need the server-side validation key and we have all the information we need to create a valid H Mac for any view state payload that that

we want to send so the CliffsNotes version here of of how to do this now to extract the payload from the view state basically taking that step back the view state packet itself is the payload plus the H Mac we just strip off the H Mac because we're gonna make our own now make the view state whatever we want it to be turn it into a malicious object to generate it by Y so serial that executes the code we want it to and we have to know the target page we're gonna send it to because we need to generate the modifier for that specific page that's going to accept it append the modifier to our malicious payload run the H Mac

routine now we have our H max signature piece it all together send it to the server see what happens because if that H Mac passes it's gonna deserialize our data and execute the object that it was not expecting to see so kind of repeating myself here a little bit so starting with the steps first things first we're gonna generate a malicious object state formatter in Y so serial net because that's what for matter what serializer view state is using server-side there's a command to do that pretty straightforward basically executing calc C next when we have that malicious payload we need a valid H Mac or the server's just gonna deny processing it we now know the routine of

how to do this you basically make the modifier append it to the payload run your H Mac algorithm and there's your valid H Mac now all we need to do is have that valid signed packet and submit it to the server pretending that it's a view state and that's pretty simple submit it to the server as underscore underscore capital u state that's the standard field name so if all of this works out the server will validate our H Mac it's gonna work because we found that valid machine key in a web config so we know that we have the right key on our given target if the H Mac checks out it's gonna deserialize our payload and

that payload we generated it in Y so serial we used an existing gadget that we know exists an unpacked our in currently patched dotnet today it exists and that payload is going to execute kalki XE there for rewarding us with our riches we wanted a calculator so show me the damn code already right so I'm gonna I'm gonna give you a link to our C evil net at the end of the talk here this this tool is a custom exploitation tool using known validation keys if you extract it from the server using you know file read xxe whatever and you have that validation key this tool is going to weaponize your why so cereal packets for you process of Al

abuse date server-side code execution where you once upon a time only had local file reads so I've verified this on a fully patched 2012 r2 2016 Foley patch 2019 reported it to Microsoft it's expected behavior in the application because the security of the viewstate is dependent on private encryption keys so if those keys are disclosed it's been accepted that this will happen they actually wished me good luck at my talk today so we're we're gonna talk about it a little bit so yeah this this isn't gonna be patched anytime soon here and quick bonus I know I'm not the first one to have the footsteps walking down this path to this code execution but you

will not find any public tools or documentation in this space I've been looking for a while there's there's nothing out there publicly available that does some of this stuff so I wanted wanted to talk about it and show that it exists and show that you need to be a little bit concerned about the keys that you're using out there or if you see an attacker gets a local file read there's code execution waiting out there for them so just wanted to raise a little bit of awareness around this one so tool usage once again use this after the fact since you don't have the tool sitting in front of you but you basically give it

the URL of your target because taking a step back to generate that salt value we need to know the URL that's going to the directory and the file name that's what generates that salt so the tool needs to know that um you need to have the validation key that's one of the requirements that's what you're hoping to get out of the server through a file include xxe whatever you need to know the validation method used the IAS server can do you know once again sha-1 any of the H max sha algorithms and if you don't know you can guess you have five attempts and one of those is going to work so you can take a guess of that

if you aren't quite sure and then it takes in a base64 encoded payload that you generated from Y so serial net so generate your payload and why so serial tell it what command you want to execute and this tool will basically sign it for you make a valid H Mak that the server's gonna process so a few usage tips if you do get access to web config which we hope you do so that you can use this tool it's gonna tell you the validation routine used in web config so like this one for example of top sha-1 you'll know when you use that RC evil net tool to sign the packet you'll know to tell it you sha-1 as the

as the hashing algorithm so it kind of cuts to the chase for you and also you know if you're dealing with a encrypted view state it always it'll always go in 16 byte blocks if it's encrypted using 128-bit AES CBC so if you see for hanging bytes at the end of a clean 16 byte block you know it's using sha-1 is it's hashing algorithm because sha-1 is 20 bytes that leaves four bytes hanging off a clean 16 byte block other than that you're gonna have to guess if it's h max sha-256 384 or 512 because those all and then clean 16 byte blocks but just a little tidbit if you run across a encrypted one quick shortcut to knowing

which hashing algorithm is there so finally once you you generate your payload in yslow serial net you sign it with a valid h mac finally all you have to do is post it to that target URL as underscore underscore view state equals and you'll get this handy-dandy there for 500 error on the right side the error basically says this state information is invalid for this page and might be corrupted to your question earlier will it DC realize the payload if it's the object it did not expect it sure will it'll throw you an error after the fact but it's too late because it's already been D serialized and the code has already executed so it's too late you

say it's already done so some of the cool stuff I found when I was going through this one basically exploit regression testing every time I added a new feature a regression tested through Server 2019 2016 and 2012 basically everything on dotnet 4/5 I didn't go into dotnet 37 too much that it's a little bit different but I just tried to focus on what are the current platforms out there so found some interesting things regression testing so going back to that slide a couple slides ago looking at an aes encrypted view state you may think to yourself well the tool i released first of all I didn't put encryption in this one I left it as

plain text but the cool thing is if the server is configured to use AES encryption you can send it a plain text view state and it will still accept it and process it and deserialize it so even if the server is configured for AES you're good to go it's gonna take it and process it and Microsoft said that's expected behavior we don't know when we cross over from plain text to AES there may be some valid plaintext packets that need to be processed out there so that's expected behavior good to go so on the flip side sites configured for non-encrypted view States will accept encrypted packets kind of the same concept there supporting both of them

simultaneously so you want to get into some ids/ips evasion let's say you're going against an adversary excuse me I'm on the red team side I think blue team's adversary so you're going against the blue team that's looking for you and they have why so serial net payloads in their IDs flip on encryption you'll go right past their IDs they aren't gonna see you anymore so even if the server's not configured to accept AES it will accept AES so you'll be good to go and AES is the default encryption standard used I honestly don't remember off the top of my head if he'll accept Triple DES right off the bat but I know it will work with AES and the target page we've

talked a lot about you state today because that was the target of my initial research but regression testing showed me that I could make a completely blank file in the Webroot blank dot aspx as zero bytes content whatsoever it is still a target so stepping back to the page object and dotnet when an aspx page is loaded the page object gets loaded and the page object automatically loads a number of potentially expected fields or parameters viewstate is one of them so if I make blank aspx no content whatsoever throw a view state at it it still processes it even if there's no logic in that page whatsoever so it makes everything target so you get that

web config but the entire website does not even use view state it's still an RC target right there remote code executes a couple other things server 20 19 out of the gates shows sha-1 in the is management console but it uses H Mac sha-256 and tell you hard-coded otherwise so another bug reported along the way and I excuse me not is Microsoft's updated some crypto code paths in dotnet 4.5 so when I first started this project I thought I was going to be looking at a lot more complicated crypto code path all the way through 2019 it still uses the old code path by default so a lot of the stuff that they implemented in that

link down there is not enabled natively by default so it still uses some of the old techniques there which made honestly which made exploitation quite a bit easy cool things on the offensive exploitation side of the house since this is deserialization and it all it all basically happens in memory this should avoid touching the disk it's all taken place in memory and one of the one of the coolest parts when I very first got this to work I popped calc and you could see a child process of IAS worker process w3w pd x ee i think ad calc running underneath it I thought I'm gonna restart AI is clean it up and running I restarted I is the worker process went

away but calc opted on its own two legs and started living on its own outside of I is so what I basically found is you execute a payload through deserialization you restart I is it completely detaches from IAS runs on its own two legs it's there until you restart the entire server or kill it manually if you launch a payload and you want a rat running in the background a remote access tool it's there it's it's running until an admin restarts the box which from a Red Team perspective pretty sweet I like it yeah restarting or even shutting down is entirely it's still detached from from the process and running at memory one cool thing that was added in dotnet

4.5.2 we talked a little bit about making the modifier it's you know splitting up the directory from the file name running the hash codes reversing the byte order I started noticing viewstate generator being presented with with the viewstate as of dotnet four or five to juice a generator is presented by default it's actually the modifier in Reverse byte order so they're actually presenting you what the salt is for the page all you have to do is take it convert the ASCII 2 hex and reverse the byte over and that takes away your dependency on the.net get hash code library so now knowing that you can completely externalize your tools from dotnet you don't have to use c-sharp

anymore you can use Python whatever you want to because there are no longer any dependencies on the.net library to use that get hash code to use that get hash code library so kind of an interesting perspective there on tooling so payloads for blue team visibility on the flip side of things here the payloads generated by this tool that I'm releasing are gonna be plaintext I didn't support encryption in this one you know give blue team some time here to work with this one you're gonna be seeing why so serial net payloads over the wire which you're not going to be naturally seeing process dot start in a view state so something you paint want to keep an eye out for if you start

seeing that going over a view state packet bad stuff is happening out there and host paste protection products that you might have out there you know your carbon blacks and whatnot they're gonna see cmd.exe spawning out of the IAS worker process so something to definitely keep an eye on from a blue team perspective you start seeing it doing crazy things there's probably crazy stuff going on out there so demo let's play a little bit so I've got a server 2012 server 2016 and a server 2019 out here so the way these are configured for demo purposes I've got my server 2012 running H Mac sha-512 encryption in auto mode which means it's plaintext and the target page implements

view state so it kind of happens naturally it uses view state second one set up for sha-1 and Triple DES just kind of showing from an encryption standpoint it still accepts a plaintext of view state and deserialize this and then finally a plain empty page on a fully patched 2019 and showing that could still be it it is not showing is it let me let me mirror displays for you here thank you

thank you for that I knew something funky was going on here I didn't even look over my shoulder all right so let's start off here's here's 2012 and this was the one setup for H max sha-512 and basically uses a plaintext viewstate so got myself some cheat sheet here so the first thing we're gonna do execute this guy and we're just gonna go with the assumption that we acquired these validation keys through a local file rate or something something similar to that so first things first I'm gonna generate a malicious serialized payload using Y so serial net so the command-line options I have here - G is the gadget this is the code execution path upon D serialization this is a

known gadget that exists in a fully patched net library today we're gonna put it - F in object state formatter format that's the underlying format of view state that's used on iOS in net we're gonna output this payload in base64 and we're gonna run the command in local host ten times just something that pops up we can see visually and then it goes away just for a proof-of-concept so there is our malicious serialized object but it does not have a valid H Mac whatsoever so next step is we're gonna sign this object by using our C evil so I'll go through the command line options here when I so command-line options we are first going to give it the target URL I

just made an example page that has a subdirectory and then a page in it and then the hashing algorithm for this target server is H max sha-512 and the validation key please don't copy and paste this one this one is for testing purposes and use it if you want to but usually at your own risk let me put it that way so this would be a validation key that you would have collected out of web config during a pendant and then finally give it the payload from Wiseau cereal net the malicious payload that that you just generated and we want to sign that using h max sha-512 with this validation based off a salt on

this URL so when we do that tool nicely URL and codes everything for you and gives you a nice payload that we can go straight to burp so this was a natural viewstate packet between the server everything looks good we see over here our iis worker process spawned now if we switch to the exploit packet we basically paste in the packet that we just signed into the viewstate parameter and boom ping spawns over here so in a fully patched 2012 server we just achieved remote code execution by running a gadget in the latest dotnet library on the latest revision of server 2012 all because it disclosed its validation key to us through a penetration test now we have full code

execution we've gone from trying to find some kind of information on the server basically information disclosure to remote code execution so the next example this server was configured for sha-1 and triple des so if we were to look at this server burps nice little view state tab we can see doesn't recognize the format it must be encrypted this is a Triple DES encrypted packet here and remember during regression testing I found if the server is configured for encryption we can send it a view state and if everything checks out it's just gonna process it anyway let's see what happens use the same packet I went back through I pre package these but I basically went

through the same routine made ping localhost ten times and then signed it using sha-1 it's a hashing algorithm for this one let it loose worker process spawns pain runs on the backend and this is a plain text view state you can see right there everything is clear as day system version equals blah blah blah this is in plain text the server was configured for encryption still works good to go but what about Server 2019 Oh Server 2019 sure let's do that next so this one I have configured it's just it's using H max sha-256 and I have I literally have one page out there called blank aspx there is no content in this page whatsoever I guess I can go to the page

instead of just trust me

see how live demos go well

blank aspx literally nothing there it is a completely blank page it's empty it's zero bytes in size we run through the same routine make a make up payload in Y so cereal net tell it the URL is blank aspx beat it the proper validation key that we acquired through a penetration test send it right after the server and boom still execute code the the the page itself has no logic in it it has zero byte content but in the background loads the page object which automatically loads view state which automatically processes and accepts our serialized packet that passes the H Mac and this is a fully patched 2019 server so one little too old add your utility about

going from information disclosure to full remote code execution all right slides here to wrap up all they're good so wrapping up basically don't ever ever use keys that you copied from someone else don't copy them off the web what is it that Eric Johnson always says don't copy code from strangers something along those lines yeah don't copy them out there if if your servers ever been caught or compromised recreate your hard-coded keys that you had in web config behind your load balancer if your web config was modified unexpectedly regenerate your keys someone may have done that maliciously if your website's ever had a read flaw or an xxe flaw regenerate your keys if you're in doubt regenerate your

keys don't leave them out there recycle them if anyone ever got their hands on them it's a ticking time bomb a remote code execution on a fully patched system out there so we've got some awesome applied research on this subject that I'm hoping to be talking about somewhere in August we'll see some really really cool stuff that we've started taking off with this this is just the tip of the spear on some of the things that you can be doing with you want to learn more about this here are some resources that you can take off line once again slide decks gonna be published so you can take a look at it and finally give me the damn tool here

are a couple links so we've got a link to the blog post here Illuminati comm and our see evil dotnet the download link I've published the code before we came in here though the code should be out there feel free to take a picture take a click go grab the code go play some CTF and stay tuned for future research projects really really looking forward to talking about some of them someday though any any final questions before yes yes the sir the gentleman in the blue shirt

so what platform was written in I I wrote it in on windows on a fully deployed dotnet deployment I wouldn't be able to tell if it runs on core my guess I believe I tested along the way I'm my guess is that it's not because of the hashcode dependency the the hash code function in particular I believe was was a Windows dependent in that deployment man yes sir

so the way that I'm gonna kind of answer your question the way the why so serial dotnet payloads are set up it will always invoke process start in dotnet which invokes cmd.exe /c than your command so that's how of this tool is is designed to launch payload it's it's possible that that behavior may change in the way someone else codes it yeah all right all right thank you everybody [Applause]