 Okay, how about now? So okay? Okay, I realized I talk really fast, so you're allowed to throw things at me if I go too quick. So put it out there. I know I talk quickly. If you are allowed to throw things, I can dodge so quick, so you won't injure me. So that's how. Who in the audience has heard of the Metasploit projects? Awesome, great. Okay, I wasn't sure how deep to go of some things and that gives me a better sense of, you know, what I should cover, what I should not cover. Who has used Metasploit 2.6 or 2.7? Who has used Metasploit 3.0? No, it doesn't exist yet. There's some version that's not actually published. So it'll be published hopefully tomorrow. We'll see how that goes. We're still working on that. I was actually trying to do a 3.0 release for FOSDA, but between my, that was being lost for about 30 hours and, you know, other slides seem to do what didn't happen. So hopefully, this week, that 3.0 final will go out and honestly the biggest problem we ran into was the window support. It's trying to get the freaking windows users something they can use and I gotta tell you, for open source projects, if you don't support windows, you're losing out on about 98.99% of your customer base and it's ridiculous. There's some people who just will not use anything other than, you know, windows for their testing and their day-to-day stuff. So if you do an open source project, make sure you at least try to get some kind of window support. Just busy with that many more users and bugs and rewards and so on. So anyways, with that, I'll start the talk. So quick, who am I? My name is H.E. Moore. I am the founder and lead developer for the Metasploit project. I'm also a director of security research for a company called Breaking Point Systems out of Austin, Texas, where we build network testing equipment. And I'm sure most people will find it very interesting, but basically what we do is kind of Metasploit done in hardware at 10 gigabits per second with lots of crazy processors. So that's where I do it. It's my day job and it's lots of fun. It's one of the few companies I've worked for that actually support my open source projects and I'm appreciate it. So why do you care? Why should you listen to me? Yeah, we're today. Well, Metasploit 3, it's basically done. It's a tool you can actually use today. There's a whole other talk that I prepared about licensing and open source and things like that, OSI through versus non-OSI through. And I'm going to put it in the back corner. If you want to hear about that stuff and kind of why Metasploit's license has been changing, feel free to talk to me after this talk and I can give you the other presentation with my laptop personally outside of the room somewhere. But basically, most of Metasploit is still ESD license and that's the important part that we call about the Rex library, the RubyExpo library. And finally, you'll see the latest in exploit technology and kind of what we're doing with Metasploit and kind of the new shiny things you can do with the new version. So the Metasploit framework, it's an exploit development platform. And by that I mean it's actually everything you need to create, test, use, debug, and have a lot of fun with exploit code. So if you're working on new formability, or you overflow, or you exploit, or even exploiting something like a web application, you can use Metasploit to build those exploits, test it, make it reliable. And best of all, we've reduced the amount of code you have to write to write exploit code. So instead of having to do things like cover, you know, have your shell code hard coded into your exploit, or have to track what targets you've supported, or all these other things that you have to normally write as part of exploit code, we do all that for you and make your code much easier to maintain. So that's good for everybody using your code. It's good for you because you don't have to worry about maintaining your code afterwards and make sure that all the new features that go into Metasploit will be compatible with your exploit in the future. So when we add a new payload to Metasploit to say, you know, pop up Clippy on the screen and they can dance around or something like that, you're exploitable, we compatible with our dance with Clippy payload. And that's one of the benefits. The people who use Metasploit are security researchers of course, people who do exploit developments and finding vulnerabilities. It's a great platform to use because one, it's great. And two, it has a lot of code for funky protocols like DCRPC and SMD for finding vulnerabilities and testing. Anybody doing penetration testing for, you know, security on a security team inside of the company or working for a security company and testing other clients use Metasploit a lot, mostly because it has slightly different coverage from the commercial tools. We don't say we have more coverage or better coverage, you know, in some cases we do, but we have a different set of coverage. So if you use something like Core Impact, who here is familiar with Core Impact? Wow, okay. They must not have good European marketing. It's a company called Core Security Technologies and they were based in Argentina. They didn't move very quickly to the US. And some really smart guys. They got Ivan Ars and Gera and Joe Arnaud and all these really, really great hackers that get to spend all day long working on X-Words. Unfortunately, they charge something like $25,000 to see for their product. And so not many people can use their product because it costs so much. So I was actually one of the beta testers for that in 2003 and I couldn't afford Core Impact so I started working on Metasploit. So, but they're definitely the inspiration. They're their originals. They do the best job. They have had years more dumb experience than that. But unfortunately, their product only works on Windows, which is another reason why even if I could afford it, I couldn't use them because I had to run Windows. And it wasn't worth the time booting VMware just to run some pen test tool. Anyway, so security vendors are actually using Metasploit now to verify that, you know, all their security products work appropriately. So that's anybody who does, at the S moment, the traditional prevention systems. Anybody who has kind of a box that runs on the network that protects attacks coming across the network, they'll use Metasploit to verify they're just matching the text against those attacks. And that puts us in a really cool position. Since Metasploit isn't really a corporate, I mean, it's, that's a company behind it. Sorry. So, yes, just want to throw things at me when I go too fast. You can throw anything, but it will slow you down. Thank you guys. So, security vendors, anybody who makes an IPS product or an IES product, use Metasploit to verify that their blocking technology actually works. And what they came to realize is that it doesn't for most of the vendors. So they'll say, well, we have our new IPS 1000 that'll block all exploits coming into your system. And that makes for a Metasploit through it. And somehow Metasploit still gets through. And they wonder what happened. And so on our side, we make sure that no matter when a new exploit comes out, that our exploit is one reliable and two passes through both IPS systems by default. And that's good because it makes the app users work much harder to make better products. And anytime there's a new evasion technique, we can force the entire industry to upgrade their products just by putting it into Metasploit. Because now we go from, okay, here's this theoretical way to bypass an IPS to, okay, now there's 90,000 users using exploits that bypass your IPS. So it's a great way to leverage our user base as Metasploit to force IPS vendors to act responsibly and to fix really super-combalties of their products. So we see Metasploit not only as a tool for development and testing, but for also forcing the industry to produce better quality software. And we believe we do that with the security vendors right now. And of course, no script kitties. Anybody who wants to exploit lots of systems, you can use Metasploit to do that, and it's lots of fun. And eventually, those script kitties will also become people doing security testing on your network. So as annoying and stupid as they can be, you still have to be nice to them because someday they'll be the real security testers that you have to hire for insane quantities of money to do testing. So that's our user base right now. So quick history. In 2003, I created the first version, which was crap, as many people told me. And, you know, the nice thing about open source is when you release a product and you start getting feedback and everyone tells you you're stupid, they can write it better. You can call them out and say, all right, we'll do it better then. And that's what happened. A hacker by the name of Spoon and came up to me and said, your software sucks, you're doing this all wrong, you don't know what you're doing, you're a horrible developer, your stuff sucks go away. And my response is, all right, man, we'll fix it, do it better. And it's like, all right, well, I will get the ego thing there. And, you know, about six months later, we came up with 2.0, which is much better. So it worked. And mostly with me saying, hey, Spoon, your code sucks. No, it doesn't. And he doesn't better. So it's a great way to get motivation in open source communities to challenge someone's ego and say, no, I can do it better than you. And that competitiveness results in a much better quality software than because of that. That actually exploit tool was recently called a, I think it was like BFG or BFG or something like that. But basically, it was like big F exploit gun. So it was supposed to be a tool for firing off exploits. And eventually became this giant thing that is involved into only about 15 exploits, this kind of crappy curses UI on it that I really liked. And we threw that all away. And starting of course with 2.0, we created this, you know, real structure and libraries and module format and all these different things for basically making exploit going easy and non not having to have a lot of boilerplate code inside of each exploit. So the exploits could be as small as possible while still being maintainable. And one of the things that kind of made that problematic is that we decided to use Perl to do that. And if you're looking for maintainable code, I mean, as a pro developer for eight years, I can write pretty clean pro code. And I still don't recognize the hell I wrote four years ago. So we decided that when we rewrite this thing again, we're going to pick a different language that is hopefully easier to read, easier for other people to contribute to. And even if no one else likes a language, screw them, they didn't help much anyway. So that's our approach. As much as you want to have the community contribute to your software, don't make language decisions based on other people contributing to it. Pick a language you're going to be able to run with and be able to do all your development on that you like to write in, because you can't really count on that community support, especially now for large projects. That's just my experience. So for 2003 to 2006, version 2.0 kind of turned the long and we kept adding new features to it, we kept adding new things to it, and we ended kind of a couple brick walls in terms of development where we could not add a new feature because it broke something else or was really hacking how we had to do it. A good example of that is Perl's object-reaching support. I think when you use Perl's for a lot of stuff or anything serious, cool. Well, you know the problem then. It has a lot of support, just like C has a lot of support. You can make it act kind of like an object, but all you're really doing is pulling a method on a pointer when it comes down to it. And that's how it works. So we decided that, you know, Python, it looked kind of nice except for, you know, caring about white space and not really being object-oriented, even though it has methods and functions. In fact, you do length, parentheses, string, as opposed to string.length, just baubles my mind you have to do that in Python at the time. So we decided to go with Ruby. So that's what 3.0 as of now is just about 100,000 lines of Ruby. As far as you know, one of the biggest Ruby projects in existence, it just keeps growing and growing and growing. So we wrote a lot of freaking Ruby in the last two years. On top of that, we've got about 53,000 lines of Z and C plus plus. Most of that is things like our payloads, our modified version of real B and C that we use for one of the payloads. The mature payload will go into a little more in a second. And about 8,000 lines of assembly across, you know, piracy, risk, MIPS, x86, x64, all these CQ architectures we had to write different shellcode payloads in comes out to about 8,000 lines of assembly total. And those are actually written in actually we have a standard API now for our assembly and our shell codes, which makes a lot of things, a lot of the payload systems easier to use. Total modules, if you look at all the payloads, all the encoders, the knobs, the exploits, you end up coming out to about 350 unique modules right now in the public source tree. And if you pull on our private source tree, it's probably upwards of 450 or 500 now, just because we haven't finished a lot of code yet. And about two years and about three developers really kind of going full time on that. So it's a huge project and hopefully it doesn't suck and feel free to tell me who does. So why Ruby? I kind of went into this earlier, but it's clean, it's easy, it's fun, it's not stupid like Python, apologies for the Python developers, but I hate the white space in Sydney. Like I don't want to care what editor I'm using when I'm writing code, I don't want it to puke up when it sees a tab versus a space. I'm sure someone will argue it's the grade about that and what's better and what's not, but we thought this was better. The OO model is awesome. It actually is real low. You can extend unique object at runtime, including all the built-in classes. And that was huge for us because we do things like extend the string class to have new shellcode functions, things like that. And in Metasploit 2, the way that we did our payloads is we actually had, let's see, there was a child inherited from a parent and the parent randomly imported the namespace of the parent at runtime, depending on what options you have. So we basically had to keep scraping the single table in Perl, trying to hack in new features and importing classes. And we got around that Ruby by using the mix-ins support and basically not really using normal inherits, but using mix-ins and modules and some class inherits and mostly mix-ins. So it was a great way to do it. It has Ruby's threading using native. It all runs in process. Basically, Ruby is a giant select loop. And that's how it processes threads internally. And that's good and bad. It's bad because everyone plans a long, you know, block-y operation, block-roll process, and then it's all these other issues with using great threads. But it also means that anytime you use threading support at Ruby, it'll work the same like every single platform that Ruby supports. What is great for us is we try to support everything out of the sun. As of yesterday, someone actually has Metasploit 3 running on the new Nokia NE 100 platform. And they're actually owning systems with the Decom exploit with a little Nokia. So we thought that was really cool. I've got the Nokia 700, and while I can get this to work, it takes about 45 seconds to start up, and trying to type that little keyboard, I can't stand it. So the NE 100 seems a lot better. A lot of the problems on the hardware have been fixed. It's much faster. And, you know, Ruby's supported around all sorts of platforms now. The next version of Mac OS X is going to include Ruby on Rails, Windows, Ruby supports also. Installer out there is great for it. You can basically build your own custom Windows Ruby install and about five minutes with the proper compilers. And, you know, Linux supports are a dead block and works great. So this is kind of a quick diagram architecture. It's pretty similar to Metasploit 2, where you basically have three levels of libraries. At the very top, you have this Magic Rex library that's licensed in BSD. That's probably all the useful, important code is. So anything that we feel someone else should be able to reuse and we feel it's useful to another outside project, we stick into that library licensed in BSD, it's a good way to use it. Below that, we've got the MSF4 license, which provides basic things like, you know, how to encode certain types of shop code, things like that. Things that are really, naturally specific. And then finally, about the MSFB stuff, which provides basic user interface classes. In case you use kind of basic tools for creating your own exploit tools using these classes, using these libraries. And, of course, below that, we've got all the different types of modules. You've got payloads, you've got exploits and coders, no-op generators, auxiliary modules. And we'll get into those a little more simply next. And, of course, you've got tools that can tie directly into the REC layer. You've got plugins that tie directly into the MSF base layer. And you've got all these different interfaces that are tied into the framework. And it was really easy for us to add a new user interface. It's really about three lines of code to create a framework and, since, pick a module and hunt it. So if you want to build a custom tool for doing exploit development or any kind of testing, it's really, really simple. It's not very much for me at all to be able to create these new instances and do testing and, you know, script it and program it. So in Brex Library, the big things that this library accomplishes are text manipulation. When you're running exploit code, one of the most common tasks is just generating strings. It's all those buffers you send across the network that you use to, you know, trigger overflows. How many people have seen exploit code and seen this long string of A's somewhere inside the buffer? Like, just, you know, stir copy A star, mem set, mode 41 or whatever it happens to be. All these exploit developers somehow think, you know, 41 is a magic character you're supposed to use for all the exploits. And what happens when you do that is the IPS vendors and all the security vendors go back to their shop and they run a signature for your exploit as a whole bunch of A's in it too. So one of the things that we do is make sure that we never have static strings in our exploits. Every exploit is unique and beautiful like a snowflake every time we run it. So that should ensure that anybody who has a signature is looking for the vulnerability and not looking for our exploit. So sometimes hackers like to do things like put their handle in one of the strings or put their name somewhere in the exploit. And we think that's all great and all, but we don't want to make our exploit vulnerable to signatures. So we remove all those things we import into Metasploit. So when Metasploit exploit sends something on the wire, we try to keep that as bare, it as clean, as random as possible. So only the important pieces stay the same. So the text manipulation libraries and the Rex library allow you to do things like generate alphanumeric characters or generate any string within a certain character set and make it all random and clean and whatnot. And that also serves as kind of a quality assurance for all of our exploits because every time you run the exploit, the strings are all a little bit different. And so if a lot of exploit developers will create the exploit, send a static string and not realize that their shellcode just happens to work because they missed a certain character. But if you put another character into it or change the shellcode just a little bit, it would all fall over and crash. So by making everything random, every single time we run the exploit, we make it really easy to verify our exploits will work under almost all conditions. Additionally, just the text manipulation, you also have things like CPU instructions, basically how to decode instructions and generate new instructions for different platforms. So in your exploit, if you say I want to have a short jump, so I want to jump forward in my op codes by this many bytes, instead of having to write the op codes out manually, you just say I'm going to actually say a short jump, and it does it all for you. So it's just kind of nice short hand for doing assembly inside your exploits. Who here likes the way that most sockets are supported under programming languages? Yeah, that's my thought. No one really likes the mutation. The socket API doesn't really extend to how people use sockets. Everybody who writes a networking library, especially when these, it's like a string for a blog, TCP, we have multiple sediments and, you know, record can end, you know, in the middle of a segment called another record, things like that. There's really a clean way to do it. You have to create these little, you know, wow receive loops and timeouts and selects and polls, and it's just kind of a big pain in the butt for anybody who's doing socket operations. So we decided we'd like that and we created this super, you know, socket class. And this socket class supports everything from built-in SSL to being able to specify what the source port and source registers are, to actually supporting proctes built into it. It supports SOPS4 and HTTP, and they can change them to get it. So in one case, we actually tested using our socket class with 500 different proctes all on a big chain, going through like secure shell with the dash D option, going through HTTP proctes and we found the internet. And about 35 seconds later, a request actually came through from all 500 proctes. So it was awesome. It was like, so our socket class actually works and we tested the proctes support really well. So if you ever need to write a quick application that's really dirty, that does something using a socket and you want to use proctes, you can just use the rex library and it's under BSD, and it's a great tool for doing socket programming and grouping. Additionally, we support things for file formats. So if you want to generate a Windows VE image, like an EMC or DLL, you can use our library to generate those in the file, whatever code you want inside of it. So we use that for our exploit. So we can serve up a magic executable to somebody that has the shell that you selected as part of the exploit. Additionally, we allow you to read that format. So you can use things like the MSF PE scan tool to analyze the DLL or EMC and define things like version information or return addresses inside the DLL, things like that. So all the libraries for reading and writing that format are there in addition to a couple of other formats. And we plan on adding L support in the OSF, to Mongo support and so on in the feature. And finally, this is kind of the big area we put a lot of code into. All different protocols supported by the Rex library. We basically have our own Samba client reading in Ruby as part of this library. And just, I mean, I worked on this thing for probably four months just this library alone. And it's huge. You have to support everything. You have to do, the way the library is now you can actually connect to a server, authenticate using HTML2. You can list files, read them, write them, whatever you want to do. And not only can you do all these cool things with just, you know, just like Samba will support, but you really equal things to the protocol. So if we just went to the Samba library and wrote a wrapper using, like, say, Swig or something like that, you wouldn't be able to control all the specific fields inside the S&E package themselves. However, with our code, you can. You can do all these things that are broke, that should break the protocol or do really equal evasion things using our S&E library that aren't possible using HTML2 to library the client. So if you want to write any tool that talks over this protocol, you can use this library and then do it in a way that no one can really detect very well or process well and kind of slip under the radar of a lot of systems out there. The same thing applies to our DCRPC, and our RPC, and our HTTP support. These libraries are designed to give you maximum control over how the data ends up going out on a wire and be really clean and easy to use where I split developers. And in addition, these protocol stacks also support, you know, really deep evasion, built-in stuff. They allow you to do things like pad out S&E headers and do fake pipe names and, you know, all kinds of evil things inside the protocols that just made it a pain to ask anyone to really detect attacks being sent using these stacks. So those are like modules. I mean, if you look at even these projects out there that support dynamic modules, everyone has a different format for it. Half the folks use like little xml file, the others use, you know, some Ruby file or some Perl file or some other kind of standalone little script. We decided that a module should just be a simple Ruby class. So every module is part of the pedestal whether it's a payload or an exploit or not a module has a unique class somewhere. It's under some namespace. And right now it's based on the directory structure and you use that to determine when a module is loaded and so on. Every module has a set of metadata information that is, you know, standard across all modules. So every module has a license field. We can tell you what every single module in the framework is licensed under with one query script. We can also tell you who wrote that module and, you know, when it was written and what the revision number is, all these different things should be trapped, descriptions and so on. And that makes it easy to work with these things and easy for us to load new ones and track them and so on. Each module type exposes different methods and there's a method based on which class, which module class, and how it's done. So exploit track one way payload track another way and so on. And we expect certain methods to be there for certain types of modules. So exploits, exploits are simple. They're just a standard module that inherits from an MSF exploit class. They use really heavy use of Ruby mixings. So your exploit will inherit from the basic exploit class. Then I'll say, I'm an exploit but I also want to use the TCP protocol. What happens is all you have to do is include the, I think it's MSF exploit remote TCP class. And all of a sudden your exploit now has all these new options. Those options are things like, what is the report that I talked to? Should I use SSL? Should I use proxies? Should I send my data really slowly across the node and little tiny bits? Should I send it normally and fast? Everything that protocol will support automatically gets loaded into your module. This will then include mine. So you don't have to say that your exploit needs a remote port to talk to you. That's already handled just by including that mixin. The same thing applies for things like UDP and SMD and ATTP. Anytime we say, I'm going to talk in this protocol, it includes all the different fancy version options for you automatically. So your exploit code doesn't have to know about any of these new evasion methods. It doesn't have to know whether our socket class supports this kind of proxy or that kind of proxy. It's all done for you just by including our mixins and they do the rest of the work. Mixin' the skeleton to find how that exploit itself functions. You can have an active exploit, which is a normal standard. I'm going to run my exploit. It's going to go right into something and give me a shell. It's kind of serial straight forward. Go do this, doc. You can also have passive exploits. These are exploits that kind of listen for something, maybe. An example would be something exploiting the Microsoft WMF vulnerability. It'll listen for connections and anytime a web browser connects to it, it'll serve up an exploit page for that client and then they keep going. So in that case, as each new client connects to the exploit and does something with it, we'll keep getting command shells and just popping in the backpack. So you just kick that exploit off the background and just watch all the command shells pour in, interact with the ones you want to and kill the ones you don't and so on. So it's kind of a, when you're doing massive exploitation of a huge network, this lets you kind of manage and trap all your exploits in your shells much easier than you have for your normal name. You can also do things like brute force. So we have a mixin' that's basically called brute force and, you know, virgin air. But that says, instead of calling the exploit function in your module, we call it exploit underscore target function. What that does is, every time that includes, excuse me, when you include that mixin' in three new options are available. That's the return address, the how far to step between each one, basically the start address or stop address and what offset to step between them. And your exploits function will be called once for every offset between those things until a shell appears. So it automates building brute force exploits. All you have to do is create a little sublet code that says exploit target and do your exploit for that target and you can handle everything else for you. So it's just a quick way to build common types of exploits and reduce the amount of code you have to write as a developer to make your exploits work right. Finally, we started adding a different kind of protocol and stack support. So recently, does anyone remember that we added a wireless support or saw our wireless support stuff in metasoy three? Okay, well, basically this library called Vorkon and it was written by the guy who knows Kizmet and then in front of it, which is Josh Wright. And that library is really cool and that no matter what type of wireless part you have in your system in Linux, it'll give you a way to do raw Eater 2.11 transmits out of it. And all kinds of cool exploits become possible and you can send raw Eater 2.11 frames. You can do things like send fake, you can request and send fake Chrome responses. And during the month of Colonel Bucks project that I was helping out with, we found something like 20 or 30 different wireless card vulnerabilities just by running really boring groupie fuzzers we wrote in metasoy for this thing. And as an example, I went to the local electronics store and I spent way too much money and basically bought like 15 or 20 little USB cards and took them home and just put them one after another this poor little windows laptop I had sitting there and then running the fuzz around until I got a shell and out of those like 20 cards I bought I probably have exploits working for about half of them now. And I actually then went back and returned old cards out of money on it and I got working exploits for all these consumer cards. So that was our methodology for that. We go out, buy a bunch of cards, test them, buy their exploits and then get our money back by returning them home. And you can do that forever. So that's actually once a month I'll do a couple more wireless cards because there's so many vendors and there's so many different drivers and they're all broken as hell so it's easy to just keep doing that. And what we noticed is that wireless card vendors don't really provide updated drivers for old equipment. So they'll release one driver for one car and that's it. They never touch that driver ever again unless a bolt comes down from the sky and lets you use them. Like there's no reason to come back and look at it. So if you bought a certain model of a wireless card and you plug it in your Windows computer, you are exploitable no matter what now it's limited time to remove that card. And even better, if you decide, well I'm a cool Linux guy and I'm gonna run it on my laptop but crap, there's no business driver. How long do you use Indisk wrap up? Because that's really cool. Well guess what? The driver is still running on your laptop on your kernel as Linux and it's still exploitable. So if you're using any of those Indisk wrapper wireless drivers more than likely your system is exploitable using the stock Metasploit fuzzer. So anyway, just kind of a fun aside from doing the wifi stuff is that most of the folks who thought they were doing great because they use Linux are still exploitable because they're still using Indisk wrapper and actually a Windows driver in their Linux kernel. We're also putting out a Bluetooth support to exploit some of those vulnerabilities and we do have a PCAP module that's actually based on the real Ruby PCAP but it's less stupid. It decodes 8 into 11, things like that. Oh and those extensions, the lowercon, the Bluetooth and the PCAP are all GPL licensed because that's what the dependent code is licensed as. So here's an example of an FTP exploit in Metasploit. Now this module would say I wanna include the FTP exploit class and this is all the code for actually running the exploit. That's all there is to it. So it's pretty small. Sure it takes about five minutes to write that and then test it and make sure it works but that's basically all there is to it. The first line, just connect. That means whatever my module is doing, connect to whatever the service is supposed to be. In the case of FTP, it's gonna say I want a remote port and that port's gonna default to 21. So if you're testing a remote FTP server, that all works for you. And if something goes wrong and that tech fails, Ruby's gonna throw an exception which will cause exploit to exit out and it's all handled, excuse me, cleanly. The next line's pretty obvious, just print out what target we're trying to exploit based on what target the user selected. The next line where it's buff and go rep to text. That just means generate some big buffer of 1,816 characters and stick it into this buffer. So that's straightforward. The next line uses the generate seh payload function and on Windows if you're exploiting an seh pointer override, which is a really standard thing on Windows. Most buffer proposals on Windows are actually seh overrides, not return habits overrides. And a lot of folks don't realize that, that's why Windows exploits are so damn easy. It's because seh is cool, it's like the global error handler for your application. When something goes wrong, that pointer is all g and called. So you can exploit something like a men copy, des, commasores, comma, negative one, which comes out to trying to copy four gigabytes of data and you can still exploit that in Windows because of the way seh is handled. But that's much deeper talk. Basically this seh routine will generate a short jump in assembly followed by a return address, followed by your payload, all at once and all done for you. And then we stick that payload, we stick that seh frame and that payload into the buffer and then we send it with user command below that. And then we call the handler and then we disconnect. And that send command function will go do all sorts of different things with that command. So if you say I want to do FTP invasion using tunnel and op codes, it'll take that user command and then use your space in that buffer. But for every single byte of that buffer, it'll also do ASCII, FF and then some random byte, which FTP server will likely ignore. So the buffer becomes you know, instead of 1,816 bytes, that means it's becoming double or triple from all the different invasion op codes put into it. So all the different ideas of invasion techniques are automatically done for you just by calling the code this way. And of course handler, if you're doing like a fine soft payload, you need this handler called there to find the shell on the socket and so on. But that's all pretty straightforward. So the method of play payloads, it's the same thing. It's just a different class from here that it's slightly different methods and there's three different types. You've got singles, you've got stages and you've got stages. So a single, just some payload that is a big buffer of data that gets processed in payload. That could be your standard, you know, bin shell, that could be your standard windows, bin shell, whatever you want it to be. It's a big block of assembly that is sent over as part of the shell code. Stager is just the first part of it. It's just not to be able to get connection back to the attacking system and then send the rest of the code over. And the stage is the code you actually send over when the connection is established. So we have kind of the standalone version, the first part that is the connection back to us or the connection to us to them and then we have the actual code we want to run. And what happens when you start a meta-sploit is it automatically cross-references all the stages with all the stages. So if you come up with a new little assembly stage that's something really cool and evil, like let's say disable the windows firewall, all you have to do is add a new stage model and you'll automatically get, you know, 50 new exploits depending on all the different stages. So no cross-reference or automatically a very compatible type of stager to make it available to the user. So it's a really clean way to do shell code development when there's a standard API and so on. In addition to the standard, you know, command shells and so on, we have DLL injection, which is really neat. We actually, when you're exploiting a windows vulnerability, we can tell you to, we can allow you to inject arbitrary DLL into memory, never touching the disk, and run that DLL like a shell code. So if you're a really like, you know, cool, happening, visual-basic developer and you want to write you some shell code, you can do that. You can go write yourselves a visual-basic shell code and use it with Metasploit if you really want to. And we promise not to laugh too much when you tell us about it. You can also do any language that you can write a DLL in, you can use as a payload now with Metasploit. And it's all standardized and easy to do and there's a generic payload for injecting your own DLLs and so on. We also support things which are kind of non-standard payloads. For instance, like PhD payloads and command shell payloads. So for instance, let's say you've got a vulnerability in a CGI script and it allows you to inject a command into a parameter. So let's say it's like a pearl of vulnerability or a meta-character of state vulnerability, something like that, where you put the command you want to run to URL and it doesn't run inside. Well, we'll give you different types of payloads. And those payloads do things like bind a command shell, do a reverse connect shell and so on. And the way it actually does it depends on what system you're exploiting. So let's say you're exploiting a unit system and you use the unit to reverse shell payload. What it actually does on the server side is it runs telnet to your host and your port and then pipe and then mid-shell. And then pipe, telnet, your host and your port again. And on the meta-split side, we'll set both of those connections to the server. We'll glue them together into a console and let the user type on it just like it's a regular old shell. But it's completely transparent to the user that there's really two different T-Sync connections coming back instead of one. And for things like bind shells, we'll do things like we just run the pearl of the background and that creates the bind shell. So we use all the features available in the library system to create these kind of payload-like commands that you can use as generic payloads or anything else. So there's actually a new virtual payload that's kind of generic, that's called bind shell. And no matter what example you pick and use that payload, it will automatically select the compatible bind-like shell payload, including the command ones and the PhD ones and so on. The Windows payloads have kind of a standard calling convention. So if you want to write your own codes if you're right with ours and work with them, you can basically double the source and create your own payload really easily. One of the payloads we have is the in-memory DNC server. So we took the real DNC source code, we modified it so that it only runs in polling mode. It doesn't hold anything or load events. We made it a single DLL to put the stand alone. And if you use this as your payload, what happens is, let's say you're exploiting with a decon vulnerability and you want to use the bind shell connection to get your payload across. So you connect port 135, you send your equal DCR proceed packet, and then that opens up a listing shell on the server. And then that exploit catch that shell, does a negotiation, sends in the entire DLL of when DNC across, and checks that DNC DLL directly to memory on the service mode process, never running to disk, never showing anywhere else in the system, and uses that existing connection to do DNC across that connection. It doesn't create a new DNC server connection anywhere. And what happens is on the metasploit side, it creates a new listener and then binds the current connection to the server for the payload to a local listener and then runs DNC viewer to connect back to itself. So long story short, what happens is you set the payload, you run it, and five seconds later, you're looking at your desktop and moving the mouse around. So it's a really cool demo. I'll do that in a couple of minutes while I'll demo that just as kind of an example. Another type of demo we use that's based on the DLL injection is pass it X. And has anyone heard that before? Okay, so we use this great thing called Internet Explorer to do all of our payload handling for us. So let's say you're exporting a system behind a firewall and that system can't connect back to directly. It can only go through a proxy. And that proxy let's say it has a password. The password is the domain credential of that user inside of Windows. So what we do instead is we create a payload that modifies the registry, removes all of the Internet Explorer security, not that there's much to start with, but we clean up the remainder, and we start the Internet Explorer and we point it at our own system that's running Metasploit. Now it connects to us and we give it an ActiveX control. And it says yes, run my ActiveX control and then it does that. So then it starts running ActiveX and then that ActiveX control crotches a t-speak connection across get and post request back to our own web server. And because we're using Internet Explorer, it reads the user's registry and uses their cached password to connect back to us because we're on proxy. And so even though they're going through authenticated ISA proxy or Microsoft proxy server, even though they don't have direct access to the Internet, we're able to get a remote working command shell or remote working VMT desktop via post to get request over this ActiveX control through Internet Explorer. So that just kind of gives you the complexity that we go into with DLL injection and transport mechanisms and so on. And that was a whole lot of fun to play with. Unfortunately it doesn't work in Internet Explorer five or seven. So unless you're using IE six, it's not gonna work too well. We're working on improving that for IE seven and porting it forward, but we have to have six more registry added to make it work and it makes the code much better. And finally there's the interpreter. Has anyone heard of the interpreter before? Oh, you're not. This is like the coolest windows payload in existence ever. So the interpreter sounds dynamically sensible payload. So we inject this DLL which has its own communications protocol, supports native transport encryption and allows you to load new extensions on the fly remotely through the connection to the server. So you can create your own DLL extensions to do anything you wanna do in Windows as long as they conform to our API and interact them on the fly. We came up with a standard API extension that has all the features you only need for a pentest. And that's actually the PS command, kill, LS, make, dirt, upload, download, execute, interact, all sorts of features. Basically almost everything you can do for a unit shell, you can now do two windows through this payload connection that's written as a DLL. And the nice thing about that is you can create your own extensions, create your own improvements to this thing and build them on the fly. One of the new features is the migrate commands. That'll actually take your current exploit inside whatever, excuse me, your current shell wherever that's running inside any process you have to exploit and move it into another process on the system. And let's say the administrator sees you inside one process like, hey, why is my internet explorer process connecting back to my server? Then they try to kill the internet explorer. Well, guess what? You're still connected. You just hop around to a different process. So it's kind of like a shell-loaded backbone where every time they try to kill you, you pop into a different process on the system. And we're working on a concept now where we inject ourselves with three different processes and we all watch. And anyone who dies, we lend to new processes and jump into that one. So you can actually do the wonderful Windows API and the, what's it called? Duplicate handle call. We can keep the same existence. He speaks action to our payload and just keep bouncing your processes in the same system. So no matter what process you kill, we still have a connection. We never interrupt it. And we actually keep our state as we move around inside other processes. So it's a really neat way to kind of like, laugh at the administrator for a couple of hours. Granted, if you reboot your system and kick you out, then you just break in again and do it all over again until they run away. So, the interpreter has this really nice API that allows you to basically drop to a Ruby problem to any point and start calling the API directly. Or you can load new scripts into the system. And we have scripts that are already pre-made to do things like go through every process in the system compared to unknown antivirus and kill it. And every firewall can kill it. And every other kind of security software can kill it and does it all for you. So you just say, I don't want to be an antivirus. Thank you. And it goes through and removes them all from the system. And it's all scripted and automatic. If you use the Ruby API for this, you can actually hear a very hard drive from the server and about, you know, it takes a lot of the do, but you can do it all in one command line, basically. We say, give me the entire C drive that the system I just broke into and copy it over here. Okay, thanks, bye. That's it. So something I haven't really talked about much yet is the Auxiliary Model Support Metasploit 3. There's all these cool types of attacks that aren't really your standard exploits. There are attacks that don't really take a payload that give you administrative access, that do trigger a general service bug or a protocol buzzer of some sort. And we need to some way to include these. We came from a new module called the Auxiliary where it's basically anything you want it to be. It's a generic way to add cool code to the Metasploit. And that's probably where most of our contributions come from now. Is anybody who has a cool hack or a cool technique that can add it to this type of module and it will take it no matter what the hell it does, as long as you're really thinking. So I won't go into it too much, but that's kind of it. With the current version of Metasploit 3, we've got four different UIs. There's the console, which is really the way to use the system. I'll demo that in a second. There's the command line interface, which is good for scripting, font jobs, and any kind of mayhem you want to do is by running through some command line. There's the web server interface, which is actually rooming on rails with Metasploit inside. So it's really neat, I'll show you a demo of that. And we're also working on the new GUI for that, which is GTK2 based, and it's being led by a French developer who has been kicking ass on it, and hopefully we'll be done the next month. I'm going to skip through some of these things. Basically, we have it in a net framework that's really cool where you can hook different operations, and automatically do things, and certain things happen. You can create plugins that hook you to the system that automatically add new features and integrate other tools with the system. And quick summary of that, we'll go to the devos. Advanced exploit framework, you can do just like me, you want to do with exploits using our toolkit. It's really simple to use, and hopefully we'll have 3.0 out next week. And if you want to get a copy of this right now, we've got a shiny new website up, which is framework.metasploit.com, you can grab the latest code and documentation for 3.0 there. And that will have major updates done to it the next week. And time for devos, and probably questions pretty soon. So over here, we have a poor little VMware system, running Windows 2000 Superstack 4, and it has a nice happy flower background. It doesn't know what's about to hit it, so I'll tell you yet. GTK2, have a little desktop, and we'll go back over here, and then we load a metasploit console, and you wait, because it's 100,000 months ruby, and it takes a while to load. Sorry. There we go. So as you can see, we have 186 exploits, 104 payloads. So all kinds of crap. And the console has complete tab completion. So once you get good with the console, you can do just about anything and about 14 strokes. So let's say I want to say I want to exploit one of the SMD vulnerabilities on that target system. So use XP, tab, exploits, Windows. Here's my SMD exploits. Now I want MSL5, P&D. Okay, here's my exploit. What kind of exploits is this? So we've got a bunch of targets. You know, I wrote this exploit, front-mended too. It's different options and so on. We're gonna use regular Windows command shell. Shell, and I want to create a mind shell, and use TCP. Then I want to show my options again. Now, okay, I need to set the R-host variable, which is what target to exploit, and then I need to set the L-port variable and I need to set the R-port on use. And then keep off 40, 444, which was my favorite port until last time I stole my shell code and now it's blocked everywhere. So we've got to change something else. We'll never get that, all right. Save for integration, protect exploit, I'm sorry, we've got to set the R-host. Our target system's running it. You know, the private VMware address. Do do do, command shell. So it was not very exciting. It goes through the game. And since our exploits are cool, you can keep running them, and again and again. And you can background or exploit. And then you can look at the sessions of the backgrounds and then interrupt one, get yourself back again. So you can then kill it. And now instead of that really boring panel, let's use the VNT injection, it's a plus upon. And we use my shell again to transport the DLO and we use a different port for it. And we run the exploit again. And now we're just going to sit back, wait for the DLO to upload and VNT to start. There we go. We've got the VNT exploit. Even if nobody's logged into the system, this command shell will still show up. Even if you're at the please log in prompt. And if you're at the please log in prompt and this blue Metasploit courtesy shell pops up, you can type explorer by VNT, and it will start an entire desktop on the login screen. So someone locks their screen and they walk away. And then they come back to their system and all of a sudden there's this command shell and all kinds of crap going on and they never even logged in. And the funny thing is they can still control, delete and then log in and they go to their real desktop. And when they log out, they go out to your desktop. So it's fun to mess with admins behind this way. So this is one of the fun exploits. And now we're going to try to get it. This time we're going to use the interpreter fail, which is a fancy do-everything one. So Windows interpreter finds speed to the ports. And that's really how easy it is to use. There's no tricks to that. That was start, go, run, exploit done. It's really about 10 seconds once you get past it. So now we're going to run the interpreter. Wait for top load. And now we have a new shell of new fancy commands. This is things like, you know, interact with the channels, edit stuff, download stuff, et cetera. So if you ever wanted to run VI out of a system, a Windows system, you can now do that through interpreter. Actually when my little sister's computer breaks down, I send her an executable interpreter inside of it and I use that to fix her system. Because it's no better than anything else out there. So let's say I want to modify the boot.ini file. I just edit boot.ini, it downloads a copy, brings to my local system, opens up my editor, based on my editor path. Let's me, you know, change everything I want to the system, editor, you know, hello, and then I save it and it fails because I suck. You know, there's probably a bug there. But normally it saves it, uploads again to the system and then, you know, you're done. You can just kind of edit files like you're on a regular shell in Windows. So anyway, this is the interface. There's also a couple of cool commands like idle time. It'll tell you how long the system's been idle. So you can wait until the administrator goes away and gets coffee before we start tearing apart the system. So now we see he's been gone for one minute, 27 seconds. And you can also see things like the UI Ctl command, which will actually lock the administrator's keyboard and mouse out. So you can say, sorry, my system now, don't touch it. And you keep it up completely and just take it all over. So, hey, that's the console. It's really easy to use. I won't do too many other demos to that, but I want to show one more thing. So just type NSF web and you need to have all the Rails stuff installed for Ruby on Rails. And we decided it was a really easy, quick way to basically bootstrap this thing and get it going. So this creates a new web server on port 55555 and localhost. Wait for Mozilla and start it up. So this is it. We have a nice console, we've got these new options. You click on exploits and you have a little AJAX search form, so you can say, I want to exploit with decon vulnerability, so, ah, can't type. So, decon, yes, decon, thank you. And bring up this exploit and you can say, okay, here's some information about it. I want to use this target. My subscriptions, let's see, where's the interpreter? Here we go, interpreter, find. And then we have all the options for running that exploit and doing everything here. And you can launch the exploit if you want to. One of the problems you're meant to when doing the metasploit on Windows is that the standard IO on Windows can't do a select them. There's no way to do a non-blocking pull of standard IO on Windows without using SIGWIN, without using these really cryptic Microsoft APIs that really don't work right. So we decided it's true. Windows users don't get a fancy console. They want type completion, they gotta use the webinar fix. So that means we had to write the type completion console for webinar fix. So now we have it. So you can open a bunch of consoles. Each one actually works fine. You can do full type completion, the Ajax. So exploit, Windows, TAB, you know, DCRPC, TAB, TAB, TAB, all that stuff. So let's do it again. Now let's use the net API exploit, which is, let's say it's 640. See, change their fonts. We set ROs to be 172.16, 233, or 28. We see what it looks like with this exploit. Oh, a lot of them. But we can use a regular bind shell here. So we do Windows slash shell, bind, and it all automatically just like a window console. And it's all done via fancy Ajax and JavaScript and all that. Now we just want our exploit to look normal. And we have a regular command model. Just do the webinar fix. And it's a little bit slower, it's a little bit too long because we're real soft, basically. And Web Brick has major problems with concurrency and multiple threads. But one of the new things about this is you can actually detach a console here and instead of running the web server on 127.001, we've opened up to the world, all your buddies can come into your system and exploit the crap out of something and share your shells. So let's say I'm my buddy and I come by and I click on sessions. It's like, oh look, I want to play with this command shell that my buddy already got. So there we go, we have the shell. And when we're done, we can detach it and let's solo play it. And you can actually forcefully detach them and share them, and everything you can probably expect from that. That's about all there is to the web interface and most of the talk. Any questions? Yes, sir. So the question was, do we have many exploits for Vista? And the answer is we've reported a bunch of vulnerabilities in it, we're waiting to see when they're gonna be fixed and then we might release our exploits for it. So yes, we have exploits for Vista, but they're not public yet. So Vista isn't really that much different, especially when it comes to keep filling exploits where you don't have the guest address, you can basically just pull it to memory and jump into it. It's pretty straightforward, there's really no difference. Yes, sir? So the question was, do we audit our contributing code to make sure it doesn't have backdoors and things like that in it? And yes, we do. Most of our contributors have to supply patches to us for about four and a half months before they ever get CVS access. And at that point, we usually know their full name, where they live, their social security number. So if they try to screw with us, we will go get them. So I'll put it that way. Yes, we're really careful about that because we have something like 90,000 users updating medicine every single month for a web server and it would be a real shame if someone's backdoor or update repository and owned all those government clients that blindly update every night. So, yes. Yes, sir? The question was, doesn't Vista have ESLR, address-based layout randomization? Yes, it does. But the addresses we care about are the DLLs and executable addresses, which are only randomized by eight bits. So it's only 256 possible values for DLL and only, every time the system boots the randomized and all applications have the same address. So if you can find a way to leak an address from one application, you can then use that to exploit another application after you know where that DLL lives. And the NetBIOS protocol via the SME service, the WinService and many other services will leak through the addresses of in-memory addresses. So there's ways to leak the addresses and use those to exploit it. So yes, it does make your exploits harder to make them reliable, but it doesn't really make much impact on exploiting them in the first place. You can still do it if you know where to go. So given an arbitrary statement that accepts connections and has some kind of service, is there a methodology for testing that service to find vulnerabilities? And there's a lot of them. There's no real way to say one's better than another. My personal method is I'll open up the executable itself or look at the source code and kind of get a feel for how it works and look at it with like add-and-pro or another disability tool and look at, kind of starting at the receipt function, see how it processes data, and then I'll go out a little quick fuzzer for that at Ruby or something that sends bad data and trying to see where it ends up and what it does. But I'm probably not the best vulnerability finder out there, but I find enough to write lots of exploits. The target machine, it was a patch. No, it was Windows 1000, SPS4 and that was it. It was supposed to be wide open, just for the demos. So how easy would it be to build scan tools in the Metasploit? And we already have some available. They go into the auxiliary directory. So the auxiliary modules do things like discovery, port scanning, fingerprinting. So any kind of, you can make a message out of Metasploit if you want to, just by adding that discovery module to it. So do we have any op codes or additions we can use for non-Windows versions? Yes, we just started adding them. The problem is there's so much data. Our database basically grows by a factor of like 10 by importing all these international versions. And although it's easy for us to get additions for all the different service packs between download those, getting the original OEM install of a given operating system is difficult for us because we don't have the media. So at some point we may ask for donations, people send them all in, but if Vista and everything else is randomized, the additions, they become less useful. So that's it. There's a question up here that's been waiting. Yes, sir? Has Metasploit ever been successfully used against my own systems? Actually, Metasploit was used to get sneak on one of my own systems, but luckily it was from a friend of mine. He found a way to take the public MSF web demo, we run on metasploit.com and bypass the safe mode and run exploits from our server. And using those exploits, so some of our payloads allow you to do things like upload files to a server that you broke into. And so he set up a fake target, used our Metasploit to break into his target and uploaded local files from our server to his remote system via meterpreter. So, great. Luckily he's a friend of mine and that was a Dino Diozoli who works for a Modesano and a really nice guy and he didn't own the crap, but it was too bad. Yes, we learned our lesson. So, yes, it has happened. Yes, sir? So the question was, have we tried Metasploit against a well-known IPS product? How did that rate? Probably that question is, that's what I did for work. And so all of my testing is actually against real IPS for them giving to us live vendors. So I can't tell you too much about how well they work. What I can tell you is about a year ago before I started that job, most IPS products would allow most exploits through with minor changes. And out of the last year, they've been proving them a whole lot, but the number I can give you is if you look at all the top IPS products, you look at our current exploits said, and if you do enough evasions using the features available without having to add a new code whatsoever, you can basically get everything, but 5% of the exploits there. So 95% bypass rate with all the popular IPS products. So the question is, how many exploits are for non-vendors? Unfortunately, that number is really small now because I have to finish reporting a whole bunch of units once. I think there's probably 30 or 40. And it's gonna get better. The web applications alone are gonna skyrocket the number. And I don't really wanna count those because all those needs to be home abilities, there's like thousands of them. But we plan on getting, I've got a whole test lab with Iorix and Iorix, Solaris, AIX, Hbox, so we need to finish running our exploits for those. The problem is that most of them, there isn't much demand anymore. Most systems people are doing pent-ups against are Windows-based, and no one really cares if you open an Hbox exploit for Samba. So that's really, it's mostly in motivation, like people will say, do you have an exploit for this, and this is rarely not on Windows system. So we wanna increase that because it sucks being all these Windows exploits on a unit of stool, but that's what people have been asking for. Okay, we're time for one more. The question is, are we dealing with, do we write exploits and support systems that aren't well known? Things like, was it an i5? Or you know, ES100, things like that. And the response is, if we have a system to test, if we have a way to write exploits, we'll do anything we can for it. It's been a question of really just, do we have time to move the equipment? If someone sends us an exploit for ES100 to bypass, you know, telenoid authentication, or an exploit for open VMS, we definitely take it. However, when you start getting to the buffer flows, things like that, before we can really support new platform architecture, we need to have encoders, we need to have knobs, we need to have all these other things need to be finished and done that really make it a lot more work to support a platform than is usually apparent. And I think that's all time for questions. Thank you again, great audience. Appreciate it. Thank you.