Monitoring OSPF Routing Protocols

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.

Figure 1: An attacker tries to blackhole the server segment

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 11.11.11.0/24, which contains all the business-critical servers. When a new subnet 11.11.11.0/24 is advertised into OSPF by R3, all the routers in that OSPF area will be updated with 11.11.11.0/24 in their routing table. If we look at the R1/R2/R4 routing table, it will contain information to reach 11.11.11.0/24. The gateway is 192.168.145.147, which is an R3 router interface.

Figure 2: Routers in the OSPF area are updated in the routing table

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 11.11.11.0/24 and sends it to the other routers in that same OSPF area. The created packet is called a link-state advertisement (LSA) packet.

Figure 3: Link-state advertisement packet captured over the wire

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 11.11.11.0/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 11.11.11.0/24 does not exist behind R3, R2, in turn, will convey that message to R3 that 11.11.11.0/24 is not behind R3 anymore. Immediately, R3 will respond with a new LSA packet indicating that someone gave false information. Actually, 11.11.11.0/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.

Figure 4: The OSPF fight back mechanism will prevent an attacker from falsifying the routing table

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 11.11.11.0/24 does not exist behind R3 — where the advertising router is equal to the victim router’s ID.

The R3 router ID is 30.30.30.30 (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).

Figure 5: A router will fight back only if the link-state ID is the same as the victim router’s 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 30.30.30.30 (refer to Figure 6) and advertising router is 130.130.130.130, which exploits the vulnerability and allows the attacker to falsify the routing tables.

Figure 6: In this example, an attacker can falsify the routing table

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.

Figure 7: The OSPF database is poisoned with false information

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.

Figure 8: A router’s uptime as shown from a Cisco blog

Figure 9: Another uptime example

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.

Figure 10: You can use NetMon in a single location to send OSPF LSA updates to all routers

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.

Figure 11: Deep Packet Analytics script

After executing the well-crafted attack packet, an alarm triggers where the link-state ID is different from the link-state advertising router.

Figure 12: An alarm triggers alerting that the link-state ID is different from the link-state advertising router

Figure 13: Further details showing the link-state advertising router

Figure 14: Drilling down to the exact metadata for OSPF protocol

Figure 15: Additional custom metadata fields are created and forwarded to the SIEM

Figure 16: LogRhythm’s AI Engine shows that the link-state advertising route is not equal with the global identity

Figure 17: Drill down for the trigger attack

Figure 18: Extracted metadata information from the alarm drilldown

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!