Welcome back everyone. This is The Changelog and I'm your host, Adam Stachowiak. This is episode 174, talking Metasploit today with Trevor Rosen and James Egypt Lee. These are the guys behind Metasploit, which is the world's most used penetration testing software.
Great show today. We had four awesome sponsors, Codeship, TopTile, Harvest and Transloadit. Our first sponsor is Codeship. Codeship launched a brand new feature called Organizations a few months back.
Everyone's been loving it. Now you can create teams, you can set permissions for your specific team members and you can improve collaboration in your continuous delivery workflows. You can maintain your centralized control over your entire organization's projects and teams with this new feature. It's super awesome.
And you can save 20% off any premium plan you choose for three months by using our code, the changelog podcast. Again, that code is the changelog podcast, 20% off any plan you choose for three months. Head to codeship.com slash the changelog to get started. And one more thing I want to tell you about.
Sean Devine is doing an API workshop called API First Training. And guess what? He's going to use Codeship as a demo tool. The URL to learn more about that API training is in our show notes.
So check those out. But now on to the show. Welcome back, everyone. Jared here.
Today, I'm joined by two interesting guys. This is Trevor Rosen and James Egypt Lee, two of the people behind the Metasploit project, which is the world's most used penetration testing software. Trevor, Egypt, welcome to the show. Thanks.
Thanks for having us. So we're here to talk Metasploit. We're here to talk Infosec. We're here to talk open source.
Lots of interesting topics out there. But first, let's let the audience get to know you guys a little bit. And Trevor, I'll start with you because we met at GopherCon, which is a bit of a theme lately. I feel like that conference was quite a boon to our podcast because we lined up a lot of new friends and a lot of guests for the show.
Yeah, I can imagine. It was a great con. It was one of my all-time favorite cons that I went to. So my name is Trevor Rosen.
I work at Rapid7 on Metasploit as the leader of the architecture team, which is a small team, kind of mostly software-oriented people who work all different areas of the Metasploit framework and the Metasploit commercial applications. So Metasploit framework is this sort of famous thing in the information security world. It's been around for a little over 10 years, and it exists basically to help you help penetration testers, which is like kind of good guy hackers, good person hackers, I should say, white hats, help determine what an organization's level of exposure is to security threats. And so I get to work in all different areas of our stacks on all sorts of fun open source stuff, mostly Ruby software and quite a bit of stuff in the Rails ecosystem.
And I'm not really a full-time security person in that I don't do security research really, but I definitely have a lot of fun working on open source. And I'm a big fan of what open source can be for the security world. I feel like it's really vital. So did you, were you always in security side of things or did you start off as a programmer?
What's kind of your background? Yeah, background is mostly software. I've done a bunch of different startups and things. I always kind of had a soft spot for security though.
I was the guy on the team that was like, you know, in mapping everything on our production boxes and finding open ports and, you know, haranguing ops guys about that or, or, you know, trying to hack my dev environment. Yeah, for sure. Yeah. And then, I mean, back in the day as a kid, I may or may not have built some hardware that wasn't a hundred percent legal.
But yeah, these days, mostly sort of, I would say I fall into the maker side of things. And I mean, by that, not like make magazine, but sort of like security, the security software world kind of has people who are interested in sort of breaking stuff and hacking it and figuring out how to make it do something crazier or weird. And then people who are much more interested in sort of just making good software. So that's really where I, I guess I put myself as kind of more on the maker end of the spectrum.
That's an interesting way to put it because I, I came to a similar conclusion as I was telling you in the pre-call, I do have a bit of a security background, a study information assurance as a concentration in college and was doing penetration testing and mapping and stuff like crazy, which was like one of my favorite things to do. But I too kind of, I found myself after that deciding I'd rather create things than tear them down. I also wasn't that good at it. I don't have that like mindset.
I'm sure you guys are well aware. And Egypt, maybe you're one of these kind of people where like you can just find a way to break everything. I was like, okay at it, but I didn't have like that, that intuition that some folks have. And I do like creating, so I can kind of relate with you a little bit there.
Let's move on to James, who I've been told not to call that. I've been called the name's Egypt. But James Egypt Lee, you want to go ahead and introduce yourself to the crowd? Yeah, I'm Egypt pretty much everywhere.
And I'm Egypt on Twitter, et cetera. I'm the Metasploit community manager here at Rapid7. And that means that I'm writing a lot more emails than code these days, at least the last couple of months. But I'm sort of involved in, in open source contributions and getting people interested in the project as well as fixing the old bugs in code that no one else has looked at in years.
So I started with the project in roughly 2006. I started using it professionally as the thing I was writing my exploits in working as a security researcher. And I found bugs and problems and things that just didn't work the way I wanted them to. So I started submitting patches.
And around 2008, HD Moore, the founder of the project, decided that it was easier to give me commit access than to keep taking all my patches all the time. So in 2008, I got commit access to the then subversion repository and broke master with my first commit. Now you are a breaker then. So what happened?
What happened there? Tell us about that. Well, I, with every, everything I committed for the first couple of months, you know, I would miss some edge case and it would make the main interface not boot up or, you know, something stupid like that. Well, the framework was not overburdened with, you know, regression tests back at that time either.
So, right. It's hard to keep too much clean. The, the count of regression tests at that point was zero and remained so for quite a bit longer. Regression testing has been an ongoing issue for us.
But yeah, I spent a lot of time fixing bugs just to make it possible to do some of the evil things that I was trying to do at the time. And that got me in the door with the project. And then in 2009, when the acquisition came about, I was basically the first hire onto the new, the newly minted Metasploit team. So I wrote most of the, or a lot of, at least the, the backend code for the original Metasploit commercial product.
I spent a lot of time there working on the commercial edition as well as the open source stuff. And in the time that I've been working at rapid seven, something north of 80% of all my code has been open source. So that's super, super helpful. It really adds to the job satisfaction to see my code is going out open source.
And it also allows me to interact with a very diverse group of, of hackers putting together exploit modules and, you know, kicking sandcastles and licking cupcakes as we do in the mostly world. Say that again. Kicking sandcastles and licking cupcakes. Yeah.
Because that's what you do when you break into a network, right? You're not in there saying, you know, everything's sunshine and rainbows. You're, you're ruining someone's day and you have to do it. You have to do it nicely.
So it's all about trip cupcakes and somebody runs over and licks all of them before anyone gets to eat them. That's what it is like cupcakes. That's, that is incredibly rude, but nice for you because you get to taste the cupcakes, I guess. That's right.
It is kind of fun, right? When you find your way in. Well, let's, let's not bury the lead here. Let's talk about this name Egypt.
Ah, yes. It originated as a nickname in college based on my appearance. So do you look Egyptian? I guess so.
Pyramidical, I guess. Yeah, I'm not really sure. I had a goatee at the time. So you look a little bit like an Egyptian pharaoh or something.
I suppose. And so friends start calling you Egypt and it just stuck. And it just stuck. Trevor, where's your awesome handle?
Oh, gosh. Yeah, I don't know. I don't really have one. You don't have one either.
No, I'm, I'm burly scud on IRC with two D's. And always have been the points to anybody out there in the audience who knows what that's a reference to. Burly scud. Yeah, because I've had one person all the time ever figured out, but it's not super hard.
It's just kind of obscure. types of data are traversing my firewall and what ports, et cetera, et cetera. You can kind of instead you can, you can turn on its head and ask the question like, what are users doing right now and is that okay? And can you use heuristics to understand, like, Hey, today, Jared accessed 12 servers he's never touched before, you know, is that strange, right?
And, and a traditional intrusion detection system might not know about that because it might just be focusing on the perimeter. Like, is, you know, are, is someone authorized person getting in or is some particular high value data getting out? Um, so user insight, again, it's that idea of being able to sort of look at um security from a slightly different perspective and say, you know, can we, can we change our perspective a little bit but dramatically increase the value of the insight that we're producing? Um, so I guess that's kind of rapid seven in a nutshell.
You found the product idea, I'll give you this one for free, so tell your friends at Rapid7, like, I'll be there, they can thank me later. It's a scanner, but it scans your office or the scans every monitor to see if anybody has written their password down on a yellow sticky note and then stuck it to their monitor. What do you think about that? That's real, that's real user user interactions scanning.
You might go ahead and just like start the patent application right now. As long as you guys give me a shout out or, you know, 1% of your first billion, something like that. So I guess that's kind of rapid seven in a nutshell. Honestly, honestly, I would prefer people write the password down somewhere and put it in their wallet rather than leave it in passwords.excel on the desktop.
Good point or just use one password, not one password application, but like literally a single password for everything that they do. So nothing bad ever came of that. Yeah, exactly. On the other side of that coin, you have companies enforcing ridiculously onerous password policies, which require their users to subvert them on a regular basis and come up with all sorts of things.
Right. And those ridiculous password policies lead to like the top four passwords in every single organization are summer followed by the year, winter followed by the year, spring followed by the year, fall followed by the year. They are in the top 10 on every organization. So is there, is there a future for us to just be rid of passwords altogether?
Is there, is there a light at the end of that tunnel as an industry or not? I don't see it. Like, I really want to, but I don't see it. Um, we've moved towards two factor authentication or multi-factor authentication.
Um, but it's so spotty and the support for it is so spread out that most of the time as a pen tester, you know, you get around, you walk all over the network, you kick those sandcastles and with those cupcakes. And at the end of it, you go and give the report and they say, oh, well, what'd you do about our two factor off? I didn't know you had it. I'm sorry.
Right. Hmm. So before we get into Metasploit, uh, the details of history and all that, let's talk about penetration testing as a thing. Um, we've mentioned it a few times here, um, but maybe Egypt, could you give us kind of uh a general definition and then maybe even like what does a security audit looks like from a company, if somebody hires a company like Rapid7, there's a lot of these firms out there that will do it for you.
What's the process, what's it about and kind of what are the results? Right. So I don't have a lot of insight into the like sales side of it, like who you call and talk to you, but I can tell you from the penetration tester side, um, you know, a penetration tester is given uh someone to talk to as a point of contact and they usually have a list of IP addresses that are in scope and don't touch anything outside of those IP addresses. Um, and sometimes the, the scope will be really restrictive and say, you know, you're only allowed to look at this web app and you're only allowed to look for cross-site scripting.
Uh, you're not allowed to look for SQL injection and that sort of thing. And that gets really limiting and you end up with a report that's not very useful. Uh, but sometimes you get a broader scope. Um, you're allowed to look for more things.
You're allowed to take more actions. Uh, and hopefully those are on um not necessarily production networks, but something that like, if it falls over, you don't lose every customer's data, etc., etc. Um, but a lot of times a penetration test is just a week or two weeks long, which means a very compressed timescale for an attacker. A real attacker is going to have months, right?
And a penetration tester is gonna have a week or maybe two weeks. And one of those days is going to be for reporting, so they really only have four days. Um, and you start out, sometimes it's acceptable to stand beforehand and that saves a lot of time. So as a penetration tester, because of this compressed timescale, you need to find stuff as quickly as possible and identify it as quickly as possible because you're looking at a lot of data.
So if you have 1,000 IP addresses that you need to check out, you want to scan those as quickly as possible and it's going to be super noisy. And so for example, if there's a firewall in the way or an IPS in the way that says, oh, this is a port scan and then blocks your access. Now suddenly that scan is basically invalid. So that happens pretty frequently.
Um, and assuming that those roadblocks don't come up, you do your scan, you find out what's available. Usually there's a whole bunch of static HTML. There's a whole bunch of web applications and not a whole lot else on the outside. Um, occasionally you'll find the, you know, the golden FTP server with uh all of the company's financials on it, open anonymously to the public.
But that doesn't happen terribly often. Um, I did find a domain controller on the public internet once, so that was fun. Um, but fortunately that doesn't happen frequently anymore. Um, so then you do your, you do your external scans.
You find all the things. Um, if there are a bunch of web applications out there, you spend some time fuzzing input. You look at a thing called burp suite, which allows you to muck around with, with HTTP headers and values. Uh, it makes it really easy to fuzz and stuff and to examine responses.
Um, there are a number of other tools in that same vein, but burp suite is kind of the de facto standard for screening around with HTTP. When you say fuzz some stuff, can you elaborate on that? Yeah. Uh, basically just throwing uh values that might break an application.
Um, so in the case of if you're looking at a C application, an application written in C, you'd be throwing large, uh, large strings because it might overflow a buffer. In the case of a web application, you might be throwing uh various kinds of quotes to, to escape something out of a SQL statement. Uh, so those sorts of things. Just trying inputs that are probably bad, giving the application, uh, hoping for a crash or some aberrant behavior.
Um, and so once you, once you get through that step, um, occasionally you'll end up with uh external access via something like uh a SQL injection or command injection on a web application. Uh, and then you start the whole process over again and you scan the internal network. Uh, a lot of, of external uh engagements require that once you get inside all everything stops until you talk to your point of contact. That's pretty common, which sort of makes sense from the, from the customer's perspective because you as, as the person running the network, you want to know when there's a big vulnerability that lets someone into the DMZ or into the production environment.
You want to know that as soon as possible. Um, and you also don't necessarily want a penetration tester uh running around rampant on your production internal network. So a lot of times everything stops, comes to a dead end right there, um, and you call up your point of contact and, and tell him the bad news. Um, there is also like social engineering campaigns um where you send out a whole bunch of emails and inevitably someone is going to run the executable.
Um, and that gets you usually corporate network access. And again, the thing starts all over again. Now, uh, as a penetration tester or as any attacker, really, you're looking to expand your influence. So if I'm coming in from the outside, I'm looking to gain access to uh either data through SQL injection or possibly shell access through command injection or other sorts of things.
Um, and if I'm sending you a phishing email and looking to expand my influence instead of getting into the DMZ into the corporate network, uh, usually there's all sorts of information in there that's, that's company sensitive that you really want to get a hold of. Um, the crown jewels are always on somebody's desktop, though, uh, or some file share that's available to everyone in the company. Most of the time you're not dealing with exploits. Um, I'm, when I, I'm sending, when I'm talking to a web app on the external, I'm creating my own exploits for the most part.
You know, most of those things are custom apps. That's what I was gonna ask is if you are targeting specific, you know, endpoints on a network that are public facing, they're usually web apps. And are you just fuzzing those or are you actually, you know, inspecting the application and saying of Apache chunk encoding overflow. I remember it well.
You had the class C network block as individual pixels, and whenever you compromised a machine, one of the pixels would turn red. That's awesome. Yeah, it was super cool, but not very useful at the time. Yeah.
So it got, it got, it was originally in Perl. It got rewritten, basically an entire rewrite when HD picked up a couple of contributors, Spoonim and Scape. Scape later went on to Microsoft and created a whole bunch of mitigation technologies that made exploitation a heck of a lot harder in terms of memory corruption. So the project went on without him and went on without Spoon.
And around 2005, 2006, I started using it for writing my own exploits. And it was about that time when Scape and Spoonim left. And that's when it started moving towards Ruby, where it had originally in Perl had a Yula-like license to prevent some of the blatant corporate misuse that had been going on with it. And when it moved to Ruby, it maintained that license for a little while.
Shortly after I got commit access, we changed the license to BSD. So now it's real full-fledged open source and you can do anything you want with it. But the great thing about that is that we get somewhere in the neighborhood of 200 unique authors on commits every year for the last two to three years. Nice.
So that's really cool. And a lot of them are only a single commit, which is great because it means that someone new is coming in and saying, you know, here is something that I see missing or some functionality that I want to have. And so they write it up and they submit it to us as a pull request. And then they go about their business and they continue using the tool and breaking into networks with it.
But, you know, they've contributed something that 200,000 people use, which really, really makes me happy that we can get that kind of contribution from so many unique people. It is really cool to see, I got to say, like, and one thing I'll add to that, that is something I think Drew has run a lot of people who work on it full time to the project is that Metasploit is now, because it's been around and you know, when it first started, it was sort of controversial, like, oh, we're going to actually publish these exploits. We're going to create this sort of library of malware. Well, now it's that notion where it was sort of very scary and controversial when it first started, it's now pretty well understood and it's pretty well accepted, even to the point where I think it was in an article in 2012, the New York Times referred to it as a sort of early warning system for malware.
And I've kind of always liked that, that notion of what Metasploit can be. It's sort of like, you know, if you're vulnerable to something in Metasploit, you're doing it wrong because we're not generally going to be publishing things that have no mitigation available. I mean, there are going to be times when we do that, but it's specifically to help put pressure on vendors and create a good outcome for all of the huge numbers of people who are going to be vulnerable to some given software flaw. And when we do that, usually if we publish something that has no patch or has no vendor response yet, it's because it's already being exploited in the wild.
Exactly. Yeah. One of my favorite examples is also, I believe from 2012, from late 2012, I'll get the dates and timing wrong, but there was a large vulnerability in pretty much every browser. There was the way that like the bridge of from JavaScript to Java that was available to, like, you know, in 2005, you could go to like Yahoo games and play the Jewel online or whatever that that kind of like Java applet sort of loading directly through JavaScript to kind of bridge things called Rhino.
And there was this major, major flaw that that was being exploited in the wild and that was getting, you know, remote code execution, like the Holy Grail to whoever was doing these attacks. And these attacks were being weaponized in this real sort of compaction drive-by form. Right. So you click the wrong web link and bam, you're owned.
So this is terrible. And it was estimated to affect over 750 million computers. And we were in, you know, we maintained a disclosure program at Rapid7. One of our colleagues does.
And so that involves a lot of sort of like, you know, closed door conversations with the security researchers who have found the vulnerability and want to do responsible disclosure of that vulnerability. And these researchers had disclosed to the maintainers of Java Oracle already. They had done it that that spring. Right.
So by the late summer or so, it had been a significant amount of time that they had since they had disclosed with Oracle. And then they came to us because I guess we had a little bit more of a megaphone or whatever. And we disclosed again with them. And Oracle came back and said, you know, we needed like a really long time to patch this.
I can't remember the exact amount of time. I believe it was something like a year or 18 months to affect this patch. Yeah, at the time, Oracle's patch cycle was 18 or was six months and they wouldn't guarantee a patch on anything fewer than two cycles out. Right.
So you're looking at potentially a year and a half before you're going to see anything on this. And, you know, and Metasploit was in a position to basically say, we don't care if we don't believe that that's an acceptable thing. Like, you know, you bought you bought Sun. You've got Java.
It's your thing now. And, you know, your product is vulnerable in this enormous number of computers. So we were we published the exploit. And I believe that Oracle had a patch out.
If I recall correctly, it was like three days, but it was certainly less than a week later they had a patch for Java. And now Java, as you know, there's a kind of spade. You might remember around this time, a whole bunch of bugs and sort of this general area of things, a whole bunch of vulnerabilities. And now I believe that on OS 10 and on Windows, I believe pretty much anywhere you can think of if you're going to install a browser, that browser is no longer going to have a hard dependency on Java.
And if you want to do some Java stuff, you're going to need to go ahead and, you know, install it yourself in the case of like OS 10 or I'm not 100% certain how it works on on Windows right now. But, you know, Java used to just be like a dependency, just kind of there and nobody really thought anything of it. But, you know, that's one of my favorite examples of Metasploit putting very significant pressure on a very large vendor and getting a really, really positive outcome out of it. Man, that's that's interesting.
There's so many different avenues I could go off of that because we have a licensing aspect. You have kind of the script kiddies idea. You have the balancing act that you guys have to be participating in of what do we include in what is out. So whenever you wield a tool that's powerful like Metasploit, it can be used for good.
It can be used for bad. This is where we kind of get the idea of white hat hackers, black hat hackers, gray hats, which that was a thing back in 2006. I'm not sure if people still use that term. Yes, I think so.
Just making sure. What's it mean? I don't remember. Like you're kind of doing both.
Well, the funny thing about white, you put a little black in it and then no matter how much more white you put on top, it's always going to be a little black. Oh, so like you have a history. Is that what it means? I see.
So it's a black hat turn white. Maybe that's where the intrigue comes in. Open source is not necessarily entirely. Got you.
Got you. Okay. So you got those people. And man, there's just a lot of actors, a lot of interested parties.
And then we have this idea of a script kiddie. Egypt, you want to kind of explain what that is, perhaps. And then maybe address Metasploit's history with, with these type of people. Yeah, that's an interesting term.
Script kiddie. Is that still a term? Maybe I'm dating myself. It is a term.
It definitely is. It still exists and people still use it. Do you hate that term? But I, I just don't think it has the meaning that it used to.
It doesn't have the weight that it used to because it used to mean that there was a script kiddie was someone who used other people's scripts and didn't have the skill to write their own. Couldn't write their own exploits. But the fact is today you don't have to write your own exploits because there are just so many things out there. You know, you don't need to know the intricate details of a particular heap allocator on this operating system because most exploits, most things that get you data that let you steal credit cards are going to be SQL injection.
I've seen 12 year olds bust out SQL injections and steal stuff. Like you, you don't need to be super deep into all the details of how an operating system works to steal data. So it's just getting even easier. Right.
And that's not because exploitation has gotten easier. It's because the kind of bugs that are prevalent these days are different. You know, there's still a lot of memory corruption vulnerabilities, but they've gotten exponentially more difficult to exploit. So I mentioned escapes work with Microsoft with, um, SEH mitigations.
SEH is the structure exception handler, which was sort of a generic It's false. I mean, most people probably don't think about it, but it's probably easier to hack the average corporation, almost certainly, of any size, than it is to hack an individual person, just simply because there's so much out there, that the attack surface is so large. Right, and you've got years and years of IT guys that have installed random stuff on there, or a local admin on a particular Windows machine, and da-da-da-da-da. And, you know, there's attrition, people leave jobs, people forget what they installed, people, you know, just kind of leave things around as business moves forward.
So, you know, even if somebody could, say, find, to just extend your example, find a Rails application that's vulnerable to, like, the YAML injection remote code execution bug from a couple years ago, and they can get you to, you know, they can use that exploit. Well, I mean, Metasploit has provided a bit of code for that and has provided, you know, a very useful mechanism for interactivity with a nice little shell and for delivering a payload to be able to do something useful with that access. But what then? You know, I mean, in the classic formulation of a script kiddie is somebody who's just sort of like, you know, praying and spraying and just seeing what happens.
But then, what then? If that person actually knows how to, you know, move laterally through the network and steal a bunch of useful data, can you really call that person a script kiddie anymore? I mean, you know... You're like a script teenager.
Right, exactly. I mean, these people, you know, I think that the term itself, while it still gets used, and even used at our expense indirectly on Mr. Robot, go look for the... Don't spoil it.
Don't spoil it. Sorry, guys. But yeah, I mean, you know, it's just, the error, I think, of people being able to be, like, accidentally very damaging is kind of, I don't know how, I don't know how legitimate that is anymore. I mean, it's information security, right?
So, there's always, like, caveats and long tails of problems out there, and, you know, there's all kinds of things that are horribly insecure that are made directly available to the internet, like, ATMs being a fantastic example. But, you know... Which are all running Windows XP. Yeah, which doesn't get security updates anymore, so be afraid.
Yeah, it's just not a... I don't know how useful it is as, like, a genuine critique of the people who are actually trying to use a particular thing. Yeah, and I'm not necessarily critiquing. I'm trying to understand, as somebody who's involved, you know, with the project, is you have people using it for good and you have people using it for bad, and some of those concerns, you know, have to maybe not weigh on you, but things that you're actively thinking about when you decide if an exploit is going to go in, when it's going to go in, in the case of your Oracle example.
You know, that was something that you used it as leverage to get them to act, which ended up being a great win, right? That was a success story. But what if they would have just been like, well, screw you guys, we're going home? Now, I mean, effectively, okay, it's their fault, not yours, but now you've given that vulnerability and that exploit out to...
Well, but that also assumes that, like, we had that and other people didn't. That's true. And that we, you know... It could get out there in a different way.
Well, it's already out there. That's what you need to always remember. It's already out there. We put this in because we were able to do some monitoring of various forums and whatnot, and we were able to see, like, you know, these types of things are getting exploited already out there, right?
Like, keep in mind that the crime markets that you would spend a bunch of money on right now, like, say you're, I don't know, you're some bad actor somewhere in the world, and you decide to get on, there's basically like a Silk Road of, like, malware on Tor, right? You could get on there, you could buy a crime market, which costs about a thousand bucks. It's a beautiful interface. It'll come with some stuff that's, you know, it's not quite ODay because it's in the crime markets, but, you know, it's not in Metasploit either, necessarily, right?
I mean, like, we're... We are not, like, there's this temptation to believe that, oh, the thing I know about is Metasploit, and Metasploit's got this library of malware in it. Therefore, Metasploit must be filled with awful stuff that can be used to, like, own computers all over the place, which is really only true if you're not, you know, if you're not patched, right? Right.
So the idea that we aren't, like, completely, you know, that we're, like, on the forefront, and if we don't release something, it just won't be out there. That's tempting, but it's totally false. That's not true. The bad guys are going to have this stuff.
Fair point, fair point. Yeah, and I'd like to point out that, especially in that Rhino case, it was already being exploited in the wild, and that's true of a whole bunch of our exploits. Already being exploited, sometimes in targeted attacks against specific organizations, and we make it available for everyone to know what the exploit is doing, which significantly lowers the value for a malware author. Fair enough.
I'm stuck back where Trevor said you got a bad actor out there trying to hack something, and I just picture Ben Affleck sitting there at a computer. I don't know. I had to sneak that one in there. All right, let's take another break, hear from another one of our sponsors.
We'll be back because we haven't talked about Metasploit, the technology very much, how it works, how you contribute, how you use it, those fun things. We know it's built on Ruby, but that's about all that we know at this point. So let's take a quick break, and we'll be right back. For those out there working solo or on a team tracking time, you thought you were wrapping up a project until the client or your boss asks for a new feature at the last minute, and here you are stuck.
You're not sure how much time you're spending on every feature, how much time you're spending on bug fixes or tweaks. Well, Harvest is a time tracking tool built for understanding where your time is going. And for developers, it takes the pain out of time tracking. Just install the Harvest Chrome extension and you can start tracking time right from issues in Jira or GitHub, and you won't have to go searching for your time sheet.
Not only will you understand how much time you're spending on client work, you'll also be able to turn your billable hours into an invoice from Harvest in minutes. Harvest integrates with Stripe and PayPal to make sure you get paid fast and on time. There's built-in reporting in Harvest that lets you see how much time your projects took, so you can use that information to make better estimates in the future. For a better way to track time and invoice your clients and take the pain out of what you're doing when it comes to tracking time and invoicing, head to GetHarvest.com, create a 30-day free trial, and after your trial is over, here's a goodie for all of our listeners.
Enter the code CHANGELOG to save 50% off your first month. Once again, GetHarvest.com, create a free 30-day trial, and after that trial is over, enter the code CHANGELOG for 50% off your first month. Enjoy. All right, we are back, and I want to hear about Metasploit from a technological perspective, the software, how it works.
We know it's a Ruby app. We know it used to be Perl. We know it used to be a game, a curses-based game, which still sounds pretty random if you ask me. But Egypt, can you give us a little bit about the software stack, how you even use it, how you install it, and then maybe how you contribute exploits?
Okay, so there's the main thing, which is Ruby, with a client console interactive front-end called MSF Console. That's the Metasploit framework console. There are also a number of other standalone tools. MSF Venom is our payload generator.
We also have an assembler shell that allows you to assemble x86 and x64 assembly into bytecode. All of our payloads are in the payload technology that makes sense for that particular target. So for our Windows, it's written in C. And our flagship payload is called Meterpreter, the meta-interpreter.
It allows you to interact with the system like a normal command shell. And in fact, you can drop directly to a CMD shell or a PowerShell shell to talk to a Windows box. And all of that is written in C with a DLL as the actual payload that gets delivered. But we also have these things called stagers, which as a result of the way exploits typically work in memory corruption vulnerabilities, you have a small area where you can put your payload, which is often called shellcode.
And that's restricted in size, and it's usually restricted in character set as well. So for an example, if your overflow is in, like, an FTP username, well, the at symbol separates the username from the hostname. So if your payload contains an at symbol, then it's going to break the parsing and you won't get a shell. So we have encoders that get rid of those bad characters and randomize things with an XOR key.
And you can to do the classic Windows stuff and grab all of those, but then we've also got things like stealing a KeyPass database if you can find one on the machine, scraping Skype hashes from wherever they're located on whatever type of platform you've just victimized, right? And bringing them all and handing over to offline cracking tools like John the Ripper or something like that. So, you know, you can go through and just start running them through a cracker and then hopefully, you know, hours or days later, whatever, you've got a whole bunch of nice passwords you can start replaying in different places. Yeah, in some cases, you don't need to do any kind of cracking.
So Windows has this awesome thing called Encrypt Secure Data and Encrypt Unsecure Data, which is the API intended specifically for storing secret stuff in Windows. But if I'm running as your user, I can encrypt all of the stuff that you have encrypted as that user. So you can just ask the operating system and it'll give you all of those secrets for free. If you have that user's privileges at the time, right?
Exactly. So that's fine. So if I'm running as you and you can do anything at all without using your password, then I have your password. Well, that doesn't sound very awesome for me.
So let's say that I'm a budding network administrator or let's say that I'm an app developer with a network that I'm interested in running some of these things against. Or maybe I just want to play with it and see what it does. How do you get started with Metasploit? How do you use it as an end user?
Well, for an IT admin, I would suggest starting with the community edition, which is the Rails GUI that's sort of the basis for our commercial editions because it gives you a lot of the power of the console interface, but it's point and click and it's at a less steep learning curve. If you really want to dive into it, the console does have a slightly higher learning curve, but it does have faster access to some aspects of the framework. So I'd say when you're first getting started, community is absolutely the way to go. Yeah, and I would say that's definitely true.
Unless you're just like, you love CLI, you want to dive in on the command line, it's very easy to grab the code. There's also, we distribute with Kali Linux, which is a big open source sort of penetration testing Linux distribution. So the framework is available like right out of the box right there, along with a bunch of other really fun tools, pretty much everything that we mentioned for the most part on this call. And I would say that also, I personally, when I was getting up to speed on the application when I joined Rapid7, I know that some of the content is a little bit out of date, but the No Starch Press book, Metasploit Unleashed, which is written by a bunch of long time contributors and sort of friends of the family, basically a bunch of penetration testing people, is a really good book just sort of for understanding like how to get started, how to use this, how to kind of like get your head around like what the framework does and why it's powerful.
Might be a good time to mention that there is, as you guys said, there's a divide between the open source BSD license Metasploit framework and I believe what's called the Metasploit project, which is... Well, the commercial editions really is what we call them at Rapid7. So that's fun. So if I'm running as you and you can do anything at all without using your password, then I have your password.
Well, that doesn't sound very awesome for me. So let's say that I'm a budding network administrator or let's say that I'm an app developer with a network that I'm interested in running some of these things against. Or maybe I just wanna play with it and see what it does. How do you get started with Metasploit?
How do you use it as an end user? Well, for an IT admin, I would suggest starting with the community edition, which is the Rails GUI that's sort of the basis for our commercial editions because it gives you a lot of the power of the console interface, but it's point and click and it's at a less steep learning curve. If you really wanna dive into it, the console does have a slightly higher learning curve, but it does have faster access to some aspects of the framework. So I'd say when you're first getting started, community is absolutely the way to go.
Yeah, and I would say that's definitely true. Unless you're just like, you love CLI, you wanna dive in on the command line, it's very easy to grab the code. There's also, we distribute with Kali Linux, which is a big open source sort of penetration testing Linux distribution. So the framework is available like right out of the box right there, along with a bunch of other really fun tools, pretty much everything that we mentioned for the most part on this call.
And I would say that also I personally, when I was getting up to speed on the application when I joined Rapid7, I know that some of the content is a little bit out of date, but the No Starch Press book Metasploit Unleashed, which is written by a bunch of sort of long time contributors and sort of friends of the family, basically a bunch of penetration testing people, is a really good book just sort of for understanding like how to get started, how to use this, how to kind of like get your head around like what the framework does and why it's powerful. Might be a good time to mention that there is, as you guys said, there's a divide between the open source BSD license Metasploit framework and I believe what's called the Metasploit project, which is... Well, the commercial editions really is what we call them at Rapid7. So, right, so we have like a lot of commercial open source things.
We have like a couple of different like, you know, price points with different features turned on or off, right? The framework is the engine of all of those things though. So, yeah, we have... So what's outside of the framework?
What's in the proprietary ones? Metasploit Pro contains things like a Jasper report space reporting engine. It has a whole really nice social engineering toolkit that you can use. I like to tell people it's sort of like an evil online marketing system in a way, because like you can use it to like create a little website and then like create an email and generate links that are like, you know, the half tags like to, you know, you can upload like an Excel spreadsheet of like all the people in your org and then you can basically try to phishing them and see like, okay, you know, Joe, you know, opened the email but didn't click on it.
Mary didn't even open the email, but Frank opened the email, clicked on the link inside it and then filled out the form on the resulting web app and hit submit and we stole his creds. So, you know, Frank's got to go for security training or whatever, right? So a bunch of, quite a few of our customers really enjoyed using that. They can kind of like click, click, click.
They can clone an existing website if they want to or whatever. Wow, so you can deceive your own employees into... Right, right. It's a little weird, but at the same time, most of the major breaches that anybody could name off the top of their head for the last couple of years have been what we refer to at Rapid7 as deception-based attacks.
So it's very germane. Like it really, really is. And you'd be surprised how many people can fall for this. Now, granted, if you're creating one of these things and you've got internal knowledge of the company, you know, you're kind of tempted to sort of go a little bit out of the bounds of where you would normally go just kind of naturally.
But that's available. Hold on there, hold on there. I think that that insider knowledge isn't always all that inside. So as an example, the first phishing campaign that I ever did, that I was ever involved with, there were public rumors about a merger with this company that we were targeting and another company.
And so we sent a phishing email with a PDF containing an exploit in it. And the subject of the email was basically the merger has gone through and this PDF contains a list of everyone who's getting fired. Yeah, fair point. Like at that point, I don't know whether that's just preying on human intuition.
Yeah, that's pretty compelling content, right? Right, like who's not gonna open that? I would see that as one of the most suspicious things ever to come into my inbox, but maybe that's just me after spending four years on Metasploit. Yeah, I think you're probably pretty unique in that regard.
I think... But I mean, there are a couple other larger features that are available inside Pro. And most of those are effectively to help people who are kind of in the security admin space run a collection of Metasploit content and then do some things and report on what it was able to do in a sort of, you know, a nice kind of automated orchestrated fashion, right? Whereas the framework is all kind of nitty gritty hands-on.
You can script it, but it, you know, that's a lot of work to really scale your way up, right? Versus Pro is gonna give you a nice GUI interface for dealing with, for instance, maybe you've, you know, maybe you've compromised hundreds of machines at the same time and you wanna run, you know, the same two or three modules on all of those machines and have that all be part of like one big report or something like that. That would be a pain in framework and it's very simple in Pro. So Pro is all about scalability, communication with other people, communicating up to your bosses or stakeholders, that kind of thing.
Very cool. Well, and the knowledge they assume amongst people they talk to and realize that they might be talking to a software person who's an extraordinarily adept creator of software and really doesn't know the security landscape. But given the right kind of particular piece of knowledge could really be somebody who's a benefit to the information security world. I think that's kind of the attitude that Egypt and I both approach it with, is that there's just a lot of latent capability out there.
We've kicked around ideas for years about how could we get people who were more software-oriented thinking in terms of security. And really, frankly, people who are security people thinking a little bit more in terms of people software practices. I think there's definitely an opportunity for people to kind of meet in the middle on that. Well, hopefully here at The Changelog we can help facilitate such things.
I think even just having a conversation around it brings up people thinking about such topics. So hopefully you'll have more, gosh, can I say, synergies and get away with it? Sometimes you can. I think I just did.
Sometimes it's the word you need. All right, well, I think it's time for our closing questions. So you all know the drill. I'm going to start with Egypt and ask you, who is your programming hero?
I think my hero, my programming hero, is a former co-worker named Michael Milvich, who was just amazing in his breadth of knowledge. He knew a little bit about everything, from how compilers work at the base fundamental levels to the Python VM to everything, basically. And what really made him special to me as a colleague was that his depth was at least as impressive as his breadth. So he knew a lot about everything.
And that was really inspiring to me, and it got me looking into a lot more things and really challenging myself to be a better programmer. Awesome. Trevor, how about yourself? Yeah, I've been spending so much time in Go in the last year, and I've been watching kind of all this sort of constant controversy of people being like, oh, it's not my favorite thing, or whatever.
And I've been pretty severely impressed with Rob Pike, you know, who's kind of a legend in the programming world. But, you know, this whole idea that, like, there could be a much better language. We could go back to some of our basic principles and say, look at these old principles from C and from some early Unix programming and say, you know, there's some really great ideas here. There are some fundamentals.
And if we keep our language very small and if we really sort of chart a particular course and not waver from that course and not kind of, like, bring in every idea that everyone's ever had, we'll be making something kind of interesting. I'm always a big fan of the idea of creativity within constraints. And it's been interesting to watch this guy who's, you know, I doubt he ever really considered himself somebody who's going to become, like, this person who was sort of kind of the high priest of a programming language in the same way that he has. But it's been nice to watch the way that the Go authors have been very, I would say, very generous with their time and very interested in the reactions that people have to the things that they've built.
But they also kind of maintain that, you know, they've got a vision for what this thing can be, and they kind of stick to that. And it's been cool to watch. I'm also, like, kind of in awe of Yehuda Katz. And I know a lot of people probably mentioned him on this program, but the guy, like, just makes things that need to exist.
And as a sort of practically minded person, I really, really appreciate that. I remember Rails dependency management before Bundler. You know, I really appreciated a couple of times I needed to write a CLI tool in Ruby. I really appreciated the existence of Thor.
You know, yeah, I love that somebody, like, sits down, he's gonna write something in Rust, and he's like, well, I need Bundler for Rust, so I guess I'll just make it. And that kind of attitude, you know, somebody who spends a lot of time dealing with open source stuff, that kind of attitude is just... It's like the ultimate answer, right? Like, I need to, I'm gonna write something in Rust.
I need a dependency manager. And, you know, months... months later, he comes with the cargo. Here we are all together.
Very cool. Hats off. Okay, last one. We're running low on time here, is what would you be doing if you weren't working on Metasploit?
And Egypt, we'll start with you. I would probably be penetration testing networks, breaking into stuff, stealing things. Security has always been my passion, and programming has been the means to that. And if not penetration testing of networks, I would be reverse engineering binaries, staring at debuggers and disassemblers all day long.
In fact, that's what I was doing before I came to the Metasploit team. So, Lee, you just totally love it. How about you, Trevor? I've always liked to really stay startups.
I like sort of chaos and the interesting opportunities that come out of it. So I would probably be off doing something on my own, probably in, like, agricultural tech. I'm really fascinated by the intersection of, like, maker technologies and the whole sort of, like, I don't even know if you call it the food movement, but I guess kind of the food movement. So...
Something in that area. Just speaking to that briefly, I actually listened to a great podcast this morning on EconTalk. Have you ever heard of EconTalk? It's an economics podcast out of Stanford, I believe.
I'm a bit of an economy nerd from time to time. All about ag tech and kind of the return of nature that's been happening. I'll link that up in the show notes. It's pretty interesting to see the results of some of the advancements that we've made recently in ag tech.
Very cool, guys. Man, this was such a fun time. I could probably talk to you all for hours about these things, mostly because I'm so rusty that I'll just sit here and say, is this still a thing? Is that still a thing?
As you can tell by now. Well, come down to Austin. Hang out. It might have to happen.
It might have to happen. Where can we find you? So, metasploit.com on the internets. What's a good way to get a hold of you?
Well, I'm EgyptEGYP7 on Twitter. We also maintain the account Metasploit on FreeNode. And I'm in there all the time. And Trevor?
Yeah, same for me. I'm Trevor Rosen on Twitter and GitHub both. I mock politicians frequently on my Twitter account, so that's not really my professional thing, but there it is. I also talk about code.
So if you're pretty politically aligned, you may not want to follow Trevor on Twitter, because he may make you angry. He could be, yeah. Or even if it's not politics. It just might happen.
It just might happen. Very cool. Well, thank you guys again for joining me today. I also want to thank our awesome sponsors for this episode.
That is CodeShip, TopTal, Harvest, and Transloaded. We appreciate your support. And if you love the ChangeLog, we would love if you would help support those companies as well. Give a little bit of a tease to upcoming shows here.
In case you have not hit the subscribe button quite yet. We have the Hybrid group coming on to talk about Cylon.js, GoBot, and the Internet of Things. We have RethinkDB. Follow up with an earlier interview we had with the CTO there, as well as Saran Yebarak with GoNewbie upcoming.
All sorts of fun stuff. Make sure you subscribe. And with that, until next time, let's say goodbye. Goodbye.
Goodbye.