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 LabInitially 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: http://www.c0decafe.de/loki.html
Cisco 1841 Router config:
service timestamps debug datetime msec
service timestamps log datetime msec
no aaa new-model
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
dns-server 184.108.40.206 220.127.116.11
ip address dhcp
no cdp enable
ip address 192.168.1.254 255.255.255.0
ip nat inside
router ospf 1
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
line con 0
line aux 0
line vty 0 4
access-class 1 in
transport input ssh
scheduler allocate 20000 1000
ExploitationExploitation 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 18.104.22.168/32 and 22.214.171.124/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 126.96.36.199/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 188.8.131.52 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.
MitigationThis 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.