 Welcome to the annual DEF CON convention. This meeting was held in exciting Las Vegas, Nevada from July 9th through the 11th, 1999. This is video tape number 21. Introduction to TCPIP Exploits. Okay, next up is Pete Shippley. He's an elaborate on what I just talked about. He's going to be talking about TCPIP and its weaknesses. Let's give him a round of applause. Don't leave it. It's not going anywhere. He's not melting. That's good work, Mike. Okay, let's talk about stuff. Let's see. There we go, we're back. Welcome to review a little bit of what Pug has talked about. Then go on and explain the general exploits you're seeing every other day on bug tracks. If you're a security expert, I'm going to bore you to death. This is a newbie track. The purpose of this newbie track is so you don't have to ask stupid questions. We'll answer them for you. What we're basically covering here is what's TCPIP, why do we need it, basically what are ports and sockets, known problems, and these are general attack methods. If you're awake during the last hour, you already know this, what TCPIP is, set of protocols, basically became internet or fun stuff. I'm going to skip over the first several slides, obviously, since it's kind of redundant from Pug's talk. We have basically your... I'm stupid enough to try to call me during my talk. Basically, if you use the internet, you use TCPIP. That's just where your life is. What is IP? It's basically a collection of protocols. They compromise the suite. While you're at the last talk, let me try to skip this stuff. That's the ISO stack. I'm going to raise this up here. You should actually know the ISO stack. I think it's from Bullshit. It reminds me of Senator Laird-Britto. Laird-1 makes you physical. That's your physical. That's your actual wire. Laird-2 is the protocol on the wire to the Ethernet. Laird-3, we're talking about IP. On top of that, it's TCP. Then we jump up to 6, which is probably the application. Now, I want you to keep an eye on this, because as I talk about various exploits, I'm probably going to work from the top down. What I'm going to do is point out, because everybody keeps saying, oh, what we're going to do is we're going to have a very secure program. Well, also, I break the foundation, the transport layer. Well, I'm going to write a secure transport layer. So I break the network layer. Well, we're going to use a better IP authentication. Well, I'll just break your link layer. This is what's happening in security continuously, and that's what I'm going to try to point out in this talk while explaining things. Everybody understands this, right? Good. Now, what nice thing TCP does is provides a connectionless, basically provides reliable connections over a connectionless protocol. As you know from this talk, it basically relies on three-way handshaking. I'm going over this again because it's important that you understand this part. It's ensured both sides agree that, hey, not only are we ready to talk, but we're going to talk. Like, for example, I go, hey, punk, yes, he goes, hey, Pete, we've established a communication. I've called him. He acknowledges my request to him, and we continue communication. That's exactly the three-way handshake is. So we have a client and server. I send a SIN packet. That's basically a SIN equals X. That is acknowledged. So the acknowledgement is a SIN plus one, and it also establishes a sequence. Now, at this point, that second sequence is acknowledged. There's a point down here. Again, you send out this. Now, the sequence in this direction is X, and the sequence in this direction is Y. Now, do you understand that this point is established and somebody has to be enduring the break? Well, how do we have randomized sequences? How do you know which sequence to use? Well, what is the starting sequence? That's the important part. Questions? Interrupt me any time for the question. Okay, with three-way handshakes, basically again, I'm reiterating this, so you understand so you don't get lost in five minutes. That we now all agree that both sides are very strange data and we have fun. Now, how do connections fail? That's actually kind of simple. We are on a client and server. I send a SIN. It sends a reset. Basically it says, no, thanks. Oh, mind you. This is an oversimplified case, but in general, that's hopefully the way it's going to work. Unfortunately, the IP stack is susceptible to tons and tons of, well, possible attacks for the millions-proofs. And that's what the remainder of this talk is about. Are there questions at all? Please just interrupt. If I get ahead of you, just say so. Now, before you go on to attacks, we should talk about what kind of attacks exist. One frustration I see is like, oh, I've got a new exploit. It's now a service attack. One thing in security to classify your attacks. So, in general, I find there's four types. There's disclosure information. That's theft of information. Getting your info file. Getting your credit report. There's destruction of data. Racing your files. Alteration of data. Changing your grades. Well... Disclosure is a tax against confidentiality of data. Stealing it. Exposing things. Reaching quake before it's ready. Password sniffers, e-mail sniffers. Those are all disclosure information. Destruction is wiping. Alteration is basically modification of data. It doesn't have to happen on a disk. It can actually happen on a network. While you're logged in from a client to a server, for example, some might insert data. That's alteration of data. And the most common is denial of service. These really script kiddies think they're hackers because they can just flood your network. No. That is not a break-in. That's denial of service. That's the fourth type. Now, what types of dust attacks exist? Well, we have ping flooding. Then there's modification echo-apply flooding. I'll explain these terms next slide or two. TCP looping. Ping of death. Sync. Fegro flow. I'm going to explain all these talks. I mean, that always exploits to you. Ping flooding is the most simple one. That's when you just send lots and lots and lots of pings. Just run ping-f from the Unix shell. Give it an IP host name. And the machine that you're on sends as many packets as possible to remote site. Effectively, it allows the attacker to possibly inhibit network activity. This is not going to work in your dial-up to my home T1. It will work for my T1 to your dial-up. And those that are here, the OC48, don't take out my T1. It's high bandwidth, it's low bandwidth. There's a friend who works at a large web development company, and they've got several OC48s. It's kind of humorous because people try to flood them out on IRC all the time. It's a waste of time. Okay. And another method is setting ping packets. Basically, he's in any kind of packet. But the ping program comes with the Unix shell. You know, why write code right? You just type ping-f. Well, if you really wanted to flood people out, you wouldn't use ping because routers are going to fail through that. How does it work? Simple. You know, I'm sending back to the Internet, it's flooding your machine. No brainer. To be effective again, I want to reiterate you need greater bandwidth. I reiterate this because I don't know how many kitties in their dial-ups try to flood my home T1. It just doesn't work. One common trick is if you're being flooded a lot, you will modify your firewall to say, for example, to block ICMP echo packets. Well, in that case, the person can start setting reply packets. If that doesn't work, because they could literally start spawning your whole bunch of other, you know, host and reachable packets, just random UDP packets. Now, what do you want me to find? Do you have a problem with bandwidth that you have a small bandwidth that I have a greater bandwidth? Well, how do we abuse this? Well, we could abuse other people's bandwidth. As you know, ping is a simple program. You send out a packet and you get a reply back. Well, it comes back to you because you send it from your address. Here's a situation. There's my little notebook on the bottom. There's a bunch of badly set-up machines on the right and, of course, a nice little victim that I want to take out. Now, smurf attack is simple. I send a single spoofed packet to that network. This is tested to a broadcast address if that was covered, but when you transmit IP addresses, you transmit to a single host and you also transmit to all hosts on the network. If you're dumb enough to leave your gateway open to allow inbound broadcast address, you're going to have problems. And also, not only you have problems, but other people will have problems from you. So when the government starts calling you up and why you're flooding the network, somebody's probably using you as that group of hosts on the right. Now, I send one packet to that group of systems. What do all those hosts do? They apply a lot. Now, again, I iterate one packet. Many packets. This is a classic smurf attack. Now, if I'm saying, so this is where your 14-4 modem can wipe out somebody's large neck connection. Again, flow attacks are easy to do. You should do it by filtering ICMP echo applied packets. The annoying part is you start filtering those. You can't ping people from your site. Other forms. Well, we have UDP echo spoofing. I'll explain this. We don't know what UDP is now. Well, we have echo spoofing. There's a nice little port. There's a whole bunch of little ports called internal services that come with your Unix machines and NT machines. One of which is echo. You tell it to that port and whatever you type gets typed back at you. If you send a UDP packet, it'll transmit the packet back to you. Kind of a ping-like thing, but it's a different layer of service. I don't know why it's there anymore. It's more of a legacy service. If any brings it all, you automatically turn this off. But we can have fun. Like, there's a little NT box over on the right-hand side. They put it, they install all the network services, including UDP echo. So, me being a nice person on the left, I send a UDP packet with a from address and to address of my victim. What does my victim send the reply? Thus? What is that machine busy doing with all of its CPU time? This can go on for quite a while. Eventually, the CPU time maxes out. You drop a packet and it goes away. Another method I can send is, I can use a source address of localhost, which is, again, kind of a unique host that always refers to yourself. And I send local packets. The machine keeps quite busy. Variationally, transmitting to a broadcast address, we get a lot of machines broadcasting at each other and such. But it's kind of simple. There are patched versions of iNetD. That's the demon that spawns most of your internet network services under Unix. There are patched versions that would block these attacks as in, I'm not talking to myself, screw this, ignore it. That type of thing. IPv3 helps unprotected systems. I hope you all have a firewall. Cyber, who flaked out in his early morning talk, will be rescheduled. He's got to drop his PKI talk. He's got to build a firewall on a BSD. That's going to be five o'clock in this room. And if you do attend that talk, ask him where he was this morning. He was out shooting his guns instead of talking to you. So give him lots of help for that. Now, sin flooding. We all read the paper a few years ago. Sin flooding has actually been around for, about 15 years. A couple years ago, we actually released a public program and all of a sudden, all the script kiddies can do it. And all the script kiddies think it's new technology. Read a paper from Security Bureau 10 years ago. It's all talked about. In fact, all of the attacks were talked about 15 years ago. Here we are. Sin flooding allows attacking to deny a system, attacks a purple basis. You can read. Now, the way this simply works, you have my attacker system, not existent legitimate client. It used to be that most inmates at IP can only allow a certain number of starting connections. Now, they can have an infinite amount of current connections with only a small amount of pending connections. So if you're allowed to end pending connections, I can pick somebody and I go, hi. And this person says hi back to me, but I don't respond to that. Third person does it, fourth person does it. I send down connections. And anybody else says hello to him, he won't respond because he's too busy waiting for an answer from me and the other people. You understand? So, I sin flood that system. Now, remember the 3D handshake. It sends all the acts into a black hole, a non-existent system. Now, that victim system is waiting for the acknowledgement to its acts. Are they going to come? We have to time out first. So, since nobody can establish a new connection, a legitimate client cannot connect. Now, if you're logged in the victim system, everything's just fine and handy. Your shell's working and typing away. Your machine's load is nothing, but nobody else can establish any new connections. What's the typical varies per host. It's usually, I'll do it on 45 seconds, Puckus. It's average. It pretty much varies a lot per host. There's a lot of software out there, actually. More advanced firewalls these days will detect this. And in the middle of an attack on a victim system, an intelligent firewall or perhaps certain type of security utilities will start transmitting the resets, causing all the acts to be reset. Destination holds in reachable. It depends on your firewall. Some firewall types, by default, just say host and reach before any packet they reject. Some firewalls don't apply anything. Other firewalls say never can reachable. It really depends on what product or whose security company brought into it. Hopefully, the firewall will reset will actually retransmit the connection. Again, it really depends on the product. I can't say what will happen. In most of my examples here, we're assuming there's no firewall involved. There's no connection. In this mode, active victim systems block takes very little bandwidth. You and your old dial-up, your ricochet modem can take out entire corporations this way. This assumes that you're running a like, you know, old version of Salaris or Salas. Any modern system that basically released in the last year or two is listed to this. Let's run into it. Again, strong filtering helps. Sins sniping. It is a fun one. Everyone will be on a network and will shut people down. Well, this is how you do it. Is that layout again? Is that sin packet again? Now, remember how the three-way handshake you remember how normally a connection fails? Now, you'd assume the reset would come from the person receiving the connection to serve on the right. Instead, I fake the reset. The generic client doesn't know any better. Sin, reset, okay. Port that open. Now, when the act does come along, the generic client sees a sin part of that and says, reset. Both machines did not establish TCP connection and there are no errors in your logs. Actually, if you're running a program, our watch is kind of fun because our watch effectively the spoofed reset came from a wrong MAC address, but that could be fooled also. Yes? Huh? These old machines are on the same physical wire, on the same unswitched dumb hub, and the attacker sniffed the packet and said, oh, here it is, reset. By the sequence number of the reset zero, your sequence number by default is zero unless you've established a sequence. So, in theory, the attacker can stream resets of sequence zero at legitimate client. A connection can never be established. Again, now, the victim system can be selectively blocked. It requires, as I pointed out, local or intermediate network access. In other words, it has to be on one of the physical wires that this packet is traveling over to see the packets going back and forth. And it's pretty hard to detect because you're always spoofing. You can basically spoof your MAC address, spoof your IP address, obviously. It's kind of a bearer track down. Smart hubs help. Buy your Cisco Catalyst. Nice little VPN networks. Spoof protection. I hope a lot. Then, of course, I'd rather buy a nice car than a decent Vio5500. We're a free-loaded Catalyst Vio5500 with 110,000. Yeah. Security is expensive sometimes. Ping of death. We all know about this one. It's really simple. This is commonly implemented. It can be any type of IP packet, but it's commonly implemented as a ping. It implements a bug in layer three. Now, in all protocols, or most packet protocols, this is a concept of a maximum-sized packet. In ping of death, the error was that's 65K. And then I would transmit a ping packet which was fragmented. When you reassembled all the parts of that packet, it was larger than a buffer. So you see the first fragment, you write it to the buffer. You see the second fragment, write it to the buffer. You see the third, write it to the buffer. You see the fourth, over the edge. You overwrite parts to your system of kernel memory. Make you a blue screen of death. This worked on about every machine out there. Oh, wow. Again, this has been known for about a decade. Only really came to public light about a year or two ago. Basic options. If you have a firewall of control of, filter fragmented packets. There's no reason to allow a fragmented packet through your network. You want to say why? Well, why should a packet be fragmented? If you have a healthy network going over a healthy internet it shouldn't happen. The only time fragmentation could possibly happen if you have a large packet network, for example, FDDI, re-transmit it over Ethernet which has smaller packets at which point they're fragmented. But if you configure your network to do that, you should suffer. Again, so just filter fragmented packets. I think on the average, if you're on a website, you can lose up to 10% of... if I connect to you, sometimes it is 2%. As far as I'm concerned, tough. They have a broken network. Now, permutations of this. Teardrop attack. And so we have IP fragment flooding that is micro-fragments overlapping is fun stuff. Overlapping fragments are fun. Effectively, teardrop is a widely available tool. I can download it, root shell. I kind of hate root shell for this because they have umpteen versions of teardrop, yet they don't say what the teardrop attack is. Wouldn't it be nice for those hacker websites out there actually bothered to write even a paragraph to say what it is right off the club here, explain them to you? No, that might take effort. This is mostly almost Linux and NT. Linux and Windows are mostly vulnerable to this. Linux should be upgraded. Perhaps FreeBSD. And if you want FreeBSD, we have free CDs in the conference area. Unlike Linux, FreeBSD is free. How much is red hat? Ejected for prices, actually. And by the way, it wouldn't make any available for free at DEF CON. I'm not going to rank them too much. I'll do that in a bar later. Okay. Again, IP filtering helps. Generally what happens is you have a badly formed fragment. So you have one fragment comes in. You have a badly formed packet that comes in that tries to process the packet. Machine burps. In other words, it wasn't analyzing the fragments as it came in. Maybe the assumption that the offset in the packet was correct. It would, well, inside the packet in a fragment, I kind of skipped out on punks as talking about the option for breakfast. So in case you explained this to you, I'm sorry. But thankfully, in a packet, if you're fragmented, there's an offset reference. Well, if that offset reference doesn't match the content of the packet, your program might be trickling to doing something wrong and blowing up. Another fun thing, this is not in my slides, but one great way it used to be to take out Cisco routers about eight years ago, is an IP of lots of variable options. And the way the header assembles is there's a byte offset to next option. And the way the computer works is take current address, add offset, and process current option. If you set that byte to zero, what does the machine do? Re-process that option until power goes out. On a single-threaded TSPIP stack like Linux, you can really wait for your machine to really just slowly stops. If you're multi-threaded, like any slurs of BSD machine, it's not a problem. It'll just eat up a thread which will eventually die. Again, fragment-fragmenting is another fun one. When fragments come in, as you realize, you need to deal with these things. Sometimes fragments don't show up in order. So you're getting snippets of articles coming in, snippets of packets. You've got to scroll them in memory somewhere until the other part comes up. You connect them together and then pass it on to the application layer. What if I send lots and lots of fragments to your machine? What happens to your RAM space? It fills up with useless garbage. Indeed, really vulnerable to this. Linux and the BSDs are actually really good about this. When they begin to run out of memory, they start just dumping the packets. Because if the packet wasn't properly acknowledged, it would be retransmitted or resent, it's not a problem. But there's a good way of eating up lots of CPU resources and run out of RAM real fast. In other words, micro fragments. Let's make fragments so small, I don't recognize what they are. So if I fragment, now mind you, we had Ethernet, IP, TCP. If you filter it at the TCP layer, it's assumed you could read the entire TCP packet. At least the header part. Or what if I fragment my packet so small, you can't read the header as a full part. Can you still filter? No? What do you do? We probably pass it through. So what you do is use fragment in your packet so small, each one is not identified as a problem. Simple. Yes? Firewall policy of dropping off fragments would help a lot. Certain firewalls actually do reassembly. I believe the Cisco had a firewall that just discontinued. The NT based one. Yeah, Sentry was pretty good because the Sentry actually had a packet, fragment packet policy that would reassemble fragments for passing them on. Actually pretty good. It was a bit memory intensive but it worked. Most other firewalls were simply forward to fragments. The PIX firewalls option is only pass fragments when they come in order. So obviously the micro fragments may not work, actually. I think it just drops those. The overlapping fragments and the fragment flooding would not work because it only allows fragments in order. Mind you, this breaks the Linux because when Linux fragments, it breaks a packet, maybe three parts. It says the last part first and the first part last. So the PIX firewall simply drops the packet because it gets fragments four, then three, then two, then one. When it gets packet four, it goes three, two, one, ditch it because this is a random fragment. I don't know if that's a bug in Linux or a bug in PIX, but well, questions? Okay, other fun things. What more about sniffing? You know how to get your password stolen? Uh-huh. Up-cash poisoning is a fun one. Now mind you, if you want to work my way down that protocol stack. Every time I explain a fix, I'm going to break it again in about five minutes. Now sniffing is a fun one. Don't you have a little number on the bottom? 85. Yeah, 95% of attacks. I love these kids that call themselves hackers because they break into one ISP two passers breaking into another ISP two passwords. What are you actually showing technique? Now sniffing is easy for the person who hasn't figured it out yet. It's simply the intersection of data. It's client sends a server, my notebook sitting on your machine has your password. Anybody use any of these applications or protocols? Come on! Your password has been stolen. Tell them that. Clear text, unencrypted. I'll log in. Clear text, unencrypted. Well, pop. I'm that. Clear text. A-pop is kind of fusing A-pop. Okay, then you're a little bit safer. I can only read your mail. I can't read your password. Uh, HTTP. You know, when your dialogue box pops up, you type your name and password Clear text. Hmm. RPC. Clear text. Simple mail transfer. Clear text. Simple network management. Clear text. RPC. NFS. Clear text. All of which are available to be listened to over your network. You guys secure? Have you used SSH? SSL will be provided encryption. SSL simply means the person who cannot listen to your packets between you and the server. It does not mean a server is secure. Well, my pet pee is like, we're secure. We use SSL. That doesn't mean they're secure. It means that the data getting to them is encrypted. The second it's headed off to their applications is clear text. This again, just name a few. Be aware. Download SSH. Download secure. You know, secure CRT. Use it. If your ICP doesn't support it, tell them to. If they don't, get a new ISP. Best protection? Buy a smart hub. I know. It's kind of expensive, but you got to do it if you're going to be serious. Use SSH. Use Kerberos. That's kind of nice. There's DESchallup. It's not really widely distributed as it should be. Whenever possible, remove Miscous Mode. On my home site, you can't sniff. I've rebuilt all my kernels, and I removed the capability from sniffing from my kernels. I removed my system. People do all the time. You can't sniff. It makes your network a little bit more secure. Well, to rebuild the kernel, it'd be kind of nice, but you got to replace the kernel. But because it's a immutable file, you need to reboot the machine from console and install it. Which is kind of a pain in the ass, because I have to be there, console, to install it. Maybe by cow, I'll have to be there or sneak in the war room and do it for me, but I don't know. Hopefully, but on local etherettes, and I love this. I've told you about all the different ways about TCP IP and how you can fool things and redirect things. Let's go one layer. Let's go to layer two. Ethernet level. Press anybody to impersonate anybody on your local LAN. Hmm. Yeah, I love it. We've got a secure IP coming out. We're doing all the secure stuff with IP. We're encrypting our packets and everything else. Oh, it's too bad. I just blew your foundation away. Bound analysis service is a lot of redirects. How does ARP cache work? Well, you run a network. Every network, if the ether card has, in theory, a unique MAC address and also a lot of unique IP addresses. Hopefully, it's a unique IP address. How do the machines figure out who's who? Well, some called ARPs. So, host 3.4 does a transit. Hey, who's 3.8? That's a broadcast over the local ethernet. That machine applies. Hey, that's me. Oh, field notification. That's a MAC address number. The first several bytes are... You can pretty much tell what kind of host I'm working with here by looking at the first several bytes. I'll leave that to your own figuring out what kind of machine I have at home. And the second set of bytes are the host type. But by just looking at the MAC address, you can tell the hardware type. So, in the case of a break-in, what happens? Here we are with that little transmission. Hey, who is this person? I lie. Where did the IP packets go? Straight down. By the way, Loft will be announcing a product this weekend. If you're interested in this stuff, look for the announcement. So, up-cash browsing by a smart switch, by a smart hub. One more quick thing about this. You don't have to wait for the request. A lot of applications will just take except a packet. If you just get on a network and say, Hi, I'm the new RAC, I'm the new RAC, I'm this manager running addresses. A lot of machines are like, Oh, okay, update the cache, and start sending information here. And, of course, I don't believe in hand-out-things-on-hand-out fixes. Again, mortgage a house by a smart hub or switch. You know? Whatever possible, remove some misgivings from your kernel. That's like a broken record. Our watch is really good. This is a program that a friend of mine wrote. It basically listens to your network and keeps a table of IP addresses to Ethernet addresses. If someone gets, if a new one shows up, it says a notification, Hey, new IP address, or Hey, new MAC address. If somebody uses somebody else's IP address, it goes, Hey, that changed. So, if I plug this my notebook into your network and start trying to take over your network, at least I know about it. It's really good for people running large sites, when people are already having employees bringing new computers in and moving computers around the network. It catches them real fast. On stable networks, in other words, places on being the IP address all the time. Go to your servers, preferably Unix. You can also do some NT, or you figure out where that menu is by yourself. And you can permanently insert into an ARP table. That's the command ARP-S, IP address, MAC address You have to permanently insert that MAC address into your kernel table. Which means that I ignore the broadcasts. If you have your mail server, your DNS server, all your different servers, I hope you're not running on the same machine. That's another foolish thing to do. But that's different talk. I hope each of your major network services runs on dedicated individual hardware. And I hope when you get home that you go into hard code, your MAC address is between servers. This way, no one can spoof. Mind you, when a machine crashes and you replace the Ethernet card, life will be bad. You have to go to every fucking machine and we do your up table. But, good luck. And this doesn't quite work with transit networks, DHCP based stuff. Pardon me. Do you need MAC addresses and MAC hardware? Yeah. Yes and no. Most cards, the most newer cards actually have the MAC address that's changed, usually programming. By default, the MAC address is assigned to the card unless you use SPARC, which puts it out as bound to the CPU. So it's kind of a pain, yes. If you put two Ethernet cards into the same SPARC station, they both have the same MAC address. And if you connect them both to the same Ethernet for some various reasons, things are going to get broken real fast. But real thumb it's bound directly to the card. Fact done. On the back it says EA and then my Ethernet address happens to be the same one in the slide. But it's bound into your card. Now, sequence prediction. You thought you had SSH? Well, this won't break SSH. It'll just make your life a little bit more annoying. But this is a good way of trashing your Ethernet connections. Trot to route. Route will be happy to point you to the FRAC article that gave you the program to do this, no problem. Now, again, we have a bunch of hosts. Let's say I take out Trusted Hosts. So, sin flood. Bye-bye. It could be Ping of Death. It can be the latest application. Don't worry about that. That machine is out. Next, I go Hi, Target. Hi, Pete. Now, so let's go to sequence one. Let's say the sequence number, let's say you'd be 10. Next one, that's 12. 14. What's next? We're going to be 16. So what do I do? I send a spoofed packet. It replies to me as the 16. Using that number I can reply, even though I never saw the acknowledged sequence number. Again, there you go. We connect up. We send a few packets. Eventually we get. We actually figure out what the sequence is. We find it's very predictable. Most new machines now randomize the starting sequence. But before, I mean, it was that clockwork. I mean, you ran our bone as one program. It was great. Sequenced, guest sequence, real sequence. And you just watch the numbers converge. And then once the numbers converge, the program just, you're out. It was really funny that these numbers streaming up your screen, and that, you know, converging, and then when the delta hits zero, boom, you're in. It's like in a movies. So, I love all the watching the hacker movies, because, you know, these hackers put more time into the GUIs of the application. I wish I could I wish I could do it when I was just like yeah, from other people. I mean. But okay, back here we send this poof, send it to the, you know, send it to the trusted host. By default, you'd think the trusted host would have sent a reset. But it's down. Can't send a reset. Which allows me to do it. Mind you, you only get one packet. That's one of the problems. But that packet can be reboot. Send me a next term. Our host, you know, defconn.org. You know, whatever you want to be. All you need is one command. Follow? Questions? No, see, again, this is just an explanation. I wasn't going to print out the slides, but it's too early in the morning to go to King Island and print them. These slides will probably be available on a defconn web page. DTO has always published these things. But this is an explanation of what I just said. OS is now a randomizer. Numbers makes it a little bit harder to do. Turns out some of the randomizations were very weak. So even though it looked random, it wasn't random. Crypto-login helps a lot. Because under crypto-login, after you've established a three-way handshake, when you're still using the encrypted, especially SSH as an example, you still need to perform the key exchange. So it's more than one packet. Yes? There's one for RFC. Some of the RFCs are basically in the documents that propose standards. And then there's another one for randomizing the sequence key. Do you know about those? I'm familiar with the different propositions. I recommend using the RFC of the randomized one, not the non-randomized one. It's up to you. I imagine that the RFC is a standard and the other one is a homebrew. I mean, if your network works, don't worry about it. And here we are, session hijacking. This is very similar to what I just did. Is that slide again? No. I'll save you the effort of seeing the three-way handshake. Let's just see it happen. You are happily logged into your ISP. You're on IRC. Don't let it in. What else? And what happens? I speak for packet. I hijack the session. Basically, I know what your sequences are. I jump into the conversation midstream. I exchange a packet or two. All of a sudden your trusted host is out of sequence. So it's going to be ignored. And I now have your teleconnection. That time means tricky. That's why you use software. Now, once I send that, I can send out. Now, the problem is you're going to have an axe storm. Because your target host is going to say it's not going to get acknowledgement for packet it sent. And it's going to start screaming axes at each other. Same thing for the trusted host. And eventually your connection will drop. Because you're going to discover the axe associated with that TCP. And you're kind of going to go, I have something screwy here called connection. A partial hack might be to send an ARP to the target host. And make it send its axe to Never Never Land. That would be a pretty good one. It drops a little bit. So quick exclamation. I desynchronize the connection. Then I jump into the sequence that I established. And your type and the long list on your screen doesn't respond anymore. And I've got the session on my notebook. The software's published in FRAC. Anybody feel, everybody going to use tell it again? Anybody who used tell it before and not again? And again, mortgage the house by decent network equipment. Port scans. We're all about them yet. Yeah, I'm going to go over them quickly because that's actually what the next talks about. DNS cache poisoning is a fun one. Did you notice that DEF CON web page was down for a few weeks ago? DNS cache poisoning. So port scan is kind of easy. I'll skip through this quickly because this is actually what the next talks about. You send a port to connection one. I get a reset. It's closed. Two, reset. Port three, reset. Skip to seven. Open. I got ports open. Port seven. Discard was open. 11 was closed. 20, FTP was open. This basically happens when you're on strobe or end map. You're on strobe or end map. That's the next talk. Yeah, I'm going to skip through this. Different types of options. I'm going to skip through this because, again, I don't want to take the window of somebody's sales. So we're doing fine on time. Basically, by the way, I don't want to do resets. I'm going to skip through this again. I don't want to take the window out. You can spot this stuff. There's a few applications. GCP log, NET-STAD, APICUS. Those are the little applications you can run on your server. Again, I'm skipping these slides. They're all next hour. DNS catch poisoning. Everybody know about DNS or how it works? I'll tell you. Okay. Here's the .server, .com server, and the acne.com server. And, of course, legitimate client and DNS server. Now, this is a normal, healthy situation. Your client goes to your local DNS server and goes, hey, where's acne.com? We send a packet off to the root of our internet called . He goes, hey, who's acne.com? I don't know, 1js.com. Hey, who's acne.com? I don't know, 1js acne. Hey, who is this person? Oh, the answer is, and it gets sent up with the proper IP address. Simple, huh? Now, it might seem inefficient, but actually what happens is your DNS server down here caches that information. So next time somebody asks, is already in the cache. A little bit more efficient that way. Also causes some minor security problems. Vulnerability is a cache. You always insert erroneous information. Like, where did that reply actually come from? Here we are again. As an outside person, I go, hey, who's acne.com? It goes, where is that? I reply. It sends you the answer. That's obviously the wrong address. Gee, could that be the save IP address at www.defcom.org had maybe three weeks ago? I don't know. I don't know. I don't know. So what happens later on? Somebody else asks for it. You get that reply. Okay, what if we were talking Wells Fargo bank and that IP address was my home web server? What would happen when I ask for your password? You type it in. I don't know. I don't know. I don't know. I don't know. You type it in. And what happens when I ask you about your account number? You type it in. Then what happens? I go to jail. I go to jail. I go to jail. I have to pay for my death contract. I have to pay for my death contract. But again, you update the current versions 8.something by Paul Vixie. I recommend that. For a person who knows what I was talking about, yes, I know there are several permutations to this. It used to be we're just having a mess. It used to be that DNS servers would only accept responses. They would just accept a response, actually. They wouldn't even care if it asked a question or just accept it. Now it only accepted responses for questions asked. Well, eventually you realize what would just ask a question first. So the DNS server goes, fine, we'll start sequencing our requests. And making sure the answer is the same sequence. That didn't work. The sequences are very predictable. B, you're able to send all the possible sequences within a minute anyway. Let me know the sequence. How long does it take to send like 65,000 packets? Not long. So they took care of that. But it turns out the sequence ramization is not that random. So it's a little finger in here, but in the latest version it's a lot better. In the next version we're actually going to have encryption. That'll help a lot. Yes. In the earlier rate, yes and no. In this case, we're assuming you're actually going to ask it. Yes, it will ask it, but a lot of times we'll send a packet out asking for what's the current version of IP address. It's called the SLA record, which is a serial number. And if I reply with a higher serial number I can override it. So when I say that little fake packet it's going to have a serial number of 9,999,000 just to have some astronomical number with an expiration date we'll never time out. So that's going to be in your cache. It's already in your cache. I might not get it in, but then all I got to do is ask for another record that's not in your cache and I can probably slip it in. One of the other exploits, of course, was piggybacking. I run Disorg. That's my home domain. And I would, for example, get you to do a Disorg lookup. And then my Disorg reply, piggyback a Wells Fargo reply. That's another way of slipping past the gates. Again, I can quite literally go on for an hour of just permutations of this one. So in closing for this particular topic, we'll just say even you just install slow seven upgrade. Whenever you buy a commercial product, download install. Same thing with Sandbell. So effectively upgrade, fix pending, you know, modern version tracks queries, etc. BGP, anybody know what that is? Yes. This is a fun one. We always talk about it was a take it. Want to know how to do it? Actually Disorg has released some automated scripts for this one. Okay, here's a little network. We have an internal router with a couple of peers. Obviously these people have got money since they have multiple connections to the internet. Internal router establishes a BGP connection to the peer routers. Blue Routers. I'm on the outside world. BB and Nasty Saab I don't know what the sequence is. But there's only 65,000 of them. How long is it going to take me? Now, eventually that network goes out. When internal router and router A discover a drop of T speak connection, internal and A assume the other guy crashed. Automatically we rebalance the internal hash return of balance tree of routes. And if you're anywhere near a large hub or large center of the universe, that can take a long time or a lot of memory. And after it balances this, it reestablishes connection and then rebalances the tree after the tree is balanced, then your connectivity. So the network can be down for up to 20 minutes. This is an extreme case, but it takes a while. So if a peer loses a BGP connection, you're screwed. You no longer have connectivity to your one peer. There's a blind attack. There are one in 65,000 chance. Not a problem. Not a lot of read, but in the slot machine. It's the attacker may be able to keep the connection down infinitely by continuously resetting resets to zero. Again, what's the first sequence number? Zero. And to reestablish a sequence, it's assumed to be zero. So when you send out the sin, the reset is sequence zero since we've reestablished a full sequence. The attacker may keep things down. And eventually the routing table is large enough. There's no time to come back up. So your network goes up, what? Three minutes every 10 minutes? Or worse? Your site's out of luck. You can really embargo a corporation this way. And the network admins will go nuts because the routers are up. The routers are pinging each other. Your Cisco Discovery protocol says, yep, I see a router right next to me, and you get the connection. It goes right back down and you can pull the howl all day to the network monitor. And again, this attack is best fixed by filters. Unfortunately, if I get to pick on Cisco, it's more actually networks. You lose about 40% of your bandwidth when you turn on IP filtering. So since people only buy a big enough router that they need, nothing more, they discover they've turned on IP filtering and their router isn't big enough, but they spend how much money? So what's the problem? Question? Yeah, how is it possible Well, since I'm probably spoofing, it's going to take a while. You probably have to manually do it. You really just can't say where the packet came from because the source address has a wrong stamp on it. You probably have to call up each person in their chain of connections, hopefully in the 255 hops, usually about 30, and get them to run a monitor and tell you where the packet's coming from. How long do they get to call this? I don't know, I don't work there. It really depends. I don't want to subpoena first. It's a whole privacy versus workability issue. It falls into Jennifer's, I guess, column. But this is a fun one. This one's really just way too much fun. You know, we have IP filters, so... Yeah. Again, you know, it's, you know, DNS is getting overloaded. The centralized hubs just don't have enough bandwidth to support filtering. Most companies, the best thing you can do is if you run a company, you run an ISP, filter your outbound. There's no reason a packet should leave your network if it's not from your network. That being, have an outbound filter means that all packets leaving your net have a source address of your network.