Sunday 3 May 2015

Widening Attack Landscape with OSPF Route Injection.


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.

The only additional tool I have installed into my Kali build for this is Loki which can be found here:

Cisco 1841 Router config:
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
hostname TEST_RTR
no aaa new-model
resource policy
ip cef
no ip dhcp use vrf connected
ip dhcp excluded-address
ip dhcp excluded-address
ip dhcp pool DHCP_POOL
interface FastEthernet0/0
description OUTSIDE
ip address dhcp
duplex auto
speed auto
no cdp enable
interface FastEthernet0/1
description INSIDE
ip address
ip nat inside
duplex auto
speed auto
router ospf 1
network area 0
ip route 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 any
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



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 and 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, 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 will be routed back onto the internal network to, 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.



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:



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.

1 comment:

  1. You're better off just running a virtual router in vmware workstation or virtualbox and connect to the network and configure it for OSPF. Then, just create your dnsspoof on another box. Just a thought to keep things ... in the same context.