1
00:00:06,650 --> 00:00:09,830
My name is Fyodor from Insecure.org.

2
00:00:09,830 --> 00:00:11,290
Can you guys all hear me?

3
00:00:12,270 --> 00:00:13,230
No?

4
00:00:13,730 --> 00:00:15,450
Then listen up!

5
00:00:17,890 --> 00:00:19,390
Alright, well...

6
00:00:21,610 --> 00:00:23,650
Alright, well thank you all for coming.

7
00:00:23,890 --> 00: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.

8
00:00:31,050 --> 00:00:34,550
This year I'm going to talk about NMAP hacking.

9
00:00:34,890 --> 00:00:42,270
Basically, there are a lot of security people who use NMAP but many of them don't understand its full power.

10
00:00:42,770 --> 00:00:48,250
And NMAP deserves a lot of the blame for this because it kind of is too helpful sometimes.

11
00:00:48,250 --> 00: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.

12
00:01:04,930 --> 00: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.

13
00:01:22,590 --> 00: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.

14
00:01:42,090 --> 00:01:49,110
I'm also happy to be releasing a new version of NMAP special for DEF CON.

15
00:01:49,710 --> 00: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.

16
00:02:01,270 --> 00:02:06,790
It has a lot of cool features, which I'll talk about in this presentation shortly.

17
00:02:08,650 --> 00: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.

18
00:02:22,370 --> 00:02:22,810
Also...

19
00:02:24,310 --> 00: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.

20
00:02:37,390 --> 00:02:39,030
I'd appreciate that.

21
00:02:39,670 --> 00:02:46,510
Before I begin, it would help me to get an idea of how much introductory NMAP material I need to cover.

22
00:02:46,790 --> 00:02:55,050
So if I could get a show of hands for anyone here who has ever used NMAP All right, everyone.

23
00:02:55,110 --> 00:03:00,870
So we'll skip NMAP for dummies and move directly to Host Discovery.

24
00:03:05,090 --> 00: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.

25
00:03:13,370 --> 00:03:19,010
Maybe you're a pen tester who just busted into a new subnet and wanted to see what machines are on.

26
00:03:19,010 --> 00:03:22,850
Or maybe you're a network administrator doing IT inventory.

27
00:03:22,850 --> 00: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.

28
00:03:31,530 --> 00:03:39,230
NMAP used to only be able to send an ICMP echo request message and later a TCP ACK to a port.

29
00:03:40,010 --> 00: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.

30
00:03:52,670 --> 00:03:55,450
Unfortunately, that time is well past.

31
00:03:56,110 --> 00:04:01,990
Many hosts, you know, don't respond to a ping even though the RFCs say that they should.

32
00:04:01,990 --> 00:04:05,770
The Internet is a much more guarded and filtered place nowadays.

33
00:04:06,050 --> 00: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.

34
00:04:15,650 --> 00:04:24,290
For example, you can send SIN probes if you want to get through a stateful firewall that only allows SINs.

35
00:04:24,490 --> 00: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.

36
00:04:35,790 --> 00: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.

37
00:04:44,430 --> 00:04:52,470
Also ICMP echo requests and pings, timestamp requests, netmask requests, so you have a whole lot of options there.

38
00:04:52,690 --> 00:04:55,830
And you can combine those options almost arbitrarily.

39
00:04:55,830 --> 00:05:01,570
But with so many options, that leaves you to the question of well, what's going to be most effective?

40
00:05:01,730 --> 00: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.

41
00:05:12,310 --> 00:05:16,610
So let's start with what are the most valuable TCP ping ports to use?

42
00:05:16,670 --> 00: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.

43
00:05:33,190 --> 00:05:39,490
And of those I said, hey, which hosts, which ports are most responsive to a SIN packet?

44
00:05:39,490 --> 00:05:43,910
And this is the list starting with the most common which is HTTP.

45
00:05:46,780 --> 00:05:48,700
SMTP is also popular.

46
00:05:49,100 --> 00:05:49,980
SSH.

47
00:05:51,280 --> 00:05:52,160
HTTPS.

48
00:05:52,500 --> 00:05:53,380
FTP.

49
00:05:54,480 --> 00:05:57,560
Telnet's down there, but it's nice to see it below SSH.

50
00:05:58,600 --> 00:06:01,680
And these are the sort of things that you would expect to see.

51
00:06:01,680 --> 00:06:06,760
If you have your firewalled host, you still have to have port 25 open if you want to receive mail.

52
00:06:06,760 --> 00:06:11,780
A lot of times they make 22 widely open so if they're off it, but Defcon's a bad example.

53
00:06:11,780 --> 00:06:17,620
But if something bad happens while you're away, you want to be able to connect in and remotely administer.

54
00:06:18,640 --> 00:06:22,220
So your best bet is to pick a variety of these.

55
00:06:23,160 --> 00:06:26,520
The next question then is what sort of TCP probes do I want to send?

56
00:06:26,520 --> 00:06:29,020
There's the SIN probes and the ACK probes.

57
00:06:29,020 --> 00:06:30,780
The answer is just send both.

58
00:06:30,780 --> 00:06:37,560
That way if it's the stateful firewall, like Microsoft.com your SIN will get through, but your ACK won't.

59
00:06:37,560 --> 00:06:40,540
Whereas a stateless firewall, your ACK's more likely.

60
00:06:40,540 --> 00:06:41,560
So send them back.

61
00:06:41,560 --> 00:06:44,700
All you need is one response to tell you that the host is open.

62
00:06:44,700 --> 00:06:45,740
So send them both.

63
00:06:46,480 --> 00:06:48,180
What about UDP ports?

64
00:06:48,380 --> 00:06:51,000
Here you have a little different idea than with TCP.

65
00:06:51,020 --> 00:06:56,440
With TCP, an open port is still responsive so it tells you that the host is up.

66
00:06:56,440 --> 00:07:02,960
With UDP, NMAP's blank UDP messages are unlikely to elicit a response from an open port.

67
00:07:03,140 --> 00:07:05,500
And so you don't want to hit an open one.

68
00:07:05,500 --> 00: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.

69
00:07:12,880 --> 00: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.

70
00:07:19,340 --> 00: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.

71
00:07:31,220 --> 00:07:39,040
For ping types, I would recommend an echo request and then either a timestamp request or a netmask request.

72
00:07:39,140 --> 00:07:44,880
The idea is that some hosts for example Google or Insecure.org will let you ping them.

73
00:07:44,880 --> 00: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.

74
00:07:54,980 --> 00:07:59,060
But the ones who block the latter are likely to block them both.

75
00:07:59,080 --> 00:08:05,020
So your best shot is generally to do both or to do a ping request and then one of these others.

76
00:08:05,500 --> 00:08:07,200
So let's put that all together.

77
00:08:07,200 --> 00:08:11,600
Take all of these ideas and put it into one intense discovery combination.

78
00:08:11,720 --> 00:08:13,940
And here's one that I would recommend.

79
00:08:13,940 --> 00: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.

80
00:08:22,480 --> 00:08:27,140
You never know when that little trick will work to get through poor configurations.

81
00:08:27,480 --> 00:08:33,180
One thing to note when doing this is that this is 13 probes rather than 2.

82
00:08:33,360 --> 00:08:38,420
And host enumeration time is going to be roughly proportional to the number of probes that you send.

83
00:08:38,700 --> 00:08:42,720
And so you want to consider whether it's worth it.

84
00:08:42,720 --> 00:08:47,700
But in many cases you really do want a comprehensive list so it's worth taking a little longer.

85
00:08:47,960 --> 00: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.

86
00:08:59,320 --> 00:09:00,820
So I did a test.

87
00:09:05,230 --> 00:09:11,810
I used the random target option again to generate a list of 50,000 random IPs.

88
00:09:11,810 --> 00:09:15,850
And then I ran it and mapped with the default scan types.

89
00:09:15,850 --> 00: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.

90
00:09:24,810 --> 00:09:28,290
Alright, so now let's try it with the more intense discovery.

91
00:09:28,510 --> 00:09:36,010
We use all these probes and suddenly instead of 1,700 it gets 2,698 hosts up.

92
00:09:36,050 --> 00:09:42,330
So we see a 50% improvement just by adding these extra options.

93
00:09:42,590 --> 00: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.

94
00:09:52,530 --> 00:09:52,990
And...

95
00:09:55,110 --> 00: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.

96
00:10:02,450 --> 00: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.

97
00:10:11,890 --> 00: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.

98
00:10:27,830 --> 00: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.

99
00:10:38,170 --> 00: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.

100
00:10:51,250 --> 00:10:55,350
If you're scanning a local LAN, the defaults may work fine.

101
00:10:55,890 --> 00:11:03,930
But while we're speaking about scanning a local Ethernet LAN that crops up with its own big bunch of issues.

102
00:11:04,470 --> 00: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.

103
00:11:12,690 --> 00: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.

104
00:11:23,450 --> 00: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.

105
00:11:32,510 --> 00:11:34,450
I give the OS an IP packet.

106
00:11:34,490 --> 00:11:38,750
It sends an ARP request looking for the machine immediately.

107
00:11:38,850 --> 00: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.

108
00:11:51,250 --> 00:11:54,190
And there are a couple of problems that...

109
00:11:55,630 --> 00:11:58,050
Can you guys hear me better?

110
00:11:58,590 --> 00:11:59,870
All right.

111
00:11:59,870 --> 00:12:03,410
There are a couple problems with this two seconds.

112
00:12:03,410 --> 00: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.

113
00:12:13,230 --> 00: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.

114
00:12:25,850 --> 00:12:32,250
Another problem is that most operating systems, you know, they have an ARP table and that ARP table is finite.

115
00:12:32,430 --> 00:12:39,590
So when they have an incomplete entry such as this, they'll add, that ARP table will fill up.

116
00:12:39,590 --> 00:12:46,350
And sometimes NMAP has to wait, you know, as much as 4 minutes for those ARP entries to expire.

117
00:12:46,450 --> 00:12:48,550
You may have seen that if you scan a big network.

118
00:12:48,550 --> 00:12:53,470
NMAP is like, hey, I can't send right now, waiting 60 seconds, then waiting 120 seconds.

119
00:12:53,510 --> 00:12:55,270
It's very frustrating.

120
00:12:55,750 --> 00:13:01,990
And since scanning your own local LAN is extremely common, that's something that's worth optimizing.

121
00:13:02,510 --> 00:13:07,530
And so one of the features in the new NMAP is ARP scanning.

122
00:13:07,650 --> 00:13:11,810
The idea is give NMAP full control to send those ARP packets.

123
00:13:11,810 --> 00:13:15,470
That way NMAP can worry about the timing and the retransmissions.

124
00:13:15,470 --> 00:13:23,610
It can skip over the ARP table for the OS entirely and do the scan a lot faster.

125
00:13:23,770 --> 00:13:28,450
Another advantage, not only is it much faster, but it's more accurate.

126
00:13:28,570 --> 00:13:34,670
You know, as we've already seen, many hosts have all sorts of filters that can block your host discovery packets.

127
00:13:34,670 --> 00:13:39,570
But if they want to communicate on the network, they generally have to reply to ARP.

128
00:13:39,570 --> 00:13:43,650
So if NMAP gets an ARP reply, it knows that it's online.

129
00:13:43,650 --> 00: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.

130
00:13:57,870 --> 00:14:00,750
And then it gives up in two tenths of a second.

131
00:14:00,750 --> 00:14:04,990
So it takes, you know, less than an eighth of the time that it took before.

132
00:14:05,610 --> 00: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.

133
00:14:12,610 --> 00:14:15,390
So here I'm doing NMAP, a ping scan.

134
00:14:15,390 --> 00:14:17,510
I probably have to make this bigger, don't I?

135
00:14:18,450 --> 00:14:19,990
Or can you guys read it?

136
00:14:21,330 --> 00:14:22,190
All right.

137
00:14:33,470 --> 00:14:35,150
All right, huge we are.

138
00:14:35,570 --> 00:14:38,530
So I'm going to do a...

139
00:14:39,230 --> 00:14:40,750
What a mess this is.

140
00:14:40,990 --> 00:14:42,970
So I'm going to do a ping scan.

141
00:14:42,970 --> 00:14:44,810
PR is the new ARP feature.

142
00:14:44,810 --> 00:14:49,810
And I'm going to scan the wireless network that I'm on now with aggressive timing.

143
00:14:50,390 --> 00:14:51,610
And so it goes.

144
00:14:51,610 --> 00:14:55,830
It starts showing you the machines that are up, and it shows you their MAC addresses.

145
00:14:55,830 --> 00:15:00,630
Right now we're only seeing one, because I'm just scanning this short subnet.

146
00:15:00,870 --> 00:15:04,610
But we see that it finished and showed that Dell guy.

147
00:15:05,550 --> 00:15:10,390
Another tool that you can use to do this sort of scanning is THC Root.

148
00:15:10,390 --> 00:15:11,970
How many people have used that?

149
00:15:12,950 --> 00:15:16,290
It's a nice little tool by the hacker's choice.

150
00:15:16,570 --> 00:15:18,850
So here I'm going to do the same scan.

151
00:15:18,850 --> 00:15:21,310
And I'll make it huge again.

152
00:15:23,170 --> 00:15:24,890
With THC Root.

153
00:15:28,550 --> 00:15:30,690
And again, it goes through.

154
00:15:30,890 --> 00:15:33,450
It finds the gateway machine.

155
00:15:34,070 --> 00:15:35,930
And it thinks and it thinks.

156
00:15:35,930 --> 00:15:38,610
But you can see that it's taking a bit longer.

157
00:15:38,610 --> 00:15:40,650
NMAP took five seconds and it took ten.

158
00:15:40,650 --> 00:15:41,970
Which is no big deal.

159
00:15:41,970 --> 00:15:45,790
But on a large scan, you know, having it go faster is a lot helpful.

160
00:15:47,170 --> 00: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.

161
00:15:53,630 --> 00:15:57,070
For example, I compiled it just recently.

162
00:15:59,250 --> 00:16:02,070
And you can see all the configure screens.

163
00:16:02,230 --> 00: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.

164
00:16:13,730 --> 00:16:15,230
Please don't hurt me.

165
00:16:15,750 --> 00:16:19,330
So NMAP can't quite compete with their ASCII art.

166
00:16:20,670 --> 00:16:22,170
Or can it?

167
00:16:22,250 --> 00:16:25,830
Yes, I'm pleased to announce that the new DEF CON version...

168
00:16:26,890 --> 00:16:29,730
Yes, we've got the ASCII art for you.

169
00:16:29,730 --> 00:16:31,390
It's just not quite as violent.

170
00:16:33,270 --> 00:16:35,010
So that's ARP scanning.

171
00:16:35,010 --> 00:16:39,010
And another feature I added just for you guys is ARP spoofing.

172
00:16:39,110 --> 00: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.

173
00:16:47,930 --> 00:16:54,130
So say you're sitting in a conference room and you've got the only ThinkPad.

174
00:16:54,290 --> 00:16:55,610
Unlikely, I know.

175
00:16:55,970 --> 00:17:01,630
And all of a sudden, a big scan starts and everyone sees the MAC address is registered to IBM.

176
00:17:01,710 --> 00:17:03,910
You know, heads will turn in your direction.

177
00:17:04,110 --> 00:17:08,210
So with the new spoofing option, I did this at the hotel last night.

178
00:17:08,350 --> 00: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.

179
00:17:29,180 --> 00:17:30,060
Thanks.

180
00:17:31,600 --> 00:17:34,520
You can also specify it, you know, in other formats.

181
00:17:34,520 --> 00:17:39,500
If you want to specify a specific MAC address or just give another prefix, it'll fill in the rest.

182
00:17:39,500 --> 00:17:43,200
Or just give it zero and it'll give you a fully random MAC.

183
00:17:43,200 --> 00:17:46,260
And it shows you down here what MAC that it selected.

184
00:17:49,100 --> 00:17:51,460
So that's basically host discovery.

185
00:17:51,460 --> 00:17:54,600
As you can see, there are a lot of different options that you can do there.

186
00:17:54,600 --> 00:17:56,500
A lot of different things to play with.

187
00:17:56,520 --> 00:18:02,660
And by manipulating these different options, you can get much faster and more accurate results.

188
00:18:02,960 --> 00:18:07,180
Now let's look at another common scan.

189
00:18:07,180 --> 00:18:09,240
And that's single host discovery.

190
00:18:09,660 --> 00:18:13,340
Say a new vulnerability comes out in some product.

191
00:18:13,340 --> 00:18:20,600
You want to scan your network before the bad guys can and identify all instances of the vulnerable product.

192
00:18:20,600 --> 00: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.

193
00:18:29,700 --> 00: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.

194
00:18:38,040 --> 00:18:44,260
Well, scan your network real quick and maybe you'll find other compromised machines that have the same backdoor.

195
00:18:44,260 --> 00: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.

196
00:18:55,600 --> 00:19:02,600
Our mission statement is to locate web servers on the playboy.com network offering free images.

197
00:19:03,540 --> 00: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.

198
00:19:11,620 --> 00:19:19,520
Maybe they have a development server or a staging server somewhere where you can download all the images for free.

199
00:19:19,720 --> 00:19:21,400
You know, it's worth a try.

200
00:19:21,700 --> 00:19:23,320
So how are we going to do this?

201
00:19:23,320 --> 00:19:26,240
Well, first we need the address to scan, and that's pretty obvious.

202
00:19:26,240 --> 00:19:30,080
Just do a lookup on Aaron for netblocks owned by Playboy.

203
00:19:30,340 --> 00:19:35,740
The first one we get is this slash 20 of 4,096 hosts.

204
00:19:35,780 --> 00:19:41,860
There are a lot more netblocks they have, but for this example, that's enough for us.

205
00:19:42,440 --> 00:19:44,960
And so let's give it an initial try.

206
00:19:44,960 --> 00:19:46,280
We're going to do nmap.

207
00:19:46,280 --> 00:19:49,400
We'll say don't ping because we're only scanning one port.

208
00:19:49,400 --> 00:19:51,680
The ping would take longer than the scan.

209
00:19:52,140 --> 00:19:53,720
The port is 80.

210
00:19:53,900 --> 00:19:59,200
Save the results in grepable format so we can easily grep out the open servers.

211
00:19:59,200 --> 00:20:00,740
And then we give it the network.

212
00:20:00,740 --> 00:20:05,060
And it chugs along and it completes, but it takes 20 minutes.

213
00:20:05,280 --> 00:20:10,180
You know, even for 4,096 hosts, you know, that's longer than I want to wait.

214
00:20:10,600 --> 00:20:13,480
So how can we speed that up?

215
00:20:13,480 --> 00:20:19,400
One thing you can do is help by giving nmap timing information that it is trouble getting itself.

216
00:20:19,420 --> 00:20:24,800
On a responsive network, on your local LAN or whatever, you can usually...

217
00:20:24,800 --> 00: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.

218
00:20:32,240 --> 00:20:40,580
But when you're scanning over the Internet on a highly filtered network, nmap's not actually getting much responses.

219
00:20:40,580 --> 00: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.

220
00:20:47,700 --> 00: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.

221
00:20:54,280 --> 00:20:56,300
So I look for hosts on the network.

222
00:20:56,300 --> 00:21:00,980
First I try their web server and I see that that's on a different IP, so that's no good.

223
00:21:01,020 --> 00: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.

224
00:21:08,060 --> 00: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.

225
00:21:15,000 --> 00: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.

226
00:21:24,820 --> 00:21:26,880
So how do we figure out the latencies?

227
00:21:26,940 --> 00:21:28,780
Well, let's ping the hosts.

228
00:21:29,400 --> 00:21:33,500
Well, we try that, but they both say 100% packet loss.

229
00:21:33,500 --> 00:21:35,000
They're blocking our pings.

230
00:21:35,040 --> 00:21:36,400
Well, that's a bummer.

231
00:21:36,860 --> 00:21:41,020
But, you know, they're mail servers, and so they've got to have port 25 open.

232
00:21:41,420 --> 00:21:48,040
So let's use HPing 2 to do a TCP ping of those ports and see how long that takes.

233
00:21:48,200 --> 00: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.

234
00:22:00,980 --> 00: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.

235
00:22:10,480 --> 00:22:13,020
Because you want to be a little bit conservative here.

236
00:22:13,020 --> 00: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.

237
00:22:21,860 --> 00: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.

238
00:22:34,040 --> 00: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.

239
00:22:40,480 --> 00: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.

240
00:22:48,160 --> 00:22:51,660
And Nmap can still go faster if it determines that it can.

241
00:22:51,800 --> 00:22:55,060
Another optimization is to say scan in bigger groups.

242
00:22:55,060 --> 00:22:59,620
We're going to specify a minimum host group size of 512.

243
00:22:59,960 --> 00: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.

244
00:23:13,760 --> 00:23:16,340
And the rest of the options are pretty much the same.

245
00:23:16,340 --> 00:23:17,800
So how long does that take?

246
00:23:17,800 --> 00:23:23,060
Nmap chugs away and it still takes almost 15 minutes.

247
00:23:23,140 --> 00:23:25,820
That's better than 20 by a long shot.

248
00:23:25,820 --> 00:23:29,820
But let's be honest, when I'm looking for these free images, I'm not a patient guy.

249
00:23:30,660 --> 00:23:32,520
This is an urgent matter.

250
00:23:32,520 --> 00:23:38,080
And so I say, how can we make it a bit faster here?

251
00:23:38,840 --> 00:23:43,120
Well, think about what Nmap is doing under the covers in this case.

252
00:23:43,180 --> 00:23:47,140
Nmap, you may know, does reverse DNS resolution by default.

253
00:23:47,480 --> 00:23:53,400
And when I'm doing P0 scans, no ping, that means that Nmap is considering all of the hosts up.

254
00:23:53,400 --> 00:23:57,740
And so it's doing a reverse DNS resolution on every host.

255
00:23:57,780 --> 00:24:04,060
And reverse DNS, I'm afraid, is one of the few Nmap functions that's not yet parallelized.

256
00:24:04,060 --> 00:24:06,620
So that may be taking quite a lot of time.

257
00:24:07,040 --> 00:24:13,360
So I do the same scan, but this time I add hyphen N to get rid of reverse DNS resolution.

258
00:24:13,620 --> 00: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.

259
00:24:20,520 --> 00: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.

260
00:24:32,720 --> 00:24:33,940
But enough about timing.

261
00:24:33,940 --> 00:24:35,300
Let's look at the results.

262
00:24:36,480 --> 00:24:43,160
We did that big scan of 4,000 IPs, but we only found two that are open.

263
00:24:43,320 --> 00:24:46,500
Well, that was sort of a little bit worrisome, but you never know.

264
00:24:46,500 --> 00:24:47,760
Maybe they're good ones.

265
00:24:47,800 --> 00:24:49,580
Let's take a look in Firefox.

266
00:24:56,140 --> 00:25:01,640
So we'll go to the first one, which is 216.163.140.20.

267
00:25:03,080 --> 00:25:07,160
And we see Microsoft Outlook Web Access.

268
00:25:07,660 --> 00: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.

269
00:25:16,680 --> 00: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.

270
00:25:27,200 --> 00:25:33,300
It is nice to note their cute little Playboy mail logo up in the URL bar.

271
00:25:35,200 --> 00:25:39,720
But all is not lost because we still have one more site.

272
00:25:39,720 --> 00:25:48,320
And I'm very pleased to report that that one has gigabytes of free images that I downloaded immediately upon download.

273
00:25:52,460 --> 00:25:55,440
In fact, I think I'll even show you.

274
00:25:57,400 --> 00:26:05,220
So this one is 142.135.

275
00:26:05,680 --> 00:26:08,180
And so here it chugs away.

276
00:26:08,680 --> 00:26:13,680
And we see FreeBSD ISO images right over here.

277
00:26:13,680 --> 00:26:17,740
We see Fedora images, lots of them.

278
00:26:17,740 --> 00:26:23,460
And if you're on the kinky side of things, they've got the whole Perl network right around here.

279
00:26:23,460 --> 00:26:28,300
So whatever your tastes, this is a great site to download images.

280
00:26:28,300 --> 00: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.

281
00:26:40,980 --> 00:26:44,740
So we can say mission accomplished on that goal.

282
00:26:44,920 --> 00:26:50,780
But let's look at another quick single-service discovery option.

283
00:26:50,780 --> 00:26:53,060
And that's NMAP's version detection.

284
00:26:53,420 --> 00: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.

285
00:27:01,100 --> 00: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.

286
00:27:11,860 --> 00: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.

287
00:27:22,480 --> 00:27:31,980
And NMAP now has well over a thousand different version detection signatures to identify all sorts of crazy things.

288
00:27:32,320 --> 00:27:40,340
In this example, this is just one that someone sent last year when MyDoom was basically causing havoc.

289
00:27:40,600 --> 00:27:44,020
Right when it was released, he posted this to the NMAP dev.

290
00:27:44,020 --> 00:27:50,200
Here's a probe you can add so that you can identify compromised machines or infected machines.

291
00:27:50,640 --> 00: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.

292
00:28:01,600 --> 00:28:03,960
So you just say, do a TCP probe.

293
00:28:03,960 --> 00:28:05,400
We'll call it MyDoom.

294
00:28:05,400 --> 00:28:08,600
These two bytes are the data that you need to send.

295
00:28:08,820 --> 00:28:11,540
These are the ports that it normally listens on.

296
00:28:11,640 --> 00:28:14,180
And you'll match for service MyDoom.

297
00:28:14,180 --> 00:28:18,580
If you get this back in the response, the program is MyDoom.

298
00:28:18,580 --> 00:28:22,380
And for the version number, he just put, you know, the date it was found in the wild.

299
00:28:22,880 --> 00:28:25,220
So that's a real useful thing to add.

300
00:28:25,220 --> 00: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.

301
00:28:32,340 --> 00:28:36,020
So that's enough for single-service scanning.

302
00:28:36,360 --> 00:28:39,340
Let's try something a little different that's also common.

303
00:28:39,340 --> 00:28:41,700
What if you want to defeat a firewall?

304
00:28:41,700 --> 00: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.

305
00:28:48,920 --> 00:28:53,340
And NMAP has some techniques that can help you resolve that problem.

306
00:28:53,340 --> 00:28:55,160
So we've got another mission.

307
00:28:55,460 --> 00:29:01,280
This time we want to discern the open TCP ports on docserv.caldera.com.

308
00:29:01,500 --> 00: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.

309
00:29:11,800 --> 00:29:15,440
But lately, you know, their litigation is in shambles.

310
00:29:15,440 --> 00:29:17,780
And they're pretty much a laughingstock.

311
00:29:17,780 --> 00:29:20,440
And so it feels kind of like beating a dead horse.

312
00:29:21,320 --> 00: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.

313
00:29:32,560 --> 00:29:36,020
Also, they are a fun horse to beat, so let's do it.

314
00:29:38,040 --> 00: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.

315
00:29:43,340 --> 00:29:44,740
You know, that makes sense.

316
00:29:44,740 --> 00:29:45,560
It's the default.

317
00:29:45,560 --> 00:29:47,000
It's often the most useful.

318
00:29:47,040 --> 00:29:49,160
So we do a SIN scan against the machine.

319
00:29:49,160 --> 00:29:55,880
We find port 80 open, port 5007 open, and 113 is closed.

320
00:29:55,880 --> 00:29:57,240
So did we do it?

321
00:29:57,240 --> 00:29:58,180
Well, not really.

322
00:29:58,180 --> 00: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.

323
00:30:05,900 --> 00:30:08,100
So we don't know if they're open or closed.

324
00:30:08,220 --> 00: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.

325
00:30:16,680 --> 00:30:22,560
But just like with the Playboy example, I'm limiting it just to be a useful example.

326
00:30:22,720 --> 00:30:27,700
So we've got three, but there's still a huge number that we've not really determined.

327
00:30:27,720 --> 00:30:32,440
Those ports could be open and exploitable, those 1660, or they could be closed.

328
00:30:32,440 --> 00:30:33,600
We just don't know.

329
00:30:33,600 --> 00:30:35,380
So what do we want to try next?

330
00:30:36,640 --> 00:30:38,540
Let's try a different type of scan.

331
00:30:38,540 --> 00:30:40,420
Let's try the FIN scan.

332
00:30:40,420 --> 00: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.

333
00:30:53,240 --> 00: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.

334
00:31:01,100 --> 00: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.

335
00:31:12,860 --> 00:31:14,420
So that's very interesting.

336
00:31:14,420 --> 00: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.

337
00:31:21,380 --> 00: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.

338
00:31:31,680 --> 00: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.

339
00:31:39,180 --> 00:31:42,160
Well, let's try yet another type of scan against them.

340
00:31:48,120 --> 00:31:52,200
This time, we're going to try an ACK scan against DocServe.

341
00:31:52,220 --> 00: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.

342
00:32:08,600 --> 00:32:11,140
And so this gives us a lot more information.

343
00:32:11,140 --> 00:32:18,640
Here, the vast, vast majority are unfiltered, but it tells us that just two of them are filtered.

344
00:32:19,220 --> 00: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.

345
00:32:27,580 --> 00:32:29,880
For example, look at port 135.

346
00:32:29,960 --> 00:32:35,980
Here it says filtered, whereas before, 135 was open or filtered.

347
00:32:35,980 --> 00:32:41,860
Well, if you kind of take the logical end of those, you see that it's got to be filtered.

348
00:32:42,860 --> 00:32:47,040
Similarly, 1434 looks like it's really filtered.

349
00:32:47,240 --> 00:32:48,860
Let's take another example.

350
00:32:48,860 --> 00:32:51,840
Say you want to know about the SSH port, 22.

351
00:32:51,840 --> 00:32:57,680
In this case, it says that 22 is unfiltered, because it's one of all these other ports.

352
00:32:58,220 --> 00:33:02,260
And in this case, we see 22 is open or filtered.

353
00:33:02,260 --> 00:33:10,060
So if we have open or filtered on one scan, and unfiltered on the other, you know, that just leaves open.

354
00:33:10,640 --> 00: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.

355
00:33:29,380 --> 00:33:32,420
And so, you know, that tells you a lot.

356
00:33:32,420 --> 00: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.

357
00:33:39,300 --> 00:33:44,400
You see here as well, 80 and 507 in the open or filtered.

358
00:33:44,400 --> 00:33:47,100
So we have a pretty good idea about what we're seeing.

359
00:33:47,100 --> 00:33:48,720
But networks can be tricky.

360
00:33:48,720 --> 00:33:53,160
It's always good to check your results, try different things, see what's matching up.

361
00:33:53,160 --> 00:33:55,600
So let's try yet another type of scan.

362
00:33:55,600 --> 00:34:00,020
And that's the Windows scan, which is a little-known scan technique.

363
00:34:00,020 --> 00: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.

364
00:34:18,800 --> 00:34:24,460
Whereas, when they're sending a reset back from a closed port, they set the window to zero.

365
00:34:24,660 --> 00: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.

366
00:34:32,220 --> 00: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.

367
00:34:44,080 --> 00:34:50,080
Or no, it was my MS SQL was the other one, 1434 was filtered.

368
00:34:50,080 --> 00:34:52,420
So that sort of confirms our results now.

369
00:34:52,420 --> 00:34:57,700
We've tried a lot of different things, and now we have a good idea where they're open.

370
00:34:58,360 --> 00: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.

371
00:35:10,000 --> 00:35:13,620
So that was basically our three missions.

372
00:35:13,820 --> 00: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.

373
00:35:23,280 --> 00:35:28,520
There's the ARP scanning that we've already talked about, the MAC spoofing.

374
00:35:28,520 --> 00:35:35,740
One nice new feature is raw Ethernet packet sending, because raw IP packets can be a huge mess.

375
00:35:35,740 --> 00: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.

376
00:35:43,360 --> 00:35:45,620
So now we're saying, well, screw you, Microsoft.

377
00:35:45,620 --> 00:35:50,500
We're just going to send at a lower level, and send the Ethernet packets directly.

378
00:35:50,500 --> 00:35:52,300
And that should be a lot faster.

379
00:35:52,620 --> 00: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.

380
00:36:06,280 --> 00: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.

381
00:36:20,080 --> 00:36:26,420
It integrates Doug Song's excellent LibDNet, which helps with the raw Ethernet packets sending.

382
00:36:27,400 --> 00:36:32,620
Version detection now helps you find OS information.

383
00:36:32,760 --> 00:36:38,140
So the version detection now can find three extra things in many cases.

384
00:36:38,140 --> 00: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.

385
00:36:49,300 --> 00:36:54,740
The OS detection results are this, and version detection says it looks like this OS.

386
00:36:54,780 --> 00:37:00,040
And some people would say, hey, combine those to get just one result.

387
00:37:00,040 --> 00:37:04,660
But in reality, what you really want is to have both, because they may be distinct.

388
00:37:04,660 --> 00: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.

389
00:37:22,540 --> 00:37:23,500
And that's pretty common.

390
00:37:23,500 --> 00: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.

391
00:37:33,440 --> 00:37:40,140
Version detection also now gives device information and host name information, which can be valuable.

392
00:37:40,180 --> 00:37:46,680
I broke the Windows support, I'm afraid, for the moment, but that may be fixed eventually.

393
00:37:47,540 --> 00:37:52,480
And when it is fixed, though, we'll have the advantages of the raw packet sending.

394
00:37:53,060 --> 00: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.

395
00:38:03,900 --> 00:38:09,300
And then there's also quite a few more features, which you can find in the changelog.

396
00:38:09,860 --> 00:38:11,420
What's coming next?

397
00:38:11,420 --> 00:38:17,780
Well, I'm happy to report that Google has sponsored 10 students to work on Nmap for the summer.

398
00:38:17,940 --> 00:38:24,940
And yeah, they're student programmers, but some of them are serious students, like PhD students in doing very relevant research.

399
00:38:25,160 --> 00:38:29,180
And so that's pretty exciting, and they're working on a whole lot of projects.

400
00:38:29,180 --> 00:38:36,500
There were 233 applications, and I picked the top 10, and we worked out some pretty cool projects.

401
00:38:36,700 --> 00: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.

402
00:38:44,380 --> 00: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.

403
00:38:59,240 --> 00:39:01,000
You know, all sorts of cool features.

404
00:39:01,000 --> 00:39:06,700
And you'll find a man page that he's posted so far on the Nmap dev list.

405
00:39:06,780 --> 00:39:09,060
And he's working on the implementation.

406
00:39:09,320 --> 00:39:10,520
New GUIs.

407
00:39:10,520 --> 00: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.

408
00:39:17,780 --> 00:39:20,900
But these are more advanced user GUIs.

409
00:39:21,480 --> 00:39:23,460
They're mostly results viewers.

410
00:39:23,460 --> 00:39:26,520
So you've scanned tens of thousands of machines.

411
00:39:26,520 --> 00: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.

412
00:39:35,520 --> 00:39:37,100
You know, features like that.

413
00:39:37,120 --> 00:39:43,280
And there are actually two of these SOC students writing independent GUIs.

414
00:39:43,740 --> 00:39:45,300
Potential scripting language.

415
00:39:45,300 --> 00:39:47,500
I'm not sure if that's going to work out yet or not.

416
00:39:47,500 --> 00:39:49,620
But this guy is working on that.

417
00:39:49,920 --> 00:39:54,460
And when that is added, we'll probably use that for host discovery stuff.

418
00:39:54,460 --> 00:40:01,360
Information gathering as opposed to, you know, trying to add a thousand different vulnerability detection modules.

419
00:40:01,360 --> 00:40:04,660
We'll focus on, hey, have a script that does trace route.

420
00:40:04,660 --> 00:40:07,580
Have a script that checks whether a proxy is open.

421
00:40:07,580 --> 00: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.

422
00:40:18,580 --> 00:40:21,220
Windows performance is a big priority.

423
00:40:21,600 --> 00: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.

424
00:40:29,700 --> 00: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.

425
00:40:37,220 --> 00: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.

426
00:40:49,520 --> 00: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.

427
00:40:59,740 --> 00: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.

428
00:41:09,360 --> 00:41:13,840
So that'll be useful for more understanding what's going on under the covers.

429
00:41:13,980 --> 00:41:16,540
And then I might add proxy and sock scanning.

430
00:41:17,380 --> 00:41:21,300
So that's basically my presentation, which is good because I'm about out of time.

431
00:41:21,300 --> 00:41:24,220
I'll just take two questions here, if anyone has them.

432
00:41:29,900 --> 00:41:32,500
Yes, I'll put the slides...

433
00:41:37,770 --> 00:41:38,510
Yeah.

434
00:41:38,870 --> 00:41:43,490
Yes, docserv.caldera.com No.

435
00:41:44,370 --> 00: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.

436
00:41:53,490 --> 00:41:55,030
Thank you very much.