 So this is hacking dot net applications at run time. I'm John McCoy and this is Daniel DeFries. So going after dot net at run time is using reflection to activate the functionality inside of a dot net program. This is legitimate inside of the dot net framework. It's functionality inherent. This is part of a run time language. If you go to something like Java or other run intermediate languages that have CLR, you'll find this basic same functionality. This allows us to reflectively look at objects and edit them at run time and we're going to exploit this to make a dot net application malleable to not only change the value and state of it but to literally change the logic flow. We're not going to be attacking code, we're going to be attacking the run time itself. So this presentation will be covering accessing running dot net programs, attacking the run time structure, the weak points to go after when you attack a program, and some tools that we're going to be releasing. So the tools that you'll be getting is dot net exploit. This is a framework and payload system with a management area as well as the standard deliver package or payloads. So it's easy to reuse and hopefully people want to develop for it. Metasploit payload that will work with the delivery system that will be arbitrary. And this will be a standard Metasploit delivered to SQL Server Management Studio. And we'll demo that towards the end, hopefully you'll like it. And we also found some really nice extras when we were doing this research. We're going to be leveraging an old Visual Studios exploit as well as showing some decompilation that will get around some of the protection that you might run up against when you're trying to decompile dot net applications. So the run time attack. It's going to go after the process space itself. This is your application. You can put more than one application in a process space. We're going to modify the run time objects of a process to carry out this attack. We're going to be editing the underlying structure of an application. The structure itself, not the code base. This will allow us to compromise the GUI, instantiate new features, access the code base, subvert logic, and evaluate the object structure. It's more for reconnaissance. When you get into someone else's application, assuming you do or don't have access to their source code, you want to go around and figure out how those objects lay in memory. What instance of an object do you want to attack? This is also useful when you're attacking a program live. So if you're not making it out of the box attack, you want to attack it on the fly. This is also useful. So what is it and what is it not? This is a memory-only attack. We're not going at it on disk. This is deployment independent. That means that whatever way that you are able to make it into your target's run time, this attack will be carried out the same. We have a few demonstration ways of getting into your target's application. And stability. We're not playing games with the heap. We're not messing with pointers. We're inside of the dotnet framework. So we have the stability that dotnet comes with. You don't have to worry about accidentally changing one thing that changes everything else in the program. And this is language agnostic. When you're attacking a dotnet program at run time, it's I-L. So you don't have to care about what language it was coded in, as well as you should be going up against protected programs, which will have obstification, so you shouldn't be able to convert it back into a language anyway, so it doesn't matter. So this is what we're attacking. A dotnet process. You have app domains, assemblies, modules, classes. This is kind of the structure. At the end, we have our instances. And this is what we're going after. So this is the classical view of a dotnet process. You have a process where you have your GUIs and your instances. Inside of that, you have app domains, assemblies, and eventually have your classes and values and functions. And this is our target. We're going to be going after instances at run time. We really don't care what class it came from. We will be utilizing what class it came from, but the structure of the application doesn't matter. The structure of the objects matters. And this is what a program kind of looks like at run time. You'll be going up against a lot of objects spinning around in memory. We have logical sections like the GUI and the core functionality. These objects are interrelated by pointers behind the scenes, but basically value references. And we have a button. It's interconnected by an event to a specific object. And this is our target. To go after the run time, to go after the instances, to go after the events and remold all this. And this will allow us to change the underlying structure of a dotnet application. So the specific task behind this attack, going to connect into your target application. Find objects and hunt for the references to the specific object you want to attack. Like if you're going after a timer or a SQL connection or a TCP connection, you have to hunt down your references in order to attack it. Going to move between objects. Depending on your connection method, you might need to hunt objects. Other connection methods will give you references for free. And finally, we're going to change objects. Using reflection, we'll look at the meta structure of an object, use its signature, and edit it at run time. Okay, so, down to the meat of it, how do you get into your target application? So you connect into your target's run time. You inject into it and spin up some dotnet. There's some projects we'll be demoing for this and is the favored method for injecting or for connecting to your target application. This is what we're going in with Metasploit. This is how you attack them on your system. Also, you can exploit the target's code base or the problems inside of the application. We're going to be demoing Visual Studios and exploiting that. Both of these get you into a target application, not necessarily where you want to go, but it gets you inside. There's infecting the target's code base on disk. This is an old hack. You find your entrance. You add yourself into a NOOP or something and you're in. That's kind of been done. This is on disk, so you're going to leave some forensics evidence behind as where with injecting your code into memory, you're not going to be worrying about leaving something on disk that can be recovered later. And finally, there's attacking the framework where you infect the framework itself. This was presented last DEFCON and has a little bit of research behind it and it's pretty strong. When you infect the framework, you don't have to worry about the target application seeing your code running inside of it. You can access core things like two string and when someone uses it, you attack them. So you can basically have an entrance into any application that uses the framework, which is all the .NET applications. So demoing how to connect into a target application will bring up Mandian's highlighter. Going to be injecting a 64-bit payload in there. If it's a 32-bit application, you inject a 32-bit payload in there. So we inject in and this spins up a payload that says, what do you want to load in? We'll select hack buttons, a nice little demo that goes in and it adds objects to the form itself. And it's pretty easy to go in and edit form since they're made to be fairly receptive to new objects. And we can click these buttons and they go through and add events programmatically to everything it finds on the form. In this case, it adds a right click event to everything on here. When you right click, it brings up an editing menu. And so you can edit pretty much anything as you normally would. This is pretty much the same concept as what Visual Studios does when you're editing it offline. And you can dig into pretty much any part of this and edit it however you want. And of course, you can do this programmatically to reskin any application. And there's some other ones. Like you can make them draggable and all that. Make them poppable. But this is just a demonstration of the injection. So that's injecting. Demonstrating the exploitation. As a quick exploit for Visual Studios, there's a way to run arbitrary code inside of Visual Studios when you open a project. So we open a project and now there's arbitrary code running. So we'll again say, hey, what payload do we want to load into this? And we'll load the lead. So this just programmatically goes through and changes everything into lead. So this is actually dot net form. It's live. It's actual objects. And we're going to lead it. Part of this system is a communication console with all of the payloads. So we have our delivery system. We have our lead. What application it's in, the PID, the user. And this will hopefully be extracted to run over the network. So you can arbitrarily communicate with payloads that have been deployed on someone else's system. So we'll go ahead and lead Visual Studios. We'll also bring up a data connection. So we lead it. It comes through. It iterates through every object that it finds that's of a control type and changes its text to lead. And this actually happens in code. So the plus side of this is it's completely programmatic and we don't have to worry about disturbing the underlying structure of the program. And also FYI, if you save this, it actually saves lead into your code base. And that's exploiting that. So that's the general connection types. There's also infecting the framework, which I'm not going to be demoing, but there's some code base that we're going to be releasing to do that. Like I said, it's pretty strong and pretty effective. So this is the overall structure of the application or the system. You have your payloads. They get packaged into a safe wrapper that gets injected into your target application. So you don't have to worry about threading or any other hiccups when you're running inside of another application. And you have your injection into your target application. So this is the basics for how we're getting in. We inject into our target application. We spin up some C++. This unpacks itself in memory and spins up C sharp. This can either be your hack or your payload delivery system. At this point, it loads up our arbitrary payloads and they attack the target application. So this is the basic idea of what you're up against when you inject into a target application. You basically end up in nowhere. You have no references and you have no way of getting to your target application. You can hope to get some statics or some entrances, APIs or some object reference. But on a whole, you're pretty much in the middle of nowhere. So how do you get from the middle of nowhere to your target application? There's nothing stopping you, but there's also no doors to use. So the favorite method that we're going after is accessing the GUI to turn that around into an object. You say, windows give me a handle to the window. And then you ask .net to turn that handle into an object. Once you have the windows formed that you want inside of your target application, you can iterate inside of that through all of the controls, access all of the events, the events being function pointers to your target objects. And once you've done this, you can iterate through the object structure using each object to gain more references until you've either reached your target object or you have exhausted the entire object structure. And that's how you get around into the object structure. At this point, once you have all of the references, it's pretty simple to implement your changes to your target application. So as a quick demo for mixing the GUI, we'll spin up Redgate's memory profiler, we'll inject into it. And a nice thing about this is basically any .net application is susceptible. Once you're in, there's nothing that can really stop you. There are a little bit of tricks that can be played inside, but I'll get to that later. So we're inside of our target application. We'll load up our hack buttons again, and we have a payload inside of our target. Utilizing our communication paradigm, we can say, we want to load another payload in there. And so instead of picking from one of the payloads, we'll actually load another .net application into it. And this is .net reactor, a code protection system, itself being protected by a good number of obstification, shells, everything that this protection system could throw at protecting other .net applications. So we're injecting one application into another, and at this point, they're essentially becoming one application. They're in the same app domain. They're not sharing logic flow, but they are one application now. And so now we can say, add yourself to that form, since these are all one application now. Ants memory profiler and reflector. And again, we can go through and lead everything, all that. And it leads everything that it finds in this object structure, and this one leads everything in that object structure, which is why they're separate. But at this point, we can do things like pop controls on and off. But we can also pop controls on and off of multiple applications. So we've now popped a button. And at this point, this button over here is still part of this logic flow. And its functionality here is maintained. We haven't broken it. When we put it over here, we kept all of the same links. So when this is clicked, it activates the same functionality. This is allowing us to intermix the GUIs and the core functionality of independent applications. Also notice that the style of this window matches the application we put it into and not its actual parent. This is due to where threads come from determines their style. And there's some fun games that you can play with this. So now that we can intermix GUIs, we can intermix logic. We can basically remold applications into new Frankenstein apps or mashups, whatever you want to call it. And this allows us to do more complex things when we get into other applications. We can bring tools with us that are other applications. And so that's being able to play with the GUI. So this is basically what we can attack. When we actually go after fundamentally changing a target application, we'll go after the events that are inside of the application. We'll go to a button and wrap the function that it goes to. So the games that I like to play is find this object that it goes to, wrap it, derive from it, inherit and intercept all of the functionality that they would be calling, and then put it back in place of its original. This allows you to intercept the event, arbitrarily do new functionality, and not have to worry about whether you're going to match the signature or anything else, because you're basically the original object structure. Also, this doesn't change the underlying object's code, so you don't have to worry about someone detecting that you're making changes to your target's code base, because this is just a wrapper in another module that's being loaded into it. So something fun that we've whipped up for you is an SQL modification. So we spin up SQL Server Management Studio and inject into it. SQL Server Management Studio is a 32-bit application. A lot of the .NET apps you'll be going up against will be an MSIL and targeted generically, but this is targeted at 32-bit, so you have to use a 32-bit injection system. So for the payload for this, we're going to be using a targeted attack. These are pretty much just generic attacks that can be deployed against any .NET application arbitrarily. This is more for R&D and showing you in code how to do these things. The SQL attacks, we'll start out with SQL Defender. It's loaded in. It goes after this form, adds a star to it to say, yeah, we're online. So now what this does is it adds a whole new security model to the login process to defeat brute forcing. What we've basically done is subverted that event for the connect button, as in the previous slide, and now that we own this connect button, when you click this, it now has your username password. And so what this is, is when you type in a username and password defined in the protection mechanism, it opens up an admin console. This lets you choose how many failed attempts you'll allow before you lock out the login process. You can change your username and password to get to this admin panel. Also, if someone does get locked out and they keep brute forcing into your server, if they finally do get in, it'll instead of logging them in, it'll change your password to a 40-character random. And this is also where you come in and say, I don't want to be locked out anymore. Let me in, let me try again. As well as some Twitter keys that say, hey, if someone is trying to hack my system, what account should I notify? So someone breaks into your physical and decides that they're going to try and brute force overnight. This will add an extra layer protection. This is just a demonstration of adding third party patches to a .NET application. The basic premise of this is you can pretty easily add third party solutions to existing applications without having to worry about compromising the overall structure of the program. You don't have to worry about some pointer when you're connecting to a database because we're affecting this one object. And these hack, these modifications are done in just a few lines. Instead of being hundreds and hundreds of lines, these most of the time are in between 50 and 100 lines. You're dealing with high level .NET instead of walking lines. Another targeted attack that whipped up is going after ants memory profiler again. So this one is loading up a payload that will go after the trialware. The trialware on ants memory profiler pretty much works off of this one window. As most good programmers do a whole bunch of logic and then return a value, that's all this window does. If you've activated or you're still in your trial period, this window says okay, everything's fine, go on. And that's all this does. It says everything's fine, go on. And the nice thing about this is it's implemented in two lines. The code is literally dialogue result okay, close window. So reflection is the main tool we're using. You can do a whole bunch of things like hey object, what's your events, what's your functions, what's your method, so on and so forth. You can get constructors and all of that. So if you're a coder, this is the most interesting part and if you're not, here's a nice graphic for you. So when you come into reflection, you're going to have an object. You say get type for object. That'll get you a type. You say hey type. What kind of methods do you have? This will return you a method info object. You can then utilize this to activate that method info. You pass in a couple of parameters and you activate the method. You can ask for values and properties, properties being the getter and setter that wraps a value. And at runtime, getters and setters turn into functions. You can go around and get events. Events are a really nice part to attack, so I've spent a little bit of time focusing on that. Also, you can get constructors for your objects. You can basically dig around in an application and grab anything that you want. You can grab the inherited types. You can grab interfaces and basically think of it as developing at runtime. So here's a little bit of code for hacking an event. Events are normally completely secured against outside tampering, so you can be confident that if you've set something to your event that no one outside of you can change that. This gets around that. Basically, you say, give me a flag that says instance non-public and then you ask for the events. So this function takes in, say, a button. And you say, hey, get me the field of events in string. So you're actually using proper names at runtime. And you say, get me the instance non-public. And so it does. It just returns a private instance variable. You can say static, private. Anything you want will be returned. So simply take your events object that you now have that you've got off of the button and you say, hey, get me your head off of your events. And again, it returns it. And then, finally, it's a linked list inside of an event. And you say, get me your handler. And again, instance non-public, which is private. And it returns that value. And then you say set value on that. And you set the event to null. And that's all you have to do to access someone else's event and wipe it out. This is basically the same premise that you would use to reconnect the connect button or anything else. Or text boxes are pretty much anything. You can, once you can control someone's values, you control everything. So the basic premise of this attack is you inject into your target application. You drive deep into it. You gain access to the target objects. Once you've done this, you can access the objects. You access a button. You rip out the events out of the button and you change them. And then you pwn the application. And it's done. You're not worried about editing anything else outside of the object structure. At this point, you don't care about what the code is underlying this. So no matter what kind of protection mechanisms they may have implemented on the code at memory, they're all objects. And they're free to be messed with. This is what it used to look like. When you would go after an application, you might spin up IDA and step through it and try and change values this way. This is what .NET brings us. A lot faster development time. Instead of hundreds of hours and looking through thousands of lines, you're talking about 15 minutes and looking at 50 lines. Most protection mechanisms can be broken down to attacking one function or one value. And with the .NET attack, you can basically iterate through the object structure and find what you want in a matter of minutes or seconds, hopefully, with a little bit of practice. So as a quick public service announcement, we found a really old visual studios hack that's been around since 2006. Microsoft thinks this is a feature that it runs arbitrary code on your system. So basically, all you have to do to make an infected project is, let's see, let's spin up. So all you have to do to make an infected project for any version of visual studios, this is a feature that's core to the functionality of visual studios. They say it's not a threat because it requires multiple clicks. So this loads arbitrarily whatever code you want. They say it's a couple of clicks because when you load it up on a system that you didn't develop it on, it either comes up with this or hey, you didn't develop this code. So you come into the application, you look at the about box and that's it. So this happens because this image box is infected and it's the constructor of the image box. All you have to do is put whatever arbitrary code you want inside of there and that's it. It executes when they look at it. So the added scary thing is maybe you can make a scanner that would go through and look for the code base and you could look at it before you open it. It turns out that if you don't rebuild that whatever code was left in there, so we'll go to that same constructor, it's completely empty. Look at the about box and it's still there. So regardless of what the code says until you rebuild, it'll be utilizing old objects that could be infected and this is core to the functionality apparently. Microsoft has no plans in taking it out. So I decided that I would whip up a nice little infected app that instead of showing the user something pleasant, it would Twitter out the computer name and the IP address. So when people download and run this application, it decides to Twitter out and so I'll be putting out an application that says in the ULA, hey, when you use this I'm in a Twitter and hopefully Microsoft will get the message that this is not some feature. If you have arbitrary code execution on a programmers machine, you can basically hone whatever company they might work for. You can do something that specifically messes with the development cycle. You can go after the SVN that it has access to. Developers often run as admin, so you can leverage that into something pretty powerful and scary. So some of the other fun ones that we also have is data piggybacking. The basic premise of this is the same as the other ones. Once you're inside of another target application, you can send whatever you want. So SQL Server Management Studio. So you make it into someone else's machine through some exploit and you're unable to get back out to the net, but SQL Server has a valid communication portal and you leverage its credentials to get you back out to the net. So we inject into it. We select data piggybacking and again this management console allows us to talk directly to that payload. We can send emails, Twitters, UDPs, and so we can send a Twitter of whatever we want and it inside of the object structure leverages the credentials of SQL Server Management Studio to send Twitters. Or UDP packets or email. This is just a nice data exfiltration tool. So once you're inside of your target you can migrate around until you find an application that does have rights to get out. And so here's a Metasploit payload that we developed. All right. So I'm not much of a .NET programmer, but I do like Metasploit quite a bit. And I like getting Metasploit integrated with as much stuff as possible. So we thought it would be really cool if you could go from one machine to another remote machine using any arbitrary exploit that you had that you could get from Metasploit anyway you can find in and then do in-memory remote .NET code injection to the remote machine through that. So we set out to do that. So what we wrote was essentially just a C++ shim. That right now it's a interpreter extension but you can do it. It's just a DLL so you can just use the IRB load library call to load it up. You don't actually have to write your own interpreter extension if you don't want to. And that will spin up .NET from within whatever process that you've migrated to. So now you can execute arbitrary C-sharp if you feel like it and you don't have to write your payloads in C++ if you're attacking a C-sharp application. So we just have a VM over here that's got SQL server management studio running on it and I should get a remote desktop to that. And so we've got a interpreter shell I just put something vulnerable on it. And then if you look at the process list and find SQL server management studio SMS it's 3088. So if you just migrate to 3088 use this is the boilerplate interpreter extension that they wrote. And I just wrote this command alive that spins up .NET and then whatever payload that you have. So you can write anything that has some C-sharp in it and avoid main and this will just execute it for you inside that C-sharp application. So we just the thing you saw before that attacks SQL server management studio that twitted your password. If we look at the login here, oh it would have worked if this was open. There. So let's try it again. Is it there? Yeah. So there's the asterisk on SQL server management studio. So now you don't have to do any of the work of figuring out how to get .NET running within a C-sharp process or anything like that. It's all there for you and you can just deliver metasploit payloads in .NET now. Which I thought was kind of cool. And it never touches disk because the metasploit people did all that great stuff with DLL injection and that's essentially underlying how this works as you DLL inject into some process and they're doing all the fancy reflective DLL injection stuff and then we leverage that and spin up .NET inside and it's pretty cool I think. And so like you said of course you can use any of these payloads and deploy them across the network or make your own void main. So now that you've successfully pwned, you can pretty much do anything you want. Anything in .NET can now be done. You can do anything from access the system's Windows API to write to disk. Leverage any of the credentials of your target application or migrate around to your target application until you find the credentials you want. Some of the non-evil uses of this are also quite applicable. If you want to write third-party patches for your application and you want to do it with a short development time this is great. You can edit the GUI, you can edit the logic and then you wrap your application with a loader that injects it every time it loads. Also there's defensive payloads like the SQL one that will stop brute forcing. So you can write independent protection systems that will work for you that no one else maybe knows about or you have one set of developers developing something to be injected and you can hold this back from your main development cycle. There's also bug hunting. You can inject into your target application and of course bug hunt. You can find the exact values of anything and get deep inside of it and find out the state. You can find out the connection and there's also flexible programs that can be built. This is nice because now you basically have an API that can work with any application. Instead of worrying about how do you connect to a target application you reach straight down inside of it and access any part of it you wish. This is specifically nice when you're maybe trying to figure out how an API works. You can reach inside of it and literally dig around inside of it until you understand it or even remold it to add a new API. So the things that can slow this attack there's a little bit of framework security but that's not any concern. Some people say they're trying to make defensive countermeasures but of course you can attack their countermeasures or since this is basically loaded at a specific instance in time you can wait till all of your authentication is done and the defensive countermeasures have all spun down and then inject into the application and get your work done and possibly unload from memory. A lot of the hacks that you can do are merely rewiring you don't actually have to add code to your target so you can get in rewire your target and then get out and so you won't be resident in memory anymore. Also bad programming design can make this really hard. When you find a program that has vestigial buttons and classes all over the place for no apparent reason you can get pretty lost and other bizarre development cycles but as a whole most programmers have a pretty clean design in high-end apps so you can get around pretty logically and I'm hoping that development cycle will spin up and we'll be developing a better way to walk around the objects and attack them that way. Was there one more? How do I get paid from this? We're going to make these hacks and give them away for free so this is all going out for free under the Creative Commons non-commercial so it's all going to be out there to play with. We get paid hopefully to build countermeasures against this. Basically we get paid by building countermeasures so if it company would like to get this they would be able to hire us as contractors to come in and protect their system from this or add additional protection. Sweet. So some of the people that really helped with this on coding the wheel James Devlin sorencer band they did some nice research and he did attacking the framework some really nice stuff thanks to some of my good friends that added to this and check out the book Managed Code Root Kits this is coming out in a couple of months and definitely something if you want to attack the framework and as I said this is all going out under the public use license and they'll be Q&A over in 106 and some of the additional payloads if you want to watch we can run over them okay we want to show Twitter real quick one last thing in case you didn't believe that it was actually doing it so when you log into your SQL server every time now it shows you your essay password in black hat so we have a couple of extra minutes so I'm gonna just spin up some injection and do a couple of fun demos that I've really enjoyed so we can basically at this point intermix applications of course and injecting into our target application allows us to edit the GUI and add some intermingling features so when we get into the target application we can ask code object the code behind it so when you're inside of it you say hey what's your code and it divulges its code so you can jump around to objects and say hey what are you running and instead of hunting through the object structure you're right there in code also going after SQL server we'll inject into that and spin up the communication console pretty much the same hacks leading I guess I lost a couple of payloads okay well thank you very much for coming to my talk hope you enjoyed it