 working at random other projects, and we do this on our side, neither of us do this for work. He does use it at work, I don't really. We both work in the security industry, I'm also a student, and this is about exploit frameworks in general, and about new exploit technology that we and other people have been working on along the road of metasploit. Okay, well LightSpoon said, my name's HD, I work for a company called Visible Defense, video risk assessment services, yada yada yada spam. What this talks about is exploit frameworks in general, the metasploit framework in particular, and kind of showing me that all the technologies for hacking like in the movies like, you know, watching the net or watching like, you know, hackers or sneakers is already there. That was the whole flying through the cities with the Gibson's and stuff. What do you do if you want to, but why waste the CPU on it? I mean, so some of the things we're going to show up today will be things like the... So things we're going to show up today will be things like the VNC shell code where it doesn't touch the disk at all, but it gets us a remote interactive desktop where this is more hacking, things like that. Yeah, we'll start with an injection, and then, well, we know this is two hours, a lot of people have other things that they may want to do, so we sort of split it into like two different sections. So we look through the first thing and do some demos, and then go more in depth and do some more demos. So we'll start with some background information on an exploit framework, it's not necessarily specific to metasploit, but just what's out there now, and what the current state of things are. So what is an exploit framework? It's an interface for launching exploits. There's a lot of reasons to use one. It allows you to standardize exploit modules. It allows you to have a suite of liable shell code. At least in our framework, you can specify a different shell code. That's not necessarily the same for all other frameworks. You have a lot of common routines, and I think there's a lot of core features. A lot of this is really good from the export developers point of view. A lot of code reuse, a lot of things that you don't have to do that you would have to do in a standalone C program. And also a lot of it shows in using it, having a standardized interface to use only different things, and having a lot of advanced features that you wouldn't have in a normal standalone exploit. So what are exploit frameworks needed? Well, as anyone who's been going to PacketStorm or other public security websites to get exports for us for years, just about everything you download is a piece of crap. Honestly, the things that you're able to find publicly as far as exploit code, 90% of the stuff just sucks. Even worse, if you start looking at this code, half the code is boiler-fed. It's copy-pasted to someplace else. How many times have you seen the same T-stool shell handler being copied from the same D-com exploit to D-com exploit to serve you up to boot all in a row? I mean, it's kind of gross out there. No one can really code. The people who are running exploits aren't really programmers, so people who know just enough about security and programming to get the code done and working. And that's kind of what we're running against. If you're doing a pent-test and you need to reliably exploit a system and say that that's what you're using as hard code to a bind shell or a reverse shell, and you use the opposite type of payload, well, you're going to have to go there and hack this one else's ugly assie trying to get it all working. So the goal of the framework is to be able to provide you a consistent interface for exploiting a system in a way that you don't really have to worry about what the payloads are, who wrote it, or whether you need to convert Win32 socket calls to Winsocket calls or remove WCA startup sequences. One thing that's important about this is, for the last point, nobody posts code for old bugs. This is one thing a lot of pent-testers will admit, too, that it's very important. There's a lot of bugs that may be three years old, but there's still a lot of exploitable machines running it. And the thing is that people aren't now going and revising old exploits with new techniques and new technologies. They're not retrofitting old code. So something we've done is we've gone through and we've written a lot of important exploits. And also just the fact that it's in the framework itself where we come up with new technologies, we can use that then in older exploits. Right now, there's two public-export projects. Excuse me. There's a few public-export projects. There's two commercial projects. Each project's a course impact product and a community-use canvas product. For those who are not aware, in about 2001-2002, something called KORUSG released the automated pent-test toolkit, essentially as a giant GUI interface that had tons of exploits in it where you can just drag and drop root shells. Now, that's great and all. I mean, it's nice. It worked pretty well. We've got some really sharp guys working on it, but it charged $15,000 a license. And I don't know about you guys, but I can't afford $15,000 for an exploit. So the other product is Canvas by immunity, and we keep this one as a mini-select, apologies to Dave by telling us he's in the audience, but his company is called immunity. His product is kind of a cut-down version of Impact. It has a different focus in that it provides lots of exploits and a lot of actually undisclosed or unpublished exploits, and it actually runs on Linux and 1.32 at once. Finally, you have the Metasploit framework, which is our project, open source, and it's not really meant to be directly competitive even these commercial projects, but it's different goals. And we're going to kind of talk about some of the goals in the next section. Yeah, we're going to cover both Core Impact and Moody's Canvas in a little detail in the next couple of slides. So first, Core Impact. It was the first real exploit framework. I think it came around 2000 or maybe a little bit later. And they were the first to do a lot of things. They were the first to have a functioning syscall proxy and a lot of the kind of set the standard for a lot of the technologies. They're pricey and other solutions, but they're extremely complete. The tool is written in Python as C++ and the tool itself only runs on 1.32, but you can obviously own and pivot through non-windows boxes. You can pivot through own boxes. Basically the way that works is after you compromise the machine, you can launch your attacks through Impact through that machine to be able to box on the perimeter. You can then use that box and start owning things on the internal network, et cetera. And they also have a syscall proxy and payload system which is how to implement pivoting, a lot of other things like upload, download, file, a lot of other advanced payload, techniques, or payload features. Unity Canvas, this is written by Dave Idle and I think he started running in early 2002. It might have been before that and this wasn't aware of it. There was the second commercial framework out there when everyone saw his product. They were like, wow, look, he's competing in his core Impact and kind of curious how it's going to happen and how it's going to work out. And it ends up that they're running pretty well. No one tends to see which of his exploits. So you often find exploits that are in Canvas that aren't in anything else. And that's kind of what Dave and the rest of the Unity team kind of rides themselves on. It supports limited syscall proxing. It has one payload. Instead of having a reverse shell or a bind shell, it uses all reverse shells as far as I know. Or it can use bind sockets for other things as well. And the actual payload is kind of a multi-connect payload. You can use upload files, download files, manage the system, create new connections, do other things through that one payload. It may actually be able to pivot in their future where you can actually compromise one host then export another host directly after work like Spoon was talking about a second ago. It's less extensive than Impact. I think it has somewhere between 70 and 80 modules as opposed to core Impact's around 300 or so. And it runs for about $1,000 a pop instead of $15,000. So if you're a small shop and you need a commercial exploit framework, it's not a bad thing to use. So the current capabilities, we actually did this talk at Black Hat too. I've been quoted a lot in news articles saying point, click, root. So we're going to repeat it. So the current capabilities, we've really gotten down the expectation to point, click, and root. You can pivot through the boxes after you earn them, watching attacks from the box and just compromise. Automatic payload encoding, avoiding things like that, characters. That's something more in the background that you don't see. But it's definitely important. And we also have dynamic shellcode creation systems. Canvas has more stuff, which is a Python-based compilation for compiler and assembler. And Impact has inline egg, which is, I guess, they have a greater system called egg. But that's what they do, a similar dynamic shellcode creation. Next section is the Metasploit framework. I have no idea what the project's about, what it's going, what it can do right now. We've got the project is stable enough right now. So we're using it in our organizations to verify vulnerability assessments, to do pen test work, things like that. We've been using professionally for about a year or so now, so it's definitely ready. Okay, so just a brief introduction. It's an open source expert framework. I believe it's the, pretty much the only one out there. There's some other projects that sort of concentrate on subsets of things that Metasploit do, like payload systems, etc. But this is the only open source total expert framework. We also think of it more as a expert development environment. All of us are security researchers, and we do a lot of development work. So we're really using it more for that than actually for going out and using it for pen tests. So it really, I would consider it more than expert development platform, than core impact or Canvas, which are sold as products, not really sold as environments for you to be writing things in, although you can, but that's not really the main goal. It's written in Perl, which is a choice we've made and have gotten platform, but we stand behind it strongly, and it's been working out really well for us. It runs on most modern platforms. Right now we can run it on HPox and Solaris, straight out of the box. It runs on Windows 32 under the single environment, runs on Linux and BSD and pretty much everything else. HD has it running on a source. So I mean, it's really pretty perlable if you look at it. If that's been over, you know, you can have a office building with a device, hypothesize your hand and have a list of about 30, 40 X-boys, you can start owning boxes with nice little Wi-Fi cards. It really reduces the amount of time it takes to go into unknown environment and really start rolling with it. Even though we don't really support pivoting with the project right now, you can literally just copy the framework over to another host and start running it because we do have 132 installers and it does run on every modern UX platform. We're mostly focused on improving technology, things that may be as important from the users perspective, but a lot of the back-end things like shell coding encoders and just really trying to improve some of the some of the things that are more important to us as developers than maybe someone as a user. But that doesn't mean that it's not good for you using too. The project history, about a year ago I started working on a network game with a timeline. It was this cheesy little end-curses client that looked kind of like the BDS game Overkill. I don't know who else has played that, but it's a fun little game. You have a little text screen and these arrow keys and we'll go around, go north, go west, that kind of stuff. We actually coupled that with a vulnerability scanner with a Tiny of the Westquake framework and as you pop boxes it install a little daemon that would then report your score and who won the box. So we had a scan that you could determine what the score of the system was. We started writing this game and we wanted to start writing exploit modules for it. The problem is all the exploit models had to work the same way. They had the same inputs, same outputs, be able to take the same payload and it's actually useful for a whole lot of the stuff and we can actually use the same concept as a vulnerability exploit framework. We started writing the project in about, I think, August 2003. We dropped 1.0 out just kind of as a, you know, testing the water to see if anyone's actually interested in it and oddly enough everyone started actually using it and it could have been because we included three of our exploits that didn't really work well anywhere else. Slowly it kind of involved an open-source project and Spoon started helping out, I think, in November, December of last year and pushed through all my code on and said, eh, that sucks, I'm going to write it better. And I was like, okay, go for it and he didn't. So that's the Spoon. We have four primary developers right now. Me and HD work pretty much on the framework code and we also have Matt Miller who's probably here somewhere who's done a lot of really great work. He did a lot of the DLL injection stuff you'll see later and also working on actually some of the code going to Metasploit and we also have optics who's doing a lot of the back-end shell code and exploits on Solaris and stuff like that. So that's basically the Metasploit team. We also have a handful of other contributors people sending us exploits and different payloads. So a quick overview of the development status. We have about 35 exploits and 40 payloads right now as of release 2.2. We have a stable exploit and payload API. That was one thing that 2.2 set out to do was to sort of freeze the API so we can safely tell other people that we're providing things for Metasploit and not have them not work in future releases. It's widely used as we're slowly finding out by a lot of security firms and a lot of other groups and it's increasingly used by system admins and other people spurred verifying network scans. HD can talk more about this stuff because he does a lot more of it and work than I do. I was just trying to see a lot of the large software companies using the product to test other products. They'll have a vulnerability report on their product to test exploit for that demonstrates it Metasploit client interface with actual API itself to automatically test for that during the regression testing process. There's another large company that provides security products and specifically host protection products like this mentioned by I think another talk at this con covered those and they actually use Metasploit along with different types of payloads to verify that their protection system actually works correctly and what you'll notice with a lot of the host protection systems on the Windows environment instead of doing memory type production we'll actually look for the permissions of the page and we'll look for people calling load library A from a memory segment that is writable or things like that or from a stack address and we're starting to hear more reports people are actually using this to do that type of testing. Version 2.2 was the first development from the release. In other words, if you pick up 2.2 once we release it next week or from the secret blackout URL that you'll find at the back end of the slides you can actually use it to develop exploits that should work in all future versions of 2.2 for any modifications. An important thing to click about would be the increasing use by security firms and people after volume scans. It's one thing for a security tester to come in and say a network and say we scanned your host and we have one on PetchBox and a lot of people are realizing that it's much more impactful and useful to actually go in and then maybe if you have good notes on an exploit you know it won't crash the box and stuff actually go in and own it and then you can say not only was this box unpatched but you also had your payload sitting in an Excel spreadsheet on the desktop. I think a lot of people are realizing this and that's why it's a lot of I think that's really useful for people in that sort of area because it's a nice tool to follow up after of all the assessment. There's a meta-spoke framework that's actually made up of a ton of little components if you look at the list of files there's something like 200-odd Perl modules scripts, source code, things like that in there it's a combination of Perl, C, Assembler there's some Python stuff for supporting inline egg it's really kind of a hot pod of stuff that's what the job happened to be. There's actually the set of interfaces there's three different user interfaces in the project right now which we'll cover in the next section a little bit you have your exploits, you've got your payload encoders that are responsible for taking the raw shellcode and actually translating it into something that doesn't have a certain set of characters into it which is useful for you know if you're attacking a web server and you have to put the exploit string or you have to put the shellcode into the URL itself you have to avoid certain characters to make it a valid request still you've got the actual payloads themselves it actually runs in the box and the exploit works correctly we've got stuff ranging from bind shells connect shells, exec v to just all kinds of random rude things things that will actually reset the signal handle but it'll be something else and we've got a lot of special case payloads that we use to get around certain tasks and because of the design of the framework you can create your own payload drop it into the system and have it run with any of the exploits already there. You don't have to go through and actually have to patch all your silly .c exploits so that they all use your new payload and then have to adjust the size of the roll and what not it happens automatically finally through the payloads themselves each payload has a handler people don't really think about this too much because it tends to be automatic but if say you're exploit will create a bind shell will you have to write a bunch of code to connect to the bind shell give them a shell or tell the user to write type telmap blah blah blah to connect to the host well we think that's kind of so there's no reason to force the user to we can't do use an extra problem to connect to the shell there's no reason to have the same boilerplate code repeatedly in each and every exploit we've got a handler system where for every single payload it defines how it handles that payload itself if it's a reverse connection for instance the own box connects back to you it will create a listener then bind that to a console that console could be the actual standard input output it could be a telnet server that actually runs a different port and if you've actually seen MSF web console it actually creates a proxy telnet server that puts a command shell on that and then redirects your browser to a telnet colon colon slash those links to the proxy server and finally you have the the knob system and as you know knobs are used to pad the payload space because the way that we're able to do interchangeable payloads is we tend to hard code the amount of space that's actually used by the payloads on a pro-exploit basis so you can have one exploit has run for about 512 bytes of payload you just have to be the space for that payload to be 512 if your payload using is only 200 bytes it would have been padded 300 bytes in front of that with whatever knobs are for that platform you can actually set environment variables to randomize the knobs loads and cells you can actually specify minimum knob slides so if you're doing a brute force attack and you require a certain amount of knobs to be there it will always make sure that that amount of knobs are there. Additionally each exploit can define which registers have to be preserved during the knob slide itself so you're using a randomized knob slide and you need to make sure that EVX rogers are never touched because you have to get back to your payload you can define that in your exploit and the knobs will automatically work around that. Yeah I was going to preach on the handle part because it's actually really important and one of the reasons we've been able to do a lot of the cool stuff like the VNC eject and some of our staged payloads just the way it's designed it's really easy to back on a lot of the handlers already written for example if you were going to write a reverse connection shell that does a simple one byte XOR it would be a matter of writing a payload and adding two sub-functions to filter the outbound and inbound traffic to do the XOR so it's really a matter of an extra six lines or something in the payload and you can already back already on the shell and MSF lab and any other consoles that we have already written and this actually comes into play a lot when we do we'll show the VNC stuff and all of it was really really simple to implement just because of our payload system and the way the handlers all work so a lot of it's hidden for me but there's a lot of times there's some pretty complicated stuff going on on the back end that as a user if you didn't have a handler system to do it would be really annoying you know dubbing that cat, seeing that and trying to figure out which one's read which one's write and a lot of stuff like that so this is actually more important than it may seem and it's pretty hidden from the user but all the magic going on is a lot because of this so this is a brief layout of sort of the design of Metaspray you have the interfaces which is extracted from the firmware code and it's really trivial to write a new interface we just have three simple ones we have the console interface which is the supported client and what we do all of our development work on we have a command line interface which is good for scripting and parsing and we also have the Web Interface which is sort of the flashy proof of concept demo interface we also, I don't know if you want to touch on some of this stuff, we have we explained some of the modules before we have four types of modules the handlers we were talking about before are considered part of the payloads we have some libraries for example we have a lot of code in packs for example we have an SMB stack we have a lot of stuff in MSF we have a lot of core classes UI utils and stuff like that the nice thing is that all of those modules all inherit from those bottom classes so we have probably the strangest pull you've ever seen before in your life we start looking at the way it's going to implement some of this stuff you actually have payloads that import from one class and then tell the imported class who's its parent is so it gets pretty tweaked as far as what payload inherits, whatever the class but the endpoint is you can actually have a payload which handles a command shell and be able to find whether it's a find shell or reverse shell find sock or whether it goes through some other encrypted channel through ICMP or whatever have you but because of the way it's designed you can actually replace the parent handles the handlers parents on the fly and one that's important is because for example we have a staging a staging system for the windows stuff and if you're not familiar with what a stage payload is basically if you want to say get a reverse connection and get a command shell that may be 300 bytes so for space problems you can then do the staging and it's also nicer just for a lot of reasons then you can have really big payloads and stuff like that we have a lot of staging going on so because of how that works you can just write a stage which is really independent of the stager and then you can build stages by just saying I want a stage and a reverse stage or I want a stage and a bind stage or I want a stage and a find sock stager and you can sort of like build your pairs together and with a lot of code reuse and a lot of backing and stuff like that So a quick intro to the command line interface this is actually the same sort of interface that's been around since version 1.0 but apparently it's used to MSF CLI give it some string that will match the type of the name of the payload excuse me that's what you want to use so you want to explore with the LSA Assas you used to do LSA Assas for the match you don't have to do the full module name if you dump a summary which dumps all kinds of information about that exploit one of the biggest problems with public exploits is you don't really know what the hell that exploit does you can go through and look at the comments you can assume that the usage is actually correct you can verify that whatever advisor they thought that exploit reference is actually the vulnerability that it affects but we put all the information directly in the exploit module itself if you look at most of the exploit module at least half the code is just meta information these things are only like 400-500 lines long at the most about half that is just like what the exploit is what it affects, references to it some URLs, things like that it kind of gives you some information about what the exploit actually is you can see this information with the summary option this is kind of consistent with the rest of the interfaces you don't see what options are available like if there's an advanced excuse me if there's an option for the host you're going to attack or the port you want to attack it's all done through the environment you can look at these options through that there's an advanced section etc but brief idea you put them all on the command line you went at the console with the client interface and you can script this real easy an important thing to think about is MSCLI is like I don't know 100 Bonds or something a lot of that user interface code is back in the framework and when you sort of stick code in front of it for example the console interface the majority of the code is handling nice stuff like tab completion all of the session logging and the environments are handled actually on the back end and a really user interface is independent so brief review of the console interface HD worked a lot on getting really broad tab completion so there's pretty much tab completion on everything they'll store cache of IP addresses that you've used and you can tab complete IP addresses commands payloads pretty much everything it supports session logging which is really important for people doing pen testing if you want to remember what you set your back to or your password to a couple weeks later you can go through the logs and it keeps a full time stamped record of not only the export attempts and whether those are successful or not but also the log of the data sent through our handler system so if you get a shell a log of the shell activity this is off by default by the way it's optional and well of course we'll log all of that around with time stamps and then we have a tool MSF log dump that can go through and gives you red and blue output so you can go through it after you log and if you wanted to it's all time stamped so you can go through and replay it and this is really good if you're pen testing or something and you have a customer that come back and said our system crashed at 5 o'clock you can come back and be like we owned it at 4 we were out by 4.15 so it wasn't us so I mean this is something that's definitely very valuable it has history it's read line so it's very familiar for everybody that used to bash the same library so you can do up and down for history you can do tab completion all sort of that the Metasport interface is very environment driven so we have access to complete environment for Metasaf and it's very much like you'd use to sell or something, set commands you can see the environment on set of environmental variables stuff like that Metasport interface was kind of written as a joke but it was fun enough to keep it in there essentially it starts a little built-in web server on the system and you can just bash this web interface and give you a list of all these different exploits you just kind of click along, you click the exploit and it gives you a list, okay here's what the exploit does you can click the select payload, pick whatever payload you feel like using, go to the next section where it fills in all the form values for all the options that are set and finally just hit exploit and what actually happens is it does everything that the console or the CLI would possibly do in terms of breaking into the box, connecting to whatever the payload itself was and the web server then connect into the server to the port that the shell is on, connect into it is the worst connect over and listen for the connection etc, find solve, all that same thing and what actually has a connection it then starts a separate server on the web server itself and then redrives the user's browser actually I think right now it just gives you a link to it to a telnet URL to the port itself so pretty much you just click through the web interface until it says got shell and then you click that and pops a little X term with your shell and all goes through the web server itself so you can have a single system on whatever network you're running on you can have a web interface and export every system through that box so it's kind of nice, it's kind of broke it could be written better it's probably a better way to put it but it's functional right now and we don't recommend if you use it for production environments but it's a fun thing to play with and do demos for management and whatnot this is another something you can attest to the handler system I think writing MSF web was the matter of changing one backend method to be able to do the connection proxings that are actually dropping into a shell the screen right now is actually showing an X1 encrypted shell but the telnet connection to the proxy server itself is completely protected so in other words the MSF web server handles the connection including actually encoding the data as it goes back and forth across the network and the connection back to the telnet server itself is just like being a remote console on the system so this is more of a development tool I mean it's not more of a development tool so it's something that just a user probably isn't familiar with and it's sort of the one tool that isn't really part I mean it is part of the framework but it isn't really part of a normal user's use of Metasploit what this is is if any of these have been written exploits for Windows it's very important to be able to find code in DLLs to return to and then to return into your code so this will scan PE images offline, either DLL or executable and it'll find arbitrary matches, you can do regular expressions you can then take regular expressions and pump them through a disassembler with one command line option and you can go through and build things looking for certain instructions that you want in the DLL space we use this a lot when we find some very good universal return addresses it's very easy to script, the output is pretty much universal it's very easy to parse and one example of using it this is for example the server you exploit there was something like installers from version like 3 through 5 something so we just took all the installers you can use cab extract because the installers are just cab files pull all the DLLs out of them write an FPE scan over all of them we've got output for each one then do a correlation and we had a universal return address in a matter of a few minutes and that actually ends up working for every version of server from NT through to 2003 so you can see that a tool like this is very useful the nice thing about this is you don't have to run windows at all windows process to do it so something you'll notice if you start using the framework is that none of the tools that are included really have to run windows in the first place so we really don't want to have to run windows desktop to do exploit depth or windows box and that's really why we've gone through and written our own SMD class written our own DCRPC class I'm not sure, but got it so okay and things like our decom exploit where it's actually one request that exploits and did that with the help of an MSP scan there's actually a couple other help and utilities that are included besides just the user interfaces and MSP scan we included a couple other just nifty things that we found useful at one point there's MSF DL Debug which is a tool for downloading debugging symbols for any given file so if you have a kernel 32 DLL from a system you're trying to break into and you're able to obtain the DLL from a similar system or running whatever the service pack or operating system or version of it is what MSP deal with the bug on it and it's actually down with the PVB files directly from Microsoft's symbol server and then you just do your own disassembly with the PVB files themselves so it's a nice way to be able to obtain the symbol files for any given executable that have to run a window bug or anything like that this is all done in pure pearl with the PV class part and so on and on another utility that we find pretty useful is emerald payload every single payload is included in MSP file but you can actually extract out of it if you're running something in Python or you just don't like the framework at all and you think it's crap, you can actually use MSF payload to generate payloads from it anyways so if you want to use our Linux reverse connect shell if you want to use a 132 bind shell if you just want MSF payload with red options it'll dump out a nice pretty C formatted or pearl formatted buffer for you if you want to do this through the web there's the CGI version of this you can install on your web server and just be able to go to the web site and dump payloads all day long or you need to deploy a certain slash character to your web exploit you can learn through the MSF encoder system which actually uses all the different encoders in the framework to encode in whatever way to possibly do you can specify a specific encoder if you want to or to automatically figure it out based on the bad characters and the architecture and the OSU specify for instance you say I want to avoid all moles and this character set it'll then try one of about 15 different X2D6 decoders trying to find some way to avoid that character and as each one fails it'll then fall through to the next one so it'll probably land on alpha numeric before it's finished at which point you'll have a payload which is twice the size but it's all uppercase letters and the MSF payload and MSF encode actually MSF payload won't actually do encoding but MSF payload.cgi is sort of a combination of both MSF payload and MSF encode in a web version so you can go in and you can just pick any payload that we have in Metasploit it actually just works right out of our framework build so you can say Linux bind saw code or Linux bind 4444 and it will build it optionally encoded you can just pick a bad character right there in the web interface you have a nice little blob ready to put in C code, a car, shell code so for some reason you do have to be writing exploits not in Metasploit for whatever reason you can go through here and still have advantage of using some of the payload work that we have unique to your Metasploit you want to talk about MSF update? as of version 2.2 you can actually automatically update the entire framework online because it's not just a backdoor it's a way for you to actually get latest exploits and whatnot too so if you're loving to go through and look at the code and verify things before you install it etc etc but essentially it will do it you can NB5 summon all the files to pull it against your remote version download any new files that you want and then it does it all through our own custom CA cert we actually define the open and sell search directory and do you just put everything we possibly can and pull up and verify it's really the right system similarly to that the Metasploit project would be a stable exploit development platform we've been working on it for a year and a lot of other people in the end of our work have been coming in and we've been sort of dragging people in and being like hey try to write your exploit in Metasploit and they'll come back and be like yeah that's great so we've had a lot of work and it's now a very stable exploit development platform designed to use with pen tests admins can use it to verify scan results and another thing is we're focused on technology not money we don't have customers per se so we're not worried about getting the latest and greatest exploit we're not worried about this and that we're not worried about making a great GUI that's not a main goal so right now we're working on just building a really good foundation a lot of really good backend technology and if it means working on something but we think it's more important than working on the newest greatest exploit that was just advised before then we'll probably do that now we have 17 dollars of donations for last year at Roman effort and I bought us a pizza so we're already happy with it so we have 2 dollars of donations left so there's been a lot of people working on this for about a year so if you use it or if your company uses it feel free to donate if you have a link on our website now go straight into buying another spark station do source dev or your platform of choice if you're specified in the email so the next section is exploit technology and we have a giant ninja on it so ninja yeah it's kind of squished but it's supposed to be a ninja monkey ninja got it so mostly the interesting part of the framework that I'm sure everyone's probably heard something about is the remote DOL injection this is nice and evil because it drops the DOL into the exploited process as a new thread it never touches the hard drive and if you look at the process list you're not going to see anything at all antivirus people hate us for this because they can't do any scanning of it and since there is no access to the file itself they don't seem to know and my phone is really annoying sorry okay I guess it doesn't have files to disk it was actually written by Jarco and Matt Miller Matt Miller is probably similar to this crowd so if you see him at the normally table you know say you know hey you're code locked because it says there he is got him okay the nice thing about running DOL pilots you've got full access to the winners API inside the exploited process one of the big things that Dave I tell and some of the core ST guys were talking about with the Cisco proxying code is that when you exploit a process in the windows if you just work a command shell you're throwing away half your privileges a lot of times if you exploit something like a web server or an FTP server another process that process actually has access to a lot more resources than you would have if you just execute a command shell itself in other words it probably has access to another an impersonation thread an impersonation token in one of its threads inside the primary token itself inside the primary token of the process itself and with that token you can probably gain system access or access to one of the network users in the system and if you're just executing a command shell like everyone's doing in the exploits like Decom and whatnot you're losing one of the privileges you have there so by running a DOL which takes advantage of those privileges by scanning all processes by iterating through all processes trying to open them up and grab the primary tokens and then taking over those tokens you can actually do a lot more evil things on the windows platform and you can easily convert any code that's written in C or C++ to a payload we've actually done DOL development from X main W on a Linux box and then used those payloads directly on a Windows server as the RGL payloads and you can definitely reuse existing code like the next slide is going to show you one important thing about the full access to the Windows API is instead of having to re-implement a lot of stuff in shell code or just in shell code generally when you're trying to access the Windows API it isn't necessarily the most nice thing to do it's sort of a pain to write so we have access to the full Windows API so for example, Crypto, we can just open one of the Windows Crypto libraries download a file from the web they have libraries for that, SSL Windows has libraries for a lot of things so by writing your code as a DOL you can literally write your code write in Visual Studio, compile it down to a DOL and shovel it across the network so you have access to anything you would as if you were writing applications on the Windows platform just as an executable so what's actually done using this DOL injection technology is the Windows VNC server inject it injects the VNC server as a new thread uses the existing payload connection and what doesn't require a new connection doesn't listen on a port it's based on the real VNC source code this was actually a really fast process they went out, grabbed the real VNC source code hacked that a little bit I mean it was compiling down to a DOL very quickly it's a little slow right now because of the way the hooking has to be done since the DOL isn't on disk very functional as you'll see in a few minutes and it was a pretty cool process they did some hacks for example the hijacked lock rush stations and hijacked workstations that aren't logged in this was adapted by Scape at HD they said it breaks locked desktops and it's pretty cool that you can just go out and grab an open source project and back on all of this work and make a totally red payload and we're not installing VNC it's completely never touching disk it's never leaving memory it's not creating any new process or anything the thing is we actually hit some concerns when the people who wrote it released it especially because from an antivirus perspective it's very hard without actually being inside of the process which antiviruses aren't so because it's not doing a lot of the normal things but noting the library it can actually circumvent a lot of different antivirus techniques but the thing is right now and it's actually a three stage process we have a stager, we have the VNC literature we have the VNC DLL the VNC DLL is like 400k there's a lot of clues to the architecture that comes along with it and it's all written in pearl and it's not really something that you wouldn't be able to take and stick in a worm really at all we're not too worried about that we've thought a lot about it before we released the technology and you could I guess but I don't expect to see it anytime soon at this point you don't need that much technology for a worm that's really just overhead and they have usually a small specific task that they can just write and do anyway if you look at things like the slam alarm or what not I mean it was like 400 bytes or so that was just in memory never touched a disk not the same issue which is a lot smaller if someone who's a really really bad virus wanted to write a worm and they couldn't fit it into a couple thousand bytes and they might do something like DLL injection to do it but it's really just the statement that is small enough I'm sorry did you have a question as well? I pretty much repeated the question by answering it he asked if we thought about using DLL injection for worm development so we'll go ahead and share a VNC demo right now on the screen you see the Mac we're actually going to own Windows Box from the Mac it's going to own it create a reverse connection on that connection we're going to send a VNC injection code and then the DLL and then we're going to send a local proxy on our side so then we're just going to connect a local host for a VNC client and we'll have VNC access remotely to the machine that we just owned so we're going to go ahead and demo that now and watch the desktop that the VNC server gets installed on and notice no one's logged into it and it's really funny to see what happens to this desktop after you hit it with the VNC server anyone walking at the console might be a little bit confused but just wait probably bump the font a little bit try to get the font then as you can actually see it and ignore that ok so we're just going to go ahead and start MSF console here and set up I'll narrate while HD navigates so you can just go ahead and we're going to start MSF console which is again we're going to send the VNC server to the VNC server so you can see this is the Metasport running on this side and that's the machine that's about to get owned on the left side so we're spreading the console on our face then let's go ahead and use export when you use LSS for example um it's all a little bit powerful but we have powerful support in Naver right now it's a little bit by default so it's a little bit slower so then just do like a show options show options will show the options right now everything is saved and we have options already set up and because of the environment you can see the environment today it's going to automatically fill the options back in you can see from show options you'll see all the options that are available both for the exploit and then when you set a payload the payload has its own set of options so for example on the top you have the export options and on the bottom you have the options which are specific to the VNC injection code it's a good debugging set so we're turning it off so it's a little nicer output so then you can see these are the options set up ready to go we have remote host set up we'll report that we're attacking both are the top options and then the bottom options we have the payload information the IP address that they're going to connect back to the port we're going to set the VNC listener on our side on the rule report they're going to connect back on to the VNC connection in the location of the VNC DLL so we're also going to show targets and you can see that the title list zero is automatic it will automatically detect the LSS and exploit based on the response from the SMB transaction otherwise you can manually go in and set e3 2000 XP should hopefully work automatic ok so we owned, we got the connection back we sent the DLL we sent the DLL have it worked new session here local host tada so move the command around so they can see the lagga box behind it so another cool thing is we're actually hijacking the login so if you have a non-privileged user login for example bob but you own the box and system you don't want to lose your system privileges so we open a command window over the top it runs in system so even if you're hijacking bob's desktop you still have access to system because we pop up a system command box we just go ahead open explore we can configure the server if we want but I think we'll skip that for demonstration purposes of course he's doing this for the Mac as you can see here and you can see the actual VNC so it's a demo of a VNC stuff this is all in memory nothing got real to this it's just a side of LSSS right now if you do a task list where there's no new processes it's just LSSS and then if you apply some other techniques with DLSS like anti debugging or anti paging this is really a friend's nightmare anyone walking to the console in the system is going to see a desktop on the box that's not logged in in the case that they do re-control it still works they can actually log into the box if they want to and get through in desktop and then when they switch back and log back off in the desktop there's a system again so the thing is if you actually log off from this desktop the box doesn't like it very much it doesn't really know what to do you've got a mouse and all kinds of weird flickering windows but it doesn't really know what to do with them so if you're bored it's a fun thing to play with I mean since we're doing DLSS we have a lot of access to the Windows API we're thinking about some other techniques for example like disabling the video driver actually on the hardware so you know you can see again and we can able to let this relieve something that I've found a lot of talking about is if you take a screenshot of the desktop before we install the shell on it by using the VNC's display capture then forcing that to be the display of the system that we're attacking while we're actually doing our own thing so they never notice the desktop is doing anything whatsoever but we're still in the process trying to figure out what we actually implement that and you know it's Windows API and besides just flashy demos the desktop can be very very valuable getting system isn't always what you want for example if someone is logged in with domain credentials owning system isn't going to give you those domain credentials it could lead to that by doing some stuff and hijacking a login session but with this you can just actually get the user that was logged in for example a banking scenario where you have a client who may be logged in to a domain and they're sitting there with a thick app a custom written app that they use for transactions you can just own it and get there and you can just VNC to reopen and watch it for a couple days and they can see what they do, collect the information and you can come back and have access to a lot of those things that getting a system crap just doesn't do so besides just flashy demos it has a ton of very very practical cool uses for pen tests and you know that sort of purposes any questions on this sort of stuff? what happens is that we get the initial connection back which is a stage which is about four and we send the the stage which is the VNC loader written by Matt Miller and what that does is it expects a DLL coming over the wire so that same connection we then actually just send read and send the physical DLL 100% complete we send a size first and then send the DLL to the VNC inject code then is running on the server and on the own machine and then it actually goes through and maps into memory and everything like that so that's what the VNC loader does it will actually create a new thread and start the VNC it will call the start method on the VNC and on where the DLL we're loading so we send the thread and actually start the DLL we inject the actual connection that itself uses is whatever the original connection was so if you use it with a bind shell it will then do the VNC across the same connection if user reverse shell does that as well the question was was it a new process or a new thread or it's a new thread so right now LSA SS may normally have like five threads and now it has six so we're starting a new thread inside of LSA SS we're completely inside of LSA SS right now which is used for a lot of other techniques say if you had some DLL code that could maybe get secrets out of LSA SS that's what LSA does so it may be a VNC that actually could use whatever you're exploiting for some reason so we're actually still completely in the original process we're not destroying it it's intact for the most part depending on the exploit and it's still running, it's still LSA SS one of the other DLLs we're using for testing right now we'll actually list all available processes tell you the primary token owner of that process like the user that each process associated with and give you the ability to watch a process as that user so if we inject the thread inside of LSA SS since LSA SS acts as everything including the LSA SS secrets itself and memory we can actually whip those memory secrets out dump them out to the remote attacker or we can just hijack any other process so that process can access the question was whether by exploiting LSA SS we can actually hijack and listen to all the logon requests in the system and actually yeah because LSA SS uses the DLL to actually do the password authentication we can just bypass that by patching LSA SS directly in memory or hijacking the actual NT port it uses on the underlying system to actually sniff LSA SS requests and also because this is a real DLL and it's being loaded correctly you have access to a lot of things you can import other DLLs you can access a lot of the things that are set up correctly inside of the process for you as a DLL who will do a lot of a lot of things inside the process this of course should be custom things we don't have anything, I mean other experts can be on a different process and everything can be different based on the process but you have the ability to do a lot of really cool stuff and you're writing yourself in a DLL and that's pretty much it well yeah of course but you can just own it again so yeah of course it's not we're not setting it in startup scripts we're not always starting anything like that you could of course do it if your goal is to have some sort of long-term root kit but that isn't what this is this is a temporary shell one of the only things about pentesting is if you're installing VNC server it's really annoying to have to go through and remove those files after you're done with it a lot of times because if you start the VNC server so you can't delete the files do you stop the servers again, the files are in use and there's like a billion different things that really annoy you when you're trying to install or not administering services on a compromised system with using it in a shellcode like this after you're done, after you've exited your shell that's it, there's no memory trace there's nothing left in the box that you've ever been there the nice thing about the VNC the VNC DLL payload itself is that if you don't have system access and it tries pretty hard to get system access and there's a lot more for the installation techniques in the near future it'll actually work to read only mode so if you're exploiting an IAS bug an IAS as well as an iUser account which has been impersonated from iWAM account it'll do it work itself to get iWAM user and then familiar can actually has read access to the desktop so you can't actually read the keys of the desktop if you're not assisting that but we're working in different ways to manipulate the API to get further into the system even if we're not in a system there's no place to immediately get system access or do other bad things from an iUser account we're working on another system called the interpreter which we'll talk a little bit later that's more of a complete payload solution this is just a flashy demo VNC stuff it was actually put together very quickly which goes to attest the very cool technology that it is is there any way to do this on VNC? well we're going to go to these are they could not pop up a shell the first thing we wanted to look at was getting a hidden background desktop in the system and then actually providing VNC access to that background desktop what we ran into though and what actually what Matt found out when he started investigating this stuff was that there's limitation of the window system itself you cannot read the screen of the non-interactive desktop so the only desktop you can actually read the display of is the interactive desktop and there's only one of those in the system and that's what the physical mouse and keyboard are hooked into the exception to that is terminal services but the thing is the Microsoft designed the API on purpose that way so you can't let your own access to the desktop and you can't interact with that desktop it was not the current input desktop so it drove us freakin nuts for like 3 days trying to figure out why we could not have access to this back end desktop and Matt actually wrote his own custom VNC implementation on the back end where it put bitmaps into different desktops struggling to back out and we tried pretty hard we couldn't find a way to create our own custom hidden desktop and still interact with it and owning the actual real desktop is very useful and it's a great way to do it and it's a great way to do it and it's a great way to do it the actual real desktop is very useful and something like we talked about you could for example have a module but you can see if there's any mouse movement or keystrokes or something you know and say 20 minutes right so you can say it's probably clear it owns with mouse you can go in wait and then launch VNC so you don't need to do it as the first stage and that's what the more involved systems that we'll show later are kind of designed to address next I want to talk about is the interchangeable payloads we mentioned this earlier but essentially any payload inside the framework you can put any payload you feel like putting into it in other words if for some reason you you've got a custom payload that works around the Akina system, the Cisco security agent what it happens to be or you've got a payload that does something predefined you really need just do this one thing like delete this file from the system and you don't want to do anything else you don't want to do anything you know you just want to do one specific task you can drop in a payload that does just that and additionally if you have a payload which bypasses is not yes or you're just writing a new shellcode you want to make sure it works correctly you can take your shellcode, drop it in and go this approach has given us an advantage over commercial products, core impact and immunity canvas because they really support their own payload what we really try to do is provide a way to do research and do testing of third party payloads and help with the development process in a way you can actually verify that what you're writing works because of that we actually have a lot of redundant payloads and those are actually on purpose we also do reverse connect in the state system we have ones that are actually the same payloads just written different ways I was just going to say we have an hour left so I know some people are leaving but just to make sure that people realize we do a lot of other stuff we showed some of the flashing stuff first but we'll go in depth and we have some other demos for example owning LSX which we're the first public exploits for and some other things so we're going to go ahead we hope all of those but they didn't work right so we'll go into them a little bit we'll get into the results the encrypted XOR command gels we actually took the inline egg sample provided by CORE-ST for the inline-egg Python system and took it out dropped it down to the meta-sprite and it works you do minimal modifications to get an inline egg payload , written in Python working with the meta-sprite framework in Perl there's a whole support for external payloads you can take any program that generates shellcode output and integrate it into the payload into the meta-sprite framework so if you've got a really nifty tool back on inline egg is very similar to David Tell's. Most stuff, for example, if you had some sort of most stuff build that you wanted to write, or your own payload system, or for some reason you wanted to do some sort of complication dynamic generation of shell code, it isn't written in payload and you can't or don't want to integrate it directly into Metasploit. You can just have an external program, and we actually have a class called external payload that makes it very easy to do exactly the sort of stuff that we do with inline egg. You talk about land generation. Oh, sorry. One thing that we've actually come up with over the week is sort of unique and somewhat interesting. There's a lot of exports out there that a lot of guys see to command show. And, you know, OK, great. You can run a command. What happens to be? A lot of times you can't see the output. And people have already been doing things like, you know, an X term dash display to get their shell back, or doing a, you know, a telnet pipe to bin shell, pipe to telnet again. And those are all great, but there are probably a lot of work in the user's part to set up. It's really annoying to do in the first part. What we're going to be doing is all the command exec payloads that we've included with the, excuse me, all the command execution payloads, where you're actually just injecting a command and not a shell code. We've actually created a set of command underscore payloads, not just the name of them, so we're using that terminology for that. That do things like a reverse connect, or a bind shell, or an exec v, or a lot of other little things. And they actually implement, like, telnet pipe shell, pipe telnet to be able to do a reverse connect style console, but all with a single unified console. For instance, use the source s-admin-d-exploit, including the framework. It'll actually call solar, you know, with the unix reverse generic payload. What it will do is it executes telnet to the system exporting it on the IP address in the port. Pipe, and then it calls, you know, bin shell again. And pipe telnet back to the host on the same port again. And when the MSF console sees that, it then says, okay, I've got two connections coming in. I'm going to write some data to one of them to see which end it comes out. It sees that data coming out. One of them says, okay, I know where my inputs and outputs are. And it glues those two handles together into a single unified console in front of you. So in other words, if you're explaining a system that's an IS over and you pop it to the host shell and you've got a nice console, then you do an s-admin-d-exploit, you won't notice the difference at all in the console. They work exactly the same, because the way the console's been abstracted and used. So if you've got a nice way to get any command shell back to yourself, or you want to do, like, you know, instead of telnet pipe shell, telnet, you want to do a telnet pipe shell, you know, run it through the TR command, a rock 13-year output of it. You can do that, you know, trivially, just by adding a filter to the handler side of the payload. So it's really easy to add, you know, custom command payloads, do things like PHP exploits, SQL injection exploits, things like that, in a way that actually gives the user the ability to pick different types of payloads and still integrate them with weird command injection exploits. Okay, so, yeah, this is for those bugs we're not actually executing arbitrary code, but you can somehow inject a command, for example, a lot of web bugs and stuff like this. Not just the coolness of the integration in Metasploit, but it's actually just a good resource. There was a lot of public, you know, I sat down and figured out that these are, like, you know, the great commands to run and stuff. So I actually sat down and thought a lot about how to do, you know, a good generic Unix reverse shell, you know, with pipes in common, or with a, you know, telnet and pipes and other common utilities. This is a good collection. A lot of times, you know, when people have an arbitrary, you know, command execution, they just need, like, you know, W, Garrett, Semicolon, GCC, or something. And we don't have that. I mean, even if you found a bug, you know, and so you found a bug in an ASP page or something, where you can execute a command, you can just drop it into Metasploit very easily. And then the command, you can just, you know, instead of, the command payload just returns the actual command as a payload. So then when you're putting in your payload, you actually just have this command. So it's really, really cool, actually, to be able to just take any sort of arbitrary bug and get shells back with really no work at all. One of the other annoying things you might find with command injection payloads is limited characters. For instance, you can't have a space inside your command injection payload. And, you know, not having a space in your W command kind of limits what you can W get. And as in other words, it'll just be one long command. You can use tricks like the IFS sequence part, the IFS separator dash command environment option to actually represent a space. There's a lot of tricks you can use to actually encode your command in a way that it still is actually a valid shell command but bypasses where the restrictions are. And this does it all for you, too. We've actually got a payload design explicitly for getting around spaces and slash requirements when you're exploiting bugs like the undisplosed one and a big old UnixOS we're going to release in about a month. Sorry. Slow on your advisory process. You didn't hear it here. Okay, so I guess we can just go ahead and do some payloads demos. We'll do some XOR shells. Go ahead and throw up a theory or something if you guys can actually see that it is indeed XOR. We'll do some inline egg stuff, some reverse and fine sock. And just go ahead and show you some of what that actually looks like in the wire and why that's good. So, can everybody see the output of this? Okay, I'm not sure. I'm trying to find a font that will actually work so you can see if that's big enough and also be able to type things or things scrolling off all funny. One second. Okay, so is that pretty decent? I'm not sure how the protectors are and stuff. So we're going to, for example, use the Samba trends to open bug. And you can see in the prompt we have in parentheses the payload connected, you can change the payload and that prompt will change. So then there's top options that are options specific for the exploit, for example, the root host in this case, the 192.168.50.12. Yeah, the root port, the port we're connecting back to, the XOR key in this case, because we're going to do an XOR reverse, which is actually an inline egg payload, and then the port to connect back to. So we'll go ahead and exploit this. So you can see now it's boot forcing this for one minute. Okay, so, hit it a couple times. Yeah, so we got the shell back, and usually inline egg payload, they do an interactive bash, you actually have a nice bash prompt as root. So that was all done for you. You actually see on the network wire, this is what the data is looking like, and if you're like a follow TCP session or something. But, so we'll do, you can see the XOR port, you see it's obviously fine for us. And, yeah. So this is what the TCP stream actually looks like. You can see that, you know, it's not, it's obviously isn't great security, but just for an IDS perspective and stuff. That's what we're going to show you with some of our snow, snow evasion stuff later, that a lot of firm signatures, for example, ID output and stuff like that, they will not be triggered by this. The XOR is done specific to the payload, so we're using an XOR payload. So yeah, if we wanted to use a non-XOR payload, it wouldn't be doing XORing. So, and then we also, the key was one of the options, if you looked in the payload options, you could set a different XOR key. You could set it to zero if you wanted to avoid XORing. Okay, so does anybody have any sort of questions about that? Right, well, we are working on some library injection technology for Linux. Obviously, the DLL injection is specific to Windows, and we'll be working on things like Linux that will come in the future. So, we have something you can do. You can do a lot of things. We're actually working on more complicated payload systems. You can do stuff with different helmet and then do some sort of, you know, asymmetric and then symmetric crypto. The tricky part about finding an API that we can use on the client side and the server side, that's easy to use in Perl. We don't want to have to install some random C library on the Perl side to be able to handle the encryption. And most of the Microsoft C API stuff doesn't work quite the same as open as cells. So, we're still trying to find a better way to do it. Yeah, any other questions? Transporters in the payloads? Transporters in the payloads? No, they're not actually using Talmud. No, they're not passing Talmud options. These are all just raw connections, for example, using Netcat or just a raw speed socket option. So, you're exactly using Netcat. You could use Talmud as a client, but no, it's not like Talmud supported payloads. It's not a Talmud server. So, we'll move on and do an example of a fine sock over Sama, since we already have the open. You can see that the know right now, you can see that this connection was on for three, two, one. So, it actually opened a new connection for that payload. So, now we'll just do it over the original connection. So, now we'll see that our shell will be over for 139. That's still real real right on the cells. Okay, cool. So, this exploits the Samba Trans to OpenBug in the effects of any like 2288, or excuse me, 228 and below, and it's batched by 228. And usually it goes a lot faster, but because we've enabled the Python payloads on macOS, it doesn't like cache-wide, and it kind of takes over to load up all the payloads and stuff. Usually we're disabled about default, so it goes a lot quicker when you're using it for real. And, as you can see, now in the payload options, we don't actually have a connect back IP address because we're not actually connecting back. We're reusing the existing connection. Another thing that would be important to explain,