This tutorial shows how to use nemesis to craft a UDP packet and custom payload then deliver it to a router running RIP.
This enables us to perform the following attacks:

1/ This allows us to propogate a bogus route into the routing environment . We can then attack from an IP block that has not yet been allocated or a subnet that is in use by another company but has not yet been allocated. (IP spoofing)

2/ We can place ourselves in the routing path of all network traffic. This allows the sniffing of traffic that normally youíd have to be on the same broadcast domain as the victim to sniff.

3/ It also can enable us to TCP session hijack our victim and take over an SSH session of the victim after they have authenticated with the server.

4/ We can disrupt all network traffic by telling all traffic to go to an unreachable destination, or add loops into the routing topology.

The basis of this tutorial is to show you how to craft a RIP packet which will convey a RIP update to a node running RIP. You will also notice it would be straightforward to use this tutorial as a basis for crafting other protocols such as DNS, OSPF, IGRP, and EIGRP.

Choose your Weapons

Here we are going to be using the following tools.

* Nemesis - Nemesis is a portable IP stack that we will use to inject our payload. Nemesis will write *anything* into the packet so we need to know what we are doing and study the packet we are going to craft's structure and what router's will expect the packet to contain.
Otherwise we will just create malformed packets, which will be dropped by the receiving device. You'd do well to read the relevant RFC's and TCP/IP illustrated before attempting to craft your own.
Available here

* Ethereal - I've said enough already. We need it to make sure our packets are well formed when we send them, also it's very useful to analyse other packets we may want to craft and use as a basis for a nemesis payload. Also if we send a request to another router for it's routing table we need it to sniff the reply. Enumeration of the targete environment is key to this attack. here

*B4rtm4n's perl script - You won't get too far with it. This converts our hex code into binary.Our payload file that will be used by Nemesis must be in binary or we'll simply write rubbish into our packet. This is our magic ingredient.

What is RIP?

RIP is an interior gateway protocol that is mature, stable, and is widely supported by many manufacturers. It is also easy to configure. Therefore, it is suitable for use in stub networks, and small AS's (autonomous systems) that do not have many redundant paths. Having too many redundant paths would warrant a more sophisticated routing protocol. RIP is broadcast based, and uses UDP as itís transport protocol, and by default will listen on port 520. There are two versions of RIP; RIP v1 (RFC 1388) and RIP v2 (RFC 1723).

RIP is also a distance vector routing protocol. What that means is it can be prone to routing loops. Which are controlled via hold down timers, and split horizon processing.

RIP sends routing table updates at regular intervals (every 30 seconds), and when there is a change to the routing topology. It also marks routes, as invalid when it doesnít receive regular updates for them.

When a router receives an update it in turn updates it's own routing table. The RIP enabled router then increases the route metric by one, and adds the sender as the next hop destination.

RIP maintains only the routes with the lowest metrics to a destination. A metric of greater than 15 is considered infinite and therefore unreachable. RIP security mechanisms consist of configuring the router to only accept routes from neighbouring routers.(easily spoofed as the transport is UDP). Lastly there is also plaintext password authentication.

RIP Packet structure

In order to get the ascii payload correct for the binary file we need to understand the RIP version 2 structure to get meaningful results. This is taken directly from RFC 1723 with a few of my own notes for clarity and brevity.

The first four octets of a RIP message contain the RIP header. The remainder of the message is composed of 1 - 25 route entries (20 octets each). The new RIP message format is:

The Command, Address Family Identifier (AFI), IP Address, and Metric all have the meanings defined in RFC 1058. The Version field will specify version number 2 for RIP messages which use authentication or carry information in any of the newly defined fields. The contents of the unused field (two octets) shall be ignored.

Command field lets the router know what it has to do with the packet.
Valid values are 1 or 2.
1 is a rip request , this tells the router to send me all the routes it currently knows. (useful for evaluating what routes you might need to change)
2 is a RIP update. This tells the router what routes to add to it's routing table

Version field - says whether or not it's rip version 1 or 2.

Unused - as it says we don't use this field and set it to 0

Address family identifier - only IP is supported therefore the value must be 2 (IP)

Route tag - The RIP route may be propogated further by other routers using other protocols such as, OSPF. If we could learn this from the network we are attacking our route may be propogated further by other routers. Otherwise set it to 0.

IP Address - IP address of the router propogating the route. As the transport for this is UDP you can pretend to have an IP other than your true IP as no session is setup between yourself and the victim as TCP would. This means you can pretend to be a trusted neighbouring router.

Subnet mask for the route you wish to propogate.

Next hop - The IP of the router you want the traffic to go to (yourself if you intend to sniff or session hijack the traffic, you could also create a routing loop or blackhole route is you wished though)

Metric - The cost of the route. 1 means directly connected , 16 is unreachable, over 16 and the packet will be dropped outright. By adjusting the metric we can add new , seemingly better, routes of our choosing or kill routes learned from other routers.

A captured RIP v2 packet

Here's packet that was captured using Ethereal, we arenít interested in anything other than the green section as that's the RIP update structure as defined by the RFC. Even though Ethereal shows this as hex it's actually on the wire in binary, This means that when we craft our payload we must write the contents of the packet in hex then convert it to binary using a script. We only need to generate the section highlighted in green as Nemesis will create the rest of our headers for us.

What we are doing here is preparing a text file, we will then convert this from hex to binary and inject it using nemesis. This is the payload Nemesis will carry to our target.
Note that what is being prepared here is the section highlighted in green from the previous section. Also the packet being prepared is sending a different route other than the one illustrated above, but they both start 02 02 for reasons shown later.
Here's the ascii which we will convert;

020200000002000000e000000ffffff00c0a8007f00000002
02 this is our command an update a 02 (remember this is hex, to convert from bin to hex get your calc out type in the decimal and click the hex button)
02 RIP version 2
0000 two unused bytes
0002 AFI is IP (it's the only valid one)
0000 this is our route tag it needs to be 0 unless we know it will be reused by another protcol
0e000000 this is the hex for the route to propogate
ffffff00 subnet mask in hex for our route
c0a8007f router advertising the route
000000002 metric for the route

we then copy the following into a text file.

Quote:

02020000000200000e000000ffffff00c0a8007f00000002

note no spaces and 00 = 1 byte therefore my ip is c0 (192) a8 (168) 00 (0) 7f (127)
After we've put the string of ascii into our text file we then convert it using the hex2bin perl script coded by b4rtm4n.

Quote:

#!/usr/bin/perl -w

### Coded by B4rtm4n (c) 06/05/2005
### HEX to binary
###
###

### Convert datagram to raw ASCII

### Get input from file

#$usage="perl hex2bin.pl hex.file > bin.file\n"

$input = "";

while (<>)
{
$input=$input.$_;
#print "$input";
}

#$input = chomp ($input);

$x=length($input); #get the size of the input
$ascii=""; #ensure the string is initally null

The syntax there was
nemesis udp - use UDP as a transport
-P payload file
-S where it's coming from which can be anywhere no TCP handshake to negotiate
-D who I want to get the route
-x source port
-y destination port
-t 0 IP type of service
That's it the receiving router will now have a newly learned route in it's routing table. You might want to knock up a short shell script to loop the nemesis command or the route will drop out 30 seconds later, and that's not long enough for a good sniff you also might want to poison two routers to get all the traffic (there and back) going through you.
Congrats, you own the entire network.

Where to now then ?

That get you started with a simple routing protocol, itís a little bit harder to use this same technique to route poison OSPF and EIGRP, but the results are exactly the same. You might even try some of the malformed packet exploits that some cisco routers are vulnerable to.

Last edited by MattA on Thu Aug 31, 2006 10:22 am; edited 1 time in total

Nice write up. This really highlights the dangers of not securing the network itself. One note, Cisco does support MD5 authentication even though it's not part of the RFC for RIPv2. OSPF and EIGRP both support MD5 as well. Using authentication is the way to stop this attack.

I am curious how this technique could be applied to more sophisticated routing protocols like EIGRP or OSPF assuming they were not using authentication. The first issue that comes to mind is the fact that both use their own transport protocol, not TCP or UDP. Second issue is how to manage the connection-oriented way these protocols work. Each uses acknowledgments and sequence numbers so address spoofing would be extremely difficult.

Assuming you have a tool that can generate the transport layer information and respond to packets sent from other routers, I don't see why you couldn't use this technique. You should be able to sniff the multicast Hello packets to get the information you need to create a valid Hello for that AS. Once you have established adjacency with the other routers, you should be able to craft LSAs with the bogus routes.

I think the easiest way to implement this attack on EIGRP or OSPF is to sniff for the Hello packets and configure a rogue router to join the AS. The router essentially becomes the tool. You would configure the router to advertise the bogus routes and it would take care of the communications protocols.

One note, Cisco does support MD5 authentication even though it's not part of the RFC for RIPv2. OSPF and EIGRP both support MD5 as well. Using authentication is the way to stop this attack.

You might be ale to break the md5 hash though

ElToro wrote:

I am curious how this technique could be applied to more sophisticated routing protocols like EIGRP or OSPF assuming they were not using authentication. The first issue that comes to mind is the fact that both use their own transport protocol, not TCP or UDP. Second issue is how to manage the connection-oriented way these protocols work. Each uses acknowledgments and sequence numbers so address spoofing would be extremely difficult.

Yes it's a nightmare spoofing OSPF the protocol can be crafted with nemesis but you can't form an association which is necessary before you can exchange routes.... team jinao wrote a few methods of effecting OSPF by ageing out routes, the RFC for OSPF is massive and complex. I think some of the association is formed via TCP which again with sequence numbers makes it difficult.

ElToro wrote:

I think the easiest way to implement this attack on EIGRP or OSPF is to sniff for the Hello packets and configure a rogue router to join the AS. The router essentially becomes the tool. You would configure the router to advertise the bogus routes and it would take care of the communications protocols.

I agree. I have to say though it's easier to hack the routers than craft protocols but you might get some interesting results causing routers to fail over using bogus HSRP messages, perhaps the acl's will be weaker on the failover router.....
phenolit have some interesting materials on this

OK , i've been just using the basics of this tut so far , i just got to the point where i inject the packet with "ascii.bin" and send it out.
I ain't sending it at a router , i am using your tut "exactly" as written, including the IP address.

Now here is the really mad bit ! Bear in mind i am using the IP's in your tut..

I send the packet's out ( 4 in total ) , and using ethereal ( on the same box, a lapper using a prism chip card ) to capture the packet's i get some really odd result's !

all the above does is -S is the source address , -D the destination and then x and y are your port numbers, you need the -S and -D as this is your new packet source and dest , try with a wired connection.

All it does is alter the IP information in the packet and stick the payload in which is not part of the IP addressing information.
It seems wierd to me too....

Thanks for the help Matt, i am typing in exactly as you have indicated.
I tried it with a LAN card, and got the same odd result!
It's generating random source and destination IP's but as noted i have given the S and D IP at the command ?
I am still trying to figure it out , but it's well beyond me

No worries about the time, a few people are currently giving me time too (coding a buffer overflow) , this is fair play , pass it on.

Yeah that does'nt look right at all.
There should be only a few bytes of data, the data content is totally wrong, looks like it was done with a wireless card too, I'm saying that as i saw references to dwepcrack.

Try doing it without the payload see what you get if it even looks vaguely correct, nemesis writes exactly what you give it to the wire, even if it's total garbage, it then wraps it's own ip and udp headers onto the payload.

PM me your e-mail addie and I'll send you the payload file i generated.
If you are using the perl script and the hex i provided that should be correct.

This is more like it, in that the IP's are reported correctly, as is the source and destination port and the data content is what you might expect.

I assume that it's reporting that it's malformed as a result of not attaching the payload, containing the missing info ?
So it's correct to assume we are looking at "operator error"
I obviously am doin something wrong with the payload.

I did create a file called "inject" and give the correct command , so its got to be something within the payload that's causing the problem , i think !
I can't see where else the problem could be at this stage.

EDIT : The problem is user error ! i did a copy and paste of your hex and ran that , guess what ? worked pretty perfect !
So Mr Stupidy Head here did screw up somewhere , sorry about that , efing n00b's
Interesting thing is where did i screw up and how did that result in the random generation of IP -S and -D addie's , this is fun

nemesis throws the error "The procedure entry point PacketGetNetInfo could not be located in the dynamic link library packet.dll"
please help what to do. I used default setting with all files in same directory i.e. nemesis.exe and ascii.bin in the same directory.

You are using WinPcap 3.1 or higher. Nemesis requires explicit use of WinPcap 3.0. So uninstall WinPcap 3.1 and install WinPcap 3.0.

I am using a PC which has 2 ethernet cards connected to 2 diffrent network. How in Nemesis should I specify on which to inject the packet. Nemesis it seems always injects the packet on the default route.

Admin note
Please don't double post. Use the edit as I just did.
alt.don

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forum

Featured Links*

Looking for more Windows Networking info?

Sign up to the WindowsNetworking.com Monthly Newsletter, written by Enterprise Security MVP Deb Shinder, containing news, the hottest tips, Networking links of the month and much more. Subscribe today and don't miss a thing!View a sample newsletter.