Attacking and defending virtual Cisco routers on Backtrack (part 1)

Learning how to secure routers in a safe environment is important lesson, so here is an attack-and-defense lesson on virtual Cisco routers, using GNS3 from within Backtrack 4.

GNS3 is a great tool for simulating router configurations, but it can also be connected to real networks for security testing of configurations and topologies for example.


Setup GNS3 on Backtrack-Linux

To install GNS3 on Backtrack use the following:

apt-get install gns3

You can also add the following tweak to the terminal configuration (which i find better because I prefer konsole) Go to...

Edit > Preferences > General > Terminal command

Change it to:

/opt/kde3/bin/konsole --notabbar --nomenubar -T %d -e /usr/bin/telnet %h %p >/dev/null 2>&1 &

Then we need to add a tunnel adapter to our backtrack system so that we can interact with the virtual router environment:

apt-get install uml-utilities
tunctl
ifconfig tap0 172.16.10.5/24



Add a test router and connect GNS3 to backtrack

We need to create our router to attack, and configure it:

Add a router to the network (make sure you choose a router IOS image with encryption capabilities, as we will add SSH later in this example) and add a cloud node that we will configure as our backtrack tap0 interface.

Configure the cloud node with a tap interface of tap0..

... and then link the two together with a FastEthernet connector.

Then we can configure the IP address of the interface on the router (using the console, by right-clicking the router) and ping the backtrack machine to test connectivity, as follows:


Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#int f0/0
Router(config-if)#ip address 172.16.10.254 255.255.255.0
Router(config-if)#^Z
Router#
*Mar  1 00:33:28.903: %SYS-5-CONFIG_I: Configured from console by console
Router#ping 172.16.10.5


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.5, timeout is 2 seconds:
.!!!!

Great, we have our GNS virtual networking environment connected to the backtrack host, and we can attack routers within it as if they were real ones!

Scan the router from backtrack

We can now scan this virtual router with nmap as follows:


nmap 172.16.10.254


Starting Nmap 5.35DC1 ( http://nmap.org ) at 2011-05-02 13:20 BST
Nmap scan report for 172.16.10.254
Host is up (0.0053s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE
23/tcp open  telnet
80/tcp open  http
MAC Address: C0:04:17:7E:00:00 (Unknown)


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


So, we see that telnet and http are open ports... Muhahaha....


Brute forcing telnet user and enable passwords

First we need to setup a password, to allow remote access to the router over telnet (then we will do a test attack)

In order for a Cisco router to accept telnet connections, it must have login enabled, and a password defined.On our router:


Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#line vty 0 4
Router(config-line)#password cisco
Router(config-line)#login
Router(config-line)#exit
Router(config)#enable password cisco
Router(config)#^Z
Router#



Now then, obviously those passwords are rather weak... time to prove the concept of pwning this router using Hydra from the Backtrack system:


hydra 172.16.10.254 cisco -s 23 -P passlist.txt -t 1 -w 2
Hydra v5.9 (c) 2010 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2011-05-02 14:03:02
[DATA] 1 tasks, 1 servers, 3 login tries (l:1/p:3), ~3 tries per task
[DATA] attacking service cisco on port 23
[23][cisco] host: 172.16.10.254   login:    password: cisco
[STATUS] attack finished for 172.16.10.254 (waiting for childs to finish)
Hydra (http://www.thc.org) finished at 2011-05-02 14:03:02


Once we have a user-level login, we can use hydra to get our enable password as follows:


hydra 172.16.10.254 cisco-enable -s 23 -l cisco -P passlist.txt -t 1 -w 2
Warning: You did not supply the initial support to the Cisco via -l, assuming direct console access
Hydra v5.9 (c) 2010 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2011-05-02 14:05:05
[DATA] 1 tasks, 1 servers, 3 login tries (l:1/p:3), ~3 tries per task
[DATA] attacking service cisco-enable on port 23
[23][cisco-enable] host: 172.16.10.254   login: cisco   password: cisco
[STATUS] attack finished for 172.16.10.254 (waiting for childs to finish)
Hydra (http://www.thc.org) finished at 2011-05-02 14:05:10

Weaknesses of Telnet and the default Cisco setup

So theoretically, if we have a large list of passwords to try, the router is ours for the taking. Also, because telnet transmits passwords in cleartext, sniffers can detect these passwords.

Here is a transcript from Wireshark showing the password transmitted over the wire:

Additionally, we just have a password currently, rather than a username and password combination.
Just to give you an idea of the relative strength of 2 passwords vs. a user password combination.

To test 2 x passwords with a 10,000 dictionary, we are looking at a maximum of 20,000 attempts, but to attack the username-password combination with the same dictionary, we are looking at 100 million attempts. That's a big difference (If you choose the username to be secure as well).

Configuring SSH on the router

For reference more details can be found on the Cisco website here:
http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a00800949e2.shtml

We are going to need to setup up a username and password and set login local.

Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#username fred secret anicelongpassword
Router(config)#line vty 0 4
Router(config-line)#login local
Router(config-line)#^Z
Router#

This has an immediate benefit over the default, because a username password combination, is much stronger than a password.

Then to setup SSH there are a few things to note. Firstly, you must have a hostname other than the default defined, and set a domain name.

Also we will be using SSH2 because of the serious security issues with SSHv1 (this means that the minimum key length is also increased to 768)

Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#hostname R3
R3(config)#ip domain-name r3.insidetrust.com
R3(config)#ip ssh version 2
R3(config)#crypto key generate rsa
Choose the size of the key modulus in the range of 360 to 2048 for your
  General Purpose Keys. Choosing a key modulus greater than 512 may take
  a few minutes.


How many bits in the modulus [512]: 768
% Generating 768 bit RSA keys, keys will be non-exportable...[OK]


R3(config)#
*Mar  1 02:15:18.471: %SSH-5-ENABLED: SSH 2.0 has been enabled

So let's login and test it:

Great, it works!

Don't forget to disable telnet!

So, we have SSH working, but if we scan the host again, we will see that Telnet is still enabled:

nmap 172.16.10.254

Starting Nmap 5.35DC1 ( http://nmap.org ) at 2011-05-02 15:01 BST

Nmap scan report for 172.16.10.254

Host is up (0.0058s latency).

Not shown: 997 closed ports

PORT   STATE SERVICE

22/tcp open  ssh

23/tcp open  telnet

80/tcp open  http

MAC Address: C0:04:17:7E:00:00 (Unknown)

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

We need to disable Telnet on the router as follows:

R3#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

R3(config)#line vty 0 4

R3(config-line)#transport input ssh

(You may also need to do the same for "line vty 5 15" if you have a newer IOS)

Once this is done, another quick scan with nmap, will show that Telnet is no more.

nmap 172.16.10.254

Starting Nmap 5.35DC1 ( http://nmap.org ) at 2011-05-02 15:19 BST

Nmap scan report for 172.16.10.254

Host is up (0.0020s latency).

Not shown: 998 closed ports

PORT   STATE SERVICE

22/tcp open  ssh

80/tcp open  http

MAC Address: C0:04:17:7E:00:00 (Unknown)

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

SSH2 is a much more secure protocol that Telnet (as long as you choose a strong username and password).

We still have a web-UI exposed though, and I will cover attacking the web-UI in another post, but that definitely needs to be locked down as well!

Part 2 of this article is here:
http://insidetrust.blogspot.com/2011/05/attacking-and-defending-virtual-cisco.html