 He's kind of, huh, fucked. So he thinks, what's the MAC address? Well, what he does? He cries out, who is 10.1.1.2? And he does that very loud. We call this a broadcast. So host B is a little bit pissed off about this crying around, but sends back his MAC address so they can communicate, which then looks like this. So, what can we do? We can be faster or just more shetty. We stress the point that really we are host B and the other one is lying. And you would believe me, right? So, looks like this. He cries around. Etyker hears this as well. So here's the non-answer. Here the Etyker appears, who? And he answers, I'm this host. And, well, what I did, he can lie to both parties as well. So, then it ends up going through his system. Great. This is a short list of tools. There are lots of tools to do this stuff. We did one for Linux and for Windows. The THC group, another German group, wrote the parasite. Itacap is pretty nice because it has a graphical user interface. So, for all the less educated people here, that's pretty easy. The classic is Hunt, which is very good but sometimes strange to handle. And, yeah, there are scores of others. Another thing, local redirection. What do I mean by local redirection? Most people just overlook this. By modifying your own system, you can just modify the way. Okay. Let's assume the administrator discovers Etyker and thinks, okay, I'm going to fuck this guy. I'm blocking him here on rather one. Well, okay. End of game. No, not really. Etyker called MAP, let's say, victims address here. If this guy is forwarding to the IP address of router one just by setting a fixed up entry. If router one is somehow using MAC addresses for filtering, like, let's say it's a switching router or something, that would pass. Another way, and that's the recommended way, just modify, yeah, that's the MAC address thing, just modify your routing table and use router two. You could even use router two if it had no connection to host B. Why? Because router two would know how to send it to router one and router one would probably accept it. So routers. Okay, we saw we can do nice things with them, but how do you find them? They're passive and active ways. Basically, listen for all the multicast and broadcast stuff or just discovery protocols like CDP. Running around the network, you just map the routers. But, well, this is not very effective because most modern routing protocols don't include the actual information in the broadcast packets. So what can we do? We can do active discovery. We can query routing processes. We call this AS scanning because it's autonomous system scanning. We can send out router solicitations. I really hate this word. Which means we just try around and look for a router. We do, I was fingerprinting, or even more interesting, protocol scans. We just scan the IP protocol. Let's say it supports IGRP. That's a good hint. It might be a router. Or we just do port scans. If it is an order model or just a strange model and it has, let's say, the report open, well, we find it this way. This is an example from our ASS, our autonomous system scanner. The upper four lines, that's passive stuff. It sees IRDP broadcasting, router information, and it sees IGRP, two different autonomous systems. Notice that it includes the iOS version. Very interesting. The rest of it is by active scanning, the IGRP in this case, you see how much information you get out there. It's internal routes or external routes. You see the net itself, the net mask, the next top, various information, even what kind of link it was, and all the information for the routing protocol, like delay, hop count, reliability, and all that stuff. So, which shoots do we have? As already mentioned, we wrote an autonomous system scanner. Etheral is very good in decoding routing protocols. If you prefer to do their stuff by hand, just take this too. The next top can be used to discover central points in the network. That would be a good hint for a router or a server. You will find out. TCP dumps option to show data link addresses is very good, because if you see a packet going from A to B on the IP layer, and the destination address on the MAC layer doesn't match to the IP, well, that's the next top router. Nmap is pretty good for protocol scan. We wrote our own tool before we discovered that Nmap supports this. You basically go down all the IP protocols, and that's a negative scan, so you wait for ICMP protocol unreachable messages, and if they don't appear, this thing is probably running this protocol. And if you get a router by DHCP query, well, why not using it? ICMP router protocol discovery. Okay, I mixed that up. IRDP is mostly, when you enable this on routers, they broadcast periodic updates, and just tell everyone I'm a router, and I know these interfaces, and you can talk to me. IRDP can be requested. That's this router's solicitation stuff, and he will answer mostly. The announcing router, let's say you are the announcing router, is entered in the host routing table with less priority, means with a higher metric than the default router, so make sure the default router is not available. And the metric depends on the preference. Most systems just run with a low preference. If you use a high preference, you're the first guy. So how does it look like? It's pretty straightforward. You just make sure everyone thinks you are a router. You send them out, make yourself known to host A, and make sure that this guy is temporary not available. You want to use it later because how are you going to pass the traffic to this cloud here? So very interesting is the fact if you have a router that runs dial on demand or something, it has to raise the line or just negotiate PPP or something. If this host here is Windows, he would think the router is not available and take the next one in his routing table, which is hopefully you. So again, here are the tools. I recommend this attack as an additional thing because you don't get the traffic right away. So if you do any kind of traffic interception or redirection, you can do this in the background just to make sure if something goes wrong with your primary attack, you still get the traffic. Hosts, as I said, Windows just really likes it. And does it all the time. And he just on boot up. On the other hand, Linux does not care at all. ICMP redirects. Most know these. They were introduced to make routing a little bit more effective. So when host A sends traffic to router one here and router one discovers shit, I forward this packet to the same segment to another router in the same IP network, which is called router two. This is stupid. And he actually tells this host A. So host A happily adjusts his routing table and uses router two for disconnection. So how do we use that? That works vice versa. The packet is sent from host A to host B through router two. We see this traffic and we think, well, we know a better way. So we actually tell this host A, please use me as your next top. And it works. It even works across routers. If you send ICMP redirect message, let's say across the internet, that works as well. Why? Because the final router who will deliver this packet to the attacked host is actually the one who's probably getting all the traffic, so the host will believe you. Okay, one important thing here. There are a lot of redirect tools out there, but most systems require the first 64 bits of the original offending packet to be included. Why? It would be good to know which direction and which communication caused this problem. So, host reactions. Windows just loves ICMP redirects. And it just adds the thing to the host as a host route to its routing table. So, if you look at your routing table and you have about 500 host routes on your routing table, you should look out for ICMP. Linux host, it depends. You can set this here in this proc file system. But most distributions now accept these things. And it's a little bit evil because you don't see them in the routing table. You really have to go into the proc file system and find out which tools exist, okay? Because we're speaking about it, we coded one. And there's, from Yuri, another one, which is basically the original ICMP redirect tool. Works pretty good. So this is how it looks like on a Windows system. You might not read this, but you see the pattern. It's all host routing here. It's all 255. Okay, let's go routing. Let's make it interesting. IGRP, interior gateway routing protocol. Is this your idea? It has actually 65,535 possible autonomous systems. It's just to separate server routing processes from each other. It uses no authentication. Hello. And various data link information, like hop count, reliability, another word I really like. And bandwidth is used to calculate the metric. Well, hosts can actually listen to IGRP without saying anything. That's called a passive interface. So make sure your protocols scan the hosts. Maybe they accept your updates. Spoofed updates mostly have a better metric. Why? Because you can choose your link however you want and you can easily compete with the real-world stuff. But keep in mind that your sender network, whatever you select as your sender network, has to be enabled as a possible source for route updates. So how does it look like? We could introduce new routes for modifying existing one. We have this guy here, host B, and we have this nice server over here. And we have the three routers here talking IGRP. Our attacker got a connection to another router and he's just way off. Okay, so what does he do? First, he adds the IP address of the server to his interface as a secondary IP and enables IP forwarding. Guess why? Because in the next step, he's telling router 1 using router 3's IP address that 10.10.3.2 is definitely the best way to reach the server. So he just makes himself very interesting for the router. Now he tells R2 that R1 is definitely a better route to reach server than the original R3. So host B actually ends up logging into his fake server running there, submitting his password and other information you just want to have or just being curious. We don't do bad stuff, right? And he gets all the traffic. Great, he can even run a fake server on it that looks like the original one. Think about web applications. So you can get a lot of interesting information there. If for some reason Attica just wants to prevent the server talking to host B, he can do another thing. He can do routing loops. He just tells R3, well, the best way to reach your host B is definitely R1. And he tells R1 that the best way to host B is definitely R3. Then he sits back and enjoys the packets using up its TTL. Okay, this is some very old stuff. Routing information protocol version 1. Rip. Good, it's one of the oldest, but it's still in use because it's so simple. It uses broadcast and just runs on UDP port 520. It has no autonomous systems and other stuff. It even uses a fixed network size, at least in most implementations. And it really, really is easy to attack. There's the routing information protocol version 2. That actually includes Nextop information and Netmask into the routing updates. Still has no autonomous systems, but it often uses multicast instead of broadcast. And there is even a ClioTek authentication defined in RFC. But this is so strange that most people don't implement it or don't use it. Cisco actually supports MD5 for Rip. What a bright idea. But since they use a double authentication block, this is not by RFC. If you have anything that is not Cisco, you definitely don't want to run this. So what are the attacks? It's basically the same stuff you can do with Rip as you can do with ERP. Watch out for the network boundaries for the fixed Netmask stuff because if you send updates that don't make sense or you just use subnetting or supernetting, you're going to confuse the network. We don't want this. The multicast stuff, Rip v2, maybe forwarded across segments. Why I love multicast is, for example, if you run a checkpoint on an AIX system, it will forward multicast whatever the checkpoint setup says. So that's why I really like it. There is a thing called Split Horizon with Poisoned Revers, which actually prevents routing loops from happening, not really. You have to have at least one router that knows that there is a routing loop and it is communicating back this to the other routers. If you have just two routers talking Rip, you can do routing loops. So which toots exist? R-Probe and S-Rip from Humble are probably the first Rip attack toots I've seen, which doesn't mean anything. You can use the Nemesis Rip or anything else you can think of based on the libnet because they support Rip. And you can use ASS to scan this. The problem at the moment is the Rip senders I know do not support the clearchecks authentication, which is defined in a RFC, so you might see that. OSPF, open shortest path first. That's a very interesting routing protocol. Unfortunately, it's very complex. Basically, one thing it does is sending out link state advertisements through the area. Area means you can define routing areas in OSPF and every router in the area knows the status of every routing information you might have. So these halo packets are used to tell each other, hey, I'm here and I speak OSPF, but they don't include much information. So there's another thing that makes OSPF more complicated to attack because it's basically one of the most secure routing protocols currently in use. Defined in a RFC are clearchecks and MD5 authentication. But one thing to remember is if you don't understand OSPF, the administrator might not as well. So there's the hard to understand factor. Let's say most people run OSPF in one area because it's simple. So you might have luck and just have a flawed design. So how do we attack this? There are several possible attack ways. I choose one that's more interesting because it's a combination of layer 2 and layer 3 attacks. We spoke about that the attacker is able to decide forwarding and is able to modify the IP traffic. So what are we going to do? Since forged LSAs are often contested by the router, they have a mechanism called fightback. So if you just introduce false information, the routers will cry around and say, he's a hacker. So the best thing seems to be you just intercept the communication between router 1 and router 2. When router 1 sends out a packet OSPF-wise, you just modify the information and pass it on to router 2 and he will happily distribute it across the area. Thank you very much. BGP4, border gateway protocol, it's an exterior gateway protocol which means it's used in vans. And it's mentioned only here because it's important. Can anyone think of why BGP is important? It runs the internet. So that makes it interesting. It relies on TCP for communication between the routers. It has a port, 179. You probably know how to find this. And more interesting is there is IBGP and EBGP. It means there is an interior BGP and an exterior BGP. Interior BGP actually means how do the routers in one area communicate with each other? Yeah, but to find each other and to do TCP, they have to have a route. Okay, so mostly they use IGP, any kind of IGP, or static routes, which is, okay, if you have a BGP4 network and you use static routes, you're just an interesting administrator. So the best way is often to attack the IGP. Yeah, because you can just prevent the routers from speaking to each other. You could intercept the TCP communication in any way, or you can use BGP communities. That's an interesting feature. It's not fully researched yet how to do evil stuff with that, but it is invented to introduce, let's say, properties to routers you don't own. So let's say UUNet uses communities. You can actually tell the router, okay, whatever I tell you, it's just for the UUNet internal network, or whatever you send me, I don't want to have this and that information. Another one, bad updates. Well, it's not too hard to send bad updates in BGP, but the internet service providers, especially the small ones, are very good in sending updates like dear internet. I actually know where the 10 network is around the world. So the background providers got used to that and filtered them pretty good. It's mostly used for internal BGP networks because you don't want all the hosts in the internet trying to reach the 10 network over your system. Okay, after so much dry routing, here's a fun thing. How to stand by a router protocol? Another Cisco idea, it's used to have a virtual or standby IP address and another virtual-like MAC address bound to an active router. And you have a bunch of inactive routers. Is the call for me? No? Okay. You have a bunch of inactive routers sitting there and waiting that an active router dies. Okay, the active router is sending out hello packets all the time. And if he stops sending out hello packets, the other routers are going to fight for the highest priority and to actually get the active state. Interesting is its first multicast. I already mentioned I love multicast. And the authentication is done in clear text. Maximum eight characters. Thank you. So it basically looks like this. The blue thing down here is this virtual IP address or standby IP address. So everyone is talking over router one. When you tell router one that R2 is actually a new router just appeared in the network and has a better priority, this is not as it is designed, but it works. R2 actually gets the standby IP address. So everyone is using R2. What's that for? Well, you could actually tell both of them that you have the highest priority. Can you wait with a question or is it... Is that a question if there is a key? No, it just uses clear text authentication, but Cisco already went the way to say, okay, HSRP is kind of interesting and if you really want to use it, use IPsec. Okay, tell this at .coms. Was this a question? Okay. So, yeah, you're telling both of them you're the best router to do the job and at the end you have about 20 risk processors just for routing. So you get the virtual IP address and the traffic. And what's the best about it? It's 100% transparent to the hosts. The IP address didn't change. The MAC address didn't change. It looks like it is before. Just there is this guy here deciding which traffic is passing. Well, so, we had a lot of routing and some fun. After so much routing, let's hop into tunnels. Generic routing and encapsulation GRE is basically used to transport protocol A over protocol B in a backpack. It's not even limited to IP. So, normally you use IPv4 and IPv4 but to connect six bone islands you use IPv6 and IPv4. You can transport IPX over IPv4 or vice versa, whatever. The best authentication you can get with GRE is a 32-bit tunnel key. Okay. There are sequence numbers to prevent evil people like... Any evil people here know. To do anything with the routing protocol but you can actually forget it because it's not defined how they work. They're far away from being as good as TCP sequence numbers and they're so bad implemented that it just works if you don't use them. Another very important thing is GRE supports source routing. Has anyone an idea what you can do with that? So, once upon a time, this is a very common situation at least in Europe. The company has an HQ on the right side with this cute little server and has server branch offices. We have one on the left side here. So, they were used to using list lines or something because they just hate central authorities. They just decided, okay, we go for RFC 1918 IP addresses. Most of you know these as private IP addresses. So then, they decided, okay, I'm going to save money because we have the internet. We can pass over traffic to the internet. And then someone said, hello, your stuff is not routable. Okay, the carrier, being a good guy and knows how to do business, offers a VPN solution. He just says, okay, we build a GRE tunnel between these two, this one, and we just encapsulate all the traffic into the tunnel and it's passed from the branch office into the tunnel, gone out in HQ. And for security, because we want you to use security, it has to be secure, we just say everything that's not out of the tunnel is dropped directly here on the interface. And whatever comes into this router and the destination is not a local network, we just put it into the tunnel. So, that makes it perfectly secure. Our poor guy editor has its own router and actually a routable IP address. Anyone noticing the IP address? No? Okay. So, he's facing the following situation. He has a network, a target network, let's say this branch office here, which uses not routable IP address and uses a filter here to prevent traffic from coming in and on top of this uses GRE. So, he's lost, isn't he? Not at all. He just sets up another system. In this case, a concept we call an attack router. Then he decides, okay, this system is my default gateway and he passes traffic to this attack router. Notice the destination of his traffic is actually the host here. It's not routable anyway, but he's sending this to the attack router. The attack router encapsulates the packet into GRE and the outer packet is addressed to the branch office router, which is getting the traffic, seeing that the source address is the HQ, guess why? He finds out it's GRE, decapsulates it, puts it back on a routing process, finds out he can reach the host over the internal interface and just pass it to the host. So, what does the host do? The host actually answers the packet, whatever that was, and sends it back to his default gateway, the branch office router, who will, according to his routing rules, encapsulate it into GRE and send it back to the HQ. So the HQ router is used for internet access as well, so he knows a way uplink to his provider. So he figures out, well, this packet is reachable over the internet, so I just send it out and see our attacker just gets the answer, which means it looks a little bit strange, but you're actually talking to a system with a private IP address across the internet, behind the GRE tunnel, behind filters, and you have fun. So, since this is so funny, we'll actually put some more work into this. There's, at the moment, no support for the source routing, which makes it so interesting. A thing to do, probably, is you can apply the same attack to IPX encapsulation, X25, any takers in the banking industry here? You can encapsulate IPv4 and IPv4, or even attack IPv6, Six Bone Islands. So what about taking over IPv6 host before it's even on the internet? So, quick ramp up, what tools do we have? Yeah, it's not that interesting, but for reference, you can download all the stuff here and the slides on this URL, or actually look at my shirt. Summary. There are a lot of ways to alter... Sorry, this one. You can actually grab me and I can tell you how to write that. Okay, I'll put it back on later. Yeah, summary. You saw there are many ways to alter traffic paths. This was not a complete... Don't go away, there's a demonstration going on later. Okay. This was by far not complete. There are a lot of routing protocols, even undocumented ones. It has still a lot of heck where you, especially the BGP4 attacks. Most routing protocols, as we saw, are very interesting protected. Means nearly nothing. And unencrypted tunneling protocols are really a high risk and really demonstrate the fact that these so-called private IP addresses do not protect at all. So, yeah, thank you to these people, especially to these red people here shipping me here. And a special thank you to you, not falling asleep and listening to me here and being at DEF CON. And whoever is interested, I'm going to show the GRE attack now live. So, I know I'm probably over my time, but this is really a fun part to do. Unfortunately, my laptop has a blank screen now for me. Just relax. What do we have here? On the upper left side, we have a tenant session to assist the router who is actually representing this branch office thing. I tried to show you in the presentation. On the right side, top right side, we have a TCP dump. I'm looking for ICMP because we are doing simple pings here. On the lower left side, we have this already mentioned Viper thing, which is our study in attack routing technologies. Now there. On the right side, you see the local routing table. So, what are we going to do? I'm trying to write blind here. Actually, it doesn't work, right? Can someone up here tell me whenever I write shit or not? Actually, it works pretty slow. So, we ping this one, and here on the right top side, we see the Cisco answers actually with administrative prohibited packages saying bad guy, bad guy. Don't send traffic to me, please. Okay. Now we have a new routing table. The new routing table says, please use this attic router, which is this poor little laptop here, to do the GRE encapsulation. We'll show the configuration file later, but it basically just includes tunnel source and tunnel destination for this virtual interface here. So, now, we actually do the same ping. What do we see? I know it's very hard to read in a crowd here, but on the right side, you see actually this interface, this virtual interface has the MAC address, double A's or double A's, and you actually see that the echo request is sent to this virtual interface and then passed on. We don't see the pass on here because someone thought it's a good idea. We show something with sniffing and they gave us a switch. Thank you. Okay, just to illustrate that you can do some more stuff with that, I'm trying to write something here. Does this make sense? Does it? Okay. We actually don't want it to do NSLOOKUPs. Where's the shit? On the left side, we see the tunneling packets, which is just the verbose output. On the right side, we see it's actually scanning through this virtual IP router and go figure we bound this IP address on a loopback of the Cisco, which is by now pretty clear. That was it. Thank you.