WEBVTT 00:06.650 --> 00:09.830 My name is Fyodor from Insecure.org. 00:09.830 --> 00:11.290 Can you guys all hear me? 00:12.270 --> 00:13.230 No? 00:13.730 --> 00:15.450 Then listen up! 00:17.890 --> 00:19.390 Alright, well... 00:21.610 --> 00:23.650 Alright, well thank you all for coming. 00:23.890 --> 00:31.050 DEF CON is always a blast, and it's an honor to be here giving the opening talk to start out the conference. 00:31.050 --> 00:34.550 This year I'm going to talk about NMAP hacking. 00:34.890 --> 00:42.270 Basically, there are a lot of security people who use NMAP but many of them don't understand its full power. 00:42.770 --> 00:48.250 And NMAP deserves a lot of the blame for this because it kind of is too helpful sometimes. 00:48.250 --> 01:04.710 If you do a scan, such as nmap-scanme.nmap.org you're leaving NMAP to worry about deciding on the scan type the timing options, the output format the target ports, the source ports and addresses, and more. 01:04.930 --> 01:22.590 While that's helpful, reducing that complexity in terms of making NMAP easy to use it's also troublesome in terms of a lot of people never explore the literally hundreds of advanced options that NMAP has for making your scan more effective. 01:22.590 --> 01:42.090 So in this presentation, I'm basically going to go over three real-world common examples and scenarios and then I'm going to demonstrate how you can use NMAP effectively to solve them, with an emphasis on options that are a little bit off the beaten path. 01:42.090 --> 01:49.110 I'm also happy to be releasing a new version of NMAP special for DEF CON. 01:49.710 --> 02:00.630 NMAP version 3.83DC13 is available at this URL here you definitely want to get the one on the web rather than the CD as it's a lot newer. 02:01.270 --> 02:06.790 It has a lot of cool features, which I'll talk about in this presentation shortly. 02:08.650 --> 02:20.950 Also, I'm going to give early warning now that this presentation does use real uncensored IP addresses and host names that's because I trust you guys not to abuse the information. 02:22.370 --> 02:22.810 Also... 02:24.310 --> 02:36.690 Okay, okay, but if there are any black hats in the room who would use this information maliciously then I'm sorry, but I'm going to have to ask you to either leave or when the IP addresses come on the screen, just cover your eyes. 02:37.390 --> 02:39.030 I'd appreciate that. 02:39.670 --> 02:46.510 Before I begin, it would help me to get an idea of how much introductory NMAP material I need to cover. 02:46.790 --> 02:55.050 So if I could get a show of hands for anyone here who has ever used NMAP All right, everyone. 02:55.110 --> 03:00.870 So we'll skip NMAP for dummies and move directly to Host Discovery. 03:05.090 --> 03:13.370 Host Discovery covers the real common case where you just want to look at a network and find all the hosts on that network that are online. 03:13.370 --> 03:19.010 Maybe you're a pen tester who just busted into a new subnet and wanted to see what machines are on. 03:19.010 --> 03:22.850 Or maybe you're a network administrator doing IT inventory. 03:22.850 --> 03:29.910 Or maybe you're going to do a more intensive scan but you want to figure out what hosts are up first so you can focus your efforts on those. 03:31.530 --> 03:39.230 NMAP used to only be able to send an ICMP echo request message and later a TCP ACK to a port. 03:40.010 --> 03:52.670 And at the time, you know, that was useful and that's still the default because there was a time when NMAP could send a ping request and expect that the vast majority of hosts would respond. 03:52.670 --> 03:55.450 Unfortunately, that time is well past. 03:56.110 --> 04:01.990 Many hosts, you know, don't respond to a ping even though the RFCs say that they should. 04:01.990 --> 04:05.770 The Internet is a much more guarded and filtered place nowadays. 04:06.050 --> 04:15.650 Fortunately, NMAP has also evolved with the times and offers a wide variety of options to make your host discovery more powerful. 04:15.650 --> 04:24.290 For example, you can send SIN probes if you want to get through a stateful firewall that only allows SINs. 04:24.490 --> 04:35.630 You can send ACK probes for those stateless firewalls that watch for SIN packets but can't tell that the ACK is not part of an established connection. 04:35.790 --> 04:44.430 UDP probes you can send and all three of these types you can send to a big list of ports in the hopes that you'll find just one of them that's responsive. 04:44.430 --> 04:52.470 Also ICMP echo requests and pings, timestamp requests, netmask requests, so you have a whole lot of options there. 04:52.690 --> 04:55.830 And you can combine those options almost arbitrarily. 04:55.830 --> 05:01.570 But with so many options, that leaves you to the question of well, what's going to be most effective? 05:01.730 --> 05:12.310 And sure, I can speculate on what might be most useful or what networks I've seen have available but the best way to answer these questions is empirical results. 05:12.310 --> 05:16.610 So let's start with what are the most valuable TCP ping ports to use? 05:16.670 --> 05:32.530 I did a scan of more than 10,000 IPs on the internet using NMAP's random target selection option and I took that and looked at just those hosts that are heavily filtered because the unfiltered ones we're going to be able to find anyway. 05:33.190 --> 05:39.490 And of those I said, hey, which hosts, which ports are most responsive to a SIN packet? 05:39.490 --> 05:43.910 And this is the list starting with the most common which is HTTP. 05:46.780 --> 05:48.700 SMTP is also popular. 05:49.100 --> 05:49.980 SSH. 05:51.280 --> 05:52.160 HTTPS. 05:52.500 --> 05:53.380 FTP. 05:54.480 --> 05:57.560 Telnet's down there, but it's nice to see it below SSH. 05:58.600 --> 06:01.680 And these are the sort of things that you would expect to see. 06:01.680 --> 06:06.760 If you have your firewalled host, you still have to have port 25 open if you want to receive mail. 06:06.760 --> 06:11.780 A lot of times they make 22 widely open so if they're off it, but Defcon's a bad example. 06:11.780 --> 06:17.620 But if something bad happens while you're away, you want to be able to connect in and remotely administer. 06:18.640 --> 06:22.220 So your best bet is to pick a variety of these. 06:23.160 --> 06:26.520 The next question then is what sort of TCP probes do I want to send? 06:26.520 --> 06:29.020 There's the SIN probes and the ACK probes. 06:29.020 --> 06:30.780 The answer is just send both. 06:30.780 --> 06:37.560 That way if it's the stateful firewall, like Microsoft.com your SIN will get through, but your ACK won't. 06:37.560 --> 06:40.540 Whereas a stateless firewall, your ACK's more likely. 06:40.540 --> 06:41.560 So send them back. 06:41.560 --> 06:44.700 All you need is one response to tell you that the host is open. 06:44.700 --> 06:45.740 So send them both. 06:46.480 --> 06:48.180 What about UDP ports? 06:48.380 --> 06:51.000 Here you have a little different idea than with TCP. 06:51.020 --> 06:56.440 With TCP, an open port is still responsive so it tells you that the host is up. 06:56.440 --> 07:02.960 With UDP, NMAP's blank UDP messages are unlikely to elicit a response from an open port. 07:03.140 --> 07:05.500 And so you don't want to hit an open one. 07:05.500 --> 07:12.800 So your best bet is probably just to pick a high port like 22,131 or whatever that's less likely to be filtered. 07:12.880 --> 07:19.040 And a little exception to the rule is you might want to try 53 as well just because DNS is so common. 07:19.340 --> 07:30.860 Yes, if it's open you probably won't get a response but sometimes administrators open it for a whole section of network and so from those machines that aren't running DNS servers you can still get through. 07:31.220 --> 07:39.040 For ping types, I would recommend an echo request and then either a timestamp request or a netmask request. 07:39.140 --> 07:44.880 The idea is that some hosts for example Google or Insecure.org will let you ping them. 07:44.880 --> 07:54.980 Whereas there are other hosts that have said hey, I'm going to block pings but they do it poorly and they forget about the sister options like timestamp request and netmask request. 07:54.980 --> 07:59.060 But the ones who block the latter are likely to block them both. 07:59.080 --> 08:05.020 So your best shot is generally to do both or to do a ping request and then one of these others. 08:05.500 --> 08:07.200 So let's put that all together. 08:07.200 --> 08:11.600 Take all of these ideas and put it into one intense discovery combination. 08:11.720 --> 08:13.940 And here's one that I would recommend. 08:13.940 --> 08:22.480 Here we're doing an echo request, timestamp a variety of SYN probes, ACK probes and also setting the source port 53. 08:22.480 --> 08:27.140 You never know when that little trick will work to get through poor configurations. 08:27.480 --> 08:33.180 One thing to note when doing this is that this is 13 probes rather than 2. 08:33.360 --> 08:38.420 And host enumeration time is going to be roughly proportional to the number of probes that you send. 08:38.700 --> 08:42.720 And so you want to consider whether it's worth it. 08:42.720 --> 08:47.700 But in many cases you really do want a comprehensive list so it's worth taking a little longer. 08:47.960 --> 08:59.180 And like I said, speculation is all well and good but when you're deciding whether you do want to spend the extra time or what's going to be most effective empirical data is the best to have. 08:59.320 --> 09:00.820 So I did a test. 09:05.230 --> 09:11.810 I used the random target option again to generate a list of 50,000 random IPs. 09:11.810 --> 09:15.850 And then I ran it and mapped with the default scan types. 09:15.850 --> 09:24.810 And it chugged away and chugged away and eventually it said, OK, out of those 50,000 IP addresses 1,770 are up. 09:24.810 --> 09:28.290 Alright, so now let's try it with the more intense discovery. 09:28.510 --> 09:36.010 We use all these probes and suddenly instead of 1,700 it gets 2,698 hosts up. 09:36.050 --> 09:42.330 So we see a 50% improvement just by adding these extra options. 09:42.590 --> 09:51.350 And yes, it did take four times as long but in many cases, if not most, it's worth it for you because you really want to find all of the hosts. 09:52.530 --> 09:52.990 And... 09:55.110 --> 10:02.350 there are a couple notes that I want to make regarding this sort of scan and these results that we've found. 10:02.450 --> 10:11.890 One is that it's not quite as exciting as it seems because some of these 2,698 hosts are going to be network artifacts. 10:11.890 --> 10:27.690 For example, in my last DEF CON talk I showed an example where a host that was a firewall was spoofing reset packets to any probe sent to port 113 on any of the hosts behind it. 10:27.830 --> 10:38.050 And so some of these are network artifacts and you'll have to use the sort of techniques I talked about last time to discern which are the artifacts and which are the actual hosts. 10:38.170 --> 10:51.250 The other thing worth noting is that these techniques will give the most improvement in a case like this where we're doing a worldwide scan over the Internet against tons of firewalls and filters and such. 10:51.250 --> 10:55.350 If you're scanning a local LAN, the defaults may work fine. 10:55.890 --> 11:03.930 But while we're speaking about scanning a local Ethernet LAN that crops up with its own big bunch of issues. 11:04.470 --> 11:12.530 Here I do an nmap command for a ping scan of a host on the Ethernet LAN that's not really up. 11:12.690 --> 11:22.750 Send IP is a new option that I'll talk about later but for now you just need to know that that does the same default behavior as all of the pre-DEF CON releases. 11:23.450 --> 11:32.510 So I run nmap and I've pasted in some ethereal output to kind of show what's going on under the covers. 11:32.510 --> 11:34.450 I give the OS an IP packet. 11:34.490 --> 11:38.750 It sends an ARP request looking for the machine immediately. 11:38.850 --> 11:50.450 Then after one second it sends yet another ARP request and after two seconds it sends a third ARP request and finally it gives up and nmap ends after just over two seconds. 11:51.250 --> 11:54.190 And there are a couple of problems that... 11:55.630 --> 11:58.050 Can you guys hear me better? 11:58.590 --> 11:59.870 All right. 11:59.870 --> 12:03.410 There are a couple problems with this two seconds. 12:03.410 --> 12:13.150 You know it may sound, oh two seconds, big deal but if you're scanning 10.0.0.0.8 that's 16 million hosts and two seconds is gonna add up. 12:13.230 --> 12:25.790 Even 192.168 is still 65,000 hosts and nmap scans these in parallel but still it's not as fast And it's wasting time waiting for these ARP requests. 12:25.850 --> 12:32.250 Another problem is that most operating systems, you know, they have an ARP table and that ARP table is finite. 12:32.430 --> 12:39.590 So when they have an incomplete entry such as this, they'll add, that ARP table will fill up. 12:39.590 --> 12:46.350 And sometimes NMAP has to wait, you know, as much as 4 minutes for those ARP entries to expire. 12:46.450 --> 12:48.550 You may have seen that if you scan a big network. 12:48.550 --> 12:53.470 NMAP is like, hey, I can't send right now, waiting 60 seconds, then waiting 120 seconds. 12:53.510 --> 12:55.270 It's very frustrating. 12:55.750 --> 13:01.990 And since scanning your own local LAN is extremely common, that's something that's worth optimizing. 13:02.510 --> 13:07.530 And so one of the features in the new NMAP is ARP scanning. 13:07.650 --> 13:11.810 The idea is give NMAP full control to send those ARP packets. 13:11.810 --> 13:15.470 That way NMAP can worry about the timing and the retransmissions. 13:15.470 --> 13:23.610 It can skip over the ARP table for the OS entirely and do the scan a lot faster. 13:23.770 --> 13:28.450 Another advantage, not only is it much faster, but it's more accurate. 13:28.570 --> 13:34.670 You know, as we've already seen, many hosts have all sorts of filters that can block your host discovery packets. 13:34.670 --> 13:39.570 But if they want to communicate on the network, they generally have to reply to ARP. 13:39.570 --> 13:43.650 So if NMAP gets an ARP reply, it knows that it's online. 13:43.650 --> 13:57.870 So here's a quick example I have here, where I scan the same machine as before with the new NMAP, and instead it sends one ARP at the beginning, and then one ARP after a tenth of a second. 13:57.870 --> 14:00.750 And then it gives up in two tenths of a second. 14:00.750 --> 14:04.990 So it takes, you know, less than an eighth of the time that it took before. 14:05.610 --> 14:12.610 I can try and do a live demonstration here, which is always risky at a conference, but we'll give it a try. 14:12.610 --> 14:15.390 So here I'm doing NMAP, a ping scan. 14:15.390 --> 14:17.510 I probably have to make this bigger, don't I? 14:18.450 --> 14:19.990 Or can you guys read it? 14:21.330 --> 14:22.190 All right. 14:33.470 --> 14:35.150 All right, huge we are. 14:35.570 --> 14:38.530 So I'm going to do a... 14:39.230 --> 14:40.750 What a mess this is. 14:40.990 --> 14:42.970 So I'm going to do a ping scan. 14:42.970 --> 14:44.810 PR is the new ARP feature. 14:44.810 --> 14:49.810 And I'm going to scan the wireless network that I'm on now with aggressive timing. 14:50.390 --> 14:51.610 And so it goes. 14:51.610 --> 14:55.830 It starts showing you the machines that are up, and it shows you their MAC addresses. 14:55.830 --> 15:00.630 Right now we're only seeing one, because I'm just scanning this short subnet. 15:00.870 --> 15:04.610 But we see that it finished and showed that Dell guy. 15:05.550 --> 15:10.390 Another tool that you can use to do this sort of scanning is THC Root. 15:10.390 --> 15:11.970 How many people have used that? 15:12.950 --> 15:16.290 It's a nice little tool by the hacker's choice. 15:16.570 --> 15:18.850 So here I'm going to do the same scan. 15:18.850 --> 15:21.310 And I'll make it huge again. 15:23.170 --> 15:24.890 With THC Root. 15:28.550 --> 15:30.690 And again, it goes through. 15:30.890 --> 15:33.450 It finds the gateway machine. 15:34.070 --> 15:35.930 And it thinks and it thinks. 15:35.930 --> 15:38.610 But you can see that it's taking a bit longer. 15:38.610 --> 15:40.650 NMAP took five seconds and it took ten. 15:40.650 --> 15:41.970 Which is no big deal. 15:41.970 --> 15:45.790 But on a large scan, you know, having it go faster is a lot helpful. 15:47.170 --> 15:53.630 But it's worth noting that while NMAP may be faster, THC Root still has a lot of great things going for it. 15:53.630 --> 15:57.070 For example, I compiled it just recently. 15:59.250 --> 16:02.070 And you can see all the configure screens. 16:02.230 --> 16:13.730 And at the end, it gives you this beautiful ASCII art of a giant monster holding a white hat severed head who's screaming, help, help, I'm just stupid white hat. 16:13.730 --> 16:15.230 Please don't hurt me. 16:15.750 --> 16:19.330 So NMAP can't quite compete with their ASCII art. 16:20.670 --> 16:22.170 Or can it? 16:22.250 --> 16:25.830 Yes, I'm pleased to announce that the new DEF CON version... 16:26.890 --> 16:29.730 Yes, we've got the ASCII art for you. 16:29.730 --> 16:31.390 It's just not quite as violent. 16:33.270 --> 16:35.010 So that's ARP scanning. 16:35.010 --> 16:39.010 And another feature I added just for you guys is ARP spoofing. 16:39.110 --> 16:47.930 When you've been kicked off as many networks as I have, you start to appreciate the values of stealth and misdirection. 16:47.930 --> 16:54.130 So say you're sitting in a conference room and you've got the only ThinkPad. 16:54.290 --> 16:55.610 Unlikely, I know. 16:55.970 --> 17:01.630 And all of a sudden, a big scan starts and everyone sees the MAC address is registered to IBM. 17:01.710 --> 17:03.910 You know, heads will turn in your direction. 17:04.110 --> 17:08.210 So with the new spoofing option, I did this at the hotel last night. 17:08.350 --> 17:24.190 I specify spoof MAC Apple and NMAP looks through the OUI table, finds the MAC prefix registered to the company you specify, fills out the last three bytes randomly, and then you can point at the Apple guy and say, it must be him. 17:29.180 --> 17:30.060 Thanks. 17:31.600 --> 17:34.520 You can also specify it, you know, in other formats. 17:34.520 --> 17:39.500 If you want to specify a specific MAC address or just give another prefix, it'll fill in the rest. 17:39.500 --> 17:43.200 Or just give it zero and it'll give you a fully random MAC. 17:43.200 --> 17:46.260 And it shows you down here what MAC that it selected. 17:49.100 --> 17:51.460 So that's basically host discovery. 17:51.460 --> 17:54.600 As you can see, there are a lot of different options that you can do there. 17:54.600 --> 17:56.500 A lot of different things to play with. 17:56.520 --> 18:02.660 And by manipulating these different options, you can get much faster and more accurate results. 18:02.960 --> 18:07.180 Now let's look at another common scan. 18:07.180 --> 18:09.240 And that's single host discovery. 18:09.660 --> 18:13.340 Say a new vulnerability comes out in some product. 18:13.340 --> 18:20.600 You want to scan your network before the bad guys can and identify all instances of the vulnerable product. 18:20.600 --> 18:29.600 Or maybe there's a new worm going around and you want to scan to find infected hosts before they can do much damage so you can quarantine them. 18:29.700 --> 18:37.640 Or maybe you're doing forensics on a compromised host and you find that they've left a backdoor open on some unusual port. 18:38.040 --> 18:44.260 Well, scan your network real quick and maybe you'll find other compromised machines that have the same backdoor. 18:44.260 --> 18:50.320 So here we're going to do an example of this, which is a little bit unusual, but basically covers the idea. 18:55.600 --> 19:02.600 Our mission statement is to locate web servers on the playboy.com network offering free images. 19:03.540 --> 19:11.540 The idea here is that I was thinking, hey, you know, they charge $10 a month for their content or whatever and I'm a cheapskate. 19:11.620 --> 19:19.520 Maybe they have a development server or a staging server somewhere where you can download all the images for free. 19:19.720 --> 19:21.400 You know, it's worth a try. 19:21.700 --> 19:23.320 So how are we going to do this? 19:23.320 --> 19:26.240 Well, first we need the address to scan, and that's pretty obvious. 19:26.240 --> 19:30.080 Just do a lookup on Aaron for netblocks owned by Playboy. 19:30.340 --> 19:35.740 The first one we get is this slash 20 of 4,096 hosts. 19:35.780 --> 19:41.860 There are a lot more netblocks they have, but for this example, that's enough for us. 19:42.440 --> 19:44.960 And so let's give it an initial try. 19:44.960 --> 19:46.280 We're going to do nmap. 19:46.280 --> 19:49.400 We'll say don't ping because we're only scanning one port. 19:49.400 --> 19:51.680 The ping would take longer than the scan. 19:52.140 --> 19:53.720 The port is 80. 19:53.900 --> 19:59.200 Save the results in grepable format so we can easily grep out the open servers. 19:59.200 --> 20:00.740 And then we give it the network. 20:00.740 --> 20:05.060 And it chugs along and it completes, but it takes 20 minutes. 20:05.280 --> 20:10.180 You know, even for 4,096 hosts, you know, that's longer than I want to wait. 20:10.600 --> 20:13.480 So how can we speed that up? 20:13.480 --> 20:19.400 One thing you can do is help by giving nmap timing information that it is trouble getting itself. 20:19.420 --> 20:24.800 On a responsive network, on your local LAN or whatever, you can usually... 20:24.800 --> 20:32.240 nmap is able to calculate its own response times based on the responses it's getting and usually optimize those pretty effectively. 20:32.240 --> 20:40.580 But when you're scanning over the Internet on a highly filtered network, nmap's not actually getting much responses. 20:40.580 --> 20:47.360 And so it doesn't really have a good idea of how long it has to wait before it can time out and retransmit. 20:47.700 --> 20:54.160 So the idea here is we'll try and figure out some of that ourselves and then we'll pass that information along to nmap. 20:54.280 --> 20:56.300 So I look for hosts on the network. 20:56.300 --> 21:00.980 First I try their web server and I see that that's on a different IP, so that's no good. 21:01.020 --> 21:07.860 So then I look for MX servers and we lucked out, there are two of them that are both on the networks we're trying to scan. 21:08.060 --> 21:14.860 Normally I might just take one host on the network, but here, you know, we don't know a lot about the network configuration. 21:15.000 --> 21:24.760 And also given the names, we can tell that this one's probably in Los Angeles and this one's in Chicago, so the latencies are likely to differ dramatically. 21:24.820 --> 21:26.880 So how do we figure out the latencies? 21:26.940 --> 21:28.780 Well, let's ping the hosts. 21:29.400 --> 21:33.500 Well, we try that, but they both say 100% packet loss. 21:33.500 --> 21:35.000 They're blocking our pings. 21:35.040 --> 21:36.400 Well, that's a bummer. 21:36.860 --> 21:41.020 But, you know, they're mail servers, and so they've got to have port 25 open. 21:41.420 --> 21:48.040 So let's use HPing 2 to do a TCP ping of those ports and see how long that takes. 21:48.200 --> 22:00.160 So we say HPing 2, send a SYN to port 25, like we're opening a connection, send five of them, and we do it to both the Chicago and the LA networks. 22:00.980 --> 22:10.440 And here, the information you really want is not the fastest time, it's not the average time, it's the longest time that any of those pings take. 22:10.480 --> 22:13.020 Because you want to be a little bit conservative here. 22:13.020 --> 22:21.580 If you try and get too aggressive, you'll actually make the scan take longer because Nmap will be retransmitting when the response is in transit. 22:21.860 --> 22:33.520 So even though the longest we saw out of these two was 61 milliseconds, you know, LA is a lot faster because I was scanning from California, we're going to pick a bit higher numbers to be on the safe side. 22:34.040 --> 22:40.400 So we're going to say the max RTT timeout is 200, so we'll wait up to a fifth of a second. 22:40.480 --> 22:48.160 And we tell Nmap to start out with 150 milliseconds, so that Nmap will only go up to 200 if it needs to. 22:48.160 --> 22:51.660 And Nmap can still go faster if it determines that it can. 22:51.800 --> 22:55.060 Another optimization is to say scan in bigger groups. 22:55.060 --> 22:59.620 We're going to specify a minimum host group size of 512. 22:59.960 --> 23:13.380 That breaks up the 4,096 machines into 8 groups of 512 and allows Nmap to go much faster by more efficiently handling them in larger groups. 23:13.760 --> 23:16.340 And the rest of the options are pretty much the same. 23:16.340 --> 23:17.800 So how long does that take? 23:17.800 --> 23:23.060 Nmap chugs away and it still takes almost 15 minutes. 23:23.140 --> 23:25.820 That's better than 20 by a long shot. 23:25.820 --> 23:29.820 But let's be honest, when I'm looking for these free images, I'm not a patient guy. 23:30.660 --> 23:32.520 This is an urgent matter. 23:32.520 --> 23:38.080 And so I say, how can we make it a bit faster here? 23:38.840 --> 23:43.120 Well, think about what Nmap is doing under the covers in this case. 23:43.180 --> 23:47.140 Nmap, you may know, does reverse DNS resolution by default. 23:47.480 --> 23:53.400 And when I'm doing P0 scans, no ping, that means that Nmap is considering all of the hosts up. 23:53.400 --> 23:57.740 And so it's doing a reverse DNS resolution on every host. 23:57.780 --> 24:04.060 And reverse DNS, I'm afraid, is one of the few Nmap functions that's not yet parallelized. 24:04.060 --> 24:06.620 So that may be taking quite a lot of time. 24:07.040 --> 24:13.360 So I do the same scan, but this time I add hyphen N to get rid of reverse DNS resolution. 24:13.620 --> 24:19.980 And here we see that it only takes about three minutes, which is perfect, because that's about as long as I last. 24:20.520 --> 24:32.520 And so, by just manipulating these different values, we've been able to reduce the scan time from 20 minutes to only three. 24:32.720 --> 24:33.940 But enough about timing. 24:33.940 --> 24:35.300 Let's look at the results. 24:36.480 --> 24:43.160 We did that big scan of 4,000 IPs, but we only found two that are open. 24:43.320 --> 24:46.500 Well, that was sort of a little bit worrisome, but you never know. 24:46.500 --> 24:47.760 Maybe they're good ones. 24:47.800 --> 24:49.580 Let's take a look in Firefox. 24:56.140 --> 25:01.640 So we'll go to the first one, which is 216.163.140.20. 25:03.080 --> 25:07.160 And we see Microsoft Outlook Web Access. 25:07.660 --> 25:15.320 Now, that would be really exciting if we were trying to break into their network, but it's not very gratifying for our particular goal here. 25:16.680 --> 25:26.240 What this does tell us is that, hey, maybe the network we scanned was the corporate network when we really should have been scanning the production network. 25:27.200 --> 25:33.300 It is nice to note their cute little Playboy mail logo up in the URL bar. 25:35.200 --> 25:39.720 But all is not lost because we still have one more site. 25:39.720 --> 25:48.320 And I'm very pleased to report that that one has gigabytes of free images that I downloaded immediately upon download. 25:52.460 --> 25:55.440 In fact, I think I'll even show you. 25:57.400 --> 26:05.220 So this one is 142.135. 26:05.680 --> 26:08.180 And so here it chugs away. 26:08.680 --> 26:13.680 And we see FreeBSD ISO images right over here. 26:13.680 --> 26:17.740 We see Fedora images, lots of them. 26:17.740 --> 26:23.460 And if you're on the kinky side of things, they've got the whole Perl network right around here. 26:23.460 --> 26:28.300 So whatever your tastes, this is a great site to download images. 26:28.300 --> 26:38.920 And I would also like to mention this is also named mirrors.playboy.com and it actually is a real valuable site that I use when I need a download. 26:40.980 --> 26:44.740 So we can say mission accomplished on that goal. 26:44.920 --> 26:50.780 But let's look at another quick single-service discovery option. 26:50.780 --> 26:53.060 And that's NMAP's version detection. 26:53.420 --> 27:01.080 In many cases, you want to not just know what ports open, but you want to find out the exact service that's listening. 27:01.100 --> 27:11.860 And so with version detection, instead of browsing the well-known ports table, NMAP actually interrogates the ports and tries to figure out what's running there. 27:11.860 --> 27:22.140 And so that way you can maybe distinguish the vulnerable services from the invulnerable ones or find the services even if they're listening on a non-default port. 27:22.480 --> 27:31.980 And NMAP now has well over a thousand different version detection signatures to identify all sorts of crazy things. 27:32.320 --> 27:40.340 In this example, this is just one that someone sent last year when MyDoom was basically causing havoc. 27:40.600 --> 27:44.020 Right when it was released, he posted this to the NMAP dev. 27:44.020 --> 27:50.200 Here's a probe you can add so that you can identify compromised machines or infected machines. 27:50.640 --> 28:01.080 So I'm just showing this as an example to show that it's actually pretty easy to add your own custom identification if you want to add services that aren't in the official file. 28:01.600 --> 28:03.960 So you just say, do a TCP probe. 28:03.960 --> 28:05.400 We'll call it MyDoom. 28:05.400 --> 28:08.600 These two bytes are the data that you need to send. 28:08.820 --> 28:11.540 These are the ports that it normally listens on. 28:11.640 --> 28:14.180 And you'll match for service MyDoom. 28:14.180 --> 28:18.580 If you get this back in the response, the program is MyDoom. 28:18.580 --> 28:22.380 And for the version number, he just put, you know, the date it was found in the wild. 28:22.880 --> 28:25.220 So that's a real useful thing to add. 28:25.220 --> 28:31.640 And to add it, all you do is add this little s, capital V, and NMAP does the rest of the work for you. 28:32.340 --> 28:36.020 So that's enough for single-service scanning. 28:36.360 --> 28:39.340 Let's try something a little different that's also common. 28:39.340 --> 28:41.700 What if you want to defeat a firewall? 28:41.700 --> 28:48.680 Sometimes you really want to look at what ports are open on a machine, but those pesky firewalls can get in the way. 28:48.920 --> 28:53.340 And NMAP has some techniques that can help you resolve that problem. 28:53.340 --> 28:55.160 So we've got another mission. 28:55.460 --> 29:01.280 This time we want to discern the open TCP ports on docserv.caldera.com. 29:01.500 --> 29:11.800 Now I was a little reticent about using SCO as an example because at one time, they were kind of considered a threat to free software. 29:11.800 --> 29:15.440 But lately, you know, their litigation is in shambles. 29:15.440 --> 29:17.780 And they're pretty much a laughingstock. 29:17.780 --> 29:20.440 And so it feels kind of like beating a dead horse. 29:21.320 --> 29:31.740 The problem is, it's so useful because every time I want to find like really pathetic network configuration, you know, I can find an example right there. 29:32.560 --> 29:36.020 Also, they are a fun horse to beat, so let's do it. 29:38.040 --> 29:42.740 If we want to find the open ports, the first thing we're going to want to do is a SIN scan. 29:43.340 --> 29:44.740 You know, that makes sense. 29:44.740 --> 29:45.560 It's the default. 29:45.560 --> 29:47.000 It's often the most useful. 29:47.040 --> 29:49.160 So we do a SIN scan against the machine. 29:49.160 --> 29:55.880 We find port 80 open, port 5007 open, and 113 is closed. 29:55.880 --> 29:57.240 So did we do it? 29:57.240 --> 29:58.180 Well, not really. 29:58.180 --> 30:05.900 Because while we figured out the state of three ports, the 1660 remaining ones are in the port filtered, are in the state filtered. 30:05.900 --> 30:08.100 So we don't know if they're open or closed. 30:08.220 --> 30:16.620 It's worth noting that in a real scenario, you would probably want to add hyphen P hyphen, so that it will scan all 65,000 ports. 30:16.680 --> 30:22.560 But just like with the Playboy example, I'm limiting it just to be a useful example. 30:22.720 --> 30:27.700 So we've got three, but there's still a huge number that we've not really determined. 30:27.720 --> 30:32.440 Those ports could be open and exploitable, those 1660, or they could be closed. 30:32.440 --> 30:33.600 We just don't know. 30:33.600 --> 30:35.380 So what do we want to try next? 30:36.640 --> 30:38.540 Let's try a different type of scan. 30:38.540 --> 30:40.420 Let's try the FIN scan. 30:40.420 --> 30:53.240 That basically sends a FIN packet, and if it receives a reset back, the port is probably closed, whereas if we get nothing back, the port is either filtered or open. 30:53.240 --> 31:00.980 And this isn't true of all machines, since some of them aren't susceptible to this issue, but it's true of a lot of them, so it's worth trying. 31:01.100 --> 31:12.560 So we try it against DocServe, and as you can see, we get a whole big long list of ports that are either open or filtered, and then the rest of them are in the state closed. 31:12.860 --> 31:14.420 So that's very interesting. 31:14.420 --> 31:21.300 It's limited the number of ports quite a bit here to just a few dozen that are either open or filtered. 31:21.380 --> 31:31.240 And one would hope that most of those are actually in the filtered state, because it would be pretty pathetic to have that many open, but this is SCO, so you never really know. 31:31.680 --> 31:39.100 So how are we going to figure out, differentiate, because it's a very important distinction, whether the port is open or filtered. 31:39.180 --> 31:42.160 Well, let's try yet another type of scan against them. 31:48.120 --> 31:52.200 This time, we're going to try an ACK scan against DocServe. 31:52.220 --> 32:07.940 And that sends an ACK packet, and if it receives a reset back, it knows that the port is unfiltered, because it got a response, whereas if it receives nothing back, or an ICMP port filtered message, it knows that it's filtered. 32:08.600 --> 32:11.140 And so this gives us a lot more information. 32:11.140 --> 32:18.640 Here, the vast, vast majority are unfiltered, but it tells us that just two of them are filtered. 32:19.220 --> 32:27.580 So what's an interesting thing you can do is combine those by looking at the last results and comparing them with these. 32:27.580 --> 32:29.880 For example, look at port 135. 32:29.960 --> 32:35.980 Here it says filtered, whereas before, 135 was open or filtered. 32:35.980 --> 32:41.860 Well, if you kind of take the logical end of those, you see that it's got to be filtered. 32:42.860 --> 32:47.040 Similarly, 1434 looks like it's really filtered. 32:47.240 --> 32:48.860 Let's take another example. 32:48.860 --> 32:51.840 Say you want to know about the SSH port, 22. 32:51.840 --> 32:57.680 In this case, it says that 22 is unfiltered, because it's one of all these other ports. 32:58.220 --> 33:02.260 And in this case, we see 22 is open or filtered. 33:02.260 --> 33:10.060 So if we have open or filtered on one scan, and unfiltered on the other, you know, that just leaves open. 33:10.640 --> 33:28.580 And so, if you combine all of these different results from the two scans, what the hypothesis is, is that 135 and 1434 are filtered, but all of these other ones on this huge list are open. 33:29.380 --> 33:32.420 And so, you know, that tells you a lot. 33:32.420 --> 33:38.960 And you can see a little bit of confirmation in terms of the two that we know are open to the SIN scan, 80 and 507. 33:39.300 --> 33:44.400 You see here as well, 80 and 507 in the open or filtered. 33:44.400 --> 33:47.100 So we have a pretty good idea about what we're seeing. 33:47.100 --> 33:48.720 But networks can be tricky. 33:48.720 --> 33:53.160 It's always good to check your results, try different things, see what's matching up. 33:53.160 --> 33:55.600 So let's try yet another type of scan. 33:55.600 --> 34:00.020 And that's the Windows scan, which is a little-known scan technique. 34:00.020 --> 34:18.800 But it's very similar to the ACK scan, except that it noticed a property that certain hosts have where when you send, when they send a reset back from a probe to one of their open ports, they set the window as they would if it was a SIN ACK for a real connection. 34:18.800 --> 34:24.460 Whereas, when they're sending a reset back from a closed port, they set the window to zero. 34:24.660 --> 34:32.220 So by looking at that window, TCP receive window value carefully, we can determine which of the ports are open and which are closed. 34:32.220 --> 34:44.080 So we do an ACK scan against this machine, and sure enough, like we thought, all the ports are open except 135 is filtered and I think 443 is the other one. 34:44.080 --> 34:50.080 Or no, it was my MS SQL was the other one, 1434 was filtered. 34:50.080 --> 34:52.420 So that sort of confirms our results now. 34:52.420 --> 34:57.700 We've tried a lot of different things, and now we have a good idea where they're open. 34:58.360 --> 35:09.020 And it kind of shows the value of taking the SIN scan and seeing it doesn't get you all the results that you want, so you just keep trying different things until you meet your goals. 35:10.000 --> 35:13.620 So that was basically our three missions. 35:13.820 --> 35:22.960 And so now I'm going to just give a quick overview, since I've got, oh, about five minutes, of some of the new features that I have in the DEF CON version. 35:23.280 --> 35:28.520 There's the ARP scanning that we've already talked about, the MAC spoofing. 35:28.520 --> 35:35.740 One nice new feature is raw Ethernet packet sending, because raw IP packets can be a huge mess. 35:35.740 --> 35:43.360 You know, a lot of systems screw them up, and Microsoft, even worse, they recently banned them with their Windows XP SP2. 35:43.360 --> 35:45.620 So now we're saying, well, screw you, Microsoft. 35:45.620 --> 35:50.500 We're just going to send at a lower level, and send the Ethernet packets directly. 35:50.500 --> 35:52.300 And that should be a lot faster. 35:52.620 --> 36:05.800 It also has 350 new OS fingerprints, for a total of 1,690 from this ACC Amazon WAN concentrator to the Zyxel Zywall. 36:06.280 --> 36:20.040 250 new version detection signatures, so there are now 1,312 of those, covering 212 protocols, such as SMTP, SNMP, Kazaa, all sorts of bizarre things. 36:20.080 --> 36:26.420 It integrates Doug Song's excellent LibDNet, which helps with the raw Ethernet packets sending. 36:27.400 --> 36:32.620 Version detection now helps you find OS information. 36:32.760 --> 36:38.140 So the version detection now can find three extra things in many cases. 36:38.140 --> 36:49.300 If it sees a service that only works on Windows, or if the service responds with a certain platform name, it can now report, Nmap now reports that next to the OS detection results. 36:49.300 --> 36:54.740 The OS detection results are this, and version detection says it looks like this OS. 36:54.780 --> 37:00.040 And some people would say, hey, combine those to get just one result. 37:00.040 --> 37:04.660 But in reality, what you really want is to have both, because they may be distinct. 37:04.660 --> 37:22.540 If you're scanning a firewall that proxies to an IIS server, you should get checkpoint firewall one or whatever for the OS detection results via TCP IP fingerprinting, whereas it should say Windows for the application version detection results. 37:22.540 --> 37:23.500 And that's pretty common. 37:23.500 --> 37:31.720 You'll get the same thing if you're scanning someone's Linksys network, for example, where they've forwarded different ports to different machines. 37:33.440 --> 37:40.140 Version detection also now gives device information and host name information, which can be valuable. 37:40.180 --> 37:46.680 I broke the Windows support, I'm afraid, for the moment, but that may be fixed eventually. 37:47.540 --> 37:52.480 And when it is fixed, though, we'll have the advantages of the raw packet sending. 37:53.060 --> 38:02.580 But for the Defcon release, I figured the priority was to get the Unix versions out, and I've tested this one on Linux, OSX, Solaris, FreeBSD. 38:03.900 --> 38:09.300 And then there's also quite a few more features, which you can find in the changelog. 38:09.860 --> 38:11.420 What's coming next? 38:11.420 --> 38:17.780 Well, I'm happy to report that Google has sponsored 10 students to work on Nmap for the summer. 38:17.940 --> 38:24.940 And yeah, they're student programmers, but some of them are serious students, like PhD students in doing very relevant research. 38:25.160 --> 38:29.180 And so that's pretty exciting, and they're working on a whole lot of projects. 38:29.180 --> 38:36.500 There were 233 applications, and I picked the top 10, and we worked out some pretty cool projects. 38:36.700 --> 38:44.380 One of them is Ncat, which is sort of a re-implementation of Netcat, that adds a bunch of new features that I've wanted. 38:44.380 --> 38:59.240 You know, things like SSL, IPv6, password protection, there's a connection brokering feature, so that two hosts behind a NAT can connect into the Netcat listener, and then it brokers the communications between them. 38:59.240 --> 39:01.000 You know, all sorts of cool features. 39:01.000 --> 39:06.700 And you'll find a man page that he's posted so far on the Nmap dev list. 39:06.780 --> 39:09.060 And he's working on the implementation. 39:09.320 --> 39:10.520 New GUIs. 39:10.520 --> 39:17.540 And GUIs sort of sometimes have a reputation as, oh, this is just for newbies who can't remember those hundreds of Nmap options. 39:17.780 --> 39:20.900 But these are more advanced user GUIs. 39:21.480 --> 39:23.460 They're mostly results viewers. 39:23.460 --> 39:26.520 So you've scanned tens of thousands of machines. 39:26.520 --> 39:35.520 These make it easier to identify which machines have this port open, or compare the difference between two scans and show me what's changed. 39:35.520 --> 39:37.100 You know, features like that. 39:37.120 --> 39:43.280 And there are actually two of these SOC students writing independent GUIs. 39:43.740 --> 39:45.300 Potential scripting language. 39:45.300 --> 39:47.500 I'm not sure if that's going to work out yet or not. 39:47.500 --> 39:49.620 But this guy is working on that. 39:49.920 --> 39:54.460 And when that is added, we'll probably use that for host discovery stuff. 39:54.460 --> 40:01.360 Information gathering as opposed to, you know, trying to add a thousand different vulnerability detection modules. 40:01.360 --> 40:04.660 We'll focus on, hey, have a script that does trace route. 40:04.660 --> 40:07.580 Have a script that checks whether a proxy is open. 40:07.580 --> 40:17.900 Have a script for all these different things that it can look up once Nmap has determined the OS and port service version and such. 40:18.580 --> 40:21.220 Windows performance is a big priority. 40:21.600 --> 40:28.940 Also I've been chugging away at my Nmap book, which has taken a long time, but I'm pleased to report progress. 40:29.700 --> 40:36.260 I've got more than 200 pages of it here now , and I think it's looking out to be pretty good. 40:37.220 --> 40:48.060 Given how slow publishing is, you know, it'll probably be six months, but I've added a bunch of cool network scanning goodies and corny jokes so it'll be great. 40:49.520 --> 40:59.740 There's a hyphen hyphen reason option I would like to add , so that Nmap can say , hey, we think this port is closed because we received a reset back. 40:59.740 --> 41:09.260 We think it's filtered because we received nothing back , or because we received an ICMP port unreachable or destination unreachable message back. 41:09.360 --> 41:13.840 So that'll be useful for more understanding what's going on under the covers. 41:13.980 --> 41:16.540 And then I might add proxy and sock scanning. 41:17.380 --> 41:21.300 So that's basically my presentation, which is good because I'm about out of time. 41:21.300 --> 41:24.220 I'll just take two questions here, if anyone has them. 41:29.900 --> 41:32.500 Yes, I'll put the slides... 41:37.770 --> 41:38.510 Yeah. 41:38.870 --> 41:43.490 Yes, docserv.caldera.com No. 41:44.370 --> 41:53.470 Right now I have the new version of Nmap up here at presentation slash defcon.13 and I'll put the slides up there shortly as well. 41:53.490 --> 41:55.030 Thank you very much.