[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:26.790] DEF CON is always a blast, and it's an honor to be here [00:26.790 --> 00:31.050] 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:39.370] Basically, there are a lot of security people who use NMAP [00:39.370 --> 00:42.270] but many of them don't understand its full power. [00:42.770 --> 00:44.890] And NMAP deserves a lot of the blame for this [00:44.890 --> 00:48.250] because it kind of is too helpful sometimes. [00:48.250 --> 00:52.470] If you do a scan, such as nmap-scanme.nmap.org [00:52.470 --> 00:56.630] you're leaving NMAP to worry about deciding on the scan type [00:56.630 --> 00:59.690] the timing options, the output format [00:59.690 --> 01:04.710] the target ports, the source ports and addresses, and more. [01:04.930 --> 01:08.610] While that's helpful, reducing that complexity [01:08.610 --> 01:10.730] in terms of making NMAP easy to use [01:11.370 --> 01:15.570] it's also troublesome in terms of a lot of people never explore [01:15.570 --> 01:19.250] the literally hundreds of advanced options that NMAP has [01:19.250 --> 01:22.590] for making your scan more effective. [01:22.590 --> 01:26.010] So in this presentation, I'm basically going to go over [01:26.770 --> 01:31.150] three real-world common examples and scenarios [01:31.850 --> 01:35.170] and then I'm going to demonstrate how you can use NMAP effectively [01:35.170 --> 01:39.230] to solve them, with an emphasis on options [01:39.690 --> 01:42.090] that are a little bit off the beaten path. [01:42.090 --> 01:47.130] I'm also happy to be releasing a new version of NMAP [01:47.130 --> 01:49.110] special for DEF CON. [01:49.710 --> 01:55.410] NMAP version 3.83DC13 is available at this URL here [01:55.410 --> 01:58.610] you definitely want to get the one on the web rather than the CD [01:58.610 --> 02:00.630] as it's a lot newer. [02:01.270 --> 02:04.310] It has a lot of cool features, which I'll talk about [02:04.310 --> 02:06.790] in this presentation shortly. [02:08.650 --> 02:11.410] Also, I'm going to give early warning now [02:11.410 --> 02:16.990] that this presentation does use real uncensored IP addresses and host names [02:17.550 --> 02:20.950] that's because I trust you guys not to abuse the information. [02:22.370 --> 02:22.810] Also... [02:24.310 --> 02:26.970] Okay, okay, but if there are any black hats in the room [02:26.970 --> 02:29.210] who would use this information maliciously [02:29.210 --> 02:32.370] then I'm sorry, but I'm going to have to ask you to either leave [02:32.370 --> 02:36.690] 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:42.470] Before I begin, it would help me to get an idea [02:42.470 --> 02:46.510] of how much introductory NMAP material I need to cover. [02:46.790 --> 02:50.170] So if I could get a show of hands for anyone here who has ever used NMAP [02:52.710 --> 02:55.050] All right, everyone. [02:55.110 --> 02:56.790] So we'll skip NMAP for dummies [02:56.790 --> 03:00.870] and move directly to Host Discovery. [03:05.090 --> 03:07.910] Host Discovery covers the real common case [03:07.910 --> 03:09.810] where you just want to look at a network [03:09.810 --> 03:13.370] and find all the hosts on that network that are online. [03:13.370 --> 03:16.270] Maybe you're a pen tester who just busted into a new subnet [03:16.950 --> 03:19.010] 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:24.930] Or maybe you're going to do a more intensive scan [03:24.930 --> 03:27.230] but you want to figure out what hosts are up first [03:27.230 --> 03:29.910] so you can focus your efforts on those. [03:31.530 --> 03:35.510] NMAP used to only be able to send an ICMP echo request message [03:35.510 --> 03:39.230] and later a TCP ACK to a port. [03:40.010 --> 03:42.290] And at the time, you know, that was useful [03:42.290 --> 03:45.510] and that's still the default [03:45.510 --> 03:48.790] because there was a time when NMAP could send a ping request [03:48.790 --> 03:52.670] 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 --> 03:58.430] Many hosts, you know, don't respond to a ping [03:58.430 --> 04:01.990] 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:08.830] Fortunately, NMAP has also evolved with the times [04:08.830 --> 04:12.050] and offers a wide variety of options [04:12.050 --> 04:15.650] to make your host discovery more powerful. [04:15.650 --> 04:17.850] For example, you can send SIN probes [04:18.630 --> 04:22.030] if you want to get through a stateful firewall [04:22.030 --> 04:24.290] that only allows SINs. [04:24.490 --> 04:26.130] You can send ACK probes [04:27.330 --> 04:29.350] for those stateless firewalls [04:29.350 --> 04:32.610] that watch for SIN packets but can't tell [04:32.610 --> 04:35.630] that the ACK is not part of an established connection. [04:35.790 --> 04:37.390] UDP probes you can send [04:37.390 --> 04:40.670] and all three of these types you can send to a big list of ports [04:40.670 --> 04:44.430] in the hopes that you'll find just one of them that's responsive. [04:44.430 --> 04:47.430] Also ICMP echo requests and pings, [04:47.430 --> 04:50.190] timestamp requests, netmask requests, [04:50.190 --> 04:52.470] 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 --> 04:59.170] But with so many options, that leaves you to the question of [04:59.170 --> 05:01.570] well, what's going to be most effective? [05:01.730 --> 05:04.910] And sure, I can speculate on what might be most useful [05:05.210 --> 05:07.930] or what networks I've seen have available [05:07.930 --> 05:12.310] 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:19.730] I did a scan of more than 10,000 IPs [05:19.730 --> 05:21.570] on the internet using [05:21.570 --> 05:23.810] NMAP's random target selection option [05:23.810 --> 05:26.770] and I took that and looked at just those hosts [05:27.110 --> 05:30.470] that are heavily filtered because the unfiltered ones [05:30.470 --> 05:32.530] we're going to be able to find anyway. [05:33.190 --> 05:36.330] And of those I said, hey, which hosts, [05:36.330 --> 05:39.490] which ports are most responsive to a SIN packet? [05:39.490 --> 05:42.110] And this is the list starting with the most common [05:42.110 --> 05:43.910] which is HTTP. [05:46.780 --> 05:49.980] SMTP is also popular. SSH. [05:51.280 --> 05:53.380] HTTPS. FTP. [05:54.480 --> 05:57.560] Telnet's down there, but it's nice to see it below SSH. [05:58.600 --> 06:00.120] And these are the sort of things [06:00.120 --> 06:01.680] that you would expect to see. [06:01.680 --> 06:05.200] If you have your firewalled host, you still have to have port 25 open [06:05.200 --> 06:06.760] if you want to receive mail. [06:06.760 --> 06:09.160] A lot of times they make 22 widely open [06:09.160 --> 06:11.780] so if they're off it, but Defcon's a bad example. [06:11.780 --> 06:15.380] But if something bad happens while you're away, you want to be able to connect in [06:15.380 --> 06:17.620] and remotely administer. [06:18.640 --> 06:22.220] So your best bet is to pick a variety of these. [06:23.160 --> 06:24.300] The next question then is [06:24.300 --> 06:26.520] 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:35.200] That way if it's the stateful firewall, like Microsoft.com [06:35.200 --> 06:37.560] 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:42.840] So send them back. All you need is one response [06:42.840 --> 06:45.740] to tell you that the host is open. 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:53.820] With TCP, an open port is still responsive [06:54.320 --> 06:56.440] so it tells you that the host is up. [06:56.440 --> 06:59.360] With UDP, NMAP's blank UDP messages [06:59.360 --> 07:02.960] 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:07.820] So your best bet is probably just to pick a high port [07:07.820 --> 07:10.080] like 22,131 or whatever [07:10.780 --> 07:12.800] that's less likely to be filtered. [07:12.880 --> 07:16.700] And a little exception to the rule is you might want to try 53 as well [07:16.700 --> 07:19.040] just because DNS is so common. [07:19.340 --> 07:21.500] Yes, if it's open you probably won't get a response [07:21.500 --> 07:25.760] but sometimes administrators open it for a whole section of network [07:25.760 --> 07:29.000] and so from those machines that aren't running DNS servers [07:29.000 --> 07:30.860] you can still get through. [07:31.220 --> 07:34.600] For ping types, I would recommend an echo request [07:34.600 --> 07:39.040] and then either a timestamp request or a netmask request. [07:39.140 --> 07:40.760] The idea is that some hosts [07:40.760 --> 07:42.980] for example Google or Insecure.org [07:42.980 --> 07:44.880] will let you ping them. [07:44.880 --> 07:47.440] Whereas there are other hosts that have said [07:47.440 --> 07:50.060] hey, I'm going to block pings but they do it poorly [07:50.060 --> 07:53.440] and they forget about the sister options like timestamp request [07:53.440 --> 07:54.980] 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:01.220] So your best shot is generally to do both [08:01.220 --> 08:05.020] 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:16.660] Here we're doing an echo request, timestamp [08:17.300 --> 08:19.460] a variety of SYN probes, ACK probes [08:19.460 --> 08:22.480] 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:29.320] One thing to note when doing this [08:29.320 --> 08:33.180] is that this is 13 probes rather than 2. [08:33.360 --> 08:35.420] And host enumeration time is going to be [08:35.420 --> 08:38.420] 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:45.380] But in many cases you really do want a comprehensive list [08:45.380 --> 08:47.700] so it's worth taking a little longer. [08:47.960 --> 08:50.560] And like I said, speculation is all well and good [08:50.560 --> 08:54.580] but when you're deciding whether you do want to spend the extra time [08:54.580 --> 08:56.020] or what's going to be most effective [08:56.560 --> 08:59.180] empirical data is the best to have. [08:59.320 --> 09:00.820] So I did a test. [09:05.230 --> 09:08.070] I used the random target option again [09:08.070 --> 09:11.810] 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:17.310] And it chugged away and chugged away [09:17.310 --> 09:21.430] and eventually it said, OK, out of those 50,000 IP addresses [09:21.430 --> 09:24.810] 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:30.030] We use all these probes [09:30.030 --> 09:31.970] and suddenly instead of 1,700 [09:32.650 --> 09:36.010] it gets 2,698 hosts up. [09:36.050 --> 09:38.030] So we see a 50% improvement [09:39.310 --> 09:42.330] just by adding these extra options. [09:42.590 --> 09:44.330] And yes, it did take four times as long [09:44.860 --> 09:48.390] but in many cases, if not most, it's worth it for you [09:48.390 --> 09:51.350] because you really want to find all of the hosts. [09:52.530 --> 09:52.990] And... [09:55.110 --> 09:57.670] there are a couple notes that I want to make [09:59.030 --> 10:00.630] regarding this sort of scan [10:00.630 --> 10:02.350] and these results that we've found. [10:02.450 --> 10:05.890] One is that it's not quite as exciting as it seems [10:05.890 --> 10:09.590] because some of these 2,698 hosts [10:09.590 --> 10:11.890] are going to be network artifacts. [10:11.890 --> 10:15.850] For example, in my last DEF CON talk [10:15.850 --> 10:19.270] I showed an example where a host that was a firewall [10:19.270 --> 10:22.150] was spoofing reset packets [10:22.150 --> 10:24.750] to any probe sent to port 113 [10:24.750 --> 10:27.690] on any of the hosts behind it. [10:27.830 --> 10:30.270] And so some of these are network artifacts [10:30.710 --> 10:33.790] and you'll have to use the sort of techniques I talked about last time [10:33.790 --> 10:38.050] to discern which are the artifacts and which are the actual hosts. [10:38.170 --> 10:40.270] The other thing worth noting is that [10:40.270 --> 10:43.090] these techniques will give the most improvement [10:43.090 --> 10:46.610] in a case like this where we're doing a worldwide scan [10:46.610 --> 10:49.870] over the Internet against tons of firewalls [10:49.870 --> 10:51.250] 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 --> 10:57.610] But while we're speaking about [10:58.470 --> 11:00.450] scanning a local Ethernet LAN [11:00.450 --> 11:03.930] that crops up with its own big bunch of issues. [11:04.470 --> 11:06.190] Here I do an nmap command [11:06.910 --> 11:10.650] for a ping scan of a host on the Ethernet LAN [11:10.650 --> 11:12.530] that's not really up. [11:12.690 --> 11:15.410] Send IP is a new option that I'll talk about later [11:15.410 --> 11:18.370] but for now you just need to know [11:18.370 --> 11:20.330] that that does the same default behavior [11:20.330 --> 11:22.750] as all of the pre-DEF CON releases. [11:23.450 --> 11:27.470] So I run nmap and I've pasted in [11:27.470 --> 11:30.470] some ethereal output to kind of show [11:30.470 --> 11:32.510] 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:41.950] Then after one second it sends yet another ARP request [11:42.450 --> 11:45.470] and after two seconds it sends a third ARP request [11:45.470 --> 11:47.950] and finally it gives up and nmap ends [11:48.470 --> 11:50.450] 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:05.390] You know it may sound, oh two seconds, big deal [12:05.390 --> 12:08.350] but if you're scanning 10.0.0.0.8 [12:08.350 --> 12:13.150] that's 16 million hosts and two seconds is gonna add up. [12:13.230 --> 12:15.370] Even 192.168 [12:15.370 --> 12:18.150] is still 65,000 hosts and nmap [12:18.150 --> 12:21.470] scans these in parallel but still it's not as fast [12:21.470 --> 12:25.790] And it's wasting time waiting for these ARP requests. [12:25.850 --> 12:30.270] Another problem is that most operating systems, you know, they have an ARP table [12:30.270 --> 12:32.250] and that ARP table is finite. [12:32.430 --> 12:37.770] So when they have an incomplete entry such as this, they'll add, [12:37.770 --> 12:39.590] that ARP table will fill up. [12:39.590 --> 12:42.870] And sometimes NMAP has to wait, you know, as much as 4 minutes [12:43.470 --> 12:46.350] 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:51.670] NMAP is like, hey, I can't send right now, waiting 60 seconds, [12:51.670 --> 12:53.470] then waiting 120 seconds. [12:53.510 --> 12:55.270] It's very frustrating. [12:55.750 --> 12:59.770] And since scanning your own local LAN is extremely common, [12:59.770 --> 13:01.990] 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:20.450] It can skip over the ARP table for the OS entirely [13:21.230 --> 13:23.610] and do the scan a lot faster. [13:23.770 --> 13:27.010] Another advantage, not only is it much faster, [13:27.010 --> 13:28.450] but it's more accurate. [13:28.570 --> 13:31.950] You know, as we've already seen, many hosts have all sorts of filters [13:31.950 --> 13:34.670] that can block your host discovery packets. [13:34.670 --> 13:36.970] But if they want to communicate on the network, [13:36.970 --> 13:39.570] 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:47.010] So here's a quick example I have here, [13:47.750 --> 13:52.070] where I scan the same machine as before with the new NMAP, [13:52.070 --> 13:54.910] and instead it sends one ARP at the beginning, [13:54.910 --> 13:57.870] 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:08.730] I can try and do a live demonstration here, [14:08.730 --> 14:12.610] 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:53.670] It starts showing you the machines that are up, [14:53.670 --> 14:55.830] and it shows you their MAC addresses. [14:55.830 --> 14:58.190] Right now we're only seeing one, [14:58.190 --> 15:00.630] 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:50.330] But it's worth noting that while NMAP may be faster, [15:50.330 --> 15:53.630] 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:05.510] And at the end, it gives you this beautiful ASCII art [16:06.930 --> 16:10.710] of a giant monster holding a white hat severed head [16:10.710 --> 16:13.730] 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:42.210] When you've been kicked off as many networks as I have, [16:42.210 --> 16:47.930] you start to appreciate the values of stealth and misdirection. [16:47.930 --> 16:50.570] So say you're sitting in a conference room [16:50.570 --> 16:54.130] and you've got the only ThinkPad. [16:54.290 --> 16:55.610] Unlikely, I know. [16:55.970 --> 16:58.510] And all of a sudden, a big scan starts [16:58.510 --> 17:01.630] 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:05.970] So with the new spoofing option, [17:05.970 --> 17:08.210] I did this at the hotel last night. [17:08.350 --> 17:10.390] I specify spoof MAC Apple [17:10.930 --> 17:13.470] and NMAP looks through the OUI table, [17:13.470 --> 17:18.350] finds the MAC prefix registered to the company you specify, [17:18.350 --> 17:20.630] fills out the last three bytes randomly, [17:20.630 --> 17:23.090] and then you can point at the Apple guy and say, [17:23.090 --> 17:24.190] 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:36.820] If you want to specify a specific MAC address [17:36.820 --> 17:39.500] 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 --> 17:59.340] And by manipulating these different options, [17:59.340 --> 18:02.660] 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:16.400] You want to scan your network before the bad guys can [18:16.400 --> 18:20.600] and identify all instances of the vulnerable product. [18:20.600 --> 18:22.780] Or maybe there's a new worm going around [18:22.780 --> 18:25.700] and you want to scan to find infected hosts [18:25.700 --> 18:29.600] before they can do much damage so you can quarantine them. [18:29.700 --> 18:32.880] Or maybe you're doing forensics on a compromised host [18:32.880 --> 18:37.640] and you find that they've left a backdoor open on some unusual port. [18:38.040 --> 18:39.400] Well, scan your network real quick [18:39.400 --> 18:42.180] and maybe you'll find other compromised machines [18:42.180 --> 18:44.260] that have the same backdoor. [18:44.260 --> 18:46.740] So here we're going to do an example of this, [18:46.740 --> 18:50.320] which is a little bit unusual, but basically covers the idea. [18:55.600 --> 18:58.940] Our mission statement is to locate web servers [18:58.940 --> 19:02.600] on the playboy.com network offering free images. [19:03.540 --> 19:06.800] The idea here is that I was thinking, [19:06.800 --> 19:10.200] hey, you know, they charge $10 a month for their content or whatever [19:10.200 --> 19:11.540] and I'm a cheapskate. [19:11.620 --> 19:15.660] Maybe they have a development server or a staging server somewhere [19:15.660 --> 19:19.520] 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:25.360] Well, first we need the address to scan, [19:25.360 --> 19:26.240] 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:38.000] There are a lot more netblocks they have, [19:38.000 --> 19:41.860] 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:56.220] Save the results in grepable format [19:56.220 --> 19:59.200] 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:03.200] And it chugs along and it completes, [20:03.200 --> 20:05.060] but it takes 20 minutes. [20:05.280 --> 20:08.320] You know, even for 4,096 hosts, [20:08.320 --> 20:10.180] 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:15.760] One thing you can do is help [20:15.760 --> 20:17.500] by giving nmap timing information [20:17.500 --> 20:19.400] that it is trouble getting itself. [20:19.420 --> 20:22.880] On a responsive network, on your local LAN or whatever, [20:22.880 --> 20:24.800] you can usually... [20:24.800 --> 20:27.640] nmap is able to calculate its own response times [20:27.640 --> 20:29.400] based on the responses it's getting [20:29.400 --> 20:32.240] and usually optimize those pretty effectively. [20:32.240 --> 20:34.120] But when you're scanning over the Internet [20:34.120 --> 20:38.300] on a highly filtered network, [20:38.300 --> 20:40.580] nmap's not actually getting much responses. [20:40.580 --> 20:42.900] And so it doesn't really have a good idea [20:42.900 --> 20:44.440] of how long it has to wait [20:44.440 --> 20:47.360] before it can time out and retransmit. [20:47.700 --> 20:49.120] So the idea here is [20:49.120 --> 20:50.900] we'll try and figure out some of that ourselves [20:50.900 --> 20:54.160] 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 --> 20:57.560] First I try their web server [20:57.560 --> 20:59.820] and I see that that's on a different IP, [20:59.820 --> 21:00.980] so that's no good. [21:01.020 --> 21:02.500] So then I look for MX servers [21:02.500 --> 21:05.020] and we lucked out, there are two of them [21:05.020 --> 21:07.860] that are both on the networks we're trying to scan. [21:08.060 --> 21:10.920] Normally I might just take one host on the network, [21:10.920 --> 21:12.960] but here, you know, we don't know a lot about [21:12.960 --> 21:14.860] the network configuration. [21:15.000 --> 21:16.820] And also given the names, [21:16.820 --> 21:19.180] we can tell that this one's probably in Los Angeles [21:19.180 --> 21:21.120] and this one's in Chicago, [21:21.480 --> 21:24.760] 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:30.640] Well, we try that, [21:30.640 --> 21:33.500] 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:38.760] But, you know, they're mail servers, [21:38.760 --> 21:41.020] and so they've got to have port 25 open. [21:41.420 --> 21:42.920] So let's use HPing 2 [21:42.920 --> 21:44.880] to do a TCP ping [21:44.880 --> 21:48.040] of those ports and see how long that takes. [21:48.200 --> 21:50.100] So we say HPing 2, [21:50.100 --> 21:52.320] send a SYN to port 25, [21:52.320 --> 21:54.020] like we're opening a connection, [21:54.020 --> 21:55.240] send five of them, [21:55.240 --> 21:56.900] and we do it to both the Chicago [21:56.900 --> 22:00.160] and the LA networks. [22:00.980 --> 22:03.100] And here, the information you really want [22:03.100 --> 22:05.220] is not the fastest time, [22:05.220 --> 22:07.020] it's not the average time, [22:07.020 --> 22:10.440] 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:14.820] If you try and get too aggressive, [22:14.820 --> 22:16.560] you'll actually make the scan take longer [22:16.560 --> 22:18.680] because Nmap will be retransmitting [22:18.680 --> 22:21.580] when the response is in transit. [22:21.860 --> 22:24.680] So even though the longest we saw out of these two [22:24.680 --> 22:26.920] was 61 milliseconds, [22:26.920 --> 22:28.120] you know, LA is a lot faster [22:28.120 --> 22:30.440] because I was scanning from California, [22:30.440 --> 22:32.100] we're going to pick a bit higher numbers [22:32.100 --> 22:33.520] to be on the safe side. [22:34.040 --> 22:35.560] So we're going to say the max [22:35.560 --> 22:37.680] RTT timeout is 200, [22:37.680 --> 22:40.400] so we'll wait up to a fifth of a second. [22:40.480 --> 22:44.340] And we tell Nmap to start out with 150 milliseconds, [22:44.340 --> 22:46.520] so that Nmap will only go up to 200 [22:46.520 --> 22:48.160] if it needs to. [22:48.160 --> 22:49.680] And Nmap can still go faster [22:49.680 --> 22:51.660] if it determines that it can. [22:51.800 --> 22:53.540] Another optimization is to say [22:53.540 --> 22:55.060] scan in bigger groups. [22:55.060 --> 22:57.500] We're going to specify a minimum host group size [22:57.500 --> 22:59.620] of 512. [22:59.960 --> 23:04.400] That breaks up the 4,096 machines [23:04.400 --> 23:07.280] into 8 groups of 512 [23:07.880 --> 23:10.100] and allows Nmap to go much faster [23:10.100 --> 23:13.380] 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:18.900] Nmap chugs away [23:18.900 --> 23:23.060] 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:26.600] But let's be honest, [23:26.600 --> 23:28.220] when I'm looking for these free images, [23:28.220 --> 23:29.820] I'm not a patient guy. [23:30.660 --> 23:32.520] This is an urgent matter. [23:32.520 --> 23:35.260] And so I say, [23:35.260 --> 23:38.080] how can we make it a bit faster here? [23:38.840 --> 23:40.780] Well, think about what Nmap is doing [23:40.780 --> 23:43.120] under the covers in this case. [23:43.180 --> 23:44.320] Nmap, you may know, [23:44.320 --> 23:47.140] does reverse DNS resolution by default. [23:47.480 --> 23:50.540] And when I'm doing P0 scans, no ping, [23:50.540 --> 23:52.060] that means that Nmap is considering [23:52.060 --> 23:53.400] all of the hosts up. [23:53.400 --> 23:55.460] And so it's doing a reverse DNS resolution [23:55.460 --> 23:57.740] on every host. [23:57.780 --> 23:59.520] And reverse DNS, I'm afraid, [23:59.520 --> 24:01.720] is one of the few Nmap functions [24:01.720 --> 24:04.060] 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:09.160] So I do the same scan, [24:09.160 --> 24:10.640] but this time I add hyphen N [24:10.640 --> 24:13.360] to get rid of reverse DNS resolution. [24:13.620 --> 24:15.680] And here we see that it only takes [24:15.680 --> 24:17.220] about three minutes, [24:17.220 --> 24:18.060] which is perfect, [24:18.060 --> 24:19.980] because that's about as long as I last. [24:20.520 --> 24:23.720] And so, [24:23.720 --> 24:27.800] by just manipulating these different values, [24:27.800 --> 24:29.640] we've been able to reduce the scan time [24:29.640 --> 24:32.520] 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:39.360] We did that big scan of 4,000 IPs, [24:39.360 --> 24:43.160] but we only found two that are open. [24:43.320 --> 24:45.500] Well, that was sort of a little bit worrisome, [24:45.500 --> 24:46.500] 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 --> 24:58.000] So we'll go to the first one, [24:58.000 --> 25:01.640] which is 216.163.140.20. [25:03.080 --> 25:07.160] And we see Microsoft Outlook Web Access. [25:07.660 --> 25:09.520] Now, that would be really exciting [25:09.520 --> 25:11.400] if we were trying to break into their network, [25:11.400 --> 25:13.000] but it's not very gratifying [25:13.000 --> 25:15.320] for our particular goal here. [25:16.680 --> 25:18.200] What this does tell us [25:18.200 --> 25:20.140] is that, hey, maybe the network we scanned [25:20.140 --> 25:21.480] was the corporate network [25:22.940 --> 25:24.620] when we really should have been scanning [25:24.620 --> 25:26.240] the production network. [25:27.200 --> 25:29.100] It is nice to note their cute little [25:29.100 --> 25:33.300] Playboy mail logo up in the URL bar. [25:35.200 --> 25:36.820] But all is not lost [25:36.820 --> 25:39.720] because we still have one more site. [25:39.720 --> 25:41.200] And I'm very pleased to report [25:41.200 --> 25:43.800] that that one has gigabytes of free images [25:43.800 --> 25:45.240] that I downloaded immediately [25:46.440 --> 25:48.320] 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:19.880] And if you're on the kinky side of things, [26:19.880 --> 26:21.440] they've got the whole Perl network [26:21.440 --> 26:23.460] right around here. [26:23.460 --> 26:25.100] So whatever your tastes, [26:25.100 --> 26:28.300] this is a great site to download images. [26:28.300 --> 26:29.880] And I would also like to mention [26:30.460 --> 26:33.720] this is also named mirrors.playboy.com [26:33.720 --> 26:35.760] and it actually is a real valuable site [26:36.310 --> 26:38.920] 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:47.460] But let's look at another quick [26:48.260 --> 26:50.780] single-service discovery option. [26:50.780 --> 26:53.060] And that's NMAP's version detection. [26:53.420 --> 26:56.440] In many cases, you want to not just know [26:56.440 --> 26:58.380] what ports open, but you want to find out [26:58.380 --> 27:01.080] the exact service that's listening. [27:01.100 --> 27:02.720] And so with version detection, [27:02.720 --> 27:06.900] instead of browsing the well-known ports table, [27:06.900 --> 27:08.740] NMAP actually interrogates the ports [27:08.740 --> 27:11.860] and tries to figure out what's running there. [27:11.860 --> 27:13.800] And so that way you can maybe distinguish [27:13.800 --> 27:17.000] the vulnerable services from the invulnerable ones [27:17.000 --> 27:20.040] or find the services even if they're listening [27:20.040 --> 27:22.140] on a non-default port. [27:22.480 --> 27:25.540] And NMAP now has well over a thousand [27:25.540 --> 27:27.760] different version detection signatures [27:28.740 --> 27:31.980] to identify all sorts of crazy things. [27:32.320 --> 27:35.800] In this example, this is just one [27:35.800 --> 27:37.280] that someone sent last year [27:37.280 --> 27:40.340] when MyDoom was basically causing havoc. [27:40.600 --> 27:42.020] Right when it was released, [27:42.020 --> 27:44.020] he posted this to the NMAP dev. [27:44.020 --> 27:45.300] Here's a probe you can add [27:45.300 --> 27:47.860] so that you can identify compromised machines [27:47.860 --> 27:50.200] or infected machines. [27:50.640 --> 27:53.060] So I'm just showing this as an example [27:53.060 --> 27:54.780] to show that it's actually pretty easy [27:54.780 --> 27:56.720] to add your own custom identification [27:56.720 --> 27:58.800] if you want to add services [27:58.800 --> 28:01.080] 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:16.880] If you get this back in the response, [28:16.880 --> 28:18.580] the program is MyDoom. [28:18.580 --> 28:19.580] And for the version number, [28:19.580 --> 28:20.580] he just put, you know, [28:20.580 --> 28:22.380] 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:26.060] And to add it, [28:26.060 --> 28:28.960] all you do is add this little s, capital V, [28:28.960 --> 28:31.640] 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:38.020] Let's try something a little different [28:38.020 --> 28:39.340] that's also common. [28:39.340 --> 28:41.700] What if you want to defeat a firewall? [28:41.700 --> 28:43.580] Sometimes you really want to look at [28:43.580 --> 28:45.460] what ports are open on a machine, [28:45.460 --> 28:48.680] but those pesky firewalls can get in the way. [28:48.920 --> 28:50.680] And NMAP has some techniques [28:50.680 --> 28:53.340] that can help you resolve that problem. [28:53.340 --> 28:55.160] So we've got another mission. [28:55.460 --> 28:58.520] This time we want to discern the open TCP ports [28:58.520 --> 29:01.280] on docserv.caldera.com. [29:01.500 --> 29:05.060] Now I was a little reticent about using SCO as an example [29:05.060 --> 29:08.400] because at one time, [29:08.400 --> 29:11.800] they were kind of considered a threat to free software. [29:11.800 --> 29:13.300] But lately, you know, [29:13.300 --> 29:15.440] 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:23.740] The problem is, it's so useful [29:23.740 --> 29:27.000] because every time I want to find [29:27.000 --> 29:29.480] like really pathetic network configuration, [29:29.480 --> 29:31.740] you know, I can find an example right there. [29:32.560 --> 29:34.540] Also, they are a fun horse to beat, [29:34.540 --> 29:36.020] so let's do it. [29:38.040 --> 29:40.200] If we want to find the open ports, [29:40.200 --> 29:42.740] 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:53.580] We find port 80 open, port 5007 open, [29:53.580 --> 29:55.880] 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:00.900] Because while we figured out the state of three ports, [30:00.900 --> 30:04.760] the 1660 remaining ones are in the port filtered, [30:04.760 --> 30:05.900] 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:10.980] It's worth noting that in a real scenario, [30:10.980 --> 30:13.700] you would probably want to add hyphen P hyphen, [30:13.700 --> 30:16.620] so that it will scan all 65,000 ports. [30:16.680 --> 30:18.760] But just like with the Playboy example, [30:18.760 --> 30:22.560] I'm limiting it just to be a useful example. [30:22.720 --> 30:24.220] So we've got three, [30:24.220 --> 30:27.700] but there's still a huge number that we've not really determined. [30:27.720 --> 30:30.140] Those ports could be open and exploitable, [30:30.140 --> 30:31.380] those 1660, [30:31.380 --> 30:32.440] 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:43.300] That basically sends a FIN packet, [30:43.300 --> 30:45.960] and if it receives a reset back, [30:45.960 --> 30:48.240] the port is probably closed, [30:48.240 --> 30:50.220] whereas if we get nothing back, [30:50.220 --> 30:53.240] the port is either filtered or open. [30:53.240 --> 30:55.160] And this isn't true of all machines, [30:55.160 --> 30:58.260] since some of them aren't susceptible to this issue, [30:58.260 --> 30:59.560] but it's true of a lot of them, [30:59.560 --> 31:00.980] so it's worth trying. [31:01.100 --> 31:03.100] So we try it against DocServe, [31:03.100 --> 31:04.140] and as you can see, [31:04.140 --> 31:06.500] we get a whole big long list of ports [31:06.500 --> 31:09.200] that are either open or filtered, [31:09.200 --> 31:12.560] 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:17.080] It's limited the number of ports quite a bit here [31:17.080 --> 31:18.640] to just a few dozen [31:19.140 --> 31:21.300] that are either open or filtered. [31:21.380 --> 31:23.460] And one would hope that most of those [31:23.460 --> 31:25.240] are actually in the filtered state, [31:25.240 --> 31:26.600] because it would be pretty pathetic [31:27.120 --> 31:28.700] to have that many open, [31:28.700 --> 31:29.740] but this is SCO, [31:29.740 --> 31:31.240] so you never really know. [31:31.680 --> 31:33.640] So how are we going to figure out, [31:33.640 --> 31:34.720] differentiate, [31:34.720 --> 31:37.180] because it's a very important distinction, [31:37.180 --> 31:39.100] 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:50.560] This time, we're going to try an ACK scan [31:50.560 --> 31:52.200] against DocServe. [31:52.220 --> 31:54.380] And that sends an ACK packet, [31:54.380 --> 31:56.380] and if it receives a reset back, [31:56.380 --> 31:58.460] it knows that the port is unfiltered, [31:58.460 --> 31:59.810] because it got a response, [32:00.160 --> 32:01.860] whereas if it receives nothing back, [32:01.860 --> 32:04.460] or an ICMP port filtered message, [32:04.460 --> 32:07.940] 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:13.460] Here, the vast, vast majority [32:13.460 --> 32:15.100] are unfiltered, [32:15.100 --> 32:17.080] but it tells us that just two of them [32:17.080 --> 32:18.640] are filtered. [32:19.220 --> 32:21.440] So what's an interesting thing you can do [32:21.440 --> 32:23.000] is combine those [32:23.000 --> 32:25.760] by looking at the last results [32:25.760 --> 32:27.580] and comparing them with these. [32:27.580 --> 32:29.880] For example, look at port 135. [32:29.960 --> 32:31.800] Here it says filtered, [32:31.800 --> 32:33.200] whereas before, [32:33.200 --> 32:35.980] 135 was open or filtered. [32:35.980 --> 32:38.760] Well, if you kind of take the logical end of those, [32:38.760 --> 32:39.800] you see that it's [32:39.800 --> 32:41.860] got to be filtered. [32:42.860 --> 32:44.560] Similarly, 1434 [32:44.560 --> 32:47.040] looks like it's really filtered. [32:47.240 --> 32:48.860] Let's take another example. [32:48.860 --> 32:51.000] Say you want to know about the SSH port, [32:51.000 --> 32:51.840] 22. [32:51.840 --> 32:54.040] In this case, it says that [32:54.040 --> 32:56.020] 22 is unfiltered, because it's [32:56.020 --> 32:57.680] one of all these other ports. [32:58.220 --> 32:59.640] And in this case, [32:59.640 --> 33:02.260] we see 22 is open or filtered. [33:02.260 --> 33:03.800] So if we have open or filtered [33:03.800 --> 33:05.760] on one scan, [33:05.760 --> 33:08.300] and unfiltered on the other, [33:08.300 --> 33:10.060] you know, that just leaves open. [33:10.640 --> 33:12.680] And so, if you combine [33:12.680 --> 33:13.940] all of these different results [33:13.940 --> 33:15.900] from the two scans, [33:15.900 --> 33:17.800] what the hypothesis is, [33:17.800 --> 33:20.940] is that 135 and 1434 [33:23.120 --> 33:24.800] are filtered, [33:24.800 --> 33:26.180] but all of these other ones [33:26.180 --> 33:28.580] on this huge list are open. [33:29.380 --> 33:30.420] And so, [33:30.860 --> 33:32.420] you know, that tells you a lot. [33:32.420 --> 33:34.100] And you can see a little bit of confirmation [33:34.100 --> 33:36.040] in terms of the two that we know [33:36.040 --> 33:37.620] are open to the SIN scan, [33:37.620 --> 33:38.960] 80 and 507. [33:39.300 --> 33:41.640] You see here as well, [33:41.640 --> 33:44.400] 80 and 507 in the open or filtered. [33:44.400 --> 33:45.720] So we have a pretty good idea [33:45.720 --> 33:47.100] about what we're seeing. [33:47.100 --> 33:48.720] But networks can be tricky. [33:48.720 --> 33:50.800] It's always good to check your results, [33:50.800 --> 33:53.160] 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 --> 33:57.540] And that's the Windows scan, [33:57.540 --> 34:00.020] which is a little-known scan technique. [34:00.020 --> 34:02.300] But it's very similar to the ACK [34:02.300 --> 34:04.080] scan, except that it noticed [34:04.320 --> 34:06.440] a property that certain hosts have [34:06.440 --> 34:08.880] where when you send, [34:08.880 --> 34:09.980] when they send a reset [34:09.980 --> 34:12.020] back from a probe to one of their [34:12.020 --> 34:14.120] open ports, they set the window [34:14.120 --> 34:16.140] as they would if it was [34:16.320 --> 34:18.800] a SIN ACK for a real connection. [34:18.800 --> 34:20.300] Whereas, when they're sending [34:20.480 --> 34:22.380] a reset back from a closed port, [34:22.380 --> 34:24.460] they set the window to zero. [34:24.660 --> 34:26.340] So by looking at that window, [34:26.340 --> 34:28.760] TCP receive window value carefully, [34:28.760 --> 34:30.240] we can determine which of the [34:30.240 --> 34:32.220] ports are open and which are closed. [34:32.220 --> 34:34.200] So we do an ACK scan against this [34:34.200 --> 34:36.300] machine, and sure enough, like [34:36.300 --> 34:38.120] we thought, all the ports are [34:38.120 --> 34:40.260] open except 135 is filtered [34:40.260 --> 34:41.940] and I think [34:41.940 --> 34:44.080] 443 is the other one. [34:44.080 --> 34:45.620] Or no, it was my MS SQL [34:46.020 --> 34:48.040] was the other one, 1434 [34:48.860 --> 34:50.080] was filtered. [34:50.080 --> 34:52.420] So that sort of confirms our results now. [34:52.420 --> 34:53.960] We've tried a lot of different things, [34:53.960 --> 34:55.160] and now we have a good idea [34:55.160 --> 34:57.700] where they're open. [34:58.360 --> 35:00.180] And it kind of shows the value [35:00.180 --> 35:02.120] of taking the SIN scan and [35:02.120 --> 35:04.240] seeing it doesn't get you all the results [35:04.240 --> 35:06.140] that you want, so you just keep trying [35:06.140 --> 35:08.200] different things until you meet your [35:08.200 --> 35:09.020] goals. [35:10.000 --> 35:12.200] So that was basically [35:12.200 --> 35:14.180] our three missions. And so now [35:14.180 --> 35:16.160] I'm going to just give a quick overview, [35:16.160 --> 35:18.200] since I've got, oh, about five [35:18.200 --> 35:20.120] minutes, of some of the new [35:20.120 --> 35:22.080] features that I have in the DEF CON [35:22.080 --> 35:23.700] version. There's [35:23.700 --> 35:26.300] the ARP scanning that we've already talked [35:26.300 --> 35:28.520] about, the MAC spoofing. [35:28.520 --> 35:30.500] One nice new feature is [35:30.500 --> 35:32.580] raw Ethernet packet sending, [35:32.580 --> 35:34.620] because raw IP packets can [35:34.620 --> 35:36.580] be a huge mess. You know, a lot of systems [35:36.580 --> 35:38.600] screw them up, and Microsoft, [35:38.600 --> 35:40.320] even worse, they recently banned them [35:40.320 --> 35:43.360] with their Windows XP SP2. [35:43.360 --> 35:44.600] So now we're saying, well, screw [35:44.600 --> 35:46.640] you, Microsoft. We're just going to send [35:46.640 --> 35:48.480] at a lower level, and [35:48.480 --> 35:50.500] send the Ethernet packets directly. [35:50.500 --> 35:52.300] And that should be a lot faster. [35:52.620 --> 35:54.340] It also has 350 [35:54.340 --> 35:56.420] new OS fingerprints, for [35:56.540 --> 35:58.600] a total of 1,690 [35:58.600 --> 36:00.640] from this ACC Amazon [36:00.640 --> 36:02.480] WAN concentrator [36:02.480 --> 36:04.460] to the Zyxel [36:04.460 --> 36:05.800] Zywall. [36:06.280 --> 36:08.480] 250 new version detection [36:08.480 --> 36:10.460] signatures, so there are now [36:10.460 --> 36:12.560] 1,312 of those, [36:12.560 --> 36:14.580] covering 212 protocols, [36:14.580 --> 36:17.160] such as SMTP, SNMP, [36:17.160 --> 36:18.540] Kazaa, all sorts [36:18.540 --> 36:20.380] of bizarre things. It [36:20.380 --> 36:23.240] integrates Doug Song's excellent LibDNet, [36:23.240 --> 36:24.460] which helps with the [36:24.460 --> 36:26.420] raw Ethernet packets sending. [36:27.400 --> 36:28.420] Version detection [36:28.420 --> 36:30.460] now helps you find [36:30.460 --> 36:32.620] OS information. [36:32.760 --> 36:34.440] So the version detection now [36:34.440 --> 36:36.560] can find three extra [36:36.560 --> 36:38.140] things in many cases. [36:38.140 --> 36:40.480] If it sees a service that only works on [36:40.480 --> 36:42.500] Windows, or if the service responds [36:42.500 --> 36:45.120] with a certain platform name, [36:45.120 --> 36:46.480] it can now report, Nmap now [36:46.480 --> 36:48.460] reports that next to the OS detection [36:48.460 --> 36:50.480] results. The OS detection results [36:50.480 --> 36:52.340] are this, and version detection [36:52.340 --> 36:54.740] says it looks like this OS. [36:54.780 --> 36:56.460] And some people would say, hey, combine [36:56.460 --> 36:57.780] those to get just one [36:59.040 --> 37:00.400] result. But in [37:00.400 --> 37:02.300] reality, what you really want is to have [37:02.300 --> 37:04.660] both, because they may be distinct. [37:04.660 --> 37:06.180] If you're scanning a firewall [37:06.180 --> 37:09.360] that proxies to an IIS server, [37:09.360 --> 37:10.160] you should get [37:10.160 --> 37:12.220] checkpoint firewall one or whatever [37:12.220 --> 37:14.600] for the OS detection [37:14.600 --> 37:17.180] results via TCP IP fingerprinting, [37:17.180 --> 37:18.520] whereas it should say Windows [37:18.520 --> 37:20.360] for the application [37:20.360 --> 37:22.540] version detection results. [37:22.540 --> 37:24.380] And that's pretty common. You'll get the same thing [37:24.380 --> 37:26.340] if you're scanning someone's Linksys [37:26.340 --> 37:28.220] network, for example, where they've [37:28.220 --> 37:30.260] forwarded different ports to [37:30.260 --> 37:31.720] different machines. [37:33.440 --> 37:34.480] Version detection [37:34.480 --> 37:36.140] also now gives device [37:36.140 --> 37:38.540] information and host name information, [37:38.540 --> 37:40.140] which can be valuable. [37:40.180 --> 37:42.280] I broke the Windows support, I'm [37:42.280 --> 37:44.340] afraid, for the moment, but [37:44.340 --> 37:46.680] that may be fixed eventually. [37:47.540 --> 37:48.340] And when [37:48.340 --> 37:49.940] it is fixed, though, we'll have [37:49.940 --> 37:52.480] the advantages of the raw packet sending. [37:53.060 --> 37:54.400] But for the Defcon release, [37:54.400 --> 37:56.320] I figured the priority was to get the [37:56.320 --> 37:58.240] Unix versions out, and I've tested this [37:58.240 --> 38:00.700] one on Linux, OSX, [38:00.700 --> 38:02.580] Solaris, FreeBSD. [38:03.900 --> 38:04.460] And [38:04.460 --> 38:06.300] then there's also quite a few more features, [38:06.300 --> 38:08.020] which you can find in the [38:08.020 --> 38:09.300] changelog. [38:09.860 --> 38:12.200] What's coming next? Well, I'm happy to [38:12.200 --> 38:14.340] report that Google has sponsored [38:14.340 --> 38:16.300] 10 students to work on [38:16.300 --> 38:18.200] Nmap for the summer. And yeah, [38:18.200 --> 38:20.100] they're student programmers, but some of them are [38:20.100 --> 38:22.220] serious students, like PhD students [38:22.220 --> 38:24.940] in doing very relevant research. [38:25.160 --> 38:26.220] And so that's [38:26.220 --> 38:28.240] pretty exciting, and they're working on a whole lot [38:28.240 --> 38:29.620] of projects. There were [38:30.720 --> 38:32.180] 233 applications, and [38:32.180 --> 38:34.060] I picked the top 10, [38:34.060 --> 38:36.500] and we worked out some pretty cool projects. [38:36.700 --> 38:38.140] One of them is Ncat, [38:38.140 --> 38:40.240] which is sort of a re-implementation of [38:40.240 --> 38:42.320] Netcat, that adds a [38:42.320 --> 38:44.380] bunch of new features that I've wanted. [38:44.380 --> 38:46.100] You know, things like SSL, [38:46.100 --> 38:48.460] IPv6, password protection, [38:48.960 --> 38:49.900] there's a connection [38:49.900 --> 38:51.940] brokering feature, so that two [38:51.940 --> 38:53.560] hosts behind a NAT [38:53.560 --> 38:56.440] can connect into the Netcat listener, [38:56.440 --> 38:57.960] and then it brokers the communications [38:57.960 --> 39:00.020] between them. You know, all sorts of [39:00.020 --> 39:02.000] cool features. And you'll find a man [39:02.000 --> 39:03.900] page that he's posted so far [39:03.900 --> 39:06.700] on the Nmap dev list. [39:06.780 --> 39:07.940] And he's working on the [39:07.940 --> 39:10.520] implementation. New GUIs. [39:10.520 --> 39:11.960] And GUIs sort of sometimes have [39:12.060 --> 39:13.980] a reputation as, oh, this is just for [39:13.980 --> 39:15.960] newbies who can't remember those hundreds [39:15.960 --> 39:17.540] of Nmap options. [39:17.780 --> 39:19.940] But these are more advanced user [39:19.940 --> 39:22.040] GUIs. They're [39:22.040 --> 39:23.840] mostly results viewers. So you've [39:23.840 --> 39:26.520] scanned tens of thousands of machines. [39:26.520 --> 39:28.280] These make it easier to identify [39:28.280 --> 39:29.940] which machines have this port [39:29.940 --> 39:31.240] open, or [39:31.900 --> 39:33.860] compare the difference between two scans [39:33.860 --> 39:36.000] and show me what's changed. You know, features [39:36.000 --> 39:37.840] like that. And there are actually [39:37.840 --> 39:39.980] two of these SOC [39:39.980 --> 39:42.100] students writing independent [39:42.100 --> 39:43.280] GUIs. [39:43.740 --> 39:45.900] Potential scripting language. I'm not sure [39:45.900 --> 39:47.960] if that's going to work out yet or not. But this [39:47.960 --> 39:49.620] guy is working on that. [39:49.920 --> 39:51.940] And when that is added, [39:51.940 --> 39:53.880] we'll probably use that for host discovery [39:53.880 --> 39:55.380] stuff. Information gathering [39:55.860 --> 39:58.140] as opposed to, you know, trying to add a [39:58.140 --> 39:59.980] thousand different vulnerability [40:00.580 --> 40:02.260] detection modules. We'll [40:02.260 --> 40:04.340] focus on, hey, have a script that does [40:04.340 --> 40:06.040] trace route. Have a script that [40:06.040 --> 40:08.000] checks whether a proxy is open. Have a [40:08.000 --> 40:09.920] script for all these different things [40:09.920 --> 40:11.880] that it can look up once Nmap [40:11.880 --> 40:13.540] has determined the OS and [40:13.540 --> 40:15.800] port service [40:15.800 --> 40:17.900] version and such. [40:18.580 --> 40:20.140] Windows performance is a [40:20.140 --> 40:22.200] big priority. Also [40:22.520 --> 40:24.380] I've been chugging away at my [40:24.380 --> 40:26.740] Nmap book, which has taken a long [40:26.740 --> 40:28.940] time, but I'm pleased to report [40:29.700 --> 40:30.240] progress. I've [40:30.240 --> 40:32.460] got more than 200 pages of it [40:32.460 --> 40:34.360] here now, and I [40:34.360 --> 40:36.260] think it's looking out to be pretty good. [40:37.220 --> 40:38.240] Given how slow [40:38.240 --> 40:40.240] publishing is, you know, it'll probably be six [40:40.240 --> 40:42.380] months, but I've [40:42.380 --> 40:44.140] added a bunch of cool network [40:44.140 --> 40:46.200] scanning goodies and corny jokes [40:46.200 --> 40:48.060] so it'll be great. [40:49.520 --> 40:50.580] There's a [40:50.580 --> 40:52.740] hyphen hyphen reason option I would like [40:52.740 --> 40:55.120] to add, so that Nmap [40:55.120 --> 40:56.680] can say, hey, we think this [40:56.680 --> 40:58.920] port is closed because we received [40:58.920 --> 41:00.440] a reset back. We think [41:00.440 --> 41:02.880] it's filtered because we received [41:02.880 --> 41:04.160] nothing back, or because we received an [41:04.160 --> 41:05.680] ICMP port unreachable [41:05.680 --> 41:07.780] or destination unreachable [41:07.780 --> 41:10.360] message back. So that'll be useful [41:10.360 --> 41:11.940] for more understanding [41:11.940 --> 41:13.840] 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:18.340] So that's [41:18.340 --> 41:19.980] basically my presentation, which is good [41:19.980 --> 41:21.900] because I'm about out of time. I'll just take [41:21.900 --> 41:24.220] two questions here, if anyone has them. [41:29.900 --> 41:30.560] Yes, [41:30.560 --> 41:32.500] I'll put the slides... [41:37.770 --> 41:38.510] Yeah. [41:38.870 --> 41:41.110] Yes, docserv.caldera.com [41:42.330 --> 41:43.490] No. [41:44.370 --> 41:45.270] Right now I have [41:45.270 --> 41:46.950] the new version of Nmap up here [41:46.950 --> 41:49.340] at presentation slash defcon.13 [41:50.170 --> 41:51.370] and I'll put [41:51.370 --> 41:53.470] the slides up there shortly as well. [41:53.490 --> 41:55.030] Thank you very much.