1
00:00:04,920 --> 00:00:10,120
And it turns out that when you're doing spell check, it would really help if you check all the files.

2
00:00:10,120 --> 00:00:12,580
So sorry about the introducing thing.

3
00:00:12,580 --> 00:00:13,380
Oh well.

4
00:00:15,400 --> 00:00:18,080
Okay, so we're going to talk about a lot of stuff.

5
00:00:18,080 --> 00:00:27,400
One of the most important things that we wanted to highlight is a new way that we are keeping track of connection state as we're talking to remote systems.

6
00:00:27,400 --> 00:00:29,120
So that's what the scatter connect is all about.

7
00:00:29,120 --> 00:00:30,900
And you'll see that in detail.

8
00:00:30,900 --> 00:00:32,960
In fact, that's the first thing that we're going to hit off.

9
00:00:33,020 --> 00:00:36,700
Then we're going to talk a little bit about the tool that we're releasing today.

10
00:00:36,960 --> 00:00:45,600
We actually have released it previously, but this new version has somewhere around 25,000 lines of code change.

11
00:00:45,600 --> 00:00:47,420
So it's definitely different.

12
00:00:47,420 --> 00:00:51,780
And then we're going to demonstrate some of what it can do.

13
00:00:52,160 --> 00:00:54,020
So, I'm Robert Lee.

14
00:00:54,020 --> 00:00:57,120
I do stuff with a couple companies.

15
00:00:57,120 --> 00:01:00,960
And this is Jack, and we also have Anthony here in the audience.

16
00:01:00,960 --> 00:01:06,340
We've been working really hard on this stuff, so hopefully you'll be able to appreciate some of what we've been working on.

17
00:01:07,240 --> 00:01:09,240
Okay, so nice and simple.

18
00:01:09,560 --> 00:01:12,400
You've all seen a TCP three-way handshake before.

19
00:01:12,400 --> 00:01:13,440
The concept is simple.

20
00:01:13,440 --> 00:01:15,740
You're trying to initiate a connection.

21
00:01:15,740 --> 00:01:16,800
You send a SYN packet.

22
00:01:16,800 --> 00:01:18,780
You expect a SYN ACK if it's open.

23
00:01:18,780 --> 00:01:22,200
You acknowledge it, and then your connection is open.

24
00:01:22,200 --> 00:01:25,600
It's actually two one-way connections, but whatever.

25
00:01:27,880 --> 00:01:32,780
I'm not sure if you can see this, but I'll visually walk you through what's happening here.

26
00:01:32,840 --> 00:01:40,460
The very first process, the master control on the far left is what's going to keep track of all the state connections.

27
00:01:40,740 --> 00:01:47,620
In this particular example, we are doing a TCP port 80 full connection with a remote host.

28
00:01:47,620 --> 00:01:50,720
That's the one on the far right with the little globe thing.

29
00:01:50,720 --> 00:02:00,900
What happens is the master control tells the first sender, the one on the very top, that we are trying to connect to that remote network.

30
00:02:00,900 --> 00:02:08,160
And then the sender will actually create a packet, spoofing its source IP address to come from the receiver.

31
00:02:08,340 --> 00:02:12,360
If you can see it, the receiver machine is the one on the far bottom.

32
00:02:12,680 --> 00:02:23,760
When the remote host, the 192.168.1.1, receives that SYN packet, it responds to the SYN packet based on the IP address that it thought it came from.

33
00:02:23,760 --> 00:02:25,900
So that's how the receiver receives it.

34
00:02:25,980 --> 00:02:37,920
Once the receiver receives the SYN ACK, it sends the meta information back to the master control thread, who then schedules an acknowledgment to be sent through an immediate sender.

35
00:02:37,920 --> 00:02:39,440
So that's the one in the middle.

36
00:02:39,500 --> 00:02:45,600
So the acknowledgment is then sent back to 192.168.1.1, and the three-way handshake is complete.

37
00:02:45,600 --> 00:02:50,440
Now, I know this looks pretty crazy, and you're probably asking yourself right now, why would you do it this way?

38
00:02:50,440 --> 00:02:51,880
And I'm glad you asked that question.

39
00:02:51,880 --> 00:02:53,400
We'll answer that later.

40
00:02:53,400 --> 00:03:03,600
But the important part here is that you understand that at this point, we have taken the TCP IP stack and moved it out of kernel space and essentially into user LAN space.

41
00:03:03,600 --> 00:03:09,320
And we've made it so that you can have a three-way handshake amongst a cluster of machines.

42
00:03:09,320 --> 00:03:16,160
But to the end machine on the right-hand side, it's all a normal connection to him.

43
00:03:16,900 --> 00:03:23,980
Once his handshake is complete, we can also then send arbitrary payload-specific stuff.

44
00:03:23,980 --> 00:03:29,820
So if you wanted to do a GET request or any arbitrary payload can be sent at that point.

45
00:03:30,000 --> 00:03:31,920
Important stuff.

46
00:03:32,540 --> 00:03:39,540
Okay, so I just explained all this, but I'll go through it one more time just for clarity.

47
00:03:39,960 --> 00:03:44,040
The first process, again, is the unicorn scan main thread.

48
00:03:44,080 --> 00:03:47,300
Second process is the sender that's Unisend.

49
00:03:47,300 --> 00:03:49,540
That's the one that actually assembles the packets.

50
00:03:50,820 --> 00:03:54,480
Again, we have the concept of batch sender and immediate sender.

51
00:03:54,480 --> 00:03:58,980
The batch sender, it turns out, is the one that you give large work units to.

52
00:03:58,980 --> 00:04:04,760
So you can say, I want to scan this slash 16 network, and I'm looking to do these ports.

53
00:04:04,760 --> 00:04:07,440
And you tell it what speed to do it, et cetera, et cetera.

54
00:04:07,440 --> 00:04:10,160
So it just goes out and sends a bazillion send packets.

55
00:04:10,760 --> 00:04:21,940
The listener process, the one on the bottom, Unilisten, is the one that's collecting all the information that comes back to it and sending all the metadata back to the main unicorn scan thread.

56
00:04:22,380 --> 00:04:26,100
And then the immediate mode is the one that completes the three-way handshake.

57
00:04:27,020 --> 00:04:29,300
They're not actually threads, by the way.

58
00:04:29,300 --> 00:04:30,460
They're actually processes.

59
00:04:30,460 --> 00:04:31,900
We just call them threads.

60
00:04:32,040 --> 00:04:33,640
Because we're silly like that.

61
00:04:35,480 --> 00:04:36,700
Okay, cool.

62
00:04:36,700 --> 00:04:38,340
I've talked about all this.

63
00:04:38,520 --> 00:04:40,580
Is that part clear at all?

64
00:04:40,900 --> 00:04:41,560
All right, cool.

65
00:04:41,560 --> 00:04:42,660
We did it twice.

66
00:04:42,880 --> 00:04:47,340
Now I'm going to talk about some problems that we were banging our heads against.

67
00:04:47,340 --> 00:04:51,660
By the way, all we do with the companies is we do a lot of security testing.

68
00:04:51,660 --> 00:04:53,000
Really big networks.

69
00:04:54,500 --> 00:04:59,400
We've been eating a lot of dirt with tools that didn't do what we needed to do.

70
00:04:59,400 --> 00:05:01,440
So that's basically why we did this.

71
00:05:01,440 --> 00:05:06,420
But one of the first problems that we ran into is the whole UDP thing.

72
00:05:06,740 --> 00:05:14,160
Just to summarize, when you're doing UDP scanning, traditionally you're sending a UDP probe with a blank datagram.

73
00:05:14,160 --> 00:05:18,940
And you're hoping that the machine on the other side will send you an ICMP packet.

74
00:05:18,940 --> 00:05:21,800
So if the ports close, you'll know.

75
00:05:21,800 --> 00:05:26,720
And you basically, the ones that you don't get the message back from, you assume that it's open.

76
00:05:26,780 --> 00:05:30,440
The problem is it turns out people are actually using firewalls.

77
00:05:30,440 --> 00:05:39,140
And so when you're doing testing from a remote perspective, if you can't get on the ICMP message coming back to you, then it's kind of a useless process.

78
00:05:39,140 --> 00:05:40,000
That's one of the problems.

79
00:05:40,000 --> 00:05:47,060
The other problem is you can't go really fast, even if the machine's sitting next to you and there's no filtering going on, because ICMP messages are rate limited.

80
00:05:47,060 --> 00:05:50,280
So it's a really slow and ugly process.

81
00:05:50,800 --> 00:06:05,460
So what we ended up doing, as a quick and dirty workaround, is we were taking the individual programs like BIG or SNMP walk, and we were scripting it to send the actual client probes.

82
00:06:05,460 --> 00:06:16,780
And then we got this idea, maybe it would be cool if we had an automated way of doing all those probes without having to manage the individual tools and all the individual output.

83
00:06:16,780 --> 00:06:18,220
But we'll come back to that.

84
00:06:19,180 --> 00:06:31,660
Another problem we had with our TCP scanning is that it was a large effort to do what we really wanted to do, which is actually talk to the service that we wanted to interact with.

85
00:06:31,660 --> 00:06:45,380
So typically if you're scanning like a Slash 8, just based on the resource limitations on your side alone, usually you'll have to do a send scan first and keep track of which ports are open.

86
00:06:45,380 --> 00:06:50,400
And then on the open ports, you can go back and actually do a banner grab.

87
00:06:50,460 --> 00:06:54,380
And then as a third step, you can start interacting with the remote service.

88
00:06:54,380 --> 00:06:57,820
You can use AMAP or manual testing or whatever.

89
00:06:58,460 --> 00:07:06,680
But it's difficult, especially if you're testing a dynamic network that's really large, because by the time you're done with your first pass, things have changed.

90
00:07:06,940 --> 00:07:13,500
Because it turns out that these networks are getting really big, especially now that we're starting to move into IPv6 stuff.

91
00:07:13,500 --> 00:07:21,000
But the tools that we're using today are not really useful if you're testing 65,000 to 4 billion machines at a time.

92
00:07:21,740 --> 00:07:27,420
And even if you were, playing with set and knock with the text output is really overwhelming.

93
00:07:28,960 --> 00:07:30,640
Really overwhelming.

94
00:07:31,880 --> 00:07:46,060
Okay, some more problems that we have with any vulnerability scanner that we've played with is that the probes that they do don't really share the information in a way that makes a lot of sense.

95
00:07:46,100 --> 00:07:59,680
So one of our favorite examples to make fun of is the situation where some sort of device in the middle is altering the TCP IP stack enough to where your operating system probe comes back and says, hey, it's an Amiga Miami OS machine.

96
00:07:59,680 --> 00:08:01,640
Who the hell runs Amiga Miami OS?

97
00:08:01,640 --> 00:08:09,400
But anyhow, then the second probe that actually connects to TCP port 80 and does a banner grab will show you that it's an IIS 5 machine.

98
00:08:09,680 --> 00:08:24,020
And then because they have an IPS or something actively killing connections when it sees something bad across the wire, when you send your Apache exploit, it kills the session and your tool thinks that the DOS attack was successful.

99
00:08:24,020 --> 00:08:29,400
So then you come back and find out that Apache DOS vulnerability was successful.

100
00:08:29,500 --> 00:08:30,640
So that's fine.

101
00:08:30,640 --> 00:08:35,000
If you're testing one machine, you can go through the false positives and figure out what's really going on.

102
00:08:35,000 --> 00:08:37,600
But imagine doing this times 4 billion machines.

103
00:08:37,600 --> 00:08:39,160
Not really useful.

104
00:08:39,440 --> 00:08:44,680
So to be useful in the future, these modules are going to need to share the information more intelligently.

105
00:08:45,960 --> 00:08:49,060
Some more problems that we're having is with the timing.

106
00:08:49,740 --> 00:09:00,040
In order to more efficiently use the resources that you have available to you, we need to be able to control how fast we're sending.

107
00:09:00,040 --> 00:09:03,660
And I'll give you the two examples in the open source space.

108
00:09:03,660 --> 00:09:08,160
We have the scanran tool that provided a minus B option for bandwidth.

109
00:09:08,400 --> 00:09:13,040
But I probably just haven't played with it enough.

110
00:09:13,040 --> 00:09:19,160
But in my experience, anything over like 5K to 10K, I was noticing a lot of packet loss.

111
00:09:19,160 --> 00:09:21,200
And it also became bursty.

112
00:09:21,660 --> 00:09:23,880
And so it didn't really work out.

113
00:09:23,880 --> 00:09:30,480
Mostly because of the way that the sleep timer was working and the get time of day counter was working.

114
00:09:30,540 --> 00:09:33,900
And then with nmap, you have normal, aggressive, insane or things like that.

115
00:09:33,900 --> 00:09:37,340
But even in insane mode, it doesn't scale to high speeds.

116
00:09:37,420 --> 00:09:44,780
And there's a lot of paralyzation going on there that's kind of tricking you into thinking that it's doing more than it is.

117
00:09:44,780 --> 00:09:50,720
But the timing of how fast you can go is still greatly affected by the machines that you're probing.

118
00:09:50,720 --> 00:09:58,760
To nmap's credit, we actually got nmap to send out more packets per second than we did scanran.

119
00:10:01,360 --> 00:10:03,720
Oh, just some raw numbers real quick.

120
00:10:04,440 --> 00:10:14,440
With our tool at this point, on a standard copper gigabit card, we're successful at sending over 160,000 packets per second reliably.

121
00:10:14,440 --> 00:10:21,580
And we're working with some FPGA people to get that in the 500,000 to million packet per second range.

122
00:10:21,760 --> 00:10:23,160
But we're still working on that.

123
00:10:23,160 --> 00:10:25,240
That's pie in the sky at this point.

124
00:10:26,060 --> 00:10:33,920
But from an average laptop, you can expect anywhere from 17,000 to 70,000 packets per second being pretty reliable to send.

125
00:10:34,120 --> 00:10:39,020
But you're still going to want to break it up into different processes and I'll show you why.

126
00:10:39,640 --> 00:10:40,860
Some more mindset.

127
00:10:40,860 --> 00:10:42,580
Okay, so now we've told you about some problems.

128
00:10:42,580 --> 00:10:44,500
What are we going to do to solve these problems?

129
00:10:44,560 --> 00:10:49,240
Well, from the get-go, we were designing this with scalability in mind.

130
00:10:49,480 --> 00:10:53,480
I talked about efficient use of resources and I'm going to give you a bus analogy.

131
00:10:54,160 --> 00:11:03,780
Basically, I watched Sesame Street as a kid and they were trying to pollute our minds with this political message that buses are better than Ferraris because they're more efficient.

132
00:11:04,360 --> 00:11:15,340
But in the example, they had 100 kids on the left and 100 kids on the right and they had three small sports cars ferreting people from one site to another site.

133
00:11:15,340 --> 00:11:20,420
They gave them a 20-minute head start and then they had the other 100 kids all jump on one bus and just go.

134
00:11:21,400 --> 00:11:23,340
Let me break it down technically now.

135
00:11:23,760 --> 00:11:29,960
When you use an individual machine, there's only so fast that you can reliably send and receive packets.

136
00:11:29,960 --> 00:11:37,460
So even if you could get Nmap or ScanRan to go at 70,000 packets per second, you're not going to have any room left to receive messages.

137
00:11:37,460 --> 00:11:48,620
And so you're going to have to throw all that back to something more reasonable around the 35,000, 30,000 packet per second range if you actually want to get the messages to come back to you.

138
00:11:48,700 --> 00:11:52,820
So that's not going to be an efficient use of even a single machine.

139
00:11:52,840 --> 00:12:06,100
But with scalability in mind, we know that we need to be able to have one logical working scanning system that can scale beyond the limitations of any single resource, any single machine.

140
00:12:06,100 --> 00:12:08,460
So it's not the same as just going faster.

141
00:12:08,460 --> 00:12:18,500
I quoted some really ridiculous packet per second rates from a single machine, but obviously if you go that fast to any network that we're playing with today, you're going to obliterate it.

142
00:12:18,500 --> 00:12:33,740
I mean, I've seen some of these networks with even the big high-end Juniper firewalls sitting in front of multiple OC3s that fall over dead at even 8,000 packets per second if they have that stupid sin scan protection thing on.

143
00:12:33,740 --> 00:12:38,900
By the way, funny, if any Juniper people are listening, I don't get that.

144
00:12:38,900 --> 00:12:44,120
Protection that completely doshes your CPU is... well, I don't understand that at all.

145
00:12:44,120 --> 00:12:45,900
Anyhow, moving on.

146
00:12:46,900 --> 00:12:48,280
Okay, accuracy.

147
00:12:48,760 --> 00:12:55,820
If you're collecting a lot of information and it's a lot of invalid information, then you're wasting your time.

148
00:12:55,820 --> 00:13:00,820
This is my problem with those log aggregation systems where you have the garbage in, garbage out model.

149
00:13:00,820 --> 00:13:03,340
If you can't trust the information, it's kind of worthless.

150
00:13:03,340 --> 00:13:09,220
One of the problems that we have with a lot of tools is they try to be smarter than is programmatically possible.

151
00:13:10,460 --> 00:13:15,840
Basically, I think tools should introduce stimulus and record response and let the humans analyze.

152
00:13:15,860 --> 00:13:22,160
Computers are good at doing the tedious automated parts, humans are good at thinking, and we shouldn't really mix the two more than we have to.

153
00:13:24,540 --> 00:13:25,380
Flexibility.

154
00:13:25,720 --> 00:13:40,620
At this point, with this framework, and you'll see examples of this, any stimulus that you want to introduce to the remote side, currently we support TCP and UDP, but we're going to support ICP and pretty much anything else that you can do over IP.

155
00:13:40,780 --> 00:13:46,940
And then, depending on which contracts happen, we're also going to support a lot of other protocols.

156
00:13:47,300 --> 00:13:53,640
But if you have the hardware and you need to write something to the hardware, we're going to be able to support it in the future.

157
00:13:54,240 --> 00:13:55,520
And then security.

158
00:13:55,620 --> 00:13:58,520
It should go with that same, but it doesn't really.

159
00:13:58,520 --> 00:14:12,000
We tried to put some formal thought into this, and we actually selected one of the IDS protection profiles from the Common Criteria to build our implementation of the scanner against.

160
00:14:12,000 --> 00:14:17,340
And we also provide a sample security policy for use with SELinux.

161
00:14:17,740 --> 00:14:23,000
And yeah, that was at least in the design phase when we considered that.

162
00:14:23,000 --> 00:14:31,480
We don't actually have the entire protection profile implemented, but we designed it so that we could when we actually release one.

163
00:14:31,480 --> 00:14:38,880
And obviously with an open source tool, we don't have $5 million to formally go through the process, but if anyone here wants to sponsor that, we would love it.

164
00:14:41,550 --> 00:14:42,510
Cool.

165
00:14:44,830 --> 00:14:47,830
All right, yeah, so what does it do?

166
00:14:47,830 --> 00:14:54,410
Right, people have been calling it a port scanner, and we're hopeful that after today, they'll see that it's more than that.

167
00:14:54,410 --> 00:14:57,550
But currently, it can do TCP and UDP port scanning.

168
00:14:57,550 --> 00:15:01,810
It can do stateless banner grabbing or active remote OS application, blah, blah, blah.

169
00:15:01,810 --> 00:15:03,030
It can do stuff.

170
00:15:03,030 --> 00:15:15,250
And some more interesting things is that instead of just sending a non-protocol specific probe, we actually can send the same thing that a normal client would do.

171
00:15:15,250 --> 00:15:17,550
So let's say that you're trying to find DNS servers.

172
00:15:17,550 --> 00:15:26,270
Instead of just sending a blank datagram to UDP port 53, we support a number of different payloads out of the default config file.

173
00:15:26,270 --> 00:15:28,950
One of them can ask it for local host.

174
00:15:28,950 --> 00:15:31,030
One of them can do a chaos.

175
00:15:32,950 --> 00:15:35,670
If you're talking to a bind server, you're trying to find out what version it is.

176
00:15:36,190 --> 00:15:44,210
But now we're doing just-in-time processing to where you can stuff things in there that you need to calculate on the fly.

177
00:15:44,210 --> 00:15:51,190
So for, like, Dan Bernstein's DNS server, we put one in there that will ask it for the IP address that you're talking to.

178
00:15:51,190 --> 00:15:54,810
So it can stuff the IP that it's talking to in there on the fly.

179
00:15:54,810 --> 00:15:59,750
But any other thing that you need to calculate right before creating the packet, that also works.

180
00:16:00,710 --> 00:16:11,370
And then for TCP, it's going to become more important nowadays as well, because a lot of the networks that we're testing have those things that complete the three-way handshake on behalf of the devices that are behind it.

181
00:16:11,370 --> 00:16:17,550
And so you're going to find situations where every single port on every single IP on the remote network come back as open.

182
00:16:17,670 --> 00:16:22,890
And you need to be able to send protocol-specific payloads so you can figure out which ones are tricking you.

183
00:16:23,490 --> 00:16:37,590
Then one of the other things that we put in there is a metamorphic shellcode encoder to make it so that when you are delivering other types of payloads, that you can make it so that they are not easily fingerprintable.

184
00:16:37,910 --> 00:16:43,270
So not only is the NOPS-led metamorphic, but the encoder itself is as well.

185
00:16:43,610 --> 00:16:48,050
And so basically there's nothing to write a signature for at this point.

186
00:16:48,050 --> 00:16:50,370
We'll see.

187
00:16:50,570 --> 00:16:53,530
Okay, and then we also can log to PCAP files.

188
00:16:53,530 --> 00:17:06,450
And everything we do, and I can't stress this enough, everything we're doing from this point forward has hooks to talk to relational databases on the back end, because you cannot process this amount of data without one.

189
00:17:07,670 --> 00:17:10,110
Okay, so now I'm going to pass the mic over to Jack.

190
00:17:11,270 --> 00:17:12,990
Alright, how are we doing everyone?

191
00:17:12,990 --> 00:17:14,810
Are we falling asleep yet?

192
00:17:15,890 --> 00:17:18,470
Alright, I guess not.

193
00:17:18,610 --> 00:17:20,870
Okay, well, there's three processes.

194
00:17:20,870 --> 00:17:23,750
I guess it's pretty obvious what they do.

195
00:17:23,750 --> 00:17:25,070
I'm not really going to talk about them.

196
00:17:25,070 --> 00:17:28,490
Hopefully we're going to actually leave some time for some demos that we want to do.

197
00:17:29,510 --> 00:17:40,710
Okay, one of the things that's different is that we try and use, it's kind of a trivial algorithm to actually carry information inside the sequence number, but the important part is that it's not one way.

198
00:17:41,010 --> 00:17:45,830
So in other words, if we used MD5 and then lopped off part of it, it wouldn't be one way.

199
00:17:45,830 --> 00:17:49,350
So we can't do that because we actually need to do TCP connections.

200
00:17:49,670 --> 00:17:58,930
The problem is that we can't actually have the guy who's sniffing and validating the sequence number send back a question to the master thread to figure out if that's correct or not.

201
00:17:58,930 --> 00:18:03,470
So we actually have to do that with a trivial algorithm.

202
00:18:03,750 --> 00:18:17,850
Anyway, and then the scatter connect is we basically send out the SYN packets, and then we gather on the syntax that we get back and act the connection and actually do whatever it is that the scanner's configured to do.

203
00:18:19,390 --> 00:18:22,390
Well, this is actually kind of long and drawn out.

204
00:18:22,390 --> 00:18:24,230
What do I have, like 20 minutes left?

205
00:18:25,710 --> 00:18:26,570
Half hour?

206
00:18:26,570 --> 00:18:27,190
Okay.

207
00:18:27,190 --> 00:18:28,650
Well, I'll go through this.

208
00:18:28,650 --> 00:18:34,970
It's actually 30 steps to a symbol SYN scan.

209
00:18:34,970 --> 00:18:40,430
So basically, obviously the user would invoke the scanner from the command line.

210
00:18:40,530 --> 00:18:50,650
It actually reads the configuration file first, and then the actual command line arguments are parsed at that point so that you can override the configuration file.

211
00:18:50,650 --> 00:18:54,970
But if you get sick of typing certain options over and over, you just put them in there.

212
00:18:55,190 --> 00:19:02,650
Anyways, the master process actually opens up binary modules through whatever facilities on the system.

213
00:19:02,650 --> 00:19:07,250
We use the LTDL interface now, so it's a bit more portable.

214
00:19:07,250 --> 00:19:10,990
And we actually have auto-conf too, which is pretty ugly.

215
00:19:11,230 --> 00:19:18,930
Anyways, the master process figures out whether or not you want it to run in a clustered mode, which is a command line argument.

216
00:19:19,390 --> 00:19:27,810
But this is actually for a local scan, so we're just assuming that the master thread is actually going to fork children.

217
00:19:28,330 --> 00:19:39,030
And then it actually records some information about them, and it actually uses... the IPC goes through a Unix domain socket, so it's actually a little bit faster than it used to be.

218
00:19:39,230 --> 00:19:47,110
And then it actually uses signals to synchronize, which I believe is actually causing us problems portability-wise.

219
00:19:47,110 --> 00:19:56,190
So one of the problems with this release is that on certain machines the signals disappear, and if we actually use reliable signals, it's not portable.

220
00:19:56,190 --> 00:19:59,090
So we might actually have to change that a bit.

221
00:19:59,090 --> 00:20:09,210
And then actually the important part is that we can't make the assumption we know what the other processes do, because we don't know if we're in cluster mode.

222
00:20:09,210 --> 00:20:15,930
If we're in cluster mode, all we know is an IP address and a port, and we don't know if it's going to send or listen.

223
00:20:16,370 --> 00:20:17,990
So we actually...

224
00:20:17,990 --> 00:20:19,470
That's an important piece right there.

225
00:20:19,470 --> 00:20:22,890
You don't have to have 16 machines to port scan one machine.

226
00:20:22,890 --> 00:20:24,610
You can do it all from one machine.

227
00:20:24,690 --> 00:20:26,790
You can't scale if you need to.

228
00:20:26,790 --> 00:20:27,570
Okay.

229
00:20:28,450 --> 00:20:32,850
Anyways, they connect up and send some information.

230
00:20:32,850 --> 00:20:39,810
It's actually the listener that contains a lot of useful information early on, because it's the guy who has the IP address that matters.

231
00:20:39,870 --> 00:20:43,790
So actually during that handshake it sends the information back.

232
00:20:44,150 --> 00:20:45,050
Anyways.

233
00:20:45,150 --> 00:20:48,050
And then everyone syncs up with a ready message.

234
00:20:48,390 --> 00:20:55,170
And then the master actually does something called stirring, which actually would be doing the work unit allocation.

235
00:20:55,170 --> 00:20:58,910
And we actually have some stuff to do that, but it's kind of specific to us.

236
00:20:58,910 --> 00:21:17,890
I think in the general code we actually don't have anything useful when it stirs, but if you actually had a big cluster and you wanted to actually distribute the send packets amongst geographical areas, that's where you would put the code to do that, so that you would actually have the shortest amount of hops between each sender.

237
00:21:18,230 --> 00:21:18,730
Okay.

238
00:21:18,850 --> 00:21:19,730
Anyways.

239
00:21:19,810 --> 00:21:20,630
Right.

240
00:21:20,630 --> 00:21:28,670
Then the listener fires up, and then we send the sender a batch work unit, which basically means it's not going to get interrupted.

241
00:21:29,030 --> 00:21:35,530
So hopefully, or if it's a batch sender anyways, we don't want to interrupt him.

242
00:21:35,530 --> 00:21:41,790
We don't want him to have to pull the IPC channel, because it slows him down.

243
00:21:42,310 --> 00:21:42,690
Okay.

244
00:21:42,690 --> 00:21:45,030
And then the master just goes into a loop.

245
00:21:45,850 --> 00:21:53,150
And when the sender finishes, it sends a work done, and then we actually check to see if it has more work.

246
00:21:53,650 --> 00:21:56,570
And if not, it just goes into a timeout state.

247
00:21:56,570 --> 00:22:09,930
But meanwhile, any important things that are happening, such as TCP connections, it will actually respond to those while it's in its timeout state, or actually throughout the entire scan.

248
00:22:10,070 --> 00:22:14,610
And then actually the master tells the sender and listener to quit, and then the scan's done.

249
00:22:15,690 --> 00:22:16,310
Right.

250
00:22:16,310 --> 00:22:16,650
Okay.

251
00:22:16,650 --> 00:22:28,770
So the important part about all that nonsense is that a general stack that's inside of a kernel normally knows the remote target that it's going to talk to, or remote host and port, but we don't.

252
00:22:28,770 --> 00:22:30,590
So we actually don't have that model.

253
00:22:30,590 --> 00:22:32,330
It's completely incompatible.

254
00:22:32,550 --> 00:22:45,830
So we actually just kind of redid some of the decisions inside the stack so that it would better fit a model where we don't know that information, which is the scatter stuff.

255
00:22:45,830 --> 00:22:46,530
Anyways.

256
00:22:47,410 --> 00:22:48,290
Right.

257
00:22:48,530 --> 00:22:49,030
Okay.

258
00:22:49,030 --> 00:22:56,930
One of the important things is a lot of stacks we'll use like a hash table, but we can't actually do that because we don't actually know who's going to talk to us.

259
00:22:56,930 --> 00:23:14,010
A good example is if we scan a network that actually syntax packets, it'll fill up our state table, and if there's nothing behind that device, we'll have a bunch of dead entries in our connection table, and we'll probably guess the size of the hash table wrong by doing that,

260
00:23:14,010 --> 00:23:20,870
and our hash table will basically either collide to death, or it'll have a bunch of linked lists instead of being a hash table.

261
00:23:20,870 --> 00:23:23,110
So that's obviously not what we want.

262
00:23:23,110 --> 00:23:30,370
We actually have to pick a data structure that responds better to unpredictable things like that, like a binary tree.

263
00:23:30,850 --> 00:23:31,590
Anyways.

264
00:23:32,410 --> 00:23:33,630
So, right.

265
00:23:33,630 --> 00:23:42,210
The point is that we can only have constant time lookups if we actually have a good guess of how many things we're going to talk to which we don't.

266
00:23:42,210 --> 00:23:44,110
So obviously we can't do that.

267
00:23:44,790 --> 00:23:50,370
And even though generally we won't fill the table, we don't really know what's going to happen.

268
00:23:51,130 --> 00:23:52,970
So, that's right.

269
00:23:53,150 --> 00:23:54,010
Anyways.

270
00:23:54,930 --> 00:24:08,030
Even if we did have a hash table that was big enough, and this is just obviously for IPv4, it would be quite a bit of RAM, actually, just to store the connection entries, not even the data.

271
00:24:08,030 --> 00:24:10,330
So that's obviously not very realistic.

272
00:24:11,250 --> 00:24:13,410
It's just for the keys.

273
00:24:13,450 --> 00:24:14,130
Anyway.

274
00:24:14,550 --> 00:24:14,910
Yeah.

275
00:24:14,910 --> 00:24:15,610
And, right.

276
00:24:15,610 --> 00:24:32,730
Like I said, the reason why that's important is because as time goes on, we see more and more devices to compensate for high-latency networks that will answer part of the three-way handshake to kind of offload that and keep the connection open for the high-latency device or improve the performance.

277
00:24:32,730 --> 00:24:34,810
Or DDoS protection.

278
00:24:35,430 --> 00:24:41,430
Or some obfuscated thing that people do to try and improve security, which I'm sure that works real well.

279
00:24:41,970 --> 00:24:42,650
Anyway.

280
00:24:44,690 --> 00:24:45,290
Yeah.

281
00:24:45,290 --> 00:24:50,870
So, one of the design goals is we need to be able to withstand this sort of network because we're testing them.

282
00:24:51,510 --> 00:24:52,170
Anyway.

283
00:24:52,850 --> 00:24:53,510
Okay.

284
00:24:53,510 --> 00:24:53,810
Yeah.

285
00:24:53,810 --> 00:24:54,870
And, right.

286
00:24:54,870 --> 00:24:55,750
I already said this.

287
00:24:55,750 --> 00:24:57,450
We use a red-black tree.

288
00:24:57,470 --> 00:25:06,670
One of the possible improvements that we're thinking of doing is actually most of the time that's probably an unnecessary data structure.

289
00:25:06,670 --> 00:25:11,350
We could probably use just a hash table and have constant time.

290
00:25:11,630 --> 00:25:15,170
So, actually, what we want to do is actually switch on the fly.

291
00:25:15,170 --> 00:25:27,550
If we actually pass a threshold and our table load goes too high, we can actually dump it and turn it into a binary tree on the fly and put a most frequently used cache in front of that.

292
00:25:27,550 --> 00:25:29,510
I think it says it in here anyway.

293
00:25:30,350 --> 00:25:35,970
Not most recently used, by the way, because that would be a lot of connections closing.

294
00:25:36,110 --> 00:25:41,410
We actually need the top talkers, so you actually want it frequent, not recent.

295
00:25:41,730 --> 00:25:42,330
Okay.

296
00:25:42,370 --> 00:25:43,310
Anyway.

297
00:25:43,310 --> 00:25:48,410
Here's some numbers about why we chose the algorithms that we did.

298
00:25:48,870 --> 00:25:56,350
And the point was is we're just trying to prove that our measurements are somewhat valid, but we actually inline some assembly in here.

299
00:25:56,350 --> 00:26:01,310
You can see it here where we actually read the timestamp counter on a Pentium CPU.

300
00:26:01,670 --> 00:26:06,050
And then we're actually going to overload our table and see what the performance numbers look like.

301
00:26:06,050 --> 00:26:09,570
And these numbers actually indicate clock ticks.

302
00:26:09,810 --> 00:26:25,130
And you can see here with the various load factors that our chained hash table turns quickly into a bunch of linked lists and our red-black tree does not, which should not be much of a surprise anyways.

303
00:26:25,270 --> 00:26:37,890
But what's interesting about this actually is the amount of load that it took for the CPU to actually get a really expensive lookup, which is mainly due to the, I suppose, large cache on the CPU.

304
00:26:37,890 --> 00:26:39,110
I'm not really sure.

305
00:26:39,330 --> 00:26:45,690
But I figured at least that after a load of maybe four that it would start dropping off.

306
00:26:45,690 --> 00:26:52,030
But it actually took somewhere around 30 for the performance to just go really badly.

307
00:26:53,510 --> 00:26:56,090
So, right, I just actually talked about that before.

308
00:26:56,090 --> 00:26:56,770
Whoops.

309
00:26:57,270 --> 00:27:00,650
Right, but yeah, reset acts obviously we don't want to cache.

310
00:27:00,650 --> 00:27:03,130
And those are always going to be the most recent.

311
00:27:03,130 --> 00:27:06,550
So if we're going to do anything to improve the performance, we can't do that.

312
00:27:06,550 --> 00:27:12,870
We actually have to calculate how often certain connections are being used and cache those instead.

313
00:27:13,330 --> 00:27:14,370
Right.

314
00:27:14,950 --> 00:27:19,250
Okay, so here's some examples from the payload configuration stuff.

315
00:27:19,350 --> 00:27:21,630
It's just ASCII text.

316
00:27:21,990 --> 00:27:27,990
But we tried to make it so that you could copy and paste stuff from like C and put it into the configuration file.

317
00:27:28,230 --> 00:27:31,090
But anyway, here's some example stuff.

318
00:27:31,310 --> 00:27:34,470
Obviously UDP is a UDP payload.

319
00:27:34,710 --> 00:27:38,750
If you don't get that, then I guess this is not going to make any sense.

320
00:27:39,350 --> 00:27:42,770
And then the destination port is actually next.

321
00:27:42,770 --> 00:27:46,950
And then the source port being negative one is just a wild card to say whatever.

322
00:27:47,130 --> 00:27:48,790
And then one is interesting.

323
00:27:48,790 --> 00:27:49,890
That's a payload group.

324
00:27:49,890 --> 00:27:55,090
One of the things that you can do is you can chain include files together or configuration files together.

325
00:27:55,190 --> 00:27:59,810
So you can actually have a bunch of different things that are meant for different sorts of environments.

326
00:28:00,150 --> 00:28:07,870
Like, for example, if you want to scan for like Windows Trojans, which are pretty popular, you probably want to put them in their own payload group.

327
00:28:07,870 --> 00:28:12,690
And then you can just use the minus big G and then the numeric option for that payload group.

328
00:28:12,690 --> 00:28:15,550
To kind of make that a little bit easier to do.

329
00:28:16,130 --> 00:28:20,670
And actually, we have now TCP payloads, which we didn't have before.

330
00:28:20,970 --> 00:28:23,470
And it's not still a real socket.

331
00:28:23,530 --> 00:28:27,910
It's kind of a trigger response mechanism, but we try and do some TCP stuff.

332
00:28:27,930 --> 00:28:33,930
But it turns out it's real hard because we actually emulate the operating system we're appearing to come from.

333
00:28:33,930 --> 00:28:36,790
So our stack code is non-trivial, unfortunately.

334
00:28:37,510 --> 00:28:43,610
But for right now, you can definitely do this sort of thing and test for, for example, open relays.

335
00:28:44,290 --> 00:28:46,130
Anyway, and here's some screenshots.

336
00:28:46,130 --> 00:28:48,210
Can you guys even see what that says?

337
00:28:48,390 --> 00:28:49,470
No.

338
00:28:49,470 --> 00:28:50,930
I'm going to explain it.

339
00:28:50,930 --> 00:28:58,070
This is a module written in C that's actually an HTTP module.

340
00:28:58,190 --> 00:29:00,030
And it just does a head request.

341
00:29:00,310 --> 00:29:04,650
And it's probably like, I don't know, 47 lines, apparently.

342
00:29:05,210 --> 00:29:08,550
But that's what it looks like.

343
00:29:08,550 --> 00:29:13,150
Okay, this is actually running a, I don't know, was this?

344
00:29:13,150 --> 00:29:19,610
Yeah, this was actually a cluster that was Connect scanning against Yahoo.com on port 80.

345
00:29:20,990 --> 00:29:27,430
And you can see that at the end here, it's got some TCP statistics, which are interesting.

346
00:29:27,430 --> 00:29:30,290
But for each host, you can actually see a banner.

347
00:29:30,330 --> 00:29:33,090
Now, that's probably not terribly exciting.

348
00:29:33,550 --> 00:29:39,930
Here's probably some better contrast for you, so you can understand why we did some of the things that we did.

349
00:29:40,010 --> 00:29:44,330
This is actually a screenshot of Nmap scanning a website.

350
00:29:45,090 --> 00:29:48,630
And it actually comes back and just says that those things are open.

351
00:29:49,190 --> 00:29:52,670
And it took eight seconds or something, too.

352
00:29:52,790 --> 00:29:58,450
But we can actually do the same thing and finish it in four seconds.

353
00:29:58,870 --> 00:30:00,730
Well, I guess this really isn't race.

354
00:30:00,730 --> 00:30:09,110
But the idea is, if you see here, you can see, like, five open ports coming back, which is identical to what we saw before.

355
00:30:09,130 --> 00:30:17,170
But during the actual SYN scan, we actually did the connection and grabbed the banner without actually initiating another connection.

356
00:30:17,190 --> 00:30:22,870
And we actually can tell what port really is open at high rates.

357
00:30:23,590 --> 00:30:24,710
Okay.

358
00:30:25,270 --> 00:30:26,670
Here we go.

359
00:30:26,670 --> 00:30:28,290
I can do these live, actually.

360
00:30:28,290 --> 00:30:29,090
We have internet.

361
00:30:29,090 --> 00:30:29,710
Okay.

362
00:30:29,710 --> 00:30:31,530
Would you rather see live demos?

363
00:30:31,530 --> 00:30:33,370
Because these things are kind of hard to read.

364
00:30:33,410 --> 00:30:33,750
Yeah.

365
00:30:33,750 --> 00:30:34,070
Okay.

366
00:30:34,070 --> 00:30:35,530
Let's do some live stuff.

367
00:30:35,530 --> 00:30:36,250
Hang on.

368
00:30:44,540 --> 00:30:46,300
Assuming my connection isn't dead.

369
00:30:46,300 --> 00:30:46,660
All right.

370
00:30:46,660 --> 00:30:47,380
Cool.

371
00:30:51,260 --> 00:30:57,560
So what you see here at this first screen, locus-casio-3, that's our master thread.

372
00:30:58,540 --> 00:31:01,940
4 is our... what is that?

373
00:31:01,940 --> 00:31:03,980
That's the listener.

374
00:31:03,980 --> 00:31:07,620
It's listening on the IP address that we're going to be sending from.

375
00:31:07,620 --> 00:31:08,940
This one's number 5.

376
00:31:08,940 --> 00:31:10,820
This is actually the sender.

377
00:31:10,820 --> 00:31:12,380
So just so you can see what that is.

378
00:31:12,380 --> 00:31:14,400
And I'm just making sure that they're live and well.

379
00:31:14,400 --> 00:31:15,720
And they appear to be.

380
00:31:15,880 --> 00:31:18,680
So the first demo here.

381
00:31:18,680 --> 00:31:21,700
Let me look inside this file real quick.

382
00:31:23,280 --> 00:31:27,020
Well, unfortunately, no.

383
00:31:29,040 --> 00:31:30,000
Maybe.

384
00:31:30,000 --> 00:31:30,640
Yeah.

385
00:31:30,720 --> 00:31:32,980
We'll try, but all bets are off.

386
00:31:32,980 --> 00:31:35,020
If everything breaks, it's your fault.

387
00:31:51,480 --> 00:31:53,060
It's real big.

388
00:31:57,230 --> 00:31:57,950
Okay.

389
00:32:01,560 --> 00:32:03,200
I assume that's better.

390
00:32:04,900 --> 00:32:06,440
You have to forgive me.

391
00:32:06,440 --> 00:32:09,720
We're pretty hard on our laptops, and some of our keys are missing.

392
00:32:16,200 --> 00:32:16,780
Okay.

393
00:32:16,780 --> 00:32:21,140
So this first one, I just wanted to show you inside it so you knew I wasn't really cheating.

394
00:32:21,140 --> 00:32:23,860
It's just a stupid shell script that runs my command for me.

395
00:32:23,960 --> 00:32:29,100
Minus E, PGSQLDB just says for the output module, go ahead and dump everything to a database.

396
00:32:29,120 --> 00:32:33,340
I'm specifying the source IP to come from, although in cluster mode, you don't really need to do that.

397
00:32:33,340 --> 00:32:35,320
Minus V means a little bit more verbose.

398
00:32:35,420 --> 00:32:45,840
W6 means emulate the Linux TCP IP stack properties, mostly because that's the one that we've spent the most time with to make sure that the connect mode stuff is reliable.

399
00:32:46,000 --> 00:32:48,860
The minus Z is where we specify our drones.

400
00:32:48,860 --> 00:32:52,120
Right now, the IPC channel is not protected.

401
00:32:52,120 --> 00:33:02,100
Normally, if you're in a sensitive environment or an environment that has any type of malice, you would want to protect that over an encrypted channel of some sort.

402
00:33:02,240 --> 00:33:05,040
I would have to recommend IPSec for that.

403
00:33:05,680 --> 00:33:06,960
I've actually tested that.

404
00:33:06,960 --> 00:33:08,080
It works pretty well.

405
00:33:08,080 --> 00:33:13,260
Minus big L5 is how long to wait after the batch sending is done.

406
00:33:13,260 --> 00:33:18,920
Minus little r 9,000 means we're going to send around 9,000 packets per second.

407
00:33:18,920 --> 00:33:24,780
We actually go a little bit lower than whatever you specify, but it won't exceed 9,000 packets per second.

408
00:33:24,780 --> 00:33:34,320
The 66.0.0.0.16 just means go to that CIDR block and do 161 for the port, the disk port.

409
00:33:34,320 --> 00:33:41,160
Minus MU is UDP mode, and then minus big I is for impatient people like me so you can see the data right away.

410
00:33:41,160 --> 00:33:42,020
Right.

411
00:33:48,330 --> 00:33:57,250
Which, of course, you don't actually want to use minus big I when you're doing a scan that matters because it's going to block on the master thread to write to the terminal, which is fairly silly.

412
00:33:57,870 --> 00:34:01,550
And it's not doing what I want, so I'm confused.

413
00:34:06,110 --> 00:34:07,830
It's the font, man.

414
00:34:32,860 --> 00:34:33,780
There you go.

415
00:34:33,780 --> 00:34:34,340
Okay.

416
00:34:34,340 --> 00:34:40,920
So now these are some SNMP public community string version 1 machines that are responding.

417
00:34:40,920 --> 00:34:52,880
As you see, we're doing a slash 16 network, and we're done sending, and we're just waiting the five-second timeout, and then it's going to process the results, and it'll spit it back here pretty soon.

418
00:34:53,080 --> 00:35:03,260
We're actually, I think, repeating the scan three times, so if you're wondering why it's just sitting there now, it's actually sending different SNMP payloads to try and get everyone.

419
00:35:11,560 --> 00:35:12,380
XOR.

420
00:35:12,500 --> 00:35:14,540
It's pretty ugly, actually.

421
00:35:14,720 --> 00:35:26,220
We're actually trying to figure out a better algorithm that'll favor randomizing the more significant bits first, but I actually haven't had time to get around to that, so it just kind of XORs a random word.

422
00:35:26,220 --> 00:35:38,540
So that was a slash 16 for SNMP with multiple payloads, but those are absolutely open because we sent a public community string request, and it sent us back responses.

423
00:35:38,540 --> 00:35:56,140
The TTL is wrapping over, thanks to our insane font size, but if it wasn't, you would be able to see the time-to-load value of the packet that's coming back to you, and so you can quickly, as you're looking through it, you can spot Windows Novell stacks versus Unix stacks versus routing infrastructure.

424
00:35:56,180 --> 00:36:03,560
But all of that went back to a database that we may be able to show you, but I don't want to run out of time because we have some really cool fireworks at the end.

425
00:36:09,100 --> 00:36:12,340
Some more demo 2.

426
00:36:12,360 --> 00:36:13,740
This one is SMTP.

427
00:36:13,740 --> 00:36:23,560
This one's actually going to look for open relay servers in the same block, and now we're actually doing three-way handshakes with all those guys.

428
00:36:23,600 --> 00:36:25,720
So this is TCP port 25.

429
00:36:25,720 --> 00:36:33,420
We are absolutely connecting to them on port 25 and sending enough of a payload to elicit...

430
00:36:33,420 --> 00:36:47,960
Well, basically what I did is I said, I'm coming from an email address that I control, sending to another email address that I control, and that way I can get bounces back telling me that I was a bad person, or I can actually get the email that I sent.

431
00:36:48,080 --> 00:36:53,680
But then, either way, I still get the banner of all the systems that we just talked to.

432
00:36:54,040 --> 00:37:01,180
So if nothing else, I now have version information in my database that I can search through and say, show me all the send mailboxes.

433
00:37:01,220 --> 00:37:09,560
One thing that's important, too, is that he had the immediate mode on, but he was doing TCP connections, so all the immediate things that needed to happen right away got stalled.

434
00:37:09,720 --> 00:37:12,780
So some of the TCP connections will actually kind of fail.

435
00:37:12,780 --> 00:37:16,880
It makes for a better demo, but you wouldn't do that in production, obviously.

436
00:37:17,380 --> 00:37:19,940
Okay, so this next one is an HTTP GET request.

437
00:37:19,940 --> 00:37:29,800
Again, we're going to connect to TCP port 80 and just hit all the people that are listening on port 80 and we'll do a GET request against them.

438
00:37:31,680 --> 00:37:32,640
Yeah.

439
00:37:43,880 --> 00:37:48,100
Okay, so that was a pretty simple GET request here.

440
00:37:48,420 --> 00:37:50,600
That was a really small range.

441
00:37:50,600 --> 00:37:51,840
Let's look at that.

442
00:37:51,880 --> 00:37:52,980
That's just a slash 30.

443
00:37:52,980 --> 00:37:54,960
That's Yahoo with a slash 30.

444
00:37:55,220 --> 00:37:56,880
So, piece of cake, right?

445
00:37:57,120 --> 00:38:01,180
Okay, let's see what else we have here.

446
00:38:01,880 --> 00:38:04,700
Oh, I wanted to show you what was in the slide.

447
00:38:05,640 --> 00:38:06,440
Sorry.

448
00:38:06,440 --> 00:38:13,560
This is Nmap with port 70 through 82 against dietsecurity.com.

449
00:38:13,560 --> 00:38:20,920
All ports come back open, which is what we expect because we have a stupid device in the middle that protects us from DDoS.

450
00:38:22,520 --> 00:38:30,540
But here's with the unicorn scan where we can actually enumerate what the protocol behind the three-way handshake looks like.

451
00:38:30,540 --> 00:38:40,680
So you see here that even though the other ones came back as open, in your database you can do a pretty simple select statement to throw away the garbage properties.

452
00:38:40,840 --> 00:38:56,580
And sometimes you'll even get better information about the stack properties itself because once you get sent to the right application behind it, there's going to be telltale signs that you're talking to a different device than the one that actually completed the three-way handshake for you.

453
00:38:56,920 --> 00:38:59,600
But, yeah, it's pretty easy at this point where you can actually...

454
00:39:00,060 --> 00:39:02,600
It's kind of like the UDP situation all over again.

455
00:39:02,600 --> 00:39:09,180
You know, in the UDP, again, now we're sending real protocol payloads as opposed to just counting on ICP messages.

456
00:39:09,200 --> 00:39:16,840
But now in TCP land, we're actually sending real protocol information so we can get away from these devices that just SYNAC everything.

457
00:39:24,310 --> 00:39:28,830
This is just showing that we can do multiple payloads all on one.

458
00:39:28,830 --> 00:39:33,150
So this one's sending like 50 or so different payloads.

459
00:39:33,150 --> 00:39:36,630
We've got some DNS servers, we've got some SNMP servers.

460
00:39:36,910 --> 00:39:39,030
Port 2367, don't know what that is.

461
00:39:39,490 --> 00:39:42,130
137, yeah, all these are coming back to us now.

462
00:39:42,430 --> 00:39:49,090
And I guess this is just showing off, you know, what it looks like to do multiple payloads.

463
00:39:49,090 --> 00:39:51,290
So that was the easy stuff.

464
00:39:51,450 --> 00:39:53,310
Now comes the tricky part.

465
00:39:53,690 --> 00:39:54,690
Hang on.

466
00:40:07,830 --> 00:40:14,230
Okay, so I'm going to talk about what we're going to do now and hopefully it won't break because I was still writing code for it last night.

467
00:40:15,550 --> 00:40:22,250
Anyway, what we do is we do basically a TCP connect scan on port 80.

468
00:40:22,330 --> 00:40:26,010
And there's actually a CGI script that has a really dumb coding error in it.

469
00:40:26,290 --> 00:40:31,490
We actually had some other stuff that we were going to do but the political climate kind of got ugly.

470
00:40:31,490 --> 00:40:36,230
Yeah, we were going to release some fun stuff but unfortunately nobody wants to hear that sort of thing these days.

471
00:40:36,610 --> 00:40:40,430
So we actually just reused some other stuff we had.

472
00:40:40,710 --> 00:40:49,130
But basically it does a three-way handshake and it actually generates the XOR encoder on the fly, which is metamorphic.

473
00:40:49,650 --> 00:40:52,790
And it actually does a two-stage exploit.

474
00:40:52,790 --> 00:40:59,510
One of the problems that I had, though, was that I didn't have enough time to write the two-stage NetBSD assembly.

475
00:40:59,510 --> 00:41:04,410
So I cheated and used someone else's stuff and it doesn't work.

476
00:41:04,410 --> 00:41:06,730
So that just goes to show me...

477
00:41:07,330 --> 00:41:08,450
Okay, so right.

478
00:41:08,450 --> 00:41:11,850
We generate a metamorphic first stage and we send the payload.

479
00:41:12,550 --> 00:41:22,190
What we're supposed to want to do here is Apache hands all the CGI scripts, a writable file descriptor on two bits, the error logs.

480
00:41:22,190 --> 00:41:25,450
So the first thing that we do in our shellcode is we truncate that.

481
00:41:25,730 --> 00:41:34,510
We create a socket and connect back to a second stage server and we send it some information about the platform that we've just...

482
00:41:34,510 --> 00:41:36,930
or the process that we've just compromised.

483
00:41:37,210 --> 00:41:44,930
And we actually just send back a 32-bit word saying what predefined constant that was.

484
00:41:44,930 --> 00:41:45,530
So...

485
00:41:45,530 --> 00:41:59,010
And then the shellcode server sends back the length of the payload that we're going to send in the second stage and it does memmap and opens up an anonymous memory region at a fixed address.

486
00:41:59,010 --> 00:42:07,470
And it loads a hacked binary into that area and jumps to the beginning of the file, which then...

487
00:42:07,470 --> 00:42:15,850
And I mentioned that the ELF is hacked because we actually overwrote the first part of the ELF header with some assembly to jump to the entry point.

488
00:42:16,770 --> 00:42:20,510
But the important point is that the second stage is written in C.

489
00:42:20,510 --> 00:42:23,350
It's similar to the impurity stuff, actually.

490
00:42:24,110 --> 00:42:24,830
Anyway.

491
00:42:24,970 --> 00:42:29,870
And then we transfer control to the second stage code by jumping to the ELF entry point.

492
00:42:31,310 --> 00:42:32,010
Yeah.

493
00:42:32,010 --> 00:42:32,630
Oh, right.

494
00:42:32,630 --> 00:42:35,090
So this is the part where I do it and it doesn't break.

495
00:42:46,060 --> 00:42:46,720
Okay.

496
00:42:46,720 --> 00:42:48,780
This is the NetBSD box.

497
00:42:49,420 --> 00:42:50,040
Okay.

498
00:42:50,040 --> 00:42:52,720
As you can see, this shellcode doesn't work.

499
00:42:52,760 --> 00:42:56,740
So the only thing we can do is just look at port 4444.

500
00:43:00,300 --> 00:43:02,420
This is the second stage server.

501
00:43:05,220 --> 00:43:08,220
And then we actually have two of these clients.

502
00:43:08,220 --> 00:43:12,000
One of them actually uses ncurses, so it opens up new windows every time you get a shell.

503
00:43:12,000 --> 00:43:12,980
It's kind of neat.

504
00:43:12,980 --> 00:43:15,260
But we're having some terminal issues.

505
00:43:15,380 --> 00:43:17,060
And we can't figure out ncurses.

506
00:43:17,060 --> 00:43:18,080
It's kind of above us.

507
00:43:18,080 --> 00:43:19,500
So we don't have that yet.

508
00:43:40,460 --> 00:43:44,360
What he's going to show you is the TCP dump, so you can see that it really is working.

509
00:43:44,680 --> 00:43:47,480
And we're being told to hurry up, so you've got like five seconds.

510
00:43:47,480 --> 00:43:48,580
Okay, so here it goes.

511
00:43:48,580 --> 00:43:49,620
Hopefully it won't crash.

512
00:43:49,800 --> 00:43:54,700
Okay, so we first have to grab an IP address that's not attached to the kernel.

513
00:43:54,700 --> 00:43:56,460
As you can see, some stuff went by here.

514
00:43:56,460 --> 00:43:57,600
So it connected to port 80.

515
00:43:57,600 --> 00:43:59,680
It sent our payload.

516
00:43:59,700 --> 00:44:00,740
And now we have a shell.

517
00:44:00,740 --> 00:44:05,260
Yeah, so you can see here that the second stage shellcode server got it connected back.

518
00:44:05,260 --> 00:44:07,120
It sent back the word that said it was...

519
00:44:07,120 --> 00:44:09,520
This particular one was Linux x86.

520
00:44:09,520 --> 00:44:13,280
The important part about that demo, though, is that after it got the...

521
00:44:13,280 --> 00:44:15,060
It connected to two different hosts.

522
00:44:15,060 --> 00:44:22,400
And after it got the SYNAC back, it did operating system detection, and it sent a platform-specific exploit to it on the fly.

523
00:44:22,400 --> 00:44:25,900
It knew how to generate a platform-specific exploit on the fly.

524
00:44:25,920 --> 00:44:27,060
So that was actually pretty cool.

525
00:44:27,060 --> 00:44:29,700
Unfortunately, we don't have time to explain in more detail.

526
00:44:29,700 --> 00:44:32,060
But if you're interested, come find us.

527
00:44:32,060 --> 00:44:32,660
Yeah.

528
00:44:32,760 --> 00:44:37,780
And you can actually watch DVDs in ASCII, which was the entire point of doing that.