Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/generic-methodologies-and-resources/pentesting-network/eigrp-attacks.md

13 KiB
Raw Blame History

EIGRP Attacks

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

This page was copied from https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9****

Attacking EIGRP Protocol

EIGRP (Enhanced Interior Gateway Routing Protocol) is a dynamic routing protocol. It is a distance-vector protocol. If there is no authentication and configuration of passive interfaces, an intruder can interfere with EIGRP routing and cause routing tables poisoning. Moreover, EIGRP network (in other words, autonomous system) is flat and has no segmentation into any zones. What could this mean for an attacker? Well, if he injects a route, it is likely that this route will spread throughout the autonomous EIGRP system.

First and foremost, attacking a standalone EIGRP system requires establishing a neighborhood with a legitimate EIGRP router, which opens up a lot of possibilities, from basic reconnaissance to various injections.

For this I will use FRRouting. This is an open-source software which is designed to create a router in Unix and Linux. FRRouting allows you to implement a virtual router that supports BGP, OSPF, EIGRP, RIP and other protocols. All you need to do is deploy it on your attacker’s system and you can actually pretend to be a legitimate router in the routing domain. I’ll show you how to deploy FRR on your system in the next section.

Network Intelligence

Connecting to the routing domain allows us to do enumeration and reconnaissance of networks and not spend a lot of time scanning. This method saves you a lot of precious time. Plus, by scanning, you can get burned in front of IPS/IDS security systems. To me, connecting to the domain and enumeration is the attack vector on routing domains that gives you the most impact. But to do this you need to deploy FRRouting. Here we go.

It is necessary to edit the configuration file daemons. It contains the configurations of the daemons in the context of their activity. Either they are enabled (yes) or not (no). We need to activate the eigrpd daemon.

~# nano /etc/frr/daemons
eigrpd=yes

After that, you need to correct the vtysh.conf file by adding a line responsible for saving the configuration to one file, so that configurations of different protocols are not scattered into different files (e.g. eigrpd.conf, staticd.conf). It is configurable optionally.

~# nano /etc/frr/vtysh.conf
service integrated-vtysh-config

The FRRouting configuration is done. Now it’s time to run the FRR daemon. And yes, we need to enable traffic routing. By default it is disabled in Linux distributions

~$ sudo systemctl start frr
~$ sudo sysctl -w net.ipv4.ip_forward=1

The vtysh command will take us to the FRR router control panel.

~$ sudo vtysh

Example:

Inguz# show version

However, don’t forget that the EIGRP routing domain can be protected by authentication. But you still have a chance to connect to the routing domain. When hello packets are sent out, they also contain cryptographic hashes. If you can extract these hashes from the traffic dump and reset the password, you can log on to the routing domain with this password.

Go to global configuration mode and start the EIGRP process, specify the autonomous system number — 1

And we also need to declare the network we are in. We are at 10.10.100.0/24. My address is 10.10.100.50/32

Inguz# configInguz(config)# router eigrp 1Inguz(config-router) network 10.10.100.50/32

After that, the neighborhood between the legitimate EIGRP routers is established. There are two of them on my network:

  • GW1 (10.10.100.100)
  • GW2 (10.10.100.200)

EIGRP Neighborship with GW1 (10.10.100.100):

EIGRP Neighborship with GW2 (10.10.100.200):

During the establishment and maintenance of the neighborhood between EIGRP routers, routers exchange their routing information. After the neighborhood is established, new routes will appear in our routing table of the attacking system, namely:

  • 10.1.239.0/24 via 10.10.100.100;
  • 30.30.30.0/24 via 10.10.100.100;
  • 100.100.100.0/24 via 10.10.100.100;
  • 172.16.100.0/24 via 10.10.100.200

Thus, after establishing the neighborhood, we know about the existence of these subnets, which makes it easier for us to pentest and save time. We can do without additional subnet scanning. Now we are in the EIGRP routing domain and we can develop some attack vectors. Let’s talk about them.

Fake EIGRP Neighbors

I have found that generating and quickly sending out mass EIGRP hello packets overloads the router’s CPU, which in turn can open the door to a DoS attack. I have developed a little helloflooding.py **** script, but it seems to me that the script lacks the speed of sending out the packets. It’s caused by GIL, which prevents the sprayhello function from running in multiple threads per second. Eventually I’ll rewrite the script in C.

Arguments of the script:

  • Interface of the attacking system (eth0);
  • EIGRP autonomous system number (1);
  • Subnet where the attacking system is located. In my case, the subnet is 10.10.100.0/24
~$ sudo python3 helloflooding.py --interface eth0 --as 1 --subnet 10.10.100.0/24

EIGRP Blackhole

The essence of this attack is a simple injection of a false route that will poison the routing table. Traffic to, say, the 10.10.100.0/24 network will go nowhere, causing a denial of service. Such an attack is called a Blackhole. The script routeinject.py **** will be the tool used to perform it. For this example, I will send traffic destined for host 172.16.100.140/32 to the black hole.

Arguments of the script:

  • interface of the attacking system
  • EIGRP AS number
  • IP address of the attacker
  • IP address of the target subnet whose traffic will be sent to the black hole
  • target subnet mask
~$ sudo python3 routeinject.py --interface eth0 --as 1 --src 10.10.100.50 --dst 172.16.100.140 --prefix 32

Our host seems to be in trouble :)

As you can see, the host loses connectivity to host 172.16.100.140/32 due to route injection.

Abusing K-Values

To establish EIGRP neighbors, routers use special K-values. They must be the same among all EIGRP neighbors. If at least one K-value does not match, the EIGRP domain will crash and the neighborhood will be broken. We will use relationshipnightmare.py **** to perform this attack**.**

Script arguments:

  • network interface
  • EIGRP AS number
  • IP Address of legitimate router

On behalf of the specified IP and will be sent an inject on the multicast EIGRP IP address, in which the K-values are different. In my case, I will break the neighborhood on behalf of router GW1 (address is 10.10.100.100).

~$ sudo python3 relationshipnightmare.py --interface eth0 --as 1 --src 10.10.100.100

Dump of traffic during a neighborhood disruption

GW1 router endlessly disconnects and reconnects EIGRP

A DoS attack can be carried out in this way. During operation, endless breakups and neighborhood attempts occur, paralyzing part of the EIGRP routing domain.

Routing table overflow

The essence of this attack is to provoke the sending of a huge number of false routes, which will overflow the routing table. This depletes the computing resources of the router, namely the CPU and RAM, since the injections occur at enormous speed. This attack is implemented routingtableoverflow.py script

Script arguments

  • network interface
  • EIGRP AS Number
  • Attacker’s IP address
in9uz@Inguz:~$ sudo python3 routingtableoverflow.py --interface eth0 --as 1 --src 10.10.100.50

After running the script, the routing table starts overflowing with routes. The random addresses of the target networks are due to the use of RandIP() in Scapy.

Routing table overflows on GW1 router

Overloaded router CPU

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥