 Alright, so at Black Hat, we did a 150 minute presentation called Tactical Exploitation. At DefCon, we're going to do a 40 minute presentation called Tactical Exploitation. You may want to record it and play it back slowly. We tried not to sacrifice content, so we'll see how well we can do this. Worst case, after this, we're not going to do any Q&A here. We're going to go to the Track 1 Q&A room and we can actually do additional demos there if anyone's interested. So, first thing, this talk is called Tactical Exploitation. It's about a different way to do pen testing, a different way to look at your targets. Personally, I've been kind of sick of how folks who are new to the security industry are getting started by running Nessus and following that up with Core Impact or Metasploit, and that's all they do. And this talk is really supposed to be a way to look at those other ways to get in, other ways to get shells, other ways to compromise a network that don't depend on existing vulnerability or specific tool. So, first off, who are we? My name is H.D. Moore. I'm the director of security research at a company called Breaking Point Systems. We do network test equipment, and it's not really that interesting to most of the folks here. I'm also the founder of the Metasploit project and one of the core developers. I'm Val Smith. I've been contributing to the Metasploit project for several years, and I'm one of the founders of Fensit Competing. So, why you should care? This talks about a different approach to owning stuff. So, instead of looking for a specific vulnerability, a new zero-day, a new something, basically looking at what you actually have and just using the stuff you already have to get a shell. All sorts of new fun techniques, new tools, rehashing some really old stuff that still works really well, and it's all real-world tested and mother-approved. So, first off, the first section of this is going to be about target profiling. Some discovery tools you may or may not know about. Hopefully some new stuff in there. One of the fun demos we're going to do today is actually first published in, I think, 1999 or 2001. And the difference is I can still get a shell on an XPSP2 box with it, so I don't care. So, when you see things like that that are kind of old research, the point is now they're really feasible, they're really easy to do, and we've automated the crap out of it. The second section of this is all about getting remote access. We're going to cover things like charge relationships, fun NTLM stuff, all kinds of cool stuff. Okay. So, basically we're going to talk about the tactical approach. Vulnerabilities are transient. They come and go. You know, you'll have a day to day, tomorrow to be patched. So, really, you need a long-term approach to breaking into computers. Target the applications, the things that people use. Target the processes, the things that they have running on their servers. Not necessarily big commercial products, things they write in-house, especially target the people. The people are a big part of this. Networks trust each other, people trust each other, accounts trust each other. So, target those things and you will gain access. Sorry, we're trying to figure out how after we chopped up our content, how to split it up. So, give us some leeway. So, first off, crackers are opportunities. They're going to break into whatever they can. If you have a job breaking into a bank and they say, well, you can test this server, this server, and this server, but not this server and not this time, well, that's your restriction. It's not the restriction a real attacker is going to have. So, make sure when you're talking to a client about a possible engagement, you make those things clear that anything they restrict you from doing is probably the most severe thing that is the point of attack. I can't tell you the number of times we've done a pent-test and someone has said, well, you can test everything but our domain controller. It's like the only reason I'm doing this pent-test is to crack your domain controller. So, keep those things in mind. Like, you really want to make sure a client or whoever you're doing your pent-test or attack against understands that whenever they put a restriction on your scope, they're doing themselves a disservice. And anything you don't test, someone else is going to test whether they want to or not. So, hacking is really not about exploits. It's all about the data, but it's all about the data, but it's not about getting root or getting admin or anything else. Sure. So, you know, see what you can go after. Can you go after corporate information, design information, things that the company doesn't want you to have? I mean, getting root on a box is cool, but what can you do with that? A lot of times having access as a regular user is actually more important than being root. They're logged less. They're watched less. You can move around the network. Hacking is using what you have at hand, not necessarily exploits, to gain further access to more hosts and to more data, whether it's passwords, trust relationships, hijacking services, authentication systems, and we'll go into detail on all these different things. Security is primarily a people problem. People write your software. People introduce your bugs. People screw up and double-click on the viruses that you send them. People skew your network. So, identify the meatware first. Sure. I'll grab this. So, there's lots of great tools for finding out who actually worked in an organization or what they do or getting a list of email addresses. There's tons of great tools for this stuff. One that I want to focus on today, just because it's so freaking awesome and not many people know about it, is a code called evolutionfrompaterra.com. Does anyone here actually use Paterra? Excuse me, evolution? Wow. Okay. So, like, one or two folks. Great. Well, this is definitely a bad-ass tool you should be using. So, what Paterra does is you give it a piece of information, like a name, an address, an email address, something like that. It'll go through and find everything related to that using about 40 or 50 different back-ends. It'll crawl Facebook trying to find pictures of you. It'll crawl, you know, Flickr. It'll go through your LinkedIn account and try to find associations. It'll go through a company name related to your LinkedIn account and gives you this really cool graph-like interface you can use to basically dig into more information about a given person, product, domain, etc. So, all these types of tools. What they give us is the full name, the user name, the email address, employment history, phone numbers, a list of personal websites. This is a huge amount of information you can grab from these tools. Here's an example of actually running the evolution GUI tool against HDMORE, which you find, like, my email address, you find websites that I've mentioned on. You actually get my phone number out of it. And at this point, if I decided to pick on, you know, double-click the hdm at metasport.com link here, it would actually go through and find every other email address at metasport.com or find any other place where that address has been referenced. So where have I done posting? Any other place where my address has shown up in a listing? Same thing down here, Gmail, the browser fund site, you'll find any site that links to that site and so on. Okay, so this is basically like a little case study of how important this information is when you're breaking into networks. A lot of people tend to focus on an IP address, a range of IP addresses, but this information really helps you out. In one example, we started with a company that we were going after, that we knew we wanted to target, and a specific type of information at this company, what the job descriptions were. So we started searching the internet for what people are likely to be working on the information or the work that we really want to target. So in this particular case, we found an online personnel directory. We found people with access to the data that we wanted. A lot of times you can find people's resumes out on their sites. They don't know its link, they have it in some hidden directory, but that's good information because it tells you they're working on the systems that you want to go after. In a lot of big corporations or large targets, the email address is the username. So if their email address is joe at whatever.com, they're going to be logging in as Joe. So target that. In this particular example, we had a guy, we'll call him Joe Targetstein, and he was a lead engineer in a big semiconductor department of a company. We found his email address in the online directory, old news groups gave us a hint as to what his host name might be. So what do we have? I mean just searching the internet about a person, we now have a username to target, a host name to target, to go after a very specific information that we want to get. Not just get root on a random machine. Alright, so we're actually been flying through a lot of this material pretty quick. The way it's kind of structured is we're going to talk about different ways to do discovery. We start with the people going to the networks, the applications and so on, and we're halfway in and we actually flipped actually doing exploits against hosts. So if this sounds like kind of boring remedial stuff, yes, but it's important and we're going to go into why it's important as we go through this process. The next thing we're going to talk about is network discovery. Basically identifying every asset that your target has. So if you know that a bank, you know what their domain name is, and you're trying to do a pen test against that site, they may not be the only server they have. They may not be the only place they've hosted a resource. You need to go through and find every MX record against every single host. You need to find out what internal networks they have, what branch networks they have, how are the branch networks connected, what outsource services do they run, do they have an outsource spam gateway. All these things are critical to your asset and critical to breaking in. They need to know how to find them. There's a lot of really good tools for this. There's things like, you know, VOS, Breedforcers, there's Mmap, you know, the different open source resource tools, but we're going to go and skip ahead to some things that most folks probably haven't heard of before. So lots of fun things. The neat things about these services is that they're services. They go through someone else's server to bring you information about your target. So in other words, the target has no idea that you're profiling them or pulling information about them at all. Val, do you want to cover the first two? All right, that mic sucks. So the idea behind this is to use other people's services to do your attacks. You know, what people currently do is they'll attack an address or they'll attack a network from wherever their lab is. So your target is going to get things in their logs to let them know that this kind of stuff's going on. There's a lot of good websites out there like CentralOps, DigitalPoint. What these sites do is provide the services that you would normally do by hand off their web page, which means that attacks are coming from their networks. CentralOps will give you like a dossier on your target. Domain name, map to IP address, who owns the network? Who owns the domain name? Even in some cases, what ports are open for a certain subset of standard ports? A lot of good information. DigitalPoint is a great site because it'll do DNS zone transfers. Super old thing that still works today. I use it all the time. So this is good intelligence gathering for your targets. And it's about building up a picture of what to attack. All right. This works. Great. So the other two sites I'm going to talk about are domaintools.com and perturber.com. A minute ago, I showed you the perturber-gui interface. So if you download their product, install it, try it. You'll see this neat little graph interface. However, they've got a web demo as well, and the web demo basically runs all these same tests, but coming from their server, not yours. The next tool I'm going to talk about is domain tools. And domain tools used to be called whois.se. Has anyone actually used that service before? Excellent. All right. Great. Well, there's a really cool feature of domain tools, and what that is is any time a domain is registered, they get that domain sent to them by the registrars. And they say, okay, this new domain exists. So we're going to reverse DNS that domain, find out what it resolves to, put it into a big-ass database, and later on, we're going to allow it on the query and say, okay, what domains exist on the given IP address? In other words, the key track of every domain on the freaking internet and give you a list of what V-hosts are on a given IP address for you. So some fun examples of that. If you run domain tools, this reverse IP thing against defcon.org, you find a great list of all these cool different domains running on the same server. You've got dark tangent, you've got defcon.net, and defcon.net is interesting because it resolves to more than one IP address. And we'll go into that a little bit later. You've got hacker jeopardy, and this thing called hacker poetry. Has that been announced by anybody? Because I'm going to put a bull through my head if I have to listen to any hacker poetry. It sounds horrible. In this case, you know who the dark tangent is, you can now go to thedarktangent.com. With defcon.net, I mentioned before that it resolves to two different IPs. So this is the first IP. If you look at the second IP, we go on to the next slide. And here you can actually see that defcon.net is actually the same server in one case as zeroday.com, zeroday.net, securityzen.com, and zeroday.com with a Z. And there's actually a bunch of personal domains I ripped out for Jeff and Ping's sake. This is like Republic of Ping, all these other great ones. So I pulled those ones out, so if you're ever mad that someone else stole zeroday.com, they're not using it, you can bitch at Jeff. But apparently he's had it for like 10 years. He's had it so long that when he first registered the domain, all the wares kids were pestering him, trying to say, hey, can you use that for my wares stuff? Because you know, zeroday used to be about wares. And now zeroday's about security stuff. So you guys have all these security guys saying, hey, can you use that for my security stuff? So I suggested that we use it for kind of like a power sellers for zero bay. So if you're a real power seller for your zeroday, you can actually get an email address at oday.com and hopefully Jeff will go with that. So what does this get us? These different sites will do proxy DNS probes, it does zone transfers, you can list a virtual host for every IP address, you can do port scans, trace routes, all kinds of great stuff. And the best thing is none of it comes from your system. So even if the client says, hey, you're not allowed to test this or hey, I only want you to do tests against this IP, you're not testing it, they are. So I'm just saying, you may not be in breach of your agreement, but it works. So those are kind of the passive, kind of indirect discovery techniques. The next thing we're talking about is active discovery. And we're still talking about network discovery. How do we figure out what IPs they use, what networks they use, where they come from, how they browse the web from, what's our NAT gateway, all those types of information. One of my favorite techniques for this is doing SNTP bounces. Despite anybody with an exchange server configure, we'll bounce an email back out from their exchange server with usually the internal headers, internal host names, internal version numbers of exchange, outside the headers of that email. So don't be scared just to email your target. I mean, they get so much freaking spam each day that if you send them a jumbled email, they're not going to know the difference. It's great. So abuse that. Sorry, go back. Also, there's things like, you know, definitely brute force, V-host, even though, you know, who is at SE or domain tools doesn't show what host names are on a given IP address, try connecting to and just sending, you know, a host header of internet or WWW or admin, things like that. The user had misconfigured the server and actually hosted their internet site on the same physical IP, but assumed that the DNS would do the work of hiding that from the external users. And finally, you can actually just watch the outbound DNS traffic. If you send someone an email from a domain where you control the resolver for it, so let's say you create a fake subdomain called mysubdomain.metasploit.com. You send them an email from Bob at mysubdomain.metasploit.com, or sorry, Bob.anothersubdomain. When that mail server tries to bounce it back to them, it's going to do DNS liquids for that. Through that technique, you can figure out what DNS server and what, excuse me, not only what type of DNS server, but where that DNS server is located inside their internal network by looking at those queries coming in. So if they're using an external server for all resolution, you'll see that because there are queries from external IP address that's not related to their NAT gateway. If it's using an internal DNS server, like Microsoft DNS, something like that, you'll be able to not only find out that they're coming through the NAT gateway, but also the port sequence and the XID sequence. So here's an example of messing with RSA, because RSA is awesome, and we all think RSA is great for security, right? RSA is security. I mean, hell, they got security in their name. All right, so RSA is nice because they run a bunch of different mail server products inside, and if you email just a random, unknown user at their domain, it'll bounce back and it'll actually have the internal IP address of the mail relay, not even the headers in the freaking subject. It'll say, hey, this bounced out of 10.100 to 8.152, and great. Thanks, RSA. Okay, so if the network is the toast, applications are the butter. This is about application discovery. Every application that your target is running is a potential entry point, whether it's commercial applications they purchased, things they've written in-house. So finding these applications is the trick. A lot of times, you're not going to get some high-profile, you know, Windows remote exploit. You're going to go after an application. So another point to this is slow and steady when to deface. A lot of times people will scan, you know, large blocks of IP addresses, every port, and that's really noisy. You know, we like to do stuff like, for example, that command up there is an end map command that says, don't ping the target, scan for a specific port. In this case, the MSSQL port. This gives you a ton of information without making a ton of noise. What does it tell you? It tells you what the operating system of the target is. If it's running MSSQL, it's probably Windows of some sort. It tells you that they're running MSSQL and that they're available. So, you know, think a little bit different. A lot of people will assume, oh, every attack is going to begin with a full-on end map port scan, and that's not necessarily true. IDS will detect that, try to avoid it by doing slow, targeted, one-shot, one-kill type attacks. So one good example of this is one of the targets we were working on had an internal application for doing software licensing and distribution. They'd written this in-house. It was installed on something like 10,000 computers at this company. We spent a couple of hours, we got a copy of this. Spent a couple of hours with IDAL, eDebug, checking it out, and it turns out they had a static admin password hard-coded in this application. So every host on the network used the same admin password to get their software and their licenses. This means every accessible node we didn't use a single exploit. We were just targeting the application. All right, so we sort of W3AF. Okay, a few folks. Great. So kind of what I'm trying to do with this talk and with some of the parts of the talk is talk about tools that are really great that a lot of folks don't really know about yet. And W3AF is a good example of that. It stands for the Web Application Attack and Audit Framework. It's this neat little read line enabled shell and you can actually do all these cool things all these things you normally want to do with websites so you normally have to use an external tool for but you can do it all from this quick little console and it's easy to use. It's kind of like Metasploit, so I like it in terms of how the console works. So I've been calling it Metasploit for the web but it's written in Python. Outside of that, I love it. I'm sure he feels the same way about Metasploit and being written in Ruby. So we get along on that. Finally, there's actually a whole new set of classes in Metasploit 3 for writing your own quick reviews. If you want to write a vulnerability scanner that connects to every host on a certain port sends some data to it, receives data from it does something to it, that takes about five minutes to Metasploit 3. You can find examples of that under Modules Auxiliary Scanner. We've got one that gets the version of every box running with a SMB open, the 139-445. We've got another version that'll go through and find the web server version for every host in the local network. Another one that actually masks the faces of every host in the local network via put request. So it's whatever you want it to be. But if you're going through the same steps over and over again of writing something that parts to the side of your mask, does connections, does air handling, and all you're really doing is taking to a service and doing a probe, you can do that in about three lines of code of the Metasploit 3 mix and modules and templates. So keep that in mind if you're writing your own stuff. It's really good if you find a custom application or an evil misconfiguration on a customer network and you want to find out what other system that applies to. So let's say a default password for a webinar phase. Say, I said to this here, I want to make sure it's not the same password set for every other node and has threading support. So you can set the number of threads to be like 1,000 or 256 and kick off that many hosts at the same time and the whole thing is kind of done for you and reporting is all nice and whatnot. So just keep that in mind if you're doing your own application discovery. The next step is client app discovery. And this is a little bit trickier because you can't, the clients have to connect to you if you need to get that information. However, client apps are so vulnerable that they're definitely a good target for the profiling of client applications during a pen test. And they're really easy to fingerprint but you have to get them to do something. But, I mean, excuse me, client apps really are your last chance entrance. If you can't do anything else, you should be able to at least exploit a random client. The reason for that is the admin can really focus his time on a couple servers to lock them down but he really can't focus his time on 10,000 users or 50,000 users or even 30 users. So there's lots of different program methods that you can use for profile client applications. The most obvious one is just mail an email link to, excuse me, mail a link to a website to every client. Abuse the all at and everyone at and tmail ease. So if you know the company of software, try emailing SWT at, try emailing everyone at, all at. These folks get so much spam that even if they see a weird email command, it's not going to raise them any flag, especially if you, you know, make it look like a Viagra spam, something like that. You can also do things like send a message disposition notification emails. There's things that, you know, when you get an email and it pops up saying, notify when you receive this. There's really, really annoying things that just about over here probably ignores. There's actually a huge swarm of corporate clients out there that will ought to respond to these. So just because you're smart enough not to enable that stuff doesn't mean they are. So definitely give a shot with those as well. And finally, once you figure out the Natgate way of your target, try searching just, you know, via Google or anything else for the external IP address. A lot of times what you'll find is that IP address will end up in exposed web logs. So you can find out not only, you know, what types of browsers they use, but whether or not they like goat porn. I mean anything. You can find out what sites they visit based on that. Finally, so this is actually a technique that, and kind of a process that a lot of folks really don't do, is when you're focusing, excuse me, when you're doing a pen test and you're trying to focus on specific servers, IPs, versions, software, what you don't look for is whether or not certain activities occur. Like, for instance, how many times have you seen a completely locked down network, but then when you go into the network, you'll see they're doing, you know, an anonymous HTTP external host every night at a certain time. I mean that kind of stuff is a, it's a huge weakness, but at the same time it's not something you can only look for. So what I want to talk about are a couple ways you can actually look for this type of activity. Actually identify the processes being used to actually attack those protocols and attack those types of weaknesses. Good examples that are looking for large IP ID increments in the middle of the night. So who you're supposed to be with an IP ID scanning? We're great, a lot of you guys. The general premise is that a lot of different hosts, each time they send a pack up they will increment their IP ID counter and that will wrap after 64K and so on. But if you ping that host and see the IP ID coming back and then ping it again, if you do the delta between those two IP IDs on a host that supports this type of incremental IP ID, you can determine how many packets are sent between those two pings. So you can do all kinds of great things. You can basically do a remote traffic monitor of any host you want through this method. Additionally, a lot of FTP servers, and especially Microsoft FTP, they support a command called site stats. What this will return is the number of times each command has been executed on that server. This gives you a great amount of information because you can determine when uploads are being done, when deletes are being done, when people log into the server. You can start getting a feeling for, okay, if I want to start hijacking data ports, what's the time to start scanning for it? And finally you can actually look for the last modified header on static content on websites to figure out when they do automated transfers or automated backups. A couple of cases I've seen, people actually don't know where they sync it over each time. So you have about 30 seconds of one minute window where things like the .htaccess file aren't there, where there's a director index listing because they delete indexed HTML. So basically by going through the web route, and this doesn't work for dynamic content, and doing basically a head request against each image in the directory, compare all those timestamps, see if they're all within a second or two of each other, or see if they're a few seconds apart or a minute or two apart. Now try it again the next day, the next day, the next day you'll have a full upload every night at a certain time. Now you know when you want to start getting that site as fast as you can, trying to find a window where the .htaccess isn't there, or it's otherwise misconfigured. So are there any existing tools for this stuff? Not that I've seen, correct me if you have seen this one, in the Q&A session hopefully. I'd just tend to use hping pipe to a log file basically, or netcat or any other tool for the site stats stuff. Here's an example of the site stats command running on .htaccess.com, and this is just one of many many nodes inside the FTP cluster. Something to keep in mind is this node's only been up for 47 days, and it's had over 2 billion user commands. So they get a lot of FTP traffic. However, they've had 2 billion users do the user command, but they've only had 3,035 store commands. So if you basically profile the number of times a store command has been run over a period of time, you can determine when they're actually doing their uploads, and when they're doing the data port. And I'll talk about hijacking data ports and that stuff a little bit later on. The kind of the point of that is even if you can't steal their file, you can still destroy their backups. And you can see some other commands like delete, make directory, etc. The next example is a website called hacker.com, which I picked right before Block Hat because it was fun. I started profiling this site around 8 p.m., and I stopped it around like 6 a.m. or something like that, or probably 10 p.m. is when it started. I counted for the integer wrap across about a 9-hour period, something like that, 9 or 10 hours. So around 10 p.m., you can see it spikes to about 3,000, but the baseline traffic is pretty low. As I get right around midnight, you see a huge spike in traffic. This is actually some kind of automated backup process, or somebody is just debuting the crap out of that site right around midnight. This is the kind of thing you want to look for. If you're profiling a server and you want to find out when they're doing other types of activity through this method and be like, hey, something really big happens at this time, let me know what that is. This little graph was generated with one line of Ruby in 5 minutes, so if you want to know how to do it, let me know after the talk and I can show you the code for it. Then you see the traffic kind of rolls down for about 6-7 hours, and finally you can see everyone in the U.S. starts to wake up again and the traffic builds back up. If you're curious how much traffic a site has in the U.S., that's about 3 sets of IP IDs back. In that case you're actually hitting a load balancer. One server will respond back with 1000, 1001, 1002, another one is 9001, 9002, and you have to kind of keep track of both of those at the same time. So onto the external network. That was kind of our discovery techniques or discovery phase, just different techniques to keep in mind when doing a pen test to profile services, find users, find networks, find applications, just some things that work and work away inside. On the external side, usually called the crunchy candy shell or whatever you want to call it, what the administrator usually thinks they're exposing are the hosts they specify, this web server, this mail server, this application server. What they're really exposing is all those things, plus their VPN services, plus their proxy services, and plus all those different client initiated sessions. A lot of folks don't realize that the public NTP servers, if you send a command called NTP, you have every IP address, every client that's actually connected to them with a certain window of time. And there's only a finite number of public NTP servers. So what you can do is build code that basically goes out and pings each one of these servers for this model list command every five minutes, and not only do you find out when a given organization is querying the public NTP servers, how many different clients are querying it, and whether or not those clients are behind or outside of the firewall. You can just help out by looking at where you know if you send a smooth packet from that time server to that host on that source port, you'll get back to that time client. And now you can actually start doing attacks against those NTP clients themselves. So in any case where you can see the outbound UDP traffic and see those source ports, you now know what the NAT gateway mapping is, and you can actually target those applications. So I went to FTP before. I'm sure, does everyone here know what FTP works? You realize there's two connections. There's control, there's data, the data is kind of allocated based on either the server or the client. Active FTP, the client opens up a listener for that, and past FTP, the server opens up a listener and the client connects to it. So that's basically it. Going through a NAT gateway, there's all sorts of problems with active FTP. I'm not going to talk about them too much, but if you see large spikes in traffic, try scanning for the ports used by the NAT gateway, like 32K to 45K, or even 1024 to 64K, just repeatedly trying to find those open ports. A lot of times there's different types of FTP, and I'm not going to get into those here, but just keep those in mind when we're doing this kind of testing. Finally, passive FTP, this is much more common. This means the server opens up a port and the client connects to that server. If you can also connect to that server, login is like anonymous, or you just port scan the crap out of it, you can actually predict the ports that are being used in a lot of cases. Microsoft FTP is a really good example of this. Their FTP server will sequentially allocate those data ports no matter what client it is saying, oh, port 100. The next client who's doing it will get port 101. The next client will get 102. And the Microsoft FTP is smart enough that if you connect to that data port, instead of being the real client, it'll kick you off. It'll say, sorry, I'm not going to send you that data, that wasn't your data port. However, you'll still break the backup. You'll still break that transfer. So what you can do is if you profile a backup process running in the middle of the night, and you know what the endpoints are, you can find that in the recovery system. There's a tool I wrote this called the passive ag.pl. It's been around for a really long time, but it still works really well for this type of thing. So finally, moving on to attacking web servers. One thing you just don't ever make sure what you're doing, excuse me, it's not something that's a website. You always check for things like, you know, slash old, slash backup, slash admin. This should be old hat, but you can find all kinds of really cool things with it. Example, slash old. Until about a year and a half ago, it actually had directory indexing enabled. Inside the directory was a 5GIG file called backup.tar. Any guess what that was? So they finally made the directory for, excuse me, the disabled directory indexing, but there probably still was a file called that. I have no idea. I didn't actually try to download it. So that's an example of a server that's kind of been misconfigured. Just an old directory there. Some admin files, stuff like that. It's really, really prevalent. Another example that I see a lot is source control files being left on the web route. Here's a contrived example I found on the internet, just some random website that happened to have it. Basically when you check out a subversion tree or a CVS tree, it usually brings out, it brings its source control directories with it. Those directories give away things like the root of the tree, where to log in and actually get that source code. So that's a good example. Another good example is ebay.com. Almost every one of their virtual hosts had CVS slash entries exposed for a really, really long time. About a year and a half ago, they finally fixed that as well. That was useful because you didn't want to see what little new advertisements coming out. You could do that on the image server, stuff like that. So a couple quick tricks and I'm going to turn it over to Val to talk about a case study and kind of get back to the internal server and you're trying to figure out whether or not it's behind an Apache Reverse Proxy, where you have Apache working in proxy mode and essentially proxying it back to the internal server. The easiest way to do that is to just do a get request with %00 after your slash. You're done. The Apache server will actually puke back an error saying hey, you know, could not find this file, Apache version, so on, so on, so on. And if you're testing an Apache dynamic virtual hosting, what this is, instead of having to create a virtual host configuration file for every system you have on your large ISP server, you say, hey, just look in the sub directory for any file, excuse me, any directory named, the host named the client sent. So if you want to add a new v-host, you just do a make directory, www, bob's, you know, house of hardware.com, what do you want to call it? Unfortunately, what I see a lot is the global configuration of the v-host directory. And each individual sub-host or v-host may be locked down, but the main configuration is not locked down. So what you can do is if you get htp1.1, host, %00 slash, what that will do is actually return you the index of every v-host on that server. You actually get served the directory below the v-host directory. So it's a neat trick when you're testing ISPs. And with that, I'm going to turn it over to Val. Val is one of the things to think about when attacking web hosts, which are pretty good targets. In this particular case, we had a web host with thousands of sites that they were hosting, both virtual hosts like whatever.com as well as tildy slash user. And all these hosts had CGI scripts, applications for the customers. We found one particular CGI that they had put up as a demo to show people who were going to sign up with their company, you know, what kind of script is it? The other thing about this particular script is it had a directory traversal problem. This isn't a remote exploit, we can get a show with this, but we can gather a lot of intelligence about the server. So in this case, we were able to basically go through the whole server into every directory which the web server user had access to and see what they had in there, backup files, other CGI scripts, you know, whatever. And eventually what we found out was they had like hundreds of maybe even thousands of CGI scripts that were either user written or just downloaded off the internet like web hints or whatever. So what we could do once we identified these scripts is go download them ourselves and either write bugs for them or find bugs that were already well known. And we had hundreds of ways to break into the server. One of the great things about this particular server was that it was Solaris. And let me see. Yeah. It turns out that Solaris treats all the things that are on a Solaris box you can do. Cat directory name is the same as doing an LS inside the directory. The nice thing that this lets us do is over a directory traversal bug, we can treat all the directories on the Solaris server as files and enumerate everything inside of them, even if they don't have indexes available for us. And again, the %00 byte destroys everything. It's great. So we're kind of flying through material here because we want to get to the DNS servers. When you're doing a pen test, make sure you brute force not only external OSAMES, just go through the whole dictionary. But also brute force internal names. Look for sites called intranet.local.land and things like that. Intranet. where the domain is but .inter.land is the TLD. A lot of folks don't split their DNS correctly. Something you may also notice is a lot of the transaction IDs used by these DNS servers or DNS clients are available. For example, recently the bind9 server had a PRNG attack demonstrated where you can actually once you know one transaction ID in the source port of the server, you can then find out what the next transaction ID is. And what that gives you is the ability to spoof responses to a DNS cache and inject whatever hosting you want into their cache externally. So these are really good attacks. And I'll talk about some ways you can exploit this stuff a little bit later on. But pretty well, you basically, excuse me, you just brute force the response you send back and eventually get it to hit because it's only 64k possible transaction IDs and the source port is usually predictable. You can almost guarantee you can hit a birthday attack with any server that doesn't do anything specifically to prevent against it. So a lot of these new DNS servers are seeing, I think Mayor DNS is okay, but a lot of the newer ones that are kind of popping up as alternatives to binds don't protect against these types of attacks and a lot of VX work servers and VX work space appliances are used for things like VPNs, proxy servers, routers, things like that. Always little embedded network devices. The built-in DNS client in the VX work product has sequential transaction IDs and sequential source ports. So if you can commit to any of these devices or anything running VX work to do a DNS query, you can spoof the response back in and basically forge the response to it. So a lot of security vendors are actually basing VX work space, VX works OS and keep that in mind that if you see that, you can probably inject random responses or spoof responses back to the clients. For the most part these products don't do a whole lot of DNS resolution internally. These are handed off to something else, but if anything does host-based checking, that's one way to get around it. And finally, a lot of alternative DNS implementations will actually, if you send an extra response to the data you send back it will also cache that response. So you may be asking if you're a Bob Sose at metasupply.com, but you can return back Bob Sose at metasupply.com and www.cnn.com and it will cache that second entry as well. So just things to try when you're testing DNS servers. Ten minutes, all right. We're going to haul ass. Authentication relaying. So one of the great things about NTLM is that no matter what authentication implementation you have coming inbound, you can redirect that to anything outbound. So for example, if you have an NTLM enabled S&TB client connecting to you as an NTLM authentication to you, you can turn around and connect back to the S&B port on a different host entirely and just basically pass the authentication straight through and use their S&TB client to authenticate against an S&B server. By the same token, you can use an S&B incoming connection to authenticate an external exchange website or any other IS server that supports NTLM authentication. So if you can get any sort of NTLM authentication coming inbound, you can then apply that to either the incoming connection server itself, or to an external host or any other host that supports NTLM because it just passes through this generic block for the most part. So we're going to go into more of this later but keep that in mind. There's a lot of great things you can do with it. Finally, it's a little bit about social engineering and this has been beat to death, but make sure that if you're charging $50,000 for a pentest, you can afford to burn a couple CDs. I mean, if you're charging $100,000 for a pentest, you can afford to get a whole bunch of USB keys and load them up with some awesome $1 million pentest. You can go out and buy a whole bunch of Nokia in 770s. You can buy a bunch of N800s, you can buy Sharp Zoress. You can send them off to each of the CEOs saying, hey, you won this new sweepstakes. Welcome to that conference you presented at. You are the winner of this new award. Enjoy your Nokia. And the neat thing about these Nokia devices, and I'm sure David Tell will test this because he has a product based around it, is they run Linux and so they can run your exploit tools. So you can put a whole set of backdoors under one of those and, you know, give them directions of how to sync it to his network. And he syncs it in, you're back to our runs and everyone's happy. Another example I saw that was really neat is actually embedding an open WRT core into an UPS battery. So you rip the battery out, you put an open WRT core into it, you put an Ethernet switch into it, you plug it in and you just walk into a building and throw it over your shoulder and say, hey, I'm here to fix the printer. You go into the printer array, you unplug their UPS if they have one, or you just put this one inline and now you've got your own UPS battery and it's really cool and definitely keep it in mind when doing physical tests. So on to the internal network. First of all, some met bios names are magic. There's a name called WPAD. Anyone know what that means? Okay, a couple folks do. So WPAD is like the web something auto proxy discovery, actually web proxy auto discovery, something like that. That's a name that's looked at by default by Internet Explorer when it's set up in its default configuration to automatically detect your proxy, it'll look for a host called WPAD and actually there's been different bugs with it, we don't have time to cover it, but if you want to see a really funny website go to WPAD.com because for a long time they're actually the top level WPAD server for the whole Internet and they had fun with it. There's also another magic host named a CA license which means if you have a name, a host called this on the network, anybody running a CA product will try to connect you for licensing updates and you can cause all kinds of hell. So the next step, so WPAD is magic because you can exploit this web proxy auto discovery technique. You can basically convince them to connect to your web server to figure out how to proxy their outbound connections, which is awesome. However, you can also do that via DHCP. You can do that in the case where you've got a Microsoft DNS server running DHCP, you can do DHCP CD or DH client with dash H option of WPAD and it'll actually register your host name of WPAD in the local domain. So you can quickly become the outbound web proxy in the local network with this one command. It's lots of fun on Microsoft Networks. Next, so now we're going to talk about a practical example of hijacking NTNLM to get a remote shell on a fully patched Windows XP service back to system and it's pretty straightforward. Yes, it's based on SAP Relay 2 but it's all done in Metasploit in Chinese and this is really old code back in 99, 2001, but now I can do it and I can read the code. So the first thing you can do is man in the middle of outbound traffic. Lots of different ways you can do it. We talked about a lot of different ways. You can have a row access point to sit around the airport. What do you want to do? You can actually inject into tour connections and do this against tour users. What do you like? Next, you want to redirect them to an intranet website and this is an intranet in the sense that they'll still connect you for the intranet site as well because you design your proxy server to redirect all traffic, even internal traffic back to yourself. What you do here is get around the zone by that. So when they try to browse the intranet site, you go to this, which is actually a UNC link to an SMB share. So in IE 5, 6, and 7, you can just do an image source tag, backslash, batch, SSIP, share name, something in JPEG. In Firefox, before 2005, you can just do mozicon, URL, colon, file, slash, slash, slash, slash. That's actually a bug. They fixed it, but they didn't fix the last case. What I'm not going to talk about. Finally, you can use third-party plugins to do the same thing. Force them to go to UNC URL. The goal here is to connect to your system. The reason for that is once they connect to your system, you can connect back to them. So when they connect to you, you connect back to them, you ask them for their challenge, say, hey, I got this cool challenge key. Why don't you authenticate against it? And they go and do that. And you pass it back and now they're authenticated. And this actually works really well. It's not a trick, it's not a bug, it's not anything else. This is how SMB authentication works. If you don't have sign-enabled and a couple other caveats, you disconnect them, you keep the authenticated session and use that to connect to admin dollar, upload your shell code inside the executable, then use the service control manager to start that shell code as a service and then enjoy your remote shell. And that's all there is to it. It's pretty damn simple and it works. So I'll show you. So over here we've got a Windows XP service back to system. It's fully patched as of this morning. There's nothing fancy with it. It has the firewall turned on, but it does the file sharing enabled. It's also joined to a domain. So that's USB2. And the user has to have a password set, which is also pretty common in a domain or corporate environment. So what we're going to do back over here is that's good. Okay. So here's a little shell script. What the shell script does is it starts up a NetBIOS named even, which basically advertises my name as WPAD. And you can do this in a billion other ways, too. This is an easy way to do it. Next, we're going to start up a patchy. And a patchy is going to serve a file called WPAD.dat. And that file is going to have, let's see, one little JavaScript function in it that says no matter where you try to connect to, go through me as your SOC server. So we return SOC to this little syntax. You can look up a lot of stuff out of WPAD, great Wikipedia article if you want to learn more. So next thing we're going to do is run MSF console with this RC file. This RC file runs a fake SOC server. So we become that SOC server, which will then, no matter what page they request, we return the image source equal backslash, backslash, UNC URL, it's my SMD server. And then we run the SOC server that they exploit. And this thing will use the shell reverse TCP payload and use that as a payload if they connect in. So we're just going to go ahead and run that. So MSF console dash R, the RC file, there we go. So this sucker will run up. Do, do, do, do, do, do, do, do, do, do, do, do. So while that's tuning through, I'm going to go ahead and on a command shell over here, I'm going to show that if I type ping WPAD, it's going to result to that host. And it's doing local network as any Windows box. You can do the WPAD method. And I'm an idiot. Set that up. All right. So here we go. So now the exploit's running. You can see we said L host, L port, normal variables. Everything's going here. It's all running in the background. So now from the vulnerable XP system, what we're going to do is try to browse internet. So go wwwmidgetsex.com. Who knows? There could be something cool there. Hopefully it doesn't actually exist. All right. So now we can see it says waiting for. What happened is it went out, connected to my Apache web server, downloaded WPAD.dat, then decided to connect to my SOX proxy. My SOX proxy said yes, you have connected to Midgetsex. Welcome. And then it started up an HTML page that basically just had a UNC URL. And now in the background now, it's trying to negotiate SMD to my SMD Relay agent. My SMD Relay agent is connecting back to them and owning the crap out of it. So here we see all kinds of crap. And then we see we're saying, your authentication failed, give me a real password. It goes, okay, here's a real password. Thank you, drive-through. So we authenticated, we connected admin, share, upload or shell code, do that, do that, do that. Here we see in the console, we actually got a shell. And Windows went ahead and tried to keep doing it a few other times. We said, nah, we already got a shell in you. We'll leave you alone for now. So now on your console, which you can have multiple background shells do that. There we go. Session. So pretty straightforward. So just to prove that it actually is the right shell, echo we, hello to text. We go over here and look at the desktop. We see we got a broken image link. And now we go look on the desktop, we got hello to text, and it says, wee. All right. So we're running short, short on time and I don't want to take up any more of Valosmas demo times. Let me get through this real quick. Back where we were. Sorry. We still have a little bit of material still, but I think our time's up. Our time is up? We will move our entire presentation into the QA room. So everybody cram in there. Shut up. Shut up.