[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:13.380] So sorry about the introducing thing. Oh well. [00:15.400 --> 00:21.360] Okay, so we're going to talk about a lot of stuff. One of the most important things that we wanted to highlight [00:21.360 --> 00:27.400] is a new way that we are keeping track of connection state as we're talking to remote systems. [00:27.400 --> 00:30.900] So that's what the scatter connect is all about. 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:51.780] So it's definitely different. And then we're going to demonstrate some of what it can do. [00:52.160 --> 00:57.120] So, I'm Robert Lee. 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:12.400] Okay, so nice and simple. You've all seen a TCP three-way handshake before. [01:12.400 --> 01:16.800] The concept is simple. You're trying to initiate a connection. You send a SYN packet. [01:16.800 --> 01:22.200] You expect a SYN ACK if it's open. 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:18.380] When the remote host, the 192.168.1.1, receives that SYN packet, [02:18.380 --> 02:23.760] 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:32.560] Once the receiver receives the SYN ACK, it sends the meta information back to the master control thread, [02:32.560 --> 02:37.920] 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:48.660] Now, I know this looks pretty crazy, and you're probably asking yourself right now, [02:48.660 --> 02:50.440] why would you do it this way? [02:50.440 --> 02:53.400] And I'm glad you asked that question. We'll answer that later. [02:53.400 --> 02:56.980] But the important part here is that you understand that at this point, [02:56.980 --> 03:03.600] 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:16.760] The listener process, the one on the bottom, Unilisten, is the one that's collecting all the information that comes back to it [04:16.760 --> 04:21.940] 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:37.120] And so when you're doing testing from a remote perspective, if you can't get on the ICMP message coming back to you, [05:37.120 --> 05:39.140] then it's kind of a useless process. [05:39.140 --> 05:40.000] That's one of the problems. [05:40.000 --> 05:44.880] 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, [05:44.880 --> 05:47.060] because ICMP messages are rate limited. [05:47.060 --> 05:50.280] So it's a really slow and ugly process. [05:50.800 --> 05:56.400] So what we ended up doing, as a quick and dirty workaround, [05:56.400 --> 06:00.620] is we were taking the individual programs like BIG or SNMP walk, [06:00.620 --> 06:05.460] and we were scripting it to send the actual client probes. [06:05.460 --> 06:12.080] And then we got this idea, maybe it would be cool if we had an automated way of doing all those probes [06:12.080 --> 06:16.780] 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:27.060] Another problem we had with our TCP scanning is that it was a large effort to do what we really wanted to do, [06:27.060 --> 06:31.660] which is actually talk to the service that we wanted to interact with. [06:31.660 --> 06:40.560] So typically if you're scanning like a Slash 8, just based on the resource limitations on your side alone, [06:40.560 --> 06:45.380] 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:02.860] But it's difficult, especially if you're testing a dynamic network that's really large, [07:02.860 --> 07:06.680] because by the time you're done with your first pass, things have changed. [07:06.940 --> 07:10.180] Because it turns out that these networks are getting really big, [07:10.180 --> 07:13.500] 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:37.340] Okay, some more problems that we have with any vulnerability scanner that we've played with [07:37.340 --> 07:46.060] 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:51.600] So one of our favorite examples to make fun of is the situation where some sort of device in the middle [07:51.600 --> 07:57.380] is altering the TCP IP stack enough to where your operating system probe comes back and says, [07:57.380 --> 07:59.680] 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:06.840] But anyhow, then the second probe that actually connects to TCP port 80 and does a banner grab [08:06.840 --> 08:09.400] will show you that it's an IIS 5 machine. [08:09.680 --> 08:16.320] And then because they have an IPS or something actively killing connections when it sees something bad across the wire, [08:16.320 --> 08:24.020] 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:35.000] So that's fine. 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:39.160] But imagine doing this times 4 billion machines. 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:10.080] With our tool at this point, on a standard copper gigabit card, [10:10.080 --> 10:14.440] 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:25.240] But we're still working on that. 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:42.580] Some more mindset. 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:00.360] Basically, I watched Sesame Street as a kid and they were trying to pollute our minds with this political message [11:00.360 --> 11:03.780] that buses are better than Ferraris because they're more efficient. [11:04.360 --> 11:08.540] But in the example, they had 100 kids on the left and 100 kids on the right [11:08.540 --> 11:15.340] 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:34.500] So even if you could get Nmap or ScanRan to go at 70,000 packets per second, [11:34.500 --> 11:37.460] you're not going to have any room left to receive messages. [11:37.460 --> 11:44.280] 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 [11:44.280 --> 11:48.620] 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:00.640] But with scalability in mind, we know that we need to be able to have one logical working scanning system [12:00.640 --> 12:06.100] 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:12.620] I quoted some really ridiculous packet per second rates from a single machine, [12:12.620 --> 12:18.500] 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:25.040] I mean, I've seen some of these networks with even the big high-end Juniper firewalls [12:25.040 --> 12:30.380] sitting in front of multiple OC3s that fall over dead at even 8,000 packets per second [12:30.380 --> 12:33.740] 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:19.580] Computers are good at doing the tedious automated parts, humans are good at thinking, [13:19.580 --> 13:22.160] and we shouldn't really mix the two more than we have to. [13:24.540 --> 13:25.380] Flexibility. [13:25.720 --> 13:29.700] At this point, with this framework, and you'll see examples of this, [13:29.700 --> 13:35.480] any stimulus that you want to introduce to the remote side, currently we support TCP and UDP, [13:35.480 --> 13:40.620] 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:06.160] We tried to put some formal thought into this, and we actually selected one of the IDS protection profiles from the Common Criteria [14:06.160 --> 14:12.000] 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:36.180] And obviously with an open source tool, we don't have $5 million to formally go through the process, [14:36.180 --> 14:38.880] 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:11.210] And some more interesting things is that instead of just sending a non-protocol specific probe, [15:11.210 --> 15:15.250] 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:21.750] Instead of just sending a blank datagram to UDP port 53, [15:21.750 --> 15:26.270] 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:04.010] And then for TCP, it's going to become more important nowadays as well, [16:04.010 --> 16:09.010] because a lot of the networks that we're testing have those things that complete the three-way handshake [16:09.010 --> 16:11.370] 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:20.670] And you need to be able to send protocol-specific payloads [16:20.670 --> 16:22.890] so you can figure out which ones are tricking you. [16:23.490 --> 16:27.310] Then one of the other things that we put in there is a metamorphic shellcode encoder [16:27.310 --> 16:32.870] to make it so that when you are delivering other types of payloads, [16:32.870 --> 16:37.590] 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 --> 16:56.490] And everything we do, and I can't stress this enough, [16:56.490 --> 17:03.010] everything we're doing from this point forward has hooks to talk to relational databases on the back end, [17:03.010 --> 17:06.450] 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:33.670] Okay, one of the things that's different is that we try and use, [17:33.670 --> 17:38.250] it's kind of a trivial algorithm to actually carry information inside the sequence number, [17:38.250 --> 17:40.710] but the important part is that it's not one way. [17:41.010 --> 17:44.790] So in other words, if we used MD5 and then lopped off part of it, [17:44.790 --> 17:45.830] 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:53.890] The problem is that we can't actually have the guy who's sniffing and validating the sequence number [17:53.890 --> 17:58.930] 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:09.470] Anyway, and then the scatter connect is we basically send out the SYN packets, [18:09.470 --> 18:13.450] and then we gather on the syntax that we get back and act the connection [18:13.450 --> 18:17.850] 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:27.190] Half hour? 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:43.930] It actually reads the configuration file first, [18:43.930 --> 18:47.810] and then the actual command line arguments are parsed at that point [18:47.810 --> 18:50.650] 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 --> 18:59.730] Anyways, the master process actually opens up binary modules [18:59.730 --> 19:02.650] 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:17.110] Anyways, the master process figures out whether or not you want it to run in a clustered mode, [19:17.110 --> 19:18.930] which is a command line argument. [19:19.390 --> 19:22.670] But this is actually for a local scan, [19:22.670 --> 19:27.810] so we're just assuming that the master thread is actually going to fork children. [19:28.330 --> 19:31.850] And then it actually records some information about them, [19:31.850 --> 19:35.850] and it actually uses... the IPC goes through a Unix domain socket, [19:35.850 --> 19:39.030] so it's actually a little bit faster than it used to be. [19:39.230 --> 19:42.730] And then it actually uses signals to synchronize, [19:42.730 --> 19:47.110] which I believe is actually causing us problems portability-wise. [19:47.110 --> 19:53.010] So one of the problems with this release is that on certain machines the signals disappear, [19:53.010 --> 19:56.190] 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:06.430] And then actually the important part is that we can't make the assumption we know what the other processes do, [20:06.930 --> 20:09.210] because we don't know if we're in cluster mode. [20:09.210 --> 20:13.030] If we're in cluster mode, all we know is an IP address and a port, [20:13.030 --> 20:15.930] 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:36.670] It's actually the listener that contains a lot of useful information early on, [20:36.670 --> 20:39.810] 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:51.590] And then the master actually does something called stirring, [20:51.590 --> 20:55.170] 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:03.870] I think in the general code we actually don't have anything useful when it stirs, [21:03.870 --> 21:08.890] but if you actually had a big cluster and you wanted to actually distribute the send packets [21:08.890 --> 21:13.230] amongst geographical areas, that's where you would put the code to do that, [21:13.230 --> 21:17.890] 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:26.070] Then the listener fires up, and then we send the sender a batch work unit, [21:26.070 --> 21:28.670] 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:49.050] And when the sender finishes, it sends a work done, [21:49.050 --> 21:53.150] 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:03.030] But meanwhile, any important things that are happening, such as TCP connections, [22:03.030 --> 22:06.930] it will actually respond to those while it's in its timeout state, [22:07.450 --> 22:09.930] or actually throughout the entire scan. [22:10.070 --> 22:13.130] And then actually the master tells the sender and listener to quit, [22:13.130 --> 22:14.610] and then the scan's done. [22:15.690 --> 22:16.310] Right. [22:16.310 --> 22:16.650] Okay. [22:16.650 --> 22:22.150] So the important part about all that nonsense is that a general stack that's inside of a kernel [22:23.170 --> 22:26.390] normally knows the remote target that it's going to talk to, [22:26.390 --> 22:28.770] 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:39.030] So we actually just kind of redid some of the decisions inside the stack [22:39.030 --> 22:43.370] so that it would better fit a model where we don't know that information, [22:43.370 --> 22:45.830] 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:53.550] One of the important things is a lot of stacks we'll use like a hash table, [22:53.550 --> 22:56.930] but we can't actually do that because we don't actually know who's going to talk to us. [22:56.930 --> 23:02.330] A good example is if we scan a network that actually syntax packets, [23:02.330 --> 23:06.370] it'll fill up our state table, and if there's nothing behind that device, [23:06.370 --> 23:09.930] we'll have a bunch of dead entries in our connection table, [23:09.930 --> 23:14.010] and we'll probably guess the size of the hash table wrong by doing that, [23:14.010 --> 23:17.090] and our hash table will basically either collide to death, [23:17.090 --> 23:20.870] 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:28.870] We actually have to pick a data structure that responds better to unpredictable things like that, [23:28.870 --> 23:30.370] like a binary tree. [23:30.850 --> 23:31.590] Anyways. [23:32.410 --> 23:33.630] So, right. [23:33.630 --> 23:37.530] The point is that we can only have constant time lookups [23:37.530 --> 23:42.210] 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 --> 23:58.270] Even if we did have a hash table that was big enough, [23:58.270 --> 24:00.610] and this is just obviously for IPv4, [24:01.170 --> 24:03.830] it would be quite a bit of RAM, actually, [24:03.830 --> 24:08.030] 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:20.010] Like I said, the reason why that's important is because as time goes on, [24:20.010 --> 24:23.410] we see more and more devices to compensate for high-latency networks [24:23.410 --> 24:27.910] that will answer part of the three-way handshake to kind of offload that [24:27.910 --> 24:32.730] 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:39.530] Or some obfuscated thing that people do to try and improve security, [24:39.530 --> 24:41.430] 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:49.170] So, one of the design goals is we need to be able to withstand this sort of network [24:49.170 --> 24:50.870] 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:00.150] One of the possible improvements that we're thinking of doing [25:00.150 --> 25:06.670] 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:20.090] If we actually pass a threshold and our table load goes too high, [25:20.090 --> 25:23.010] we can actually dump it and turn it into a binary tree on the fly [25:23.010 --> 25:27.550] 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:54.010] And the point was is we're just trying to prove that our measurements are somewhat valid, [25:54.010 --> 25:56.350] 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:15.510] And you can see here with the various load factors that our chained hash table [26:16.290 --> 26:22.210] turns quickly into a bunch of linked lists and our red-black tree does not, [26:22.210 --> 26:25.130] which should not be much of a surprise anyways. [26:25.270 --> 26:29.590] But what's interesting about this actually is the amount of load that it took [26:29.590 --> 26:34.090] for the CPU to actually get a really expensive lookup, [26:34.090 --> 26:37.890] 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:25.470] But we tried to make it so that you could copy and paste stuff from like C [27:25.470 --> 27:27.990] 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:49.890] And then one is interesting. That's a payload group. [27:49.890 --> 27:52.810] One of the things that you can do is you can chain include files together [27:52.810 --> 27:55.090] 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:04.110] Like, for example, if you want to scan for like Windows Trojans, [28:04.110 --> 28:07.870] 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:32.130] But it turns out it's real hard because we actually emulate the operating system [28:32.130 --> 28:33.930] we're appearing to come from. [28:33.930 --> 28:36.790] So our stack code is non-trivial, unfortunately. [28:37.510 --> 28:40.490] But for right now, you can definitely do this sort of thing [28:40.490 --> 28:43.610] 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:50.930] No. 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:17.190] Yeah, this was actually a cluster that was Connect scanning [29:17.190 --> 29:19.610] against Yahoo.com on port 80. [29:20.990 --> 29:26.070] And you can see that at the end here, it's got some TCP statistics, [29:26.070 --> 29:27.430] 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:36.470] Here's probably some better contrast for you, [29:36.470 --> 29:39.930] 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:02.910] But the idea is, if you see here, [30:02.910 --> 30:07.010] you can see, like, five open ports coming back, [30:07.010 --> 30:09.110] which is identical to what we saw before. [30:09.130 --> 30:11.310] But during the actual SYN scan, [30:11.310 --> 30:13.170] we actually did the connection and grabbed the banner [30:13.770 --> 30:17.170] 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:26.670] Okay. Here we go. [30:26.670 --> 30:29.090] I can do these live, actually. We have internet. [30:29.090 --> 30:31.530] Okay. 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:36.250] Yeah. Okay. Let's do some live stuff. Hang on. [30:44.540 --> 30:46.300] Assuming my connection isn't dead. [30:46.300 --> 30:47.380] All right. Cool. [30:51.260 --> 30:54.060] So what you see here at this first screen, [30:54.060 --> 30:57.560] 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:10.820] This one's number 5. 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.640] Maybe. 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:19.440] Okay. So this first one, I just wanted to show you inside it [32:19.440 --> 32:21.140] 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:27.160] Minus E, PGSQLDB just says for the output module, [32:27.160 --> 32:29.100] go ahead and dump everything to a database. [32:29.120 --> 32:31.080] I'm specifying the source IP to come from, [32:31.080 --> 32:33.340] 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:39.420] W6 means emulate the Linux TCP IP stack properties, [32:39.420 --> 32:42.180] mostly because that's the one that we've spent the most time with [32:42.180 --> 32:45.840] 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 --> 32:54.200] Normally, if you're in a sensitive environment [32:54.200 --> 32:56.400] or an environment that has any type of malice, [32:56.400 --> 33:02.100] 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:08.080] I've actually tested that. 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:22.140] We actually go a little bit lower than whatever you specify, [33:22.140 --> 33:24.780] but it won't exceed 9,000 packets per second. [33:24.780 --> 33:30.480] The 66.0.0.0.16 just means go to that CIDR block [33:30.480 --> 33:34.320] and do 161 for the port, the disk port. [33:34.320 --> 33:36.100] Minus MU is UDP mode, [33:36.100 --> 33:39.220] and then minus big I is for impatient people like me [33:39.220 --> 33:41.160] so you can see the data right away. [33:41.160 --> 33:42.020] Right. [33:48.330 --> 33:51.150] Which, of course, you don't actually want to use minus big I [33:51.150 --> 33:52.730] when you're doing a scan that matters [33:52.730 --> 33:55.970] because it's going to block on the master thread to write to the terminal, [33:55.970 --> 33:57.250] 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:34.340] There you go. Okay. [34:34.340 --> 34:39.700] So now these are some SNMP public community string version 1 machines [34:39.700 --> 34:40.920] that are responding. [34:40.920 --> 34:43.420] As you see, we're doing a slash 16 network, [34:43.420 --> 34:45.560] and we're done sending, [34:45.560 --> 34:47.500] and we're just waiting the five-second timeout, [34:47.500 --> 34:50.380] and then it's going to process the results, [34:50.380 --> 34:52.880] and it'll spit it back here pretty soon. [34:53.080 --> 34:56.100] We're actually, I think, repeating the scan three times, [34:56.100 --> 34:59.400] so if you're wondering why it's just sitting there now, [34:59.400 --> 35:03.260] it's actually sending different SNMP payloads to try and get everyone. [35:11.560 --> 35:14.540] XOR. It's pretty ugly, actually. [35:14.720 --> 35:16.680] We're actually trying to figure out a better algorithm [35:16.680 --> 35:21.600] that'll favor randomizing the more significant bits first, [35:21.600 --> 35:24.000] but I actually haven't had time to get around to that, [35:24.000 --> 35:26.220] so it just kind of XORs a random word. [35:26.220 --> 35:30.500] So that was a slash 16 for SNMP with multiple payloads, [35:30.500 --> 35:32.940] but those are absolutely open [35:32.940 --> 35:36.560] because we sent a public community string request, [35:36.560 --> 35:38.540] and it sent us back responses. [35:38.540 --> 35:42.900] The TTL is wrapping over, thanks to our insane font size, [35:42.900 --> 35:44.960] but if it wasn't, you would be able to see [35:45.600 --> 35:48.140] the time-to-load value of the packet that's coming back to you, [35:48.140 --> 35:49.900] and so you can quickly, as you're looking through it, [35:49.900 --> 35:53.680] you can spot Windows Novell stacks versus Unix stacks [35:53.680 --> 35:56.140] versus routing infrastructure. [35:56.180 --> 35:58.400] But all of that went back to a database [35:58.400 --> 35:59.980] that we may be able to show you, [35:59.980 --> 36:01.200] but I don't want to run out of time [36:01.200 --> 36:03.560] 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:17.860] This one's actually going to look for open relay servers [36:17.860 --> 36:19.640] in the same block, [36:19.640 --> 36:22.200] and now we're actually doing three-way handshakes [36:22.200 --> 36:23.560] with all those guys. [36:23.600 --> 36:25.720] So this is TCP port 25. [36:25.720 --> 36:27.920] We are absolutely connecting to them on port 25 [36:27.920 --> 36:33.420] and sending enough of a payload to elicit... [36:33.420 --> 36:35.940] Well, basically what I did is I said, [36:35.940 --> 36:39.360] I'm coming from an email address that I control, [36:39.360 --> 36:41.600] sending to another email address that I control, [36:41.600 --> 36:43.980] and that way I can get bounces back [36:44.380 --> 36:45.900] telling me that I was a bad person, [36:45.900 --> 36:47.960] or I can actually get the email that I sent. [36:48.080 --> 36:50.220] But then, either way, [36:50.220 --> 36:52.340] I still get the banner of all the systems [36:52.340 --> 36:53.680] that we just talked to. [36:54.040 --> 36:55.100] So if nothing else, [36:55.100 --> 36:57.920] I now have version information in my database [36:57.920 --> 36:59.420] that I can search through and say, [36:59.420 --> 37:01.180] show me all the send mailboxes. [37:01.220 --> 37:02.600] One thing that's important, too, [37:02.600 --> 37:04.240] is that he had the immediate mode on, [37:04.240 --> 37:06.260] but he was doing TCP connections, [37:06.260 --> 37:08.440] so all the immediate things that needed to happen right away [37:08.440 --> 37:09.560] got stalled. [37:09.720 --> 37:12.780] So some of the TCP connections will actually kind of fail. [37:12.780 --> 37:14.400] It makes for a better demo, [37:14.400 --> 37:16.880] 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:21.800] Again, we're going to connect to TCP port 80 [37:23.180 --> 37:27.340] and just hit all the people that are listening on port 80 [37:27.340 --> 37:29.800] 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:11.340] This is Nmap with port 70 through 82 [38:11.340 --> 38:13.560] against dietsecurity.com. [38:13.560 --> 38:16.300] All ports come back open, which is what we expect [38:16.300 --> 38:18.520] because we have a stupid device in the middle [38:18.520 --> 38:20.920] that protects us from DDoS. [38:22.520 --> 38:25.120] But here's with the unicorn scan [38:25.120 --> 38:27.980] where we can actually enumerate what the protocol [38:27.980 --> 38:30.540] behind the three-way handshake looks like. [38:30.540 --> 38:32.620] So you see here that even though [38:32.620 --> 38:34.400] the other ones came back as open, [38:34.400 --> 38:36.920] in your database you can do a pretty simple [38:37.800 --> 38:40.680] select statement to throw away the garbage properties. [38:40.840 --> 38:44.300] And sometimes you'll even get better information [38:44.300 --> 38:46.360] about the stack properties itself [38:46.360 --> 38:50.540] because once you get sent to the right application [38:50.540 --> 38:52.420] behind it, there's going to be telltale signs [38:52.420 --> 38:53.960] that you're talking to a different device [38:53.960 --> 38:55.660] than the one that actually completed the three-way handshake [38:55.660 --> 38:56.580] for you. [38:56.920 --> 38:58.560] But, yeah, it's pretty easy at this point [38:58.560 --> 38:59.600] 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:04.580] You know, in the UDP, again, [39:04.580 --> 39:06.620] now we're sending real protocol payloads [39:06.620 --> 39:09.180] as opposed to just counting on ICP messages. [39:09.200 --> 39:10.920] But now in TCP land, [39:10.920 --> 39:13.120] we're actually sending real protocol information [39:13.120 --> 39:14.740] so we can get away from these devices [39:14.740 --> 39:16.840] that just SYNAC everything. [39:24.310 --> 39:27.990] This is just showing that we can do multiple payloads [39:27.990 --> 39:28.830] all on one. [39:28.830 --> 39:33.150] So this one's sending like 50 or so different payloads. [39:33.150 --> 39:34.870] We've got some DNS servers, [39:34.870 --> 39:36.630] 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:44.470] And I guess this is just showing off, [39:45.470 --> 39:49.090] 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:10.270] Okay, so I'm going to talk about what we're going to do now [40:10.270 --> 40:11.290] and hopefully it won't break [40:11.710 --> 40:14.230] because I was still writing code for it last night. [40:15.550 --> 40:19.450] Anyway, what we do is we do basically a TCP connect scan [40:20.650 --> 40:22.250] on port 80. [40:22.330 --> 40:23.910] And there's actually a CGI script [40:23.910 --> 40:26.010] that has a really dumb coding error in it. [40:26.290 --> 40:28.630] We actually had some other stuff that we were going to do [40:28.630 --> 40:31.490] but the political climate kind of got ugly. [40:31.490 --> 40:33.030] Yeah, we were going to release some fun stuff [40:33.030 --> 40:36.230] 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:42.730] But basically it does a three-way handshake [40:42.730 --> 40:47.670] and it actually generates the XOR encoder on the fly, [40:47.670 --> 40:49.130] which is metamorphic. [40:49.650 --> 40:52.790] And it actually does a two-stage exploit. [40:52.790 --> 40:54.350] One of the problems that I had, though, [40:54.350 --> 40:59.510] was that I didn't have enough time to write the two-stage NetBSD assembly. [40:59.510 --> 41:03.310] So I cheated and used someone else's stuff [41:03.310 --> 41:04.410] 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:10.350] We generate a metamorphic first stage [41:10.350 --> 41:11.850] and we send the payload. [41:12.550 --> 41:14.810] What we're supposed to want to do here [41:14.810 --> 41:18.310] is Apache hands all the CGI scripts, [41:18.430 --> 41:22.190] a writable file descriptor on two bits, the error logs. [41:22.190 --> 41:23.910] So the first thing that we do in our shellcode [41:23.910 --> 41:25.450] is we truncate that. [41:25.730 --> 41:30.930] We create a socket and connect back to a second stage server [41:30.930 --> 41:34.510] 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:40.470] And we actually just send back a 32-bit word [41:40.470 --> 41:44.930] saying what predefined constant that was. [41:44.930 --> 41:45.530] So... [41:45.530 --> 41:48.230] And then the shellcode server sends back [41:48.230 --> 41:53.130] the length of the payload that we're going to send in the second stage [41:53.130 --> 41:57.490] and it does memmap and opens up an anonymous memory region [41:57.490 --> 41:59.010] at a fixed address. [41:59.010 --> 42:02.550] And it loads a hacked binary into that area [42:02.550 --> 42:06.390] and jumps to the beginning of the file, [42:06.390 --> 42:07.470] which then... [42:07.470 --> 42:09.450] And I mentioned that the ELF is hacked [42:09.450 --> 42:12.610] because we actually overwrote the first part of the ELF header [42:12.610 --> 42:15.850] 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:27.390] And then we transfer control to the second stage code [42:27.390 --> 42:29.870] by jumping to the ELF entry point. [42:31.310 --> 42:32.630] Yeah. 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:11.040] One of them actually uses ncurses, so it opens up new windows [43:11.040 --> 43:12.000] 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:42.180] What he's going to show you is the TCP dump, [43:42.180 --> 43:44.360] so you can see that it really is working. [43:44.680 --> 43:46.040] And we're being told to hurry up, [43:46.040 --> 43:47.480] 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:52.260] Okay, so we first have to grab an IP address [43:53.300 --> 43:54.700] 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:04.200] Yeah, so you can see here that the second stage shellcode server [44:04.200 --> 44:05.260] 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:11.300] The important part about that demo, though, [44:11.300 --> 44:13.280] is that after it got the... [44:13.280 --> 44:15.060] It connected to two different hosts. [44:15.060 --> 44:16.420] And after it got the SYNAC back, [44:16.420 --> 44:18.100] it did operating system detection, [44:18.100 --> 44:22.400] 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:35.480] And you can actually watch DVDs in ASCII, [44:35.480 --> 44:37.780] which was the entire point of doing that.