Introduction

Back in 2017, I started looking on some known vulnerabilities in the most commonly used routing protocols. One of my goal was to test each of them in my lab, but unfortunately I was not able to find any maintained / functioning / documented exploit. So I decided to write them on my own.

There will be 3 article: this one, focusing on the exploit I wrote for RIPv2, and 2 others, one for OSPF and one for BGP. While all the details are discussed here, the exploit code and the GNS3 configuration files can be found on my GitHub account.

Last but not least, I am going to cover only the details needed to understand how each attack works: if you are interested in a gentle introduction, I suggest you to carefully read the protocols description either in “Computer Networking: A Top-Down Approach” (ISBN-13: 978-0133594140) or in “Computer Networks” (ISBN-13: 978-0132126953).

Goal

This small series of articles has two goals:

• to give the community some tools that could be useful both to understand how the described attacks work and for proving the associated risk;
• to demonstrate the gap between the theory (where everything is simple) and the practice (fighting the “e che ce vò” approach).

The need of a routing protocol

Internet can be defined as a network of networks. While we use it everyday, nobody (more or less) cares about how those networks can interact each other.

The rules describing how every packet travels from its source (e.g.: your PC) to its destination (e.g.: your email server) and back, are called routes, being applied by devices called routers.

For routing packets in the right way, routers need to share information about the routes they know, the networks they serve and the cost (in terms of money, delay, etc…) associated to each route.

While in theory this can be achieved manually, by inserting each route in the configuration of the router, this is not feasible in practice, because routers can be everywhere around the world. Moreover, if something changes, (for example, a link from one router to another stops working), updating the configuration, by hand, of every router to adapt to the new situation may require days or weeks.

Routing protocols allow routers to dynamically exchange routes, avoiding any manual intervention (apart from the first configuration).

RIP: the theory

RIP stands for Routing Information Protocol and it is one of the oldest routing protocol being used today.

There are three versions of RIP:

• RIPv1: the original version, defined in RFC1058 in 1988;
• RIPv2: an improved version, defined in RFC2453, adds authentication support and other improvements;
• RIPv3: sometimes called RIPng, described in RFC2080 and supporting IPv6.

This article will focus on RIPv2, but from now on we are going to refer to it simply as RIP.

For calculating the cost from one network to another, RIP uses the the concept of hop: we have an hop whenever a packet passes through a router while moving from a network to another. With RIP, routers keep track of networks which are at most 15 hops away: every other network is considered unreachable.

Another important aspect, as specified in the RFC, is the fact that every router using RIP exchanges routing information every 30 seconds.

RIP: attack analysis

RIP is simple and so is the attack. The basic idea is to keep issuing fake RIP Response messages, containing basically whatever we need (in terms of routes). The other routers will eventually insert our malicious entries in they tables and start routing the packets accordingly.

Normally, RIP Response messages are sent to the dedicated multicast address 224.0.0.9, but the same messages seem to be accepted even when their destination IP address is a specific router. This is great, from an attacker point of view, because it allows he or she to be surgical in the injection process.

RIP: exploit lab

For testing my exploit, I used GNS3, which is an awesome open source network simulation tool. It provides some great features, such as:

• emulation of different routers / switches firmwares (e.g.: Cisco firmwares) through Dynamips, QEMU and so on;
• interaction with external virtualization hypervisors (e.g.: VMware, Virtualbox, …);
• sniffing of the traffic flowing between devices, using Wireshark;

For this lab, I used some Cisco 2960 firmwares to create the whole infrastructure. Then I configured the routers in such a way that they exchange their routes using RIPv2. Finally, I created a Kali VM that I attached to the scenario.

This configuration allowed me to:

• test how the configuration is done on enterprise-grade devices;
• have a VM which I can use both to develop and to launch the exploits (it is not mandatory to use Kali, but I like Kali Light because it is what I am used to);
• check the content of the packets generated by my exploit;

While setting up everything is not always trivial, GNS3 has both great documentation and a great community. Moreover, spending time setting up everything allows you to understand how every device is interacting and how to exploit the powerfulness of the various tools.

What follows is the screenshot of the scenario I created on GNS3, with the 3 steps of the attack highlighted:

1. generate the malicious packet(s);
2. send the packet(s) to the victim router;
3. let the victim router spam the injected routes.

RIP: exploit development

I started the exploit development by looking at the network traffic, to understand how the messages were composed. I then checked the Scapy‘s source code and it confirmed that Scapy is capable to generate RIP messages.

I then analysed some PCAP files, grabbed from packetlife.net, to understand how the packets were composed. The structure is quite simple, so I tried to craft some packages with Scapy, only to discover that they were not accepted by the victim router. Theory VS practice. After spending hours reviewing the content of the packets I generated, I ended up discovering only one difference between the ones I was sending and the ones inside the PCAP files: the source UDP port.

I did not setup the source port, so it was pick up randomly by Scapy, while on the PCAP files every packet had the same source port, 520/UDP. To understand better what was going on, I read carefully the RFC, discovering what follows:

“RIP is a UDP-based protocol. Each router that uses RIP has a routing process that sends and receives datagrams on UDP port number 520, the RIP-1/RIP-2 port. All communications intended for another routers’s RIP process are sent to the RIP port. All routing update messages are sent from the RIP port. Unsolicited routing update messages have both the source and destination port equal to the RIP port. Update messages sent in response to a request are sent to the port from which the request came. Specific queries may be sent from ports other than the RIP port, but they must be directed to the RIP port on the target machine.”

What. The. Hell. Theory VS Practice.

I really don’t know why an RFC defines the source port but one person at the 34c3 (where I did a workshop explaining those attacks), suggested me that this could be an ancient form of “light authentication” when, 30 years ago, the security was an interesting add on, not something mandatory. Cool!

But let’s go ahead. After statically setting the source port, the packets started being accepted. While the whole exploit code is a little bit more complicated, due to the need of getting parameters from the command line, etc… , the three lines in charge of the actual exploitation are reported here:

# prepare the evil packet
pkt_evil = Ether()/
IP(dst=dst_ip)/
UDP(sport=520, dport=520)/
RIP(cmd=2, version=2)/
RIPEntry( AF="IP",
RouteTag=0,
addr=network,
mask="255.255.255.0",
nextHop="0.0.0.0",
metric=metric)

# spoof the source IP
pkt_evil[IP].src = spoof_ip

# keep sending the evil packet every second
sendp(pkt_evil, loop=1, inter=2, iface=iface)

RIP: exploit impact

The exploit impact is hard to define, because it depends on the network inside which it is carried out.

To estimate it, just think about an attacker who is capable to inject basically every route he or she wants. Then, try to imagine what that would mean in your network:

• Are you able to identify someone sending fake routes?
• Are you able to identify traffic routed anomaly outside your network?
• Is the traffic router in your network encrypted end-to-end?

From my point of view, thinking at the worst case scenario and try to mitigate/resolve the issues is the best approach, even though it could become quite complex. And expensive.