Widening Attack Landscape with OSPF Route Injection.

Introduction

A basic overview of how we can leverage poorly configured OSPF network configurations to compromise campus networks and increase the attack landscape for further attacks.

As a former network engineer I tend to have a slightly skewed view on network attack vectors and I wanted to experiment with these for my new role as a penetration tester. Here I will discuss how we can use the OSPF routing protocol for evil.

 

The Lab

Initially I attempted this testing with a GNS3 environment but I despite all my efforts I was unable to form an OSPF neighbour adjacency using the Loki toolkit. I moved on to a physical lab setup but I'm still finding the Loki tool very flaky at maintaining relationships, It the real world It may be easier to have a small physical router to inject the routes from.

Kali and Windows 7 are VM's running on my laptop, SW1 represents the vSwitch in VirtualBox. Both VM's have bridged networking to Ethernet which is directly connected to the Cisco 1841 router. The Internet cloud is fictitious.

Loki:
The only additional tool I have installed into my Kali build for this is Loki which can be found here: http://www.c0decafe.de/loki.html

Cisco 1841 Router config:
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname TEST_RTR
!
boot-start-marker
boot-end-marker
!
no aaa new-model
!
resource policy
!
ip cef
!
!
no ip dhcp use vrf connected
ip dhcp excluded-address 192.168.1.1 192.168.1.100
ip dhcp excluded-address 192.168.1.200 192.168.1.254
!
ip dhcp pool DHCP_POOL
network 192.168.1.0 255.255.255.0
default-router 192.168.1.254
dns-server 8.8.8.8 8.8.4.4
!
interface FastEthernet0/0
description OUTSIDE
ip address dhcp
duplex auto
speed auto
no cdp enable
!
interface FastEthernet0/1
description INSIDE
ip address 192.168.1.254 255.255.255.0
ip nat inside
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes
network 192.168.1.0 0.0.0.255 area 0
!
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 dhcp
!
!
no ip http server
no ip http secure-server
ip nat inside source list 101 interface FastEthernet0/0 overload
!
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
!
control-plane
!
line con 0
logging synchronous
line aux 0
line vty 0 4
access-class 1 in
logging synchronous
login local
transport input ssh
!
scheduler allocate 20000 1000
end

 

Exploitation

Exploitation is pretty straight forward thanks to the simple Loki GUI, although as mentioned in the introduction the neighbour relationships can be pretty flaky, I found the relationship and injection processes may just stop working at random and require a reload of Loki.
Here is the output of OSPF neighbours and ip route before we begin:

 
After we fire up Loki and hit start we can see our peer HELLO packet is detected

 
All we need to do is hit the 'Hello' button and Loki will attempt to negotiate a neighbour relationship with our peer router….

 
And on the 1841 we can see we are stuck in Exchange… classic Loki. I'll have to restart Loki a couple of times until I get a success…

 
A couple of tries later and we have successfully negotiated a full relationship.

 
Now for the route injection. For the demo I will be injecting a false route to googles DNS servers, I would do this by injecting the routes 8.8.8.8/32 and 8.8.4.4/32 to avoid causing noticeable network issues. However, as Loki is not the most reliable and crashes far too frequently for my liking I will only inject a route 8.8.0.0/16, it seems to fall apart when injecting more than one route.
Or at least this was my plan. Loki seems to have gotten one of the first parts of my demo stuck and will not inject any further routes so we will have to roll with that we have for now to complete the demo.

Not what we wanted but we can deal with this for demonstration purposes.
Now any network traffic destined for 8.8.4.4 will be routed back onto the internal network to 192.168.1.175, This is great for us! From here the world is our oyster, we can do anything we want with network traffic when we can manipulate the routes. For the demo I will launch dnsspoof in Kali.

 
And then from our Window 7 Victim VM we can see that any DNS requests we believe are going to google are actually being answered by dnsspoof and returning the IP of our own server.

 

Mitigation

This type of attack can be easily mitigated by implementing a few security best practices, for Cisco networks you should make use of the passive-interface command to prevent OSPF hello's propagating the internal network on interfaces where they are not required. In addition it would be sensible to apply OSPF password authentication to prevent unauthorised neighbour relationships.
Further reading on these can be found here:
http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13697-25.html

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/xe-3s/iri-xe-3s-book/iri-default-passive-interface.html


 

Conclusion

I hope this article has demonstrated just how easily network traffic can be manipulated and if any network admins stumble upon this article I really hope they will think to take a second look at their network configurations and implement some of the mitigation techniques above.

While Loki in principle is a great toolkit, in practice is it very unreliable and frustrating to work with. If I can find more time to dedicate to this specific topic I would look to either fix Loki or develop my own toolkit for performing these types of attack.

It would be easy to think that these type of poor network configurations do not exist in the wild, but in my experience they are far more common than we would like to think.