WEBVTT 00:04.920 --> 00:10.120 And it turns out that when you're doing spell check, it would really help if you check all the files. 00:10.120 --> 00:12.580 So sorry about the introducing thing. 00:12.580 --> 00:13.380 Oh well. 00:15.400 --> 00:18.080 Okay, so we're going to talk about a lot of stuff. 00:18.080 --> 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. 00:27.400 --> 00:29.120 So that's what the scatter connect is all about. 00:29.120 --> 00:30.900 And you'll see that in detail. 00:30.900 --> 00:32.960 In fact, that's the first thing that we're going to hit off. 00:33.020 --> 00:36.700 Then we're going to talk a little bit about the tool that we're releasing today. 00:36.960 --> 00:45.600 We actually have released it previously, but this new version has somewhere around 25,000 lines of code change. 00:45.600 --> 00:47.420 So it's definitely different. 00:47.420 --> 00:51.780 And then we're going to demonstrate some of what it can do. 00:52.160 --> 00:54.020 So, I'm Robert Lee. 00:54.020 --> 00:57.120 I do stuff with a couple companies. 00:57.120 --> 01:00.960 And this is Jack, and we also have Anthony here in the audience. 01:00.960 --> 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. 01:07.240 --> 01:09.240 Okay, so nice and simple. 01:09.560 --> 01:12.400 You've all seen a TCP three-way handshake before. 01:12.400 --> 01:13.440 The concept is simple. 01:13.440 --> 01:15.740 You're trying to initiate a connection. 01:15.740 --> 01:16.800 You send a SYN packet. 01:16.800 --> 01:18.780 You expect a SYN ACK if it's open. 01:18.780 --> 01:22.200 You acknowledge it, and then your connection is open. 01:22.200 --> 01:25.600 It's actually two one-way connections, but whatever. 01:27.880 --> 01:32.780 I'm not sure if you can see this, but I'll visually walk you through what's happening here. 01:32.840 --> 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. 01:40.740 --> 01:47.620 In this particular example, we are doing a TCP port 80 full connection with a remote host. 01:47.620 --> 01:50.720 That's the one on the far right with the little globe thing. 01:50.720 --> 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. 02:00.900 --> 02:08.160 And then the sender will actually create a packet, spoofing its source IP address to come from the receiver. 02:08.340 --> 02:12.360 If you can see it, the receiver machine is the one on the far bottom. 02:12.680 --> 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. 02:23.760 --> 02:25.900 So that's how the receiver receives it. 02:25.980 --> 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. 02:37.920 --> 02:39.440 So that's the one in the middle. 02:39.500 --> 02:45.600 So the acknowledgment is then sent back to 192.168.1.1, and the three-way handshake is complete. 02:45.600 --> 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? 02:50.440 --> 02:51.880 And I'm glad you asked that question. 02:51.880 --> 02:53.400 We'll answer that later. 02:53.400 --> 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. 03:03.600 --> 03:09.320 And we've made it so that you can have a three-way handshake amongst a cluster of machines. 03:09.320 --> 03:16.160 But to the end machine on the right-hand side, it's all a normal connection to him. 03:16.900 --> 03:23.980 Once his handshake is complete, we can also then send arbitrary payload-specific stuff. 03:23.980 --> 03:29.820 So if you wanted to do a GET request or any arbitrary payload can be sent at that point. 03:30.000 --> 03:31.920 Important stuff. 03:32.540 --> 03:39.540 Okay, so I just explained all this, but I'll go through it one more time just for clarity. 03:39.960 --> 03:44.040 The first process, again, is the unicorn scan main thread. 03:44.080 --> 03:47.300 Second process is the sender that's Unisend. 03:47.300 --> 03:49.540 That's the one that actually assembles the packets. 03:50.820 --> 03:54.480 Again, we have the concept of batch sender and immediate sender. 03:54.480 --> 03:58.980 The batch sender, it turns out, is the one that you give large work units to. 03:58.980 --> 04:04.760 So you can say, I want to scan this slash 16 network, and I'm looking to do these ports. 04:04.760 --> 04:07.440 And you tell it what speed to do it, et cetera, et cetera. 04:07.440 --> 04:10.160 So it just goes out and sends a bazillion send packets. 04:10.760 --> 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. 04:22.380 --> 04:26.100 And then the immediate mode is the one that completes the three-way handshake. 04:27.020 --> 04:29.300 They're not actually threads, by the way. 04:29.300 --> 04:30.460 They're actually processes. 04:30.460 --> 04:31.900 We just call them threads. 04:32.040 --> 04:33.640 Because we're silly like that. 04:35.480 --> 04:36.700 Okay, cool. 04:36.700 --> 04:38.340 I've talked about all this. 04:38.520 --> 04:40.580 Is that part clear at all? 04:40.900 --> 04:41.560 All right, cool. 04:41.560 --> 04:42.660 We did it twice. 04:42.880 --> 04:47.340 Now I'm going to talk about some problems that we were banging our heads against. 04:47.340 --> 04:51.660 By the way, all we do with the companies is we do a lot of security testing. 04:51.660 --> 04:53.000 Really big networks. 04:54.500 --> 04:59.400 We've been eating a lot of dirt with tools that didn't do what we needed to do. 04:59.400 --> 05:01.440 So that's basically why we did this. 05:01.440 --> 05:06.420 But one of the first problems that we ran into is the whole UDP thing. 05:06.740 --> 05:14.160 Just to summarize, when you're doing UDP scanning, traditionally you're sending a UDP probe with a blank datagram. 05:14.160 --> 05:18.940 And you're hoping that the machine on the other side will send you an ICMP packet. 05:18.940 --> 05:21.800 So if the ports close, you'll know. 05:21.800 --> 05:26.720 And you basically, the ones that you don't get the message back from, you assume that it's open. 05:26.780 --> 05:30.440 The problem is it turns out people are actually using firewalls. 05:30.440 --> 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. 05:39.140 --> 05:40.000 That's one of the problems. 05:40.000 --> 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. 05:47.060 --> 05:50.280 So it's a really slow and ugly process. 05:50.800 --> 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. 06:05.460 --> 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. 06:16.780 --> 06:18.220 But we'll come back to that. 06:19.180 --> 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. 06:31.660 --> 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. 06:45.380 --> 06:50.400 And then on the open ports, you can go back and actually do a banner grab. 06:50.460 --> 06:54.380 And then as a third step, you can start interacting with the remote service. 06:54.380 --> 06:57.820 You can use AMAP or manual testing or whatever. 06:58.460 --> 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. 07:06.940 --> 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. 07:13.500 --> 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. 07:21.740 --> 07:27.420 And even if you were, playing with set and knock with the text output is really overwhelming. 07:28.960 --> 07:30.640 Really overwhelming. 07:31.880 --> 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. 07:46.100 --> 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. 07:59.680 --> 08:01.640 Who the hell runs Amiga Miami OS? 08:01.640 --> 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. 08:09.680 --> 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. 08:24.020 --> 08:29.400 So then you come back and find out that Apache DOS vulnerability was successful. 08:29.500 --> 08:30.640 So that's fine. 08:30.640 --> 08:35.000 If you're testing one machine, you can go through the false positives and figure out what's really going on. 08:35.000 --> 08:37.600 But imagine doing this times 4 billion machines. 08:37.600 --> 08:39.160 Not really useful. 08:39.440 --> 08:44.680 So to be useful in the future, these modules are going to need to share the information more intelligently. 08:45.960 --> 08:49.060 Some more problems that we're having is with the timing. 08:49.740 --> 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. 09:00.040 --> 09:03.660 And I'll give you the two examples in the open source space. 09:03.660 --> 09:08.160 We have the scanran tool that provided a minus B option for bandwidth. 09:08.400 --> 09:13.040 But I probably just haven't played with it enough. 09:13.040 --> 09:19.160 But in my experience, anything over like 5K to 10K, I was noticing a lot of packet loss. 09:19.160 --> 09:21.200 And it also became bursty. 09:21.660 --> 09:23.880 And so it didn't really work out. 09:23.880 --> 09:30.480 Mostly because of the way that the sleep timer was working and the get time of day counter was working. 09:30.540 --> 09:33.900 And then with nmap, you have normal, aggressive, insane or things like that. 09:33.900 --> 09:37.340 But even in insane mode, it doesn't scale to high speeds. 09:37.420 --> 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. 09:44.780 --> 09:50.720 But the timing of how fast you can go is still greatly affected by the machines that you're probing. 09:50.720 --> 09:58.760 To nmap's credit, we actually got nmap to send out more packets per second than we did scanran. 10:01.360 --> 10:03.720 Oh, just some raw numbers real quick. 10:04.440 --> 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. 10:14.440 --> 10:21.580 And we're working with some FPGA people to get that in the 500,000 to million packet per second range. 10:21.760 --> 10:23.160 But we're still working on that. 10:23.160 --> 10:25.240 That's pie in the sky at this point. 10:26.060 --> 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. 10:34.120 --> 10:39.020 But you're still going to want to break it up into different processes and I'll show you why. 10:39.640 --> 10:40.860 Some more mindset. 10:40.860 --> 10:42.580 Okay, so now we've told you about some problems. 10:42.580 --> 10:44.500 What are we going to do to solve these problems? 10:44.560 --> 10:49.240 Well, from the get-go, we were designing this with scalability in mind. 10:49.480 --> 10:53.480 I talked about efficient use of resources and I'm going to give you a bus analogy. 10:54.160 --> 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. 11:04.360 --> 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. 11:15.340 --> 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. 11:21.400 --> 11:23.340 Let me break it down technically now. 11:23.760 --> 11:29.960 When you use an individual machine, there's only so fast that you can reliably send and receive packets. 11:29.960 --> 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. 11:37.460 --> 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. 11:48.700 --> 11:52.820 So that's not going to be an efficient use of even a single machine. 11:52.840 --> 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. 12:06.100 --> 12:08.460 So it's not the same as just going faster. 12:08.460 --> 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. 12:18.500 --> 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. 12:33.740 --> 12:38.900 By the way, funny, if any Juniper people are listening, I don't get that. 12:38.900 --> 12:44.120 Protection that completely doshes your CPU is... well, I don't understand that at all. 12:44.120 --> 12:45.900 Anyhow, moving on. 12:46.900 --> 12:48.280 Okay, accuracy. 12:48.760 --> 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. 12:55.820 --> 13:00.820 This is my problem with those log aggregation systems where you have the garbage in, garbage out model. 13:00.820 --> 13:03.340 If you can't trust the information, it's kind of worthless. 13:03.340 --> 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. 13:10.460 --> 13:15.840 Basically, I think tools should introduce stimulus and record response and let the humans analyze. 13:15.860 --> 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. 13:24.540 --> 13:25.380 Flexibility. 13:25.720 --> 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. 13:40.780 --> 13:46.940 And then, depending on which contracts happen, we're also going to support a lot of other protocols. 13:47.300 --> 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. 13:54.240 --> 13:55.520 And then security. 13:55.620 --> 13:58.520 It should go with that same, but it doesn't really. 13:58.520 --> 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. 14:12.000 --> 14:17.340 And we also provide a sample security policy for use with SELinux. 14:17.740 --> 14:23.000 And yeah, that was at least in the design phase when we considered that. 14:23.000 --> 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. 14:31.480 --> 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. 14:41.550 --> 14:42.510 Cool. 14:44.830 --> 14:47.830 All right, yeah, so what does it do? 14:47.830 --> 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. 14:54.410 --> 14:57.550 But currently, it can do TCP and UDP port scanning. 14:57.550 --> 15:01.810 It can do stateless banner grabbing or active remote OS application, blah, blah, blah. 15:01.810 --> 15:03.030 It can do stuff. 15:03.030 --> 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. 15:15.250 --> 15:17.550 So let's say that you're trying to find DNS servers. 15:17.550 --> 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. 15:26.270 --> 15:28.950 One of them can ask it for local host. 15:28.950 --> 15:31.030 One of them can do a chaos. 15:32.950 --> 15:35.670 If you're talking to a bind server, you're trying to find out what version it is. 15:36.190 --> 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. 15:44.210 --> 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. 15:51.190 --> 15:54.810 So it can stuff the IP that it's talking to in there on the fly. 15:54.810 --> 15:59.750 But any other thing that you need to calculate right before creating the packet, that also works. 16:00.710 --> 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. 16:11.370 --> 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. 16:17.670 --> 16:22.890 And you need to be able to send protocol-specific payloads so you can figure out which ones are tricking you. 16:23.490 --> 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. 16:37.910 --> 16:43.270 So not only is the NOPS-led metamorphic, but the encoder itself is as well. 16:43.610 --> 16:48.050 And so basically there's nothing to write a signature for at this point. 16:48.050 --> 16:50.370 We'll see. 16:50.570 --> 16:53.530 Okay, and then we also can log to PCAP files. 16:53.530 --> 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. 17:07.670 --> 17:10.110 Okay, so now I'm going to pass the mic over to Jack. 17:11.270 --> 17:12.990 Alright, how are we doing everyone? 17:12.990 --> 17:14.810 Are we falling asleep yet? 17:15.890 --> 17:18.470 Alright, I guess not. 17:18.610 --> 17:20.870 Okay, well, there's three processes. 17:20.870 --> 17:23.750 I guess it's pretty obvious what they do. 17:23.750 --> 17:25.070 I'm not really going to talk about them. 17:25.070 --> 17:28.490 Hopefully we're going to actually leave some time for some demos that we want to do. 17:29.510 --> 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. 17:41.010 --> 17:45.830 So in other words, if we used MD5 and then lopped off part of it, it wouldn't be one way. 17:45.830 --> 17:49.350 So we can't do that because we actually need to do TCP connections. 17:49.670 --> 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. 17:58.930 --> 18:03.470 So we actually have to do that with a trivial algorithm. 18:03.750 --> 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. 18:19.390 --> 18:22.390 Well, this is actually kind of long and drawn out. 18:22.390 --> 18:24.230 What do I have, like 20 minutes left? 18:25.710 --> 18:26.570 Half hour? 18:26.570 --> 18:27.190 Okay. 18:27.190 --> 18:28.650 Well, I'll go through this. 18:28.650 --> 18:34.970 It's actually 30 steps to a symbol SYN scan. 18:34.970 --> 18:40.430 So basically, obviously the user would invoke the scanner from the command line. 18:40.530 --> 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. 18:50.650 --> 18:54.970 But if you get sick of typing certain options over and over, you just put them in there. 18:55.190 --> 19:02.650 Anyways, the master process actually opens up binary modules through whatever facilities on the system. 19:02.650 --> 19:07.250 We use the LTDL interface now, so it's a bit more portable. 19:07.250 --> 19:10.990 And we actually have auto-conf too, which is pretty ugly. 19:11.230 --> 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. 19:19.390 --> 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. 19:28.330 --> 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. 19:39.230 --> 19:47.110 And then it actually uses signals to synchronize, which I believe is actually causing us problems portability-wise. 19:47.110 --> 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. 19:56.190 --> 19:59.090 So we might actually have to change that a bit. 19:59.090 --> 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. 20:09.210 --> 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. 20:16.370 --> 20:17.990 So we actually... 20:17.990 --> 20:19.470 That's an important piece right there. 20:19.470 --> 20:22.890 You don't have to have 16 machines to port scan one machine. 20:22.890 --> 20:24.610 You can do it all from one machine. 20:24.690 --> 20:26.790 You can't scale if you need to. 20:26.790 --> 20:27.570 Okay. 20:28.450 --> 20:32.850 Anyways, they connect up and send some information. 20:32.850 --> 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. 20:39.870 --> 20:43.790 So actually during that handshake it sends the information back. 20:44.150 --> 20:45.050 Anyways. 20:45.150 --> 20:48.050 And then everyone syncs up with a ready message. 20:48.390 --> 20:55.170 And then the master actually does something called stirring, which actually would be doing the work unit allocation. 20:55.170 --> 20:58.910 And we actually have some stuff to do that, but it's kind of specific to us. 20:58.910 --> 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. 21:18.230 --> 21:18.730 Okay. 21:18.850 --> 21:19.730 Anyways. 21:19.810 --> 21:20.630 Right. 21:20.630 --> 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. 21:29.030 --> 21:35.530 So hopefully, or if it's a batch sender anyways, we don't want to interrupt him. 21:35.530 --> 21:41.790 We don't want him to have to pull the IPC channel, because it slows him down. 21:42.310 --> 21:42.690 Okay. 21:42.690 --> 21:45.030 And then the master just goes into a loop. 21:45.850 --> 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. 21:53.650 --> 21:56.570 And if not, it just goes into a timeout state. 21:56.570 --> 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. 22:10.070 --> 22:14.610 And then actually the master tells the sender and listener to quit, and then the scan's done. 22:15.690 --> 22:16.310 Right. 22:16.310 --> 22:16.650 Okay. 22:16.650 --> 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. 22:28.770 --> 22:30.590 So we actually don't have that model. 22:30.590 --> 22:32.330 It's completely incompatible. 22:32.550 --> 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. 22:45.830 --> 22:46.530 Anyways. 22:47.410 --> 22:48.290 Right. 22:48.530 --> 22:49.030 Okay. 22:49.030 --> 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. 22:56.930 --> 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, 23:14.010 --> 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. 23:20.870 --> 23:23.110 So that's obviously not what we want. 23:23.110 --> 23:30.370 We actually have to pick a data structure that responds better to unpredictable things like that, like a binary tree. 23:30.850 --> 23:31.590 Anyways. 23:32.410 --> 23:33.630 So, right. 23:33.630 --> 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. 23:42.210 --> 23:44.110 So obviously we can't do that. 23:44.790 --> 23:50.370 And even though generally we won't fill the table, we don't really know what's going to happen. 23:51.130 --> 23:52.970 So, that's right. 23:53.150 --> 23:54.010 Anyways. 23:54.930 --> 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. 24:08.030 --> 24:10.330 So that's obviously not very realistic. 24:11.250 --> 24:13.410 It's just for the keys. 24:13.450 --> 24:14.130 Anyway. 24:14.550 --> 24:14.910 Yeah. 24:14.910 --> 24:15.610 And, right. 24:15.610 --> 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. 24:32.730 --> 24:34.810 Or DDoS protection. 24:35.430 --> 24:41.430 Or some obfuscated thing that people do to try and improve security, which I'm sure that works real well. 24:41.970 --> 24:42.650 Anyway. 24:44.690 --> 24:45.290 Yeah. 24:45.290 --> 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. 24:51.510 --> 24:52.170 Anyway. 24:52.850 --> 24:53.510 Okay. 24:53.510 --> 24:53.810 Yeah. 24:53.810 --> 24:54.870 And, right. 24:54.870 --> 24:55.750 I already said this. 24:55.750 --> 24:57.450 We use a red-black tree. 24:57.470 --> 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. 25:06.670 --> 25:11.350 We could probably use just a hash table and have constant time. 25:11.630 --> 25:15.170 So, actually, what we want to do is actually switch on the fly. 25:15.170 --> 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. 25:27.550 --> 25:29.510 I think it says it in here anyway. 25:30.350 --> 25:35.970 Not most recently used, by the way, because that would be a lot of connections closing. 25:36.110 --> 25:41.410 We actually need the top talkers, so you actually want it frequent, not recent. 25:41.730 --> 25:42.330 Okay. 25:42.370 --> 25:43.310 Anyway. 25:43.310 --> 25:48.410 Here's some numbers about why we chose the algorithms that we did. 25:48.870 --> 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. 25:56.350 --> 26:01.310 You can see it here where we actually read the timestamp counter on a Pentium CPU. 26:01.670 --> 26:06.050 And then we're actually going to overload our table and see what the performance numbers look like. 26:06.050 --> 26:09.570 And these numbers actually indicate clock ticks. 26:09.810 --> 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. 26:25.270 --> 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. 26:37.890 --> 26:39.110 I'm not really sure. 26:39.330 --> 26:45.690 But I figured at least that after a load of maybe four that it would start dropping off. 26:45.690 --> 26:52.030 But it actually took somewhere around 30 for the performance to just go really badly. 26:53.510 --> 26:56.090 So, right, I just actually talked about that before. 26:56.090 --> 26:56.770 Whoops. 26:57.270 --> 27:00.650 Right, but yeah, reset acts obviously we don't want to cache. 27:00.650 --> 27:03.130 And those are always going to be the most recent. 27:03.130 --> 27:06.550 So if we're going to do anything to improve the performance, we can't do that. 27:06.550 --> 27:12.870 We actually have to calculate how often certain connections are being used and cache those instead. 27:13.330 --> 27:14.370 Right. 27:14.950 --> 27:19.250 Okay, so here's some examples from the payload configuration stuff. 27:19.350 --> 27:21.630 It's just ASCII text. 27:21.990 --> 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. 27:28.230 --> 27:31.090 But anyway, here's some example stuff. 27:31.310 --> 27:34.470 Obviously UDP is a UDP payload. 27:34.710 --> 27:38.750 If you don't get that, then I guess this is not going to make any sense. 27:39.350 --> 27:42.770 And then the destination port is actually next. 27:42.770 --> 27:46.950 And then the source port being negative one is just a wild card to say whatever. 27:47.130 --> 27:48.790 And then one is interesting. 27:48.790 --> 27:49.890 That's a payload group. 27:49.890 --> 27:55.090 One of the things that you can do is you can chain include files together or configuration files together. 27:55.190 --> 27:59.810 So you can actually have a bunch of different things that are meant for different sorts of environments. 28:00.150 --> 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. 28:07.870 --> 28:12.690 And then you can just use the minus big G and then the numeric option for that payload group. 28:12.690 --> 28:15.550 To kind of make that a little bit easier to do. 28:16.130 --> 28:20.670 And actually, we have now TCP payloads, which we didn't have before. 28:20.970 --> 28:23.470 And it's not still a real socket. 28:23.530 --> 28:27.910 It's kind of a trigger response mechanism, but we try and do some TCP stuff. 28:27.930 --> 28:33.930 But it turns out it's real hard because we actually emulate the operating system we're appearing to come from. 28:33.930 --> 28:36.790 So our stack code is non-trivial, unfortunately. 28:37.510 --> 28:43.610 But for right now, you can definitely do this sort of thing and test for, for example, open relays. 28:44.290 --> 28:46.130 Anyway, and here's some screenshots. 28:46.130 --> 28:48.210 Can you guys even see what that says? 28:48.390 --> 28:49.470 No. 28:49.470 --> 28:50.930 I'm going to explain it. 28:50.930 --> 28:58.070 This is a module written in C that's actually an HTTP module. 28:58.190 --> 29:00.030 And it just does a head request. 29:00.310 --> 29:04.650 And it's probably like, I don't know, 47 lines, apparently. 29:05.210 --> 29:08.550 But that's what it looks like. 29:08.550 --> 29:13.150 Okay, this is actually running a, I don't know, was this? 29:13.150 --> 29:19.610 Yeah, this was actually a cluster that was Connect scanning against Yahoo.com on port 80. 29:20.990 --> 29:27.430 And you can see that at the end here, it's got some TCP statistics, which are interesting. 29:27.430 --> 29:30.290 But for each host, you can actually see a banner. 29:30.330 --> 29:33.090 Now, that's probably not terribly exciting. 29:33.550 --> 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. 29:40.010 --> 29:44.330 This is actually a screenshot of Nmap scanning a website. 29:45.090 --> 29:48.630 And it actually comes back and just says that those things are open. 29:49.190 --> 29:52.670 And it took eight seconds or something, too. 29:52.790 --> 29:58.450 But we can actually do the same thing and finish it in four seconds. 29:58.870 --> 30:00.730 Well, I guess this really isn't race. 30:00.730 --> 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. 30:09.130 --> 30:17.170 But during the actual SYN scan, we actually did the connection and grabbed the banner without actually initiating another connection. 30:17.190 --> 30:22.870 And we actually can tell what port really is open at high rates. 30:23.590 --> 30:24.710 Okay. 30:25.270 --> 30:26.670 Here we go. 30:26.670 --> 30:28.290 I can do these live, actually. 30:28.290 --> 30:29.090 We have internet. 30:29.090 --> 30:29.710 Okay. 30:29.710 --> 30:31.530 Would you rather see live demos? 30:31.530 --> 30:33.370 Because these things are kind of hard to read. 30:33.410 --> 30:33.750 Yeah. 30:33.750 --> 30:34.070 Okay. 30:34.070 --> 30:35.530 Let's do some live stuff. 30:35.530 --> 30:36.250 Hang on. 30:44.540 --> 30:46.300 Assuming my connection isn't dead. 30:46.300 --> 30:46.660 All right. 30:46.660 --> 30:47.380 Cool. 30:51.260 --> 30:57.560 So what you see here at this first screen, locus-casio-3, that's our master thread. 30:58.540 --> 31:01.940 4 is our... what is that? 31:01.940 --> 31:03.980 That's the listener. 31:03.980 --> 31:07.620 It's listening on the IP address that we're going to be sending from. 31:07.620 --> 31:08.940 This one's number 5. 31:08.940 --> 31:10.820 This is actually the sender. 31:10.820 --> 31:12.380 So just so you can see what that is. 31:12.380 --> 31:14.400 And I'm just making sure that they're live and well. 31:14.400 --> 31:15.720 And they appear to be. 31:15.880 --> 31:18.680 So the first demo here. 31:18.680 --> 31:21.700 Let me look inside this file real quick. 31:23.280 --> 31:27.020 Well, unfortunately, no. 31:29.040 --> 31:30.000 Maybe. 31:30.000 --> 31:30.640 Yeah. 31:30.720 --> 31:32.980 We'll try, but all bets are off. 31:32.980 --> 31:35.020 If everything breaks, it's your fault. 31:51.480 --> 31:53.060 It's real big. 31:57.230 --> 31:57.950 Okay. 32:01.560 --> 32:03.200 I assume that's better. 32:04.900 --> 32:06.440 You have to forgive me. 32:06.440 --> 32:09.720 We're pretty hard on our laptops, and some of our keys are missing. 32:16.200 --> 32:16.780 Okay. 32:16.780 --> 32:21.140 So this first one, I just wanted to show you inside it so you knew I wasn't really cheating. 32:21.140 --> 32:23.860 It's just a stupid shell script that runs my command for me. 32:23.960 --> 32:29.100 Minus E, PGSQLDB just says for the output module, go ahead and dump everything to a database. 32:29.120 --> 32:33.340 I'm specifying the source IP to come from, although in cluster mode, you don't really need to do that. 32:33.340 --> 32:35.320 Minus V means a little bit more verbose. 32:35.420 --> 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. 32:46.000 --> 32:48.860 The minus Z is where we specify our drones. 32:48.860 --> 32:52.120 Right now, the IPC channel is not protected. 32:52.120 --> 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. 33:02.240 --> 33:05.040 I would have to recommend IPSec for that. 33:05.680 --> 33:06.960 I've actually tested that. 33:06.960 --> 33:08.080 It works pretty well. 33:08.080 --> 33:13.260 Minus big L5 is how long to wait after the batch sending is done. 33:13.260 --> 33:18.920 Minus little r 9,000 means we're going to send around 9,000 packets per second. 33:18.920 --> 33:24.780 We actually go a little bit lower than whatever you specify, but it won't exceed 9,000 packets per second. 33:24.780 --> 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. 33:34.320 --> 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. 33:41.160 --> 33:42.020 Right. 33:48.330 --> 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. 33:57.870 --> 34:01.550 And it's not doing what I want, so I'm confused. 34:06.110 --> 34:07.830 It's the font, man. 34:32.860 --> 34:33.780 There you go. 34:33.780 --> 34:34.340 Okay. 34:34.340 --> 34:40.920 So now these are some SNMP public community string version 1 machines that are responding. 34:40.920 --> 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. 34:53.080 --> 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. 35:11.560 --> 35:12.380 XOR. 35:12.500 --> 35:14.540 It's pretty ugly, actually. 35:14.720 --> 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. 35:26.220 --> 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. 35:38.540 --> 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. 35:56.180 --> 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. 36:09.100 --> 36:12.340 Some more demo 2. 36:12.360 --> 36:13.740 This one is SMTP. 36:13.740 --> 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. 36:23.600 --> 36:25.720 So this is TCP port 25. 36:25.720 --> 36:33.420 We are absolutely connecting to them on port 25 and sending enough of a payload to elicit... 36:33.420 --> 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. 36:48.080 --> 36:53.680 But then, either way, I still get the banner of all the systems that we just talked to. 36:54.040 --> 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. 37:01.220 --> 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. 37:09.720 --> 37:12.780 So some of the TCP connections will actually kind of fail. 37:12.780 --> 37:16.880 It makes for a better demo, but you wouldn't do that in production, obviously. 37:17.380 --> 37:19.940 Okay, so this next one is an HTTP GET request. 37:19.940 --> 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. 37:31.680 --> 37:32.640 Yeah. 37:43.880 --> 37:48.100 Okay, so that was a pretty simple GET request here. 37:48.420 --> 37:50.600 That was a really small range. 37:50.600 --> 37:51.840 Let's look at that. 37:51.880 --> 37:52.980 That's just a slash 30. 37:52.980 --> 37:54.960 That's Yahoo with a slash 30. 37:55.220 --> 37:56.880 So, piece of cake, right? 37:57.120 --> 38:01.180 Okay, let's see what else we have here. 38:01.880 --> 38:04.700 Oh, I wanted to show you what was in the slide. 38:05.640 --> 38:06.440 Sorry. 38:06.440 --> 38:13.560 This is Nmap with port 70 through 82 against dietsecurity.com. 38:13.560 --> 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. 38:22.520 --> 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. 38:30.540 --> 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. 38:40.840 --> 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. 38:56.920 --> 38:59.600 But, yeah, it's pretty easy at this point where you can actually... 39:00.060 --> 39:02.600 It's kind of like the UDP situation all over again. 39:02.600 --> 39:09.180 You know, in the UDP, again, now we're sending real protocol payloads as opposed to just counting on ICP messages. 39:09.200 --> 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. 39:24.310 --> 39:28.830 This is just showing that we can do multiple payloads all on one. 39:28.830 --> 39:33.150 So this one's sending like 50 or so different payloads. 39:33.150 --> 39:36.630 We've got some DNS servers, we've got some SNMP servers. 39:36.910 --> 39:39.030 Port 2367, don't know what that is. 39:39.490 --> 39:42.130 137, yeah, all these are coming back to us now. 39:42.430 --> 39:49.090 And I guess this is just showing off, you know, what it looks like to do multiple payloads. 39:49.090 --> 39:51.290 So that was the easy stuff. 39:51.450 --> 39:53.310 Now comes the tricky part. 39:53.690 --> 39:54.690 Hang on. 40:07.830 --> 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. 40:15.550 --> 40:22.250 Anyway, what we do is we do basically a TCP connect scan on port 80. 40:22.330 --> 40:26.010 And there's actually a CGI script that has a really dumb coding error in it. 40:26.290 --> 40:31.490 We actually had some other stuff that we were going to do but the political climate kind of got ugly. 40:31.490 --> 40:36.230 Yeah, we were going to release some fun stuff but unfortunately nobody wants to hear that sort of thing these days. 40:36.610 --> 40:40.430 So we actually just reused some other stuff we had. 40:40.710 --> 40:49.130 But basically it does a three-way handshake and it actually generates the XOR encoder on the fly, which is metamorphic. 40:49.650 --> 40:52.790 And it actually does a two-stage exploit. 40:52.790 --> 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. 40:59.510 --> 41:04.410 So I cheated and used someone else's stuff and it doesn't work. 41:04.410 --> 41:06.730 So that just goes to show me... 41:07.330 --> 41:08.450 Okay, so right. 41:08.450 --> 41:11.850 We generate a metamorphic first stage and we send the payload. 41:12.550 --> 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. 41:22.190 --> 41:25.450 So the first thing that we do in our shellcode is we truncate that. 41:25.730 --> 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... 41:34.510 --> 41:36.930 or the process that we've just compromised. 41:37.210 --> 41:44.930 And we actually just send back a 32-bit word saying what predefined constant that was. 41:44.930 --> 41:45.530 So... 41:45.530 --> 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. 41:59.010 --> 42:07.470 And it loads a hacked binary into that area and jumps to the beginning of the file, which then... 42:07.470 --> 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. 42:16.770 --> 42:20.510 But the important point is that the second stage is written in C. 42:20.510 --> 42:23.350 It's similar to the impurity stuff, actually. 42:24.110 --> 42:24.830 Anyway. 42:24.970 --> 42:29.870 And then we transfer control to the second stage code by jumping to the ELF entry point. 42:31.310 --> 42:32.010 Yeah. 42:32.010 --> 42:32.630 Oh, right. 42:32.630 --> 42:35.090 So this is the part where I do it and it doesn't break. 42:46.060 --> 42:46.720 Okay. 42:46.720 --> 42:48.780 This is the NetBSD box. 42:49.420 --> 42:50.040 Okay. 42:50.040 --> 42:52.720 As you can see, this shellcode doesn't work. 42:52.760 --> 42:56.740 So the only thing we can do is just look at port 4444. 43:00.300 --> 43:02.420 This is the second stage server. 43:05.220 --> 43:08.220 And then we actually have two of these clients. 43:08.220 --> 43:12.000 One of them actually uses ncurses, so it opens up new windows every time you get a shell. 43:12.000 --> 43:12.980 It's kind of neat. 43:12.980 --> 43:15.260 But we're having some terminal issues. 43:15.380 --> 43:17.060 And we can't figure out ncurses. 43:17.060 --> 43:18.080 It's kind of above us. 43:18.080 --> 43:19.500 So we don't have that yet. 43:40.460 --> 43:44.360 What he's going to show you is the TCP dump, so you can see that it really is working. 43:44.680 --> 43:47.480 And we're being told to hurry up, so you've got like five seconds. 43:47.480 --> 43:48.580 Okay, so here it goes. 43:48.580 --> 43:49.620 Hopefully it won't crash. 43:49.800 --> 43:54.700 Okay, so we first have to grab an IP address that's not attached to the kernel. 43:54.700 --> 43:56.460 As you can see, some stuff went by here. 43:56.460 --> 43:57.600 So it connected to port 80. 43:57.600 --> 43:59.680 It sent our payload. 43:59.700 --> 44:00.740 And now we have a shell. 44:00.740 --> 44:05.260 Yeah, so you can see here that the second stage shellcode server got it connected back. 44:05.260 --> 44:07.120 It sent back the word that said it was... 44:07.120 --> 44:09.520 This particular one was Linux x86. 44:09.520 --> 44:13.280 The important part about that demo, though, is that after it got the... 44:13.280 --> 44:15.060 It connected to two different hosts. 44:15.060 --> 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. 44:22.400 --> 44:25.900 It knew how to generate a platform-specific exploit on the fly. 44:25.920 --> 44:27.060 So that was actually pretty cool. 44:27.060 --> 44:29.700 Unfortunately, we don't have time to explain in more detail. 44:29.700 --> 44:32.060 But if you're interested, come find us. 44:32.060 --> 44:32.660 Yeah. 44:32.760 --> 44:37.780 And you can actually watch DVDs in ASCII, which was the entire point of doing that.