Despite your best efforts to protect your organization, an attacker can control an entire routing domain with a single spoofed packet. An attacker does not have to join the Open Shortest Path First (OSPF) neighborhood routers. Instead, the attacker could be stealthy and sniff the network, crafting a malicious packet to tamper with the routing table.
Let’s dive into an attacker’s potential path and how to control the routing table with a single packet using LogRhythm NetMon.
Exploring an Attacker’s Intention
In the following scenario, let us assume that the attacker’s intention is to blackhole the server segment, which is the server zone. Blackholing means the server segment is no longer available to any users.
For this use case, let’s assume this is a newly built infrastructure, and the organization created a server zone segment behind router R3. The subnet for the server zone is 184.108.40.206/24, which contains all the business-critical servers. When a new subnet 220.127.116.11/24 is advertised into OSPF by R3, all the routers in that OSPF area will be updated with 18.104.22.168/24 in their routing table. If we look at the R1/R2/R4 routing table, it will contain information to reach 22.214.171.124/24. The gateway is 192.168.145.147, which is an R3 router interface.
As you might recall from the “Monitoring OSPF Neighbors for Eavesdropping” blog post, OSPF is a link-state routing protocol. Every router in the OSPF network will form a trusted relationship with the neighbor routers.
For this example, we will create this new server subnet as a normal operational scenario and advertise it into OSPF. Router R3 creates an OSPF packet (refer to Figure 1) with the new subnet 126.96.36.199/24 and sends it to the other routers in that same OSPF area. The created packet is called a link-state advertisement (LSA) packet.
An attacker could mimic any router in the network, create a LSA packet, and falsify the neighbor router’s routing table. This would tell the neighbor router that 188.8.131.52/24 does not exist anymore. Unfortunately, this does not work due to the OSPF fight back mechanism.
The OSPF fight back mechanism occurs when a router observes a LSA that states falsehoods about itself. This mechanism prompts the router to immediately send another LSA to set the record straight.
For example, when an attacker (192.168.145.145) who is connected in the same OSPF area mimics as R1 and then advertises R2 that 184.108.40.206/24 does not exist behind R3, R2, in turn, will convey that message to R3 that 220.127.116.11/24 is not behind R3 anymore. Immediately, R3 will respond with a new LSA packet indicating that someone gave false information. Actually, 18.104.22.168/24 exists behind R3, which is R3 itself. It’s important to update your routing table with the latest information.
So, this attack does not work. An attacker will fail to falsify the routing table due to the OSPF fight back mechanism.
Exploring the Vulnerability
Interestingly, a researcher found a vulnerability in the OSPF RFC 2328 and presented it at a Black Hat conference. The vulnerability is that the OSPF RFC specification does not require a check to verify this on LSA reception by the receiving router. If the victim’s router receives a false LSA, having the advertising router is different from the victim link state router ID, which is just an identifier. This will allow the attacker to falsify the routing table.
Crafted LinkstateID Equals Advertising Router ID Packet
In this scenario, we built a OSPF LSA packet using Scapy (refer to Figure 4) and sent the false information that 22.214.171.124/24 does not exist behind R3 — where the advertising router is equal to the victim router’s ID.
The R3 router ID is 126.96.36.199 (refer to Figure 5). This is the same as the advertising router ID and link-state ID. Both must be the same for the OSPF fight back mechanism to trigger, causing the attacker to fail.
A router will fight back only if it receives a false LSA in which the link-state ID is the same as the victim router’s ID (advertising router ID).
Both the ‘link-state ID’ and ‘advertising router’ must have the exact same value. However, the OSPF spec does not specify a check to verify this equality on the router LSA reception. Researchers exploited this vulnerability.
Crafted LinkstateID Does Not Equal Advertising Router ID Packet
The crafted packet is sent with a linkstate ID of 188.8.131.52 (refer to Figure 6) and advertising router is 184.108.40.206, which exploits the vulnerability and allows the attacker to falsify the routing tables.
Any router in the same area receives this false information. As a result, the server segment won’t be reachable. Figure 7 shows R2 where the OSPF database is poisoned with false information. Blackhole is one method in which the server segment is no longer available to any users. If an attacker could control a router in an OSPF domain, they could shift the subnet through any other gateway for a longer route and conduct more malicious activities.
Why is this attack still valid in a OSPF routing domain? Routers are always treated as an operational device. Router and switch uptime tell us why this type of targeted attack is still valid. Since many organizations don’t upgrade their routers that often, a security team is not aware when the router firmware goes through an upgrade or either the routers are considered just to route traffic.
How to Detect This Attack with NetMon
An organization could have more than 70 routers in one OSPF single area. However, you don’t need to position LogRhythm NetMon in every router location. NetMon should be positioned in a single location, as OSPF LSA updates are sent to all routers. That will ensure that the routing databases are identical so positioning behind one OSPF router is all that’s needed to detect this attack.
Why is LogRhythm’s deep packet analytics important? In this scenario, detecting this type of attack requires us to look for an OSPF packet where the advertising router does not equal the victim router’s ID.
After executing the well-crafted attack packet, an alarm triggers where the link-state ID is different from the link-state advertising router.
Monitoring routing protocols is crucial in every organization. LogRhythm NetMon can help you decode OSPF protocol packets on the wire and search for maliciously crafted packets with deep packet analytics. In addition, NetMon can help you extract the required OSPF fields from the packets and then forward it to the SIEM as an alert.
Tell us how LogRhythm NetMon has helped you!