 And it turns out that when you're doing spellcheck, it would really help if you check all the files. So sorry about the introducing thing. Oh well. Okay, so we're going to talk about a lot of stuff. 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. So that's what the Scatter Connect is all about. And you'll see that in detail. In fact, that's the first thing that we're going to hit off. Then we're going to talk a little bit about the tool that we're releasing today. We actually have released it previously, but this new version has somewhere around 25,000 lines of code change. So it's definitely different. And then we're going to demonstrate some of what it can do. So I'm Robert Lee. I do stuff with a couple of companies. And this is Jack, and we also have Anthony here in the audience. 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. Okay, so nice and simple. You've all seen a TCP 3-way handshake before. The concept is simple. You're trying to initiate a connection. You send a SIN packet. You expect a SIN act if it's open. You acknowledge it, and then your connection is open. It's actually two one-way connections, but whatever. I'm not sure if you can see this, but I'll visually walk you through what's happening here. The very first process, the master control on the far left is what's going to keep track of all the state connections. In this particular example, we are doing a TCP port 80 full connection with a remote host. That's the one on the far right with the little globe thing. 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. And then the sender will actually create a packet spoofing its source IP address to come from the receiver. If you can see it, the receiver machine is the one on the far bottom. When the remote host, the 192.168.1.1 receives that SIN packet, it responds to the SIN packet based on the IP address that it thought it came from. So that's how the receiver receives it. Once the receiver receives the SIN act, it sends the meta information back to the master control thread, who then schedules an acknowledgement to be sent through an immediate sender. So that's the one in the middle. So the acknowledgement is then sent back to 192.168.1.1 and the three-way handshake is complete. Now I know this looks pretty crazy and you're probably asking yourself right now, why would you do it this way? And I'm glad you asked that question. We'll answer that later. 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 land space. And we've made it so that you can have a three-way handshake amongst a cluster of machines. But to the end machine on the right-hand side, it's all a normal connection to him. Once his handshake is complete, we can also then send arbitrary payload-specific stuff. So if you wanted to do a get request or any arbitrary payload can be sent at that point. Important stuff. Okay, so I just explained all this, but I'll go through it one more time just for clarity. The first process again is the unicorn scan main thread. The second process is the sender, that's unison. That's the one that actually symbols the packets. And again, we have the concept of batch sender and immediate sender. The batch sender, it turns out, is the one that you give large work units to. So you can say, I want to scan this slash 16 network and I'm looking to do these ports. And you tell it what speed to do it, et cetera, et cetera. So it just goes out and sends a bazillion send packets. 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. And then the immediate mode is the one that completes the three-way handshake. They're not actually threads, by the way, they're actually processes. We just call them threads. Because we're silly like that. Okay, cool. I've talked about all this. Is that part clear at all? All right, cool. We did it twice. Now we're going to talk about some problems that we were banging our heads against. By the way, all we do with the companies is we do a lot of security testing. Really big networks. And we've been eating a lot of dirt with tools that didn't do what we needed to do. So that's basically why we did this. But one of the first problems that we ran into is the whole UDP thing. Just to summarize, when you're doing UDP scanning traditionally, you're sending a UDP probe with a blank datagram and you're hoping that the machine on the other side will send you an ICMP packet. So if the ports close, you'll know. And you basically, the ones that you don't get the message back from, you assume that it's open. The problem is it turns out people are actually using firewalls. 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. That's one of the problems. The other problem is you can't go really fast, even with the machine sitting next to you and there's no filtering going on, because ICMP messages are rate limited. So it's a really slow and ugly process. 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. And then we got this idea, you know, maybe it would be cool if we had an automated way of doing all those probes without having to manage individual tools and all the individual output. But we'll come back to that. 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, the service that we wanted to interact with. So, you know, typically if you're scanning like a slash 8, you have to, you know, 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. And then on the open ports, you can go back and actually do a banner grab. And then, you know, as a third step, you can start interacting with the remote service. You can use, you know, AMAP or manual testing or whatever. But that's, 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. Because it turns out that these networks are getting really big, especially now that we're starting to move into IPv6 stuff. 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. And even if you were playing with set and knock with the text output, it's really overwhelming. Really overwhelming. Okay, so more problems that we have with, you know, any vulnerability scanner that we've played with is that they take their, the probes that they do don't really share the information in a way that makes a lot of sense. So, you know, 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. Who the hell runs Amiga Miami OS? 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. And then because they have an IPS or something actively killing connections when it sees, you know, something bad across the wire, when you send your Apache exploit, it kills the session and, you know, your tool thinks that the DOS attack was successful. So then you come back and find out that, you know, Apache DOS vulnerability was successful. So, you know, that's fine. If you're testing one machine, you can go through the false positives and figure out what's really going on. But imagine doing this times four billion machines. Not really useful. So to be useful in the future, these modules are going to need to share the information more intelligently. So more problems that we're having is with the timing. 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. And, you know, I'll give you the two examples in the open source space. We have, you know, the ScanRan tool that provided a minus B option for bandwidth. But, you know, I probably just haven't played with it enough. But in my experience, anything over like 5K to 10K, I was noticing a lot of packet loss and it also became bursty. And so it didn't really work out. Mostly because of the way that the sleep timer was working and the get time of day counter was working. And then with Nmap, you have normal aggressive insane or things like that. But even in insane mode, it doesn't scale to high speeds. And there's a lot of parallelization going on there that's kind of tricking you into thinking that it's doing more than it is. But the timing of how fast you can go is still greatly affected by the machines that you're probing. To ScanRan's, or Nmap's credit, rather, we actually got Nmap to send out more packets per second than we did to ScanRan. Oh, just some raw numbers real quick. With our tool at this point on a standard copper gigabit card, we're successful at sending over 160,000 packets per second reliably. And we're working with some FPGA people to get that in the 500,000 to million packet per second range. But we're still working on that. That's pie in the sky at this point. But from an average laptop, you can expect anywhere from 17,000 to 70,000 packets per second being pretty reliable to send. But you're still going to want to break it up into different processes and I'll show you why. Some more mindset. Okay, so now we've told you about some problems. What are we going to do to solve these problems? Well, from the get-go, we were designing this with scalability in mind. I talked about efficient use of resources and I'm going to give you a bus analogy. 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. But in the example, they had 100 kids on the left and 100 kids on the right and they had like three small sports cars ferreting people from one site to another site. They gave them like a 20-minute head start and then they had the other 100 kids all jump a one bus and just go. Let me break it down technically now. When you use an individual machine, there's only so fast that you can reliably send and receive packets. So even if you could get in-map or scan-ran to go at 70,000 packets per second, you're not going to have any room left to receive messages. And so you're going to have to throw 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. So that's not going to be an efficient use of even a single machine, 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. So it's not the same as just going faster. 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. 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 at 8,000 packets per second if they have that stupid scan protection thing on. By the way, funny, if any Juniper people are listening, I don't get that protection that completely dices your CPU is... Well, I don't understand that at all. Anyhow, moving on. Okay, accuracy. If you're collecting a lot of information and it's a lot of invalid information, then you're wasting your time. This is my problem with those log aggregation systems where you have the garbage-in-garbage-out model. If you can't trust the information, it's kind of worthless. One of the problems that we have with a lot of tools is they try to be smarter than is programmically possible. Basically, I think tools should introduce stimulus and record response to let the humans analyze. 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. Flexibility. 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 ICMP and pretty much anything else that you can do over IP. And then, depending on which contracts happen, we're also going to support a lot of other protocols. 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. And then security. It should go without saying, but it doesn't really. 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. And we also provide a sample security policy for use with SD Linux. And yeah, that was at least in the design phase when we considered that. We don't actually have the entire protection profile implemented, but we designed it so that we could when we actually release one. 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. Cool. All right. Yeah, so what does it do? 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. But currently, it can do TCP and UDP port scanning. It can do stateless banner grabbing active remote OS application, blah, blah, blah. It can do stuff. 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. So let's say that you're trying to find DNS servers. Instead of just sending a blank datagram to UDP port 53, we support a number of different payloads out of the default config file. One of them can ask it for local hosts. One of them can do a chaos, you know, if you're talking about a buying server and you're trying to find what version it is. 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. 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. So it can stuff the IP that it's talking to in there on the fly. But any other thing that you need to calculate right before creating the packet that also works. 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. And so you're going to find situations where every single port on every single IP on the remote network come back as open. And you need to be able to send protocol-specific payloads so you can figure out which ones are tricking you. 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, then you can make it so that they are not easily fingerprintable. So not only is the knob sled metamorphic, but the encoder itself is as well. And so basically there's nothing to write a signature for at this point. We'll see. Okay, and then we also can log to PCAP files and everything we do. And I just 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. Okay, so now I'm going to pass the mic over to Jack. All right, how are we doing, everyone? Are we falling asleep yet? I guess not. Okay, well, there's three processes. I guess it's pretty obvious what they do. Hopefully we're going to talk about them. Hopefully we're going to actually leave some time for some demos that we want to do. 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. So in other words, if we used MD5 and then locked off part of it, that would be one way. So we can't do that because we actually need to do TCP connections. The problem is that we can actually have the sequence number send back a question to the master thread to figure out if that's correct or not. So we actually have to do that with a trivial algorithm. Anyway, and then the scatter connect is we basically send out the send packets, and then we gather on the send acts that we get back and act the connection and actually do whatever it is that the scanners can figure to do. Well, this is actually kind of long and drawn out. What do I have, like, 20 minutes left? Half hour? Okay. Well, I'll go through this. It's actually 30 steps to a symbol send scan. So basically, obviously, the user would invoke the scanner from the command line. 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. But if you get sick of typing and there's a lot of errors and options over and over, you just put them in there. Anyways, the master process actually opens up binary modules through whatever facilities on the system. We actually use the LTDL interface now, so it's a bit more portable, and we actually have autocomf, too, which is pretty ugly. Anyways, the master process figures out whether or not you want it to run in a clustered mode, which is a command line argument, anyways. This is actually for a local scan, so we're just assuming that the master thread is actually going to fork children. And then it actually records some information about them, and it actually uses the IPC ghost through a Unix domain socket, so it's actually a little bit faster than it used to be. And then it actually uses signals to synchronize, which I believe is actually causing us problems portability-wise, 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, so we might actually have to change that a bit, anyways. And then, actually, the important part is 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. If we're in cluster mode, alls we know is an IP address and a port, and we don't know if it's going to send or listen. So we actually... That's an important piece right there. You don't have to have 16 machines to port scan one machine. You can do it all from one machine. You can't scale if you need to. Right. Okay. Anyways, they connect up and send some information. 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. So actually, during that handshake, it sends the information back. Anyways. And then everyone syncs up with a ready message. And then the master actually does something called stirring, which actually would be doing the work unit allocation. And we actually have some stuff to do that, but it's kind of specific to us. 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 like 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. Okay. Anyways. Right. 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. So hopefully, or if it's a batch sender anyways, we don't want to interrupt him. We don't want him to have to pull the IPC channel because it slows him down. Okay. And then the master just goes into a loop and when the sender finishes, it sends a work done, and then we actually check to see if it has more work, and if not, it just goes into a time-out state, but all, meanwhile, any important things that are happening, such as TCP connections, it'll actually respond to those wallets in its time-out state or actually throughout the entire scan. And then actually the master tells the sender and listener to quit and then the scan's done. Right. Okay. 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 a remote host and port, but we don't. So we actually don't have that model. It's completely incompatible. 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. Anyways, right. Okay. One of the important things is a lot of stacks will 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. A good example is if we scan a network that actually syn-acts 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. And our hash table will basically either collide to death or it'll have a bunch of link lists instead of being a hash table, so that's obviously not what we want. We actually have to pick a data structure that responds better to unpredictable things like that, like a binary tree. Anyways. So, right. 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. So, obviously, we can't do that. And even though generally we won't fill the table, we don't really know what's going to happen. So, that's right. Anyways, even if we did have a hash table that was big enough, and this is just obviously for IP version 4, it would be quite a bit of RAM, actually, just to store the connection entries, not even the data. So, that's obviously not very realistic. It's just for the keys, anyway. Yeah, and, right, like I said, the reason why that's important is because as time goes on, we see more and more devices to compensate for, like, 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, or DDoS protection, or some obfuscated thing that people do to try and improve security, which I'm sure that works real well. Anyway. Yeah, so one of the design goals is we need to be able to withstand this sort of network because we're testing them. Anyway. Okay, yeah, and, right, I already said this, we use a red-black tree. One of the possible improvements that we're thinking of doing is actually most of the time that's probably an unnecessary data structure, we could probably use just a hash table and have constant time. So actually what we want to do is actually switch on the fly. 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 most frequently used cash in front of that. I think it says it in here anyway. Not most recently used, by the way, because that would be a lot of connections closing. We actually need the top talkers, so you actually want it frequent, not recent. Okay. Anyway, here's some numbers about why we chose the algorithms that we did. And the point was, we're just trying to prove that our measurements are somewhat valid, we actually inline some assembly in here, you can see it here, or we actually read the timestamp counter on a Pentium CPU, and then we're actually going to overload our table and see what the performance numbers look like. And these numbers actually indicate clock ticks, and you can see here with the various load factors that our chained hash table turns quickly into a bunch of link lists and our red-black tree does not, which should not be much of a surprise anyways. 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, I'm not really sure, but I figured at least that after a load of maybe four that it would start dropping off, but it actually took somewhere around 30 for the performance to just go really badly. So, right, I just, actually, I talked about that before, whoops. Right, but yeah, reset acts, obviously, we don't want to cache, and those are always going to be the most recent. So if we're going to do anything to improve the performance, we can't do that. We actually have to calculate how often certain connections are being used and cache those instead. Right. Okay, so here's some examples from the payload configuration stuff. It's just ASCII text. But we try to make it so that you could copy and paste stuff from like C and put it into the configuration file. But anyway, here's some example stuff. Obviously, UDP is a UDP payload. If you don't get that, then I guess this is not going to make any sense. And then the destination port is actually next, and then the source port being negative one is just a wild card to say whatever. And then one is interesting, that's a payload group. One of the things that you can do is you can chain include files together or configuration files together. So you can actually have a bunch of different things that are meant for different sorts of environments. 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. And then you can just use the minus big G and then the numeric option for that payload group to kind of make that a little bit easier to do. And actually, we have now TCP payloads, which we didn't have before. And it's not still a real socket. It's kind of a trigger response mechanism, but we try and do some TCP stuff. But it turns out it's real hard because we actually emulate the operating system we're appearing to come from. So our stat code is non-trivial, unfortunately. But for right now, you can definitely do this sort of thing and test for example open relays. Anyway, and here's some screenshots. Can you guys even see what that says? No. I'm going to explain it. This is a module written in C that's actually a HTTP module. And it just does a head request. And it's probably like, I don't know, what is it, 47 lines apparently. But that's what it looks like. Okay, this is actually running a, I don't know, was this, yeah, this was actually a cluster that was connect scanning against yahoo.com on port 80. Yeah, and you can see that at the end here it's got some TCP statistics, which are interesting, but for each host you can actually see a banner. Now that's probably not terribly exciting. Here's probably some better contrast for you so you can understand why we did some of the things that we did. This is actually a screenshot of scanning a website. And it actually comes back and just says that those things are open. But we, and it took eight seconds or something too. But we can actually do the same thing and finish it in four seconds. I guess this really isn't erased. But the idea is, is if you see here you can see like five open ports coming back which is identical to what we saw before. But during the actual SIN scan we actually did the connection and grabbed the banner without actually initiating another connection. And we actually can tell what port really is open at high rates. Okay. Here we go. I can do these live, actually. We have internet. Would you rather see live demos? Because these things are kind of hard to read. Let's do some live stuff. Hang on. So what you see here is this first screen. Location is Casio 3. That's our master thread. Four is our... What is that? That is the listener. It's listening on the IP address that we're going to be sending from. This one's number five. This is actually the sender. So just to see what that is. I'm just making sure that they're live and well. And they appear to be. We're all here. Let me look inside this file real quick. Well, unfortunately, no. Maybe. Yeah. We'll try, but no. All bets are off if everything breaks. It's your fault. I assume that's better. You have to forgive me. We're pretty hard on our laptops and some of our keys are missing. Okay, so this first one, this is my command for me. Minus E, PGSQLDB just says for the output module, go ahead and dump everything to a database. I'm specifying the source IP to come from, although in cluster mode you don't really need to do that. Minus V means a little bit more verbose. 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. The minus Z is where we specify our drones. Right now, IPC channel is not protected. 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. I would have to recommend IPsec for that. Right. Actually tested that, it works pretty well. Minus big L5 is how long to wait after the batch sending is done. Minus little r9000 means we're going to send it at around 9000 packets per second. We actually go a little bit lower than whatever you specify, but we want to exceed 9000 packets per second. The 66.0.0.0 slash 16 just means go to that CIDR block and do 161 for the port, the desk port. Minus MU is UDP mode, and then minus big I is for patient people like me so you can see the data right away. Right. Of course you don't actually want to use minus big I to scan that matters because it's going to block on the master thread to write to the terminal which is fairly silly. And it's not doing what I want so I'm confused. It's the font man. There you go. Okay. So now these are some SNMP public community string version 1 machines that are responding. As you see we're doing a slash 16 network and we're done sending and we're just waiting the 5 second time out and then it's going to process the results and it will spit it back here pretty soon. 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 XOR. It's pretty ugly actually. We're actually trying to figure out a better algorithm that will favor randomizing more significant beds first but I actually haven't had time to get around to that just kind of XORs the random word. 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. 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 live value of the packet that's coming back to you so you can quickly as you're looking through it you can spot Windows Unix versus routing infrastructure 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 had some really cool fireworks at the end so more demo this one is SNTP 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 and we are using the SNTP port 25 we're absolutely connecting to them on port 25 and sending enough of a payload to elicit well basically what I did is I said coming from an e-mail address that I control sending to another e-mail 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 e-mail that I sent but then either way I still get the banner that we just talked to so if nothing else I know I now have version information in my database so I can search through and say show me all the send mail boxes 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 so some of the TCP connections will actually kind of fail it makes for a better demo but you wouldn't do that in production so 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 okay so that was a pretty simple get request here that was a really small range let's look at that that's just a slash 30 that's yahoo with a slash 30 so piece of cake right okay see what else we had here oh I wanted to show you what was in the slide sorry this is end map with port 78 through 82 against dietsecurity.com all ports come back open which is what we expect because we have a stupid device in the middle that protects us from DDoS but here's with the unicorn scan where we can actually numerate what the protocol behind it looks like 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 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 included through a handshake for you it's pretty easy at this point where you can actually it's kind of like the UDP situation all over again in the UDP again now we're sending real protocol payloads as opposed to just counting on ICP messages but now in TCP land we're actually sending real protocol information so we can get away from these devices that just synac everything now I think this is yeah this is just showing that we can do multiple payloads on one like 50 or so different different payloads we've got some DNS servers we've got some SNMP servers court 2367 don't know what that is 137 yeah all these are coming back to us now and I guess this is just showing off you know what it looks like to do multiple payloads so that was the easy stuff now comes the tricky part so hang on 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 anyway what we do is we do basically a TCP connect scan and on port 80 and there's actually a CGI script that has a really dumb coding error in it we actually had some other stuff that we're going to do but political climate kind of got ugly so yeah we were going to release some fun stuff but unfortunately nobody wants to hear that sort of thing these days so we actually just reuse some other stuff we had but basically it does a three-way handshake and it actually generates the XOR encoder on the fly which is metamorphic and it actually does a two-stage exploit one of the problems that I had though was that I didn't have enough time to write the two-stage net BSD assembly so I cheated and used someone else's stuff and it doesn't work so that just goes to show me okay so right we generate a metamorphic first stage and we send the payload what we're supposed to want to do here is a patchy hands all the CGI scripts are writable file the script are on two that's the error logs so the first thing that we do in our shellcode is we truncate that 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 or the process that we've just compromised and we actually just send back a 32-bit word saying what predefined constant that was so 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 memap and opens up an anonymous memory region it affix address and it loads hacked binary into that area and jumps to the beginning of the file which then 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 so but the important point is that the second stage is written and see it's similar to the impurity stuff actually anyway and then we transfer control to the second stage code by jumping to the elf or entry point yeah so this is the part where I do it and it doesn't break okay this is the netBSD box okay as you can see this shellcode doesn't work so the only thing we can do is just look at port 4444 this is the second stage server and then we actually have two of these clients one of them actually uses end curses so it opens up new windows every time you get a shell it's kind of neat but we're having some terminal issues and we can't figure out end curses it's kind of above us so we don't have that yet what he's going to show you is the t-speed dump so you can see that it really is working and we're being told to hurry up so you've got like five seconds okay so here it goes hopefully it won't crash huh okay so we first have to grab an IP address that's not attached to the kernel as you can see some stuff went by here so connected to port 80 it sent our payload yeah so you can see here that the second stage shellcode server got it connected back it sent back the word that said it was this particular one was linux x86 the important part about that demo though is that after it got it connected to two different hosts and after it got the syn act back it did operating system detection and it sent a platform specific exploit to it on the fly it knew how to generate a platform specific exploit on the fly so that was actually pretty cool unfortunately we don't have time to explain in more detail but if you're interested come find us and you can actually watch DVDs and ASCII which was the entire point of doing that