Attacking and defending virtual Cisco routers on Backtrack (part 2 - Web and SSH)

In part one of this article (available here) I talked about using GNS3 to replicate and test virtual router networks. I also showed how the default setup of telnet on many Cisco products can be vulnerable to both sniffing and brute-force attacks, and how SSH can easily be implemented to provide more protection.

In this article, I will show how the default web UI on many Cisco routers can be a serious liability, and how to disable it, and also talk about a risk associated with SSH (demonstrating SSH brute-force).

Please remember to use these techniques only for legitimate educational and testing purposes and not maliciously.

So first let's talk about router Web UIs...


Cisco's horrible old Web UI

It's getting very old now, but it is a default on many router models. Yes, it's the Cisco hideous "pretend to be a console" Web UI.

This UI was designed years ago, when security was not seen as so much of an issue. This is a really nasty interface (which I find slower and more difficult to use than the command line). This UI is enabled by default, on many Cisco router models, with no security.

Due to the sticky nature of router and switch infrastructure (it is costly, and time-consuming to replace, and requires downtime) routers of this age and type are very common.

With this example, by default if you click on "15" you end up with an unauthenticated login, at Exec level 15, i.e. with full access to view and change the configuration, and with complete control of the router.

Even if this router is only accessible internally, I would say that this MUST be locked down from the defaults. As I described in the previous article you can add an enable password for some basic configuration security.

R0(config)#enable secret mypassword

This is a global change to the router, affecting multiple protocols, and will enable HTTP basic authentication. Though this is a slight improvement, there still some serious issues with that.

Issues with HTTP basic authentication

There are various issues with HTTP basic authentication which include; No lockout, no session limits or expiry, and the password is sent base64 encoded (i.e.in clear-text) so it can be sniffed of the wire.

Couple that with the fact that there is a known username (of "enable") and only the password needs to be guessed, this is a problem.

To show the plain text nature of this authentication method, we can issue either use a sniffer like tcpdump or Wireshark to intercept the HTTP headers. Below is an extract from the header including the base64 encoded password.

...

Keep-Alive: 300

Proxy-Connection: keep-alive

Authorization: Basic ZW5hYmxlOm15cGFzc3dvcmQ=

Encoding, is NOT encryption. Base64 encoding is designed simply to protect and represent binary data within text-based protocols. Decoding is trivial. Here is a useful site: http://www.opinionatedgeek.com/dotnet/tools/base64decode/

(Pasting in the "ZW5hYmxlOm15cGFzc3dvcmQ=" above, we get the username and password "enable:mypassword" as expected)

To brute-force a HTTP basic password with Hydra is trivial, and can be quick with targeted dictionaries. See the example below:

hydra -l enable -P rockyou100.txt 192.168.50.254 http-get /

WARNING: Restorefile (./hydra.restore) from a previous session found, to prevent overwriting, you have 10 seconds to abort...

Hydra v5.9 (c) 2010 by van Hauser / THC - use allowed only for legal purposes.

Hydra (http://www.thc.org) starting at 2011-05-07 11:33:53

[DATA] 16 tasks, 1 servers, 100 login tries (l:1/p:100), ~6 tries per task

[DATA] attacking service http-get on port 80

[80][www] host: 192.168.50.254   login: enable   password: secret

[STATUS] attack finished for 192.168.50.254 (waiting for childs to finish)

Hydra (http://www.thc.org) finished at 2011-05-07 11:34:05

Ok, so you may say, "I will lock this service down to just the IP addresses of my admin machines". I would say no; It's a pain to use, it's very insecure, just turn off this web UI completely with the following command.

R2(config)#no ip http server

Confirm this is done with nmap:

nmap 192.168.50.254

Starting Nmap 5.35DC1 ( http://nmap.org ) at 2011-05-07 12:30 BST

Nmap scan report for 192.168.50.254

Host is up (0.0019s latency).

Not shown: 999 closed ports

PORT   STATE SERVICE

22/tcp open  ssh

MAC Address: C0:00:2A:5A:00:01 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 7.03 seconds

Just SSH, that's better.

Cisco's Secure Device Manager (SDM)

Cisco made an effort to produce an improved GUI called SDM. Granted, it does look a lot better.

However, although it looks nicer and adds helpful ease-of-configuration, it suffers from some of the same HTTP basic authentication issues above so my advice is to switch it off, and learn how to configure a router properly, i.e. from the command line.

(Also SDM prerequisites may mean you have to use an insecure browser and java-plugin version and it can be a real pain to install, and get it working with your browser - It's really not worth the hassle)


SSH brute force

So, all we have open  is SSH, but that is not the end of the story. SSH can still be insecure as well.

Brute force is more difficult, because now an attacker needs to find a username password combination, but if this is an external router, an attacker still has as long as it takes to attack the SSH port to brute-force the password. There are many tools that can try hundreds of millions of attempts over an extended period of time until the username and password are guessed.

As we have seen Hydra a few times already, here is an example with Medusa:


medusa -h 192.168.50.254 -u bob -P ./passlist.txt -M ssh -F -m BANNER:SSH-2.0-ssh-client -v 4
Medusa v2.0 [http://www.foofus.net] (C) JoMo-Kun / Foofus Networks


ACCOUNT FOUND: [ssh] Host: 192.168.50.254 User: bob Password: blah [SUCCESS]


The more usernames and passwords configured on the system, the higher the risk that one combination will be found, and there are many bots on the web that will trawl for Telnet and SSH servers, and try to brute-force them with commonly used passwords. Choose strong and long passwords.

The answer is to lockdown SSH to just the administrative systems IP addresses, and on Cisco routers this can be done with extended access-lists to lock-down the vty lines, as follows (the administrators systems here are 192.168.206.128 and 192.168.206.130)


R3(config)#access-list 101 permit tcp host 192.168.206.128 any eq 22 log
R3(config)#access-list 101 permit tcp host 192.168.206.130 any eq 22 log
R3(config)#access-list 101 deny ip any any log
R3(config)#line vty 0 4
R3(config-line)# access-class 101 in
R3(config-line)# transport input ssh
R3(config-line)# login local

Lockdown guidelines

There are some really useful and easy to follow lockdown guidelines for Cisco routers and switches (and much more besides) at the following location:

http://www.nsa.gov/ia/guidance/security_configuration_guides/index.shtml