 How's everyone here enjoying DEF CON 11? Fucking A! See this is DEF CON, this is not Black Hat, so I can say fucking A. Alright, so I'm here to fuck with your heads. That's the job. Worked for a via now. They don't give a fuck. I'm still here to fuck with your heads. There. So what are we here to talk about? Peace through superior firepower. That is my philosophy of security. History. Last year I came out here, talked about Black Ops at TCPIP. This is sort of the sequel talk. This is me saying great. Found lots and lots of cool little primitives. Let's go ahead and make some applied services and let's see what the result is of all the research from last year. It's kind of fun. We didn't even have the collection of tools that implemented everything last year. We didn't have this Paqueto Kiwetsu. See I have to pronounce this correctly because if I don't every time this very friendly Japanese person walks up and says it's not Kiwetsu. So basically we had a collection of tools, really fast port scanner, implementations of NAT, implementations of made network access a lot easier, bunch of toys. So the goal is to bring new tools to the table to keep with the primary advantage of being a defender. Which is you and of course the irony being it's off the screen. But you don't need to be stealthy. You don't. It's really funny. Latest 2600 actually mentioned scanrand. And it says oh yeah I showed up on this network and I like scanned it stealthily with scanrand. This is code that like spews packets at tens of thousands per second. This not equal stealth. Just so you all know. So black hat. Well the black hat guys actually went ahead and they are the reason the code's out. So that link should work. It could work. It don't work. Because that entire piece of the net is dead right now. Sorry you can blame someone for the fact that you don't get a live demo. Or the slides immediately or the code immediately. But I'm sure if you harass me enough after this I'll give it to you on CD or USB or something. But the big thing is the code actually exists. As opposed to last year where it's like I'll go write a net later. No no now the code actually exists. So flipping the order around. We're going to start at the top of the stack. We're going to talk about a hack that I discovered I don't know two and a half years ago. And I've been keeping it silent because I kind of felt they were going to patch it right after I got it out. So I've been playing with this myself for a while and this sucks. This really doesn't need the live demo for you guys to see it. It turns out ActiveX you can use it for more than deploying spyware. Gator is not the only thing that you can do with ActiveX. You can actually deploy anything. Any piece of code at all. So I've got this great history. I'll go around go to these talks and I'll find an internet kiosk. And I'm like I'm not using this web browser stuff. I want SSH. And usually at this point I go ahead and I do my live demo and go to a web page and what pops up an SSH client. How did I do that? How does this work? Well it turns out normally ActiveX applications have to be specifically compiled to be oh this is for a web page. This is an OCX. This has been specially done. It turns out none of it's necessary. You just sort of put in an executable and it just works. And OCXes have these things called GUIDs. They're signatures that say ah yes this is its globally unique identifier. Yeah IE doesn't check it. They don't care. That's it. Now you might think now damn this must be very hard to make an executable work. You have to sign it. It needs to be signed. The signature doesn't need to be anything. You can't generate in about two lines of code. But you need to sign it. Dan how am I going to do this? I know scary ten character commands. Make your cert. Convert it to an SPC. Sign it. And then you have an object. And the object instead of food out OCX or food out AX or whatever. Food out of EXT. And that class ID doesn't matter. It just needs to be some class ID. Now this is interesting. But it's not cool. It's not awesome. Why? Because you could just sort of take an executable file and make it the href on a web link and it would just sort of work. IE says the user that's a nice executable should I open it. I do this all the time for putty. So this is just sort of a stunt to make it an object. Now where it gets cool. You notice sometimes windows executables are well they're just not not complete by themselves. They need some support files. Some DLLs. Some bitmaps and what not. Wouldn't it be nice if instead of having to run this really painful install procedure you just went to a web page and everything just auto unpacked and there you were. No problem boss. You can also sign cab files. And you make your object a cab file and you sign it and in the cab you put all your stuff. Now you may be familiar with cabs. Also seen in windows setup whenever it builds itself. It builds itself from cabs. And so you put a stupid little INF file inside. And the INF file is there so the application knows how to do a setup. How to build itself. Well you basically say well my installer is just like the command that I want this thing to run. You don't install. You just run it from the setup directory. Now what's great is not only do you run it from the setup directory but after you're done it goes ahead and clears itself off. Usually. So I know it's really hard. You make an INF file that has that and there's going to be any INF file name or work. And then you generate the cab using the command called cabbark. That's it. All you do is you take your cab instead of foo.exe's foo.cab. Now any windows application you want right off the web page. That's how it works. And I'd show you this great demo. I mean I've got this demo. You click a link and oh look packet sniffer. You click a link. Oh look at stage client. You click a link. Oh look I can push a person down the stairs. No, no I'm serious. This is a great game called porous door vault. Came out at assembly 02 last year. Basically you push a guy down the stairs. And that's how you say screw you all you flash applications that think you're so cool. So that's the high level we are going to screw with stuff talk. Now we go ahead and we get into what's all good. The TCP IP stuff. So how many people here were here at my talk last year? Got some loyalty going on. Thanks guys. So last year I came out here with a 12 pack of coronas. And by the time I got off stage there were none left. I'm sorry I worked for a company. I can't do that again. I really wish there was some way this could still happen. But I can't do it. I can have nothing to do with this guys. However I will be very happy with people in the audience who happen to mess with my head. So here's the deal guys. This is not a BS thing. You are here to fuck with my head like I'm here to fuck with yours. Write notes, take notes, like Fizz here last year who I unfortunately totally forgot to give props to. Been bugging me all year. So if I am happy good things may occur. Welcome to DEF CON. So what are we talking about? Well what pisses me off? Well pisses me off is trying to get an IP address when there's no DHCP server to say here you go Dan. Go have one, have fun. So I started a little research. I'm like how do we go ahead and we fix this problem? Well what's the classic approach? Well ARP goes ahead and it spews out all this traffic looking for IP to MAC address translations. Now let me go ahead and take a second for the people in the audience who don't know. I don't know the absolute precise mechanism of ARP. The way Ethernet works it's a little like taking a taxi. If you're going somewhere in town you're going to take a taxi. You're going to use local transport. But if you're traveling 3,000 miles to some random conference, well you're still going to take a taxi. Because you still need to get wherever you are and ain't where you want to be. But you're going to take a taxi to the airport. Now this is very much how Ethernet works. In Ethernet you look okay am I going somewhere on my network? If so I tell the taxi driver hey you know let's go to this address in wherever we are. And as is anything anytime you want to go to a destination you want to go to a store. You go to Yahoo you get the address. You get the local address. That's what ARP does. It gets the local address. But let's say you want to go too far to go by taxi. Then you go to the airport. You take the address of the airport. Your destination is still way far away. But your address that you're taking the taxi to is the airport. Now let's talk about some new techniques. Well router detection. Turns out you can bounce packets still talking locally. You can bounce packets off of routers. That's how you decide to find out that they are routers. One of the things you need to do when you're on a network is you need to find out well what's a router. So you can look at all the MAC addresses that are out there. And you just basically send them traffic. And you send them traffic in a way such that you see hey I need you to send this local packet ideally to me. And you see if you get something back. It's the basic equivalent of going to the airport and picking up another taxi and going somewhere else local in town. That's how you know it's an airport because it's very easy to pick up taxis there. So the first new thing is you can send a packet to a Cisco on your LAN and you can detect that it's a router because if you basically back address to yourself, in other words you take an IP in its addressable range like you basically say I'm still coming to the same city, it'll go ahead and it'll send traffic back to you. Now it turns out you need to go ahead and when you're talking to the router and doing this spoofed local transaction, you need to actually be telling the router you're coming to somewhere local. So you can actually figure out the ranges within which the router will route locally on your interface based off of what is the range of acceptable IPs. So you try a 10.0, a 10.1, 10.2, you see what is the range. You do what's called a binary search. It's relatively straightforward. It works really quickly. Now here's where it gets really interesting. This is whatever. What if all the IP addresses are taken? What if you just don't have any more? And this is not a theoretical issue. When I was at Black Hat I'm like, can I go ahead and have an IP? I've got some hacking to do. And she's like, Dan, I'm sorry. All the exhibitors have taken the IPs. I'm like, that sucks. Check this out. How do we normally, normally how do we get new IP addresses? Well, we use NAT. NAT means, you know, the NAT is only respecting one IP address. Usually the IP address that you're getting from your DSL provider or something. Usually. I don't do things usually. So what this basically means, if you send a packet from this magic IP, packets will be returned to this magic IP. Now, problem two. Multiple hosts need to be networked. You've got one address, you've got multiple hosts. So what NAT does is it takes this one address that the outside world likes, and it uses a different range internally, and then it translates between the two. So we've got here what I just described a problem where the network is out of IP addresses. They're all in use. There are more hosts that want IPs than there are IPs to give. Well, we couldn't use NAT. I mean, there's not even one IP, right? We don't have anything. Anyone here ever heard of an art man in the middle attack? So you just sort of take someone else's IP. And now you've got an IP that the outside world likes. You tell the client you're the router, you're the client, you now control traffic for an externally respected IP address. You NAT off of someone else's IP, guys. So this is relatively straightforward. You've taken someone's IP, and hang on, how am I going to do this? Usually I do this with a couple of hands. So, let me do this. What's up? Can a goon go ahead and get this guy a mic? What if the router doesn't support gratuitous art? Ah. A, surprisingly rare. B, you go ahead and you wait, and sooner or later they will update their cache. And when you try it, basically you're stuck in a delay mode. Then you basically go ahead and try to find a silent node that is still out there, and you convince the router, because at this point it's expired from his cache. At this point you go ahead and you feed him. So you might say, Dan, you know, how come you're a heck of a lot, and you beat the legitimate host? Well, because I use raw packets, and I'm not messing around with kernels, and I write really fast code. But you're absolutely right. If you have a router that is not respecting gratuitous ARPs and has a very small window in which it's willing to accept ARP cache updates, then you're not in a good place. All right, so basically what happens, you're made in the middle against an existing IP. So now you are passing someone else's traffic. Legitimately. Packet goes from the client to the router. Packet goes from the router. You manually move it back to the client. But there's another possibility. In this second magic network of yours, you are injecting traffic into this other person's IP. And the traffic goes out. Traffic comes back. You say, hey, wait a second. Do I recognize this? Does this correspond to a packet from an outgoing session that I went ahead and initiated and not the legitimate client? Well, then I'm going to go ahead and I'm going to nat it back where it was supposed to be. And if it's not something I recognize, that must be a packet to the legitimate host. So basically, you get to splice in. Now you might say, Dan, this is a pretty black hat for you. You usually just mess with stuff. You don't do anything that's just for attacks. Well, the day I do something that's just for attacks is the day I'm not very creative. Because it turns out this is a great, great way to migrate a server from one machine to another. Because think about this for a second. You can go ahead. You start up a second server. And it handles all new sessions. The old sessions, you keep moving back to the old host. And since you're keeping track of all the sessions you're moving, you know the moment the old host has no one else listening. So this goes ahead and lets you do a graceful migration. It lets you do a phased migration. It links in with change control and change management. These are all kind of really cool things. And if you take the network down, I'm going to kick your ass world. So, wait, wait, get someone the mic. Ah, very, very little. I mean, very, very little. The code I'm doing, I cannot make it get past 0.5% CPU on a really weak processor. It turns out that is really, really low CPU. That's why idiot boxes can do it. So don't even worry about load. It does get a little bit questionable if you are starting to get into the thousands, tens of thousands, hundreds of thousands of sessions model. Then you actually want to go ahead and you don't use some random proof of concept. You use a dedicated load balancer box. All right. So, more tricks. Oh, yeah. So this little word of warning. This is the kind of thing that people have been discovering for the last three or four months for the past 10 years. It turns out when there's a scan, RAND scan, or there's a big port flood, or scanning flood, a router has to go ahead and it orbs. It says, okay, what's the local address for all of these IP addresses? And some of them aren't there. So these requests are broadcast. When you receive an incoming session, or incoming scan, not only do you see the scan, you also see all these broadcasts. So even on a switch network, your paranoia level can be increased because, oh, wait a second. Not only am I getting flooded, but I see evidence everyone around me is getting flooded as well. It's an additional thing we can do for paranoia. I'm serious. It's rediscovered every three or four months. I think I'm the latest guy since Mr. P... You know, the P-CAP team. Linkat, neat little fun toy. So, you know, packet coding is great. Packet coding is wonderful. I'm actually working my... I'm working really hard to make it easier. Working on LibPaketo to make it so you can just have a nice unified interface for the network. You don't need to go through the misery that I did. You know, I code so you don't have to. All that stuff. But that being said, at the end of the day, some of you just do not want to muck around with C. You do not want to muck around with my language of toys, my library of toys and whatnot. But you know what? I think anybody who's anyone who's even done any programming can handle moving around raw text. That's it. Like, raise your hand if you've ever used copy and paste in a clipboard. I'm here to support you. So, let's talk about some fun stuff we can do with Linkat. First of all, we can run the net through strings. Strings is a very simple tool. It basically says, hey, does this look like something a human being could read? Oh, it is. Okay, I'll go ahead and I'll dump it to screen. So, it trashes all the headers. But you actually get to see every single type of packet that's going on the network that's human readable. Unfortunately, the text on screen is not human readable because it's really tiny. Damn. But basically what you're seeing there is there's a CDP packet. There's a C2900XL on that network. Here's a web request to my website and, you know, some other stuff, PHP, the Cisco identifying its interface and so on. Turns out you don't even need Linkat to do this. You run tcpdump-w and run dash saying go ahead and spit the output out to, come on, out to the standard outs. The dash S2000 says give me the entire packet and then you pipe that into strings. And what do you see? Again, you see the raw packet data run through strings. And so we see some UPNP traffic, some SSH traffic and that thing down there, E-J-E-D-E-S-C-A's. Yeah, that's how IBM decided it would be a good idea to encode the name B-S-D. Yeah, so Samba SMB, the spec was basically written in about 1984 by some very, very strange IBM engineers. I someday must buy them a drink. There's some strange folk. So, ping over copy and paste. This is me supporting you guys. So I go ahead and I go up there and I go ahead and I ping news.com. What happens out that Linkat window? I see and it's in the blue text. Those are the bytes that contain a ping. And you'll see at the end, if you're really, really close to the string, 3-0, 3-1, 3-2, 3-3, 3-4, 3-5, it's basically a stock little ICMP header. Now I go ahead and so when I do the ping, the blue thing is what was sent. The green is the response from the internet, from news.com. And as you see at the top, there's an actual response. Now we go ahead and we copy that. Now we go ahead and we put Linkat in, not only do we receive packets, we also send them. We take that same green string of bytes and we paste it. That's it. And it shows up on the network in blue. And in green is the reply. Clippy just forged a ping. Alright, so let's move on to Scanran, the toy that everyone loves. Scanran, what is it? I'm not here to repeat the talk last year. Don't worry. I'm a little more creative than that. Not much, but a little. Goon, can we get a mic over here? I forget. I'm probably closer. It's a stateless TCP port scanner that uses the concept of TCP SIN cookies. Man's got it. And you don't. One of the cooler things that I didn't really talk about that much last year is Scanran isn't just a really fast port scanner. It happens to be able to use the TTL value to estimate how far a packet is traveled. Now this hasn't been done before. It's notably POF. The passive OS fingerprinter has a module that does this. But I go ahead and I'm starting to point out, we can go ahead and we can use TTLs. Let me give you a little bit of background. A TTL is a value that is decremented every time a packet hops once. Oh, by the way, what time do I have to finish this talk? I happen to need to know that. When do I have till? 30 minutes left? Okay. Zoom. So basically your TTL value will start at 32, 64, 128 or 255. Why? No other reason but programmers like powers of two. So the TTL is decremented every time a packet goes over a router. So if you get a packet with a TTL of 60, it was decremented four times. Not necessarily there are evil people like Fizz here who might fuck with the Annette. But in general, if you receive a packet with a TTL of 50, it went 14 hops. If you receive a packet that has a TTL of 15, it went 17 hops. Yeah. So you wonder why when you ping a host it shows you the TTL because this was realized 10, 15 years ago. The only thing is you can actually apply it to arbitrary traffic. If anyone here is working on P2P, please go ahead. Use the TTLs on the incoming traffic to cry go ahead and shrink the maximum number of hops that your virtual network that you've overlaid goes ahead and uses because you're connected and can tell it like 40 or 50 machines. Guess what, guys? You can go ahead and look at the TTLs and figure out which ones are close on the network and which ones are far away. And will it be a perfect optimization? No, but it'll be a heck of a lot better. So some returns from ScanRound. One, we've got email hijacking. This was at Black Hatcom. And I'm testing ScanRound making sure I'm not about to look like an idiot. And I'm like, oh, okay, so I see, you know, it's 19 hops away for my web server, 19 hops away for my SSL server. But somehow my mail server has teleported to four hops away. Not the rest of my machine, just my mail process. Yeah, so the hotel was hijacking all our outgoing email. Busted. This is one of the problems with hijacking, guys. You go ahead and you screw with the TTL it's not straightforward to figure out what it's supposed to be. So this is an opportunity for someone to correct me, by the way. So we went ahead and we detected that every single all traffic to port 25 anywhere on the internet was being routed through this hotel server. This lasted about five or ten minutes after I discovered it because I mentioned it to the wrong person. So that's one thing you can do with ScanRound. Look for differences in the TTLs when you do your scans. Another thing is we can go ahead, look at this thing. It's hard to see, but basically we have three different situations here. We have up ports that are 11 hops away. We have down ports that are 12 hops away. We have down ports that are 22 hops away. What's going on here? Well, it turns out that the PICS firewall, when it blocks a packet, the packet decrements all the way to the PICS. And then the PICS looks at it and says, I'm supposed to block it. And it flips the addresses around, it flips the ports around, it sets the response to a reset act, and it sends it back out. Now note, I did not say it sets the TTL back up to 255 or 128 or 64. So what happens is the packet decremented all the way there and it decrements all the way back. That's why a legitimate up is 11 hops away, but somehow a illegitimate down is 22 hops away, because 11 times 2 is 22. That's what I'm here for. This does not work nearly as much as I wish it still did. Unfortunately, the problem with giving talks that a bunch of NAT vendors go to is they get a clue from you. This is why I didn't talk about the active exit for so long. ICMP errors contain a full copy of the IP packet that elicited them. On old NATs, they NAT the IP, but they do not NAT the IP inside of the NAT, inside of the ICMP error. On this NAT here, where it's blue underlined, 17216197 is a private IP. We get two hops out, we get past the net, the ICMP error on the tracer out. Guess what, guys, 21613724206. Don't attack that, guys. Multi-home node detection. This was a dare. This is one of my co-workers saying, I bet you can't do this. That's not possible. So I went ahead, you know, nose bled for a while, and you have a firewalled corporate network. It's not supposed to be receiving port scans from the outside world. So let me ask you something. What happens if you get a port scan from the outside world just show up on your firewall network? It's there. Hello, how are you doing? Here's all these packets from this external NAT. Well, what should happen is it hits all these machines, and the machines reply if the port's up or the port's down, and the replies go ahead and go to go out. Your firewall, right? And your firewall looks at all these SIN acts and reset acts, and it's like, who are you responding to? What is your point here? And it goes ahead and it kicks you out. I mean, it drops the packet. This is not what I'm here to do. Ah, but what if you've got a host on a DSL link that is only going ahead and using the internal network to access internal network IPs? Well, then what it does, it goes ahead and looks at this routing table. It says, oh, I've got a packet destined for the internet. I'm going to send it out of my illicit DSL line. You control the machine on the internet. And what happens is this machine, this packet, this outgoing response doesn't go through the firewall, goes out through the DSL line, shows up on the outside box with your corporate IP address. You've just gone ahead and found a node that was not going, that not have outgoing packets going through the firewall. Kind of cool. And this works, by the way. Someone get a mic over there. This works because ScanRand actually has completely separate scanning and receiving processes. And so you have a sender that's on the inside of your network. You have a receiver that's on a completely different network. But the two are able to communicate. Now, we had a question or comment over here. Now, would that only work for the host that's dual-homed or are you saying that the packets are going on to the internal network and then going back out via the dual-homed host? Any host that is routing, basically any host that does not end up routing through the firewall exit, but actually has its own way out, will when it looks at its route table to see where to send the reply, it's going to send it out towards its illicit default gateway as opposed to the legitimate one. Okay. Now, there's a little issue. What about if they've got a NAT? They've got a Linksys that's before the firewall. So basically they're running their own firewall before the DSL line. Basically they're running their own firewall, but it's a crappy one. It violates policy, but it's not as nasty of a situation. But you still want to try to find it. This is problematic because TCP SINs will listen to SIN Act or a Reset Act. And even though they've got a crappy firewall, they've still got something there. Well, you've got a couple options. One, instead of sending out a bunch of SINs, you send out ping packets. And you hope that these machines go ahead and they send a ping reply out through the Linksys, and the Linksys is dumb enough just to send it out. This happens. Better though, meaning by better, I mean it actually should work, and it's very difficult to patch about 20 minutes after this talk, better, is to try to use some kind of UDP message that goes ahead and elicits an echo, some kind of sending. Basically any kind of UDP service that if I send a packet to it, it sends a reply. SMB can work. This is just simple Windows file sharing. Very widely deployed and whatnot. The only problem is some DSL networks go ahead and they specifically filter this. UDP 161 also can work very, very well, but it's not nearly as widely deployed. It's more deployed than you would think, but it's not nearly as widely deployed. If there are suggestions for things to use, let me know. Wait, what? Hang on. Who's talking? Use 111 if it's Unix. That's Portmapper, right? He's right. You'll go ahead and you'll find all the Unix machines that are multi-hosted, which has the nice little convenient feature of the smartest people will go ahead and be able to set up this multi-homing. Go ahead, go ahead with the mic. You could do 135 in Windows boxes, which you can't turn off unless you're running a local firewall. Ah, that's true. The issue is that the DSL networks are shutting him. Or could you use the ICMP port and reachables for UDP with the firewall pastings? The only problem is an ICMP port and reachable would theoretically be it'd still be linked to the state table. Okay, we've got to keep moving through this. What, how am I doing for time? Okay, we're doing great, guys. Y'all guys, everyone having fun here? Yeah. All right. ScanRAN is really lazy code. It is, especially 111. It's crap. So, yeah, that'll take the wind out of your sails. Now, ScanRAN does not keep track of anything. I mean, it sends a packet, it receives it, it dumps it to the next, dumps it to the standard out, and that's it. This happens to be good enough because even though ScanRAN is dumping it to standard out, we are people and we have minds. And though people keep saying users are dumb and people are dumb, it turns out we're really good at integrating data across multiple lines, across time, across space, and so on. So, basically, we see 10 replies from ScanRAN and we're able to analyze them as a group. Even though ScanRAN, as a program, has an idea that there's any relationship. ScanRAN doesn't know that, you know, the port 25 was four hops away and port 443 was 19 hops away, but as a user, you see it, you integrate the data, and you know something ain't right. Packets don't exist in isolation. There's more data in packets than just one. Let me give you an example. So, in TCP, TCP goes ahead and it does error correction. If a packet is dropped, it'll retry. You know, someone hangs up on a phone, you're like, hello? Hello? Hello? Well, how many times do you say hello? What is the exact delay you use between your hellos? Now works out the same thing, but it's not specified. So, each different operating system will go ahead and when you just shut up in TCP, the other side tries an unspecified amount of time to reestablish the connection. I didn't discover this. This is discovered by Frank Vesit. Vesit, I don't know, French guy, really cool guy. Can we do this with ScanRAN? Well, it turns out that we can, but we need to prevent the kernel from resetting it. But me later, if you want the specifics, just trying to be quick on it. But if you look, we're going ahead and we're allowing the other side to reply as many times as you want. There's no resets going out. First toast, we get a reply at 0.2 seconds, 3.2 seconds and 9.1 seconds. That's a plus three and a plus six. This is a Windows machine. Next toast, plus three and a plus six. That's another Windows machine. Next toast, we got a one at 0.7, we got one at 4.5, we got one at 10.5, 22.7 and 46.7. There's a plus four, a plus six, a plus 12, a plus four, 46 seconds after we sent a send to this host, it's still sending a Sinex. Guys, that's a Linux box. There's nothing in the packet. Nothing special about the packets. This is bits of data that are outside anything in there. We cannot find this out without integrating data across packets. So what's been done? This is all the hype, guess what? I don't want to write a state management engine. I don't want to write yet another database. So ScanRand will not just output SQL. You just pipe it into MySQL, pipe it into Postgres, pipe it into whatever. Write your own stuff to go ahead and parse it out. That's the model that I'm looking at to see us being able to take the data from ScanRand and really make it useful for large scale analysis. Just dumping out SQL, pipe it into the database. It turns out you can even do this over SSH. So you SSH it into a remote host and pipe the data back into your local database. Or the other way around. Yes, I know. There are injection attacks. The patch to get around that's going to happen soon. So I got this strategy for OS fingerprinting. Let's focus on things where code actually exists. But the summary, you go ahead and you send out a batch of packets that go ahead and uniquely identify a host. Maybe it's what Fyodor is using for Nmap or what Ofer is using for Xprobe. Maybe it's the temporal fingerprinting stuff. You go ahead and you send out all the requests. Now you go ahead and you get a bunch of replies, right? There are three possibilities with your replies. A, you've got no reply for a given host at all. B, you've got some replies, but not all of them. Meaning you need to go ahead and do a retry on that host. Or C, you've got all the necessary replies. You send the set of replies into Nmap's algorithm or Xprobe's algorithm or whatnot. What's cool about this? You know how ScanRan lets you scan an entire network for hosts in like four seconds? This will probably let you OS fingerprint them all in about a minute. So, this is the worst joke here. Who's down with TCP? Yeah, you know me. So, let's talk about TCP for a moment. This is so you understand what I'm about to talk about in a bit. TCP creates a reliable communication medium over a somewhat unreliable path. Now errors are fixed at the end points. You can't have errors all the time. If you have errors in every hop, wireless. There's a protocol called AirHook. It's beautiful, it's genius. Go check it out. TCP is stream oriented. It doesn't care how many packets it took to get bytes across. It is totally byte oriented. When you're doing error recovery, it's like, everything up to byte 10,000, 200, wait, 12,345, and that's too many coronas. So, you're on a certain byte, not a certain packet number. Now, instead of expressing these byte offsets directly, they're represented as offsets from some initial value that's randomly generated. Randomly now, because if it's not randomly, there's a bunch of great blind spoofing attacks we're not gonna go into. So, you can think of it like, let's say I'm in and now I'm acknowledging 1,012,345. Do a subtraction G. The last thing I got good from you was the 12,345th byte. Now, this is done among other reasons to prevent TCP spoofing. Someone wants to send you a packet. They have to know where in this 32-bit range that you will last talking. It's a little bit of a window, but we won't go into that. So, you can't do TCP spoofing, right? Well, what if the server sends it to the spoofer intentionally? Let me give you a little story. You are the president of the United States. God bless our souls. Hello to all the feds out there. You guys rule. So, check it out. Lots of people, you're the president and everyone wants to talk to you. And you cannot manage talking to everyone. But don't worry, it's Capitol Hill. You've got no shortage interns out there to handle the public for you. So, basically, you're the president and you receive letters and you pass it off to one of this horde of interns. You do not scale, but an anonymous intern scales just fine. And they go ahead and when they reply, of course they don't say, well, hi, I'm very nice to hear your opinion. Thank you, anonymous intern number 345. No, no, no, they say that the president of the United States, hallelujah. Turns out we can do this with packets as well. Is it possible for a single host to do load balancing across nearly arbitrary network boundaries without any special code on the client? Yeah. Yeah, it turns out we can do load balancing without any kind of care for network boundaries. But basically, client thinks it's talking to a server. Server's actually a redirector. Redirector goes ahead and sends the actual TCP packets, although it works for any IP service. Any IP service. Goes out to the anonymous servers. By some kind of, I'll tell you how that works. And when the servers reply, they spoof the source IP of the redirector. So from the client's perspective, it sent a packet to a host, and the host sends the packet back. Now let's talk about some details here. Again, redirector, upon receiving a packet from a client, changes the IP destination, recalculates the checksums, sends the packet out the appropriate interface. There are two session-based rules. First of all, you have to keep the, all you do has to be consistent by session, meaning, hey, you can use the TCP source port and do a mod based on the number of redirectors you have. You can use the IP source, especially once you get into geocoding. So you look at the database to figure what IP is and what country or what area, and you try to minimize the distance. There's all sorts of methods. There's a stateless. Stateful rules, as you say, you know, I know who's talking where. I know I sent this many hosts over here. You guys got some open slots, I'll send it there. Those are the stateful rules. They're harder to code, so I haven't done that yet. The anonymous server goes ahead. It receives this packet IP destination to it with some source of the legitimate source. And so normal socket code, normal application, squid, shellcast proxy, whatever, it goes ahead and it replies. But the last moment in the, this Linux specific for the moment, last moment IP tables goes in and says, wait, wait, wait, wait. It replies from the anonymous server's IP. Nobody's gonna like it. Just like if the anonymous intern replies from the anonymous intern's name, people are gonna be like, who the hell are you? So it fakes its IP to be that of the redirector. And then the packet goes to the client and the client's all happy. The client can actually notice this because of TTL errors. Now, where does it get you? First of all, global load distribution. Anyone can go ahead and have a server go ahead and spoof something else's IP. Somewhere, someone out there has extra bandwidth that they bought that they're not using. I want to start being able to see this being used to serve our traffic. But check it out. There's more that's happening here because the client, where is it acknowledging to? Is it acknowledging this great nice data is getting to the anonymous server that's doing everything? No, it's saying thank you for the thousand bytes to the redirector. Thank you for 10,000 bytes to the redirector. Thank you, thank you, thank you. The redirector is receiving information on how much data the client's getting. The redirector is receiving dozens of milliseconds updates on how much data it's getting from this anonymous server just by looking at the offset and the acts. This works today, this works now. You are able to measure the amount of traffic going on without even seeing it. And it's not even you're not even being told, oh yeah, let me tell you something. I send, you know, 10,000 bytes to this guy. No, the guy's telling me, hey, this guy just sent me 10,000 bytes. Advanced things you can do which haven't been implemented yet. Theoretically, you can say, you know, that session over here is only getting 5K a second. This mirror sucks. By the way, have you gone raise your hand if you've gone to a site that said, which of these 50 mirrors would you like to download a file from? This, this sucks. Guys, the way it needs to work is you go to one redirector, you download from the redirector and if it says, okay, this is way too slow, it just moves you somewhere else. And it does all the application specific negotiation for you. So you go ahead and you get the byte updated at the exact right point. That's how it should work. So this works for everything. Unfortunately, I have no net, so I can't do the live demo. But if I could do the live demo, I spent my time developing this listening to digitally imported and I was actually bouncing digitally imported off of this server. Excuse me, off the network of around three servers that every time I connected it would come from a different source. Why is it great to do this? Because this means the music you're coding to is coming through your code. So if your code breaks, the music stops and it sucks. So you're really motivated to fix it. Finally, this is the last thing I'm up to. I am so happy to finally get this to work. SSL versus IDS is the eternal conflict. SSL annoys me. Why does it annoy me? Because if your cert goes, oh you're screwed. Oh my god. All the traffic you've ever sent, all your traffic from a year ago exposed. All your traffic a year from now exposed. So one day they come in, they take a cert and you are screwed. This is like the only link-based protocol that has this flaw. There's one of the authors of SSL about this and he's like, Dan, we have 1.5% of the available CPU power back then. You got a point. That being said, SSL does some cool stuff. I respect the people who like it. IDS also annoys me. Hey look, wonder attack! Oh that's nice. Do you just not want to be able to sleep permanently? But that being said, I respect people who like, here's the problem. IDS says I'm going to look on the network and see what's going on to make sure nothing bad gets through. SSL says I'm going to go ahead and encrypt anything that is on the network so that no one else can watch it. You get one, you get the other, you don't get both. Ouch. Now there are certain solutions. You can go ahead and you can transfer the cert and your IDS can do RSA decryption at the seams with X or CPU cycles. New. You can go ahead and you can cut off SSL or at least that your endpoints get plain text. And you know, now you've gone ahead and done all this work to end to end crypto in the last minute. You just switch out of it. And you got to do HTTP rewriting and it's a pain. So, God that's a messy slide. So turns out SSL goes ahead and negotiates a session key. In other words, each individual, you don't go ahead and use RSA for your mass encryption. Use like triple S, use RC4, lately use AES. This is relatively fast. And there's an individual key for each session that is used. Here's an idea. Let's send that key to the IDS and have it work. This isn't just talked about anymore. As of about three days ago, it works. Today, the key is transferred to the IDS over an SSH link. SSL actually asks you what password of the host you would like to link the keys to. Ah. But it gets cooler. Because there's independent keys for each direction. So there's a key from the client to the server and there's a key from the server to the client. You can tell the IDS a key for only a single direction. You're a bank, you don't want the IDS to be able to read traffic from this really sensitive area inside your bank because regulations, but you don't trust traffic from the outside world. How can the IDS go ahead and read the bad traffic but not the trusted one? Give it the key from the client to the server. This works today. It's also not entirely necessary. Guys, HTTP is a sucky protocol overall, but it turns out you can go ahead. It takes everything you've got in your request. It gives you a nice big batch that you toss off to your web application. You take this nice big batch and you say, hey IDS, is this a good thing or a bad thing? If it says it's a good thing, then that's it to your application. Guys, we need mod IDS for Apache. This would not be hard to write. This advantage, this method, by the way, it's so straightforward. It's totally immune to TCB attacks. You can filter out bytes, XL passwords and numbers and whatnot, but it's not as cool. You don't mess with SSL in this really weird way, but it's really straightforward to write. Everyone here is a web developer so, guys, those are my toys. All right. I don't know how much time we've got for questions, but who here's got something? We've got five minutes for questions. Who's got something that'll scare me? This guy over here. I'll mic him. You've talked about Networker Director. Wouldn't you get the problem of when you're sending ARP, you're spoofing ARP packets and sending them to the router, wouldn't the original station respond sometimes with their ARP packets? Wouldn't the ARP conflict be detected by router or by the hosts? Oh. So you're actually referring to the not in the middle case, right? So basically what he's saying is that every once in a while you're going to gratuitously get your legitimate client going ahead and sending out ARPs. ARP man in the middle attacks work. They really do. As long as everybody thinks that everything now the legitimate client's going to go ahead and start sending out ARPs possibly if it's not getting traffic through. So your big thing is make sure the legitimate guy who has the address gets his traffic through, and then he's not going to go ahead and be spitting out too many ARPs gratuitously himself. But it is an issue with any man in the middle attack. Any other questions? Right over there. Hit me. What about egress filtering security professionals saying star topologies are the best thing in the world? This is me saying when you turn on egress filtering you actually do lose some significant functionality. You lose what is effectively a really good way to make load balancing distributed truly distributed. Other questions? Right there. I was thinking about the IP redirection on the server. What am I missing when I'm thinking that would be an ideal way for peer-to-peer people serving up files peer-to-peer to be... You're missing NAT. So many people are behind NAT now and you can't send a packet with a spoofed source IP behind a NAT. That's the problem. If you didn't have all the NATs out there, I mean on the flip side there are a lot of P2P users who aren't behind NATs. And yes, in that situation it's just fantastic. In which case the problem becomes Windows doesn't have nearly the nice way to go ahead and intercept the packet right before it leaves. And if someone here can tell me a good way to do it, a case of this stuff is yours. But I'm not involved with that. Any other questions or thoughts? If not, thank you. Oh wait, one more. This is the last question. In reference to ARP updates how would you deal with static ARP tables? You couldn't. But they're very rare. Even at where people are told please, for the love of God, here's your ARP address. Please, we're telling you, you're going to get spoofed. You're at the black hat briefings. Everybody. Okay, I got one last story to tell you guys. This is last year. This is my favorite event at Anycon. So by the way, what happens is this guy's giving a talk about sniffing email passwords. He goes ahead and at the beginning of the talk he says, here's a shirt. I'm going to be giving this out at the end of the talk. Sniffing email passwords over wireless networks. At the end he says, alright, will Bob Dobbs please come up? I don't remember what his real name was. Bob Dobbs, please come up. The guy comes up, how did you know I was in this talk? Sir, you came to a sniffing email passwords talk and you checked your email without encryption. Thank you.