Monday, 23 May 2011

Finding alphanumeric jump addresses for buffer-overflow exploit development

Buffer-overflow exploit-development can sometimes be challenging for services which use protocols that have restricted character-sets.

In a previous blog on bad-characters, I talked about ways to encode payloads so that problem special characters can be avoided in exploit payloads.

Whilst that is fine for "introducing" code to the target system, an attacker also needs to hijack code execution to run the malicious payload. This is done by controlling EIP through putting a jump address within the buffer. This jump address perfectly overwrites EIP, (either directly as part of the function epilogue, or via a Structured Exception Handler) to redirect code execution to the malicious payload.

For very restrictive protocols (text-only for example) finding a working jump address in memory can be challenging.

Here is one approach to finding useable jump addresses, using a couple of Metasploit tools (and a bit of grepping).

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

Dumping memory

In this example, I am experimenting with a Windows application crash.

We can dump all the accessible memory for the target process, using memdump.exe, which is available in the MSF included with Backtrack 5 in the following directory:


This tool needs to be transfered to the target Windows system and run on the target process in its crashed state, as follows:

memdump.exe <process id> <output dir>

This produces a directory full of files which can then be zipped, and transferred back to the Backtrack 5 system and unpacked.

Scanning the dump

To scan this process dump, we can use msfpescan to extract the jump addresses, from the memory locations which were available to the process.

This example would find a pop, pop, ret, for a SEH exploit:

/pentest/exploits/framework3/msfpescan -p -M ./dumpdir > scanresults.txt

Or here for example we look for the classic "jmp esp":

/pentest/exploits/framework3/msfpescan -j esp -M ./dumpdir > scanresults.txt

We can then sort through the results to remove addresses with characters that cannot be used in a restricted buffer

Removing unusable addresses

Grep can be used to filter these results in various ways.

Here we grep to remove addresses that contain null bytes, or 0x0a, and 0x0d (CR/LF characters).

cat scanresults.txt | grep ^0x | grep -v "^0x00\|0a\|0d" | grep -v "^0x..00\|0a\|0d" | grep -v "^0x....00\|0a\|0d" | grep -v "^0x......00\|0a\|0d" | sort

Here we grep for addresses which don't have any non-alphanumeric in any of the 4 octets:

cat scanresults.txt | grep ^0x | grep -v "^0x[0-2\|8-9\|a-f]\|3a\|3b\|3c\|3d\|3e\|3f\|40\|5b\|5c\|5d\|5e\|5f\|60\|7b\|7c\|7d\|7e\|7f" | grep -v "^0x..[0-2\|8-9\|a-f]\|3a\|3b\|3c\|3d\|3e\|3f\|40\|5b\|5c\|5d\|5e\|5f\|60\|7b\|7c\|7d\|7e\|7f" | grep -v "^0x....[0-2\|8-9\|a-f]\|3a\|3b\|3c\|3d\|3e\|3f\|40\|5b\|5c\|5d\|5e\|5f\|60\|7b\|7c\|7d\|7e\|7f" | grep -v "^0x......[0-2\|8-9\|a-f]\|3a\|3b\|3c\|3d\|3e\|3f\|40\|5b\|5c\|5d\|5e\|5f\|60\|7b\|7c\|7d\|7e\|7f" | sort

(That last one looks a bit horrible. There may be a shorter way to grep this,  but this is effective as a cut'n'paste hack)

The results look like this:

0x74723956 pop esi; pop ebp; retn 0x0004
0x74724a6b pop esi; pop ebp; retn 0x0004
0x74734e36 pop esi; pop ebp; retn 0x000c
0x7473526c pop esi; pop ebp; retn 0x000c

As you can see, these addresses contain only the usable characters.

So it would then be just a question of cross-referencing these addresses with the dlls you want to use (based on various criteria such as portability and protection bypass) and choosing ones that will work for the exploit.

Friday, 20 May 2011

Easy Nessus scan for a beginner with Backtrack 5

I have got to say that the inclusion of Nessus in Backtrack 5 is great. This makes performing a basic vulnerability scan easy.

UPDATE: - In Backtrack 5 R1 you will need to additionally download and install Nessus, which I have briefly described in the following post

The rest of the setup

1) Get a free home-use key on the Tenable/Nessus website

2) Enter the key as follows

/opt/nessus/bin/nessus-fetch --register xxxx-xxxx-xxxx-xxxx

3) Create a user and password (and hit enter to skip the rules)


4) Start the service

/etc/init.d/nessusd start

5) Start the scan, and view the report


The Nessus user-interface is so straight-forward that don't think there is any point in me describing where to click or what to put in. Just play with it for a minute or two and you should see how it works.

Using Nessus to scan a set of machines really is a no-brainer. Here is a sample report (This XP systems needs patching ;o)

Whilst this is no substitute for a Penetration test, a basic vulnerability scan can certainly help identify computers that are missing patches, or have poor configurations.

Thursday, 19 May 2011

Overcoming problems installing Backtrack 5 on a system

I had a challenging couple of hours today getting Backtrack 5 running on my main Desktop system.

Having tried the VMs, and and also installed the 32bit KDE version on one of my laptops (both of which were very straight forward) I thought I would bite-the-bullet, backup the data from my main research system, blow it away, and install Backtrack Linux 5 on that as well.

Unfortunately I ran into a few issues, with installation drives, and graphics drivers.

So here are some notes on solutions (more for me to remember than anything, but may be helpful to someone else?)
Boot-loader issues

There seems to be something odd about the partitioning and boot-loader installation in Backtrack 5. I have multiple drives, one of which is a striped-pair. It didn't seem to be writing the boot-loader to the correct drive. Not sure why, but to work around this, I popped out the cables for my RAID array disks, and installed on the single 500GB OS disk (with no other live disks in the chassis at the time) and that seemed to resolve it.

Graphics-driver woes

I have an on-board Nvidia card, which I know has produced some issues before, with my Backtrack 4 R2 install. No surprise, I needed to do some extra fiddling again to get this to work.

After the install, "startx" was crashing-out with various errors telling me that there were no suitable devices for X to run on.

(This was despite the fact that graphics drivers on the live DVD were working fine)

The solution to this was to use a proprietary Nvidia driver-installation script. This also requires the kernel-sources to be downloaded and unpacked as follows:


(If you need to do this, go and make a cup of tea while this downloads and unpacks)

cd /usr/src/linux
cp -rf include/generated/* include/linux/

However, the configuration script I had previously used with Backtrack 4 R2 ( did not work, but luckily a more recent script did (
(I hadn't been able to get that one working with Backtrack 4 R2)

I then ran the Nvidia driver install as follows, and bingo, it worked:

./ --kernel-source-path='/usr/src/linux'

You can get the latest drivers from here:

Setting up the rest of my lab

The VMWare-player install went seemlessly (just using the "VMware-Player-3.1.4-385536.i386.bundle" script file from the VMware website) and I have copied on my archived virtual-victim-lab.

So now I have a working online Backtrack 5. Hurrah!

Here are a few extras I have installed:

apt-get -y install gns3 tftp vlc gimp vsftpd xchat kcalc mplayer kate okular uml-utilities ktorrent k3b kmag ksnapshot

Now it's just a question of getting used to KDE 4.5 (which seems quite different to KDE 3.x).

Missing things

There seem to be some other things that I am used to seeing on Backtrack 4, that are either not there, or have changed significantly, I guess I will figure those out my immersing myself with some exploit development over the next few days.

Anyway, time for some pwnage...

Wednesday, 18 May 2011

Nmap nse broadcast scanning in Backtrack 5

One of the more recent developments in nmap, over the past couple of years, is the addition of nmap nse scripts making nmap a much more flexible and expandable network-mapper and vulnerability-scanner (it seems like there are many more scripts being contributed with every release).

There are now over 170 different scripts included by default in nmap. (I've been playing with nmap version 5.51, which comes with Backtrack 5)

One of the more interesting new types of nse scripts are the broadcast discovery scripts, which I feel are certainly very interesting currently. To me, it looks like these new scanning techniques will become much more important in the future, as more IPv6 is deployed and used, and IPv4 gradually wanes. (though I do think some IPv4 could be around for another 15-20 years, these protocols will gradually decrease in importance)

IPv6-only networks mean a lot of changes in the way hosts can be discovered, as scanning entire net-blocks will become much more difficult due to the vast size of the address-space, but broadcast scanning, and passive sniffing can help identify IPv6 systems.

I've seen it reported that "nse broadcast-scans, are stealthy because they are passive". This is not true, they are still active scans. However, they are very low traffic scans, which attempt to discover network services using inbuilt ease-of-use functionality in the target network. (This type of scanning is perhaps something that could be done early in reconnaissance or discovery as a first network scan.)

What are broadcast scans?

Rather than UDP or TCP port-scans or network scans using ICMP or ARP, broadcast scans are a lot less intrusive. Think of broadcast scans as nmap saying:

"Hi there. I'm new on the network. Do any computers out there have any services I might want to use?"

Whilst this sounds a bit dumb from a security perspective, there are lots of computers and various protocols that could respond, even systems that have firewalls enabled with all ports blocked will respond in some cases.

From a network visibility perspective, we are also talking about only a very few packets per protocol, rather than the thousands required for a port-scan, and these "conversations" should be normal on the network, so this is much less likely to be detected by network security software.

I set up a couple of systems in my test network. Broadcast scans don't need an IP address range. They are simply run like this:

nmap -P0 --script=broadcast

..and here is one of my initial results

This shows Universal Plug and Play running on a couple of systems which lets us know of their existence. As you can see from a wireshark capture, this is not a passive scan, but is low bandwidth:

Here is another example with Web Services Dynamic Discovery responding (this is another Windows 7 system on my test network).

nmap -P0 --script=broadcast

Starting Nmap 5.51 ( ) at 2011-05-18 05:23 EDT
Pre-scan script results:
| broadcast-wsdd-discover:
|   Devices
|         Message id: c6cf6b9b-834d-4320-85e1-e1a65299ee2f
|         Address:
|_        Type: Device pub:Computer
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 40.08 seconds

The responses

So these responses for the target systems are basically telling us their IP address (in this case with its IPv4 address) the fact that the system has a HTTP service, and a service it might be running. Basically, following the broadcast, these systems are contacting the attacker to the him their addresses.

In both these cases Windows 7 has the firewall enabled (with default "secure" settings, so you be the judge of whether this is a good default behavior or not).

So, in short, I think we will be hearing a lot more about broadcast-based service scans, (and also passive data collection) as IPv6 rolls out in corporate infrastructure.

Monday, 16 May 2011

Building a web-application hacking lab - to practice web attacks

One of the most important aspects of improving your web-application security-testing skills, is practice. There are a wealth of attack vectors in modern feature rich web-applications, and familiarity with the various attacks and tools are key to finding and plugging holes.

Web application problems

There are many categories of web-application exploits; from ones that most security professionals should have heard of, such as XSS, SQL-injection, session-hijacking and authentication bypass, to less well known techniques, such as; fixed-sessions and session prediction, cross-site-request-forgery (CSRF), XPath-injection, LDAP-injection, SOAP-injection, OS command and script injections, CGI overflows and format-string vulnerabilities, local and remote file inclusion (RFI/LFI), directory traversal, logic-flaws, encoding and canonicalization issues.

There are also insecure client-side code and input-validation issues such as AJAX UIs, Java applets and flash components (which can be decompiled and changed) and the end-user to consider.

In short, there are many potential problems in modern websites and web UIs.

The attackers toolkit

There are many tools available to the attacker can use, some of which are very advanced and simple to use. These can range from the very noisy bruteforce, fingerprinting and spidering tools, to very stealthy attack-frameworks with encoding/encryption to prevent detection.

Some tools have inbuilt abilities to pivot from a compromised system and attack other machines. There are also some very well written frameworks that focus on client-side exploitation, such as XSS and CSRF, social engineering, browser exploits, and various spoofing and session-hijacking techniques to attack end-users.

There are hundreds of tools for web-application attacks. Here are some of the main opensource or free ones (in no particular order); Nikto, wfuzz, Webscarab, skipfish, Paros, Burpsuite, SET, BeEF, Grendel scan, HTTPPrint, sqlmap, Tamperdata, wget, curl, Cewl, Fierce, Dirbuster, the list goes on and on...

Building a web-application hacking lab

So, with dozens of technique types, hundreds of tools available to exploit them, and many thousands of potential exploits out there, it is important to constantly practice techniques to stay ahead of the game. One of the best ways to do this is in a virtual lab, using one of the many virtualization technologies, such as vmware, virtual-server, virtual-box etc. I use vmware player currently, but use whatever you think is best for you.

I am currently using three systems as my attack systems, Backtrack 4, 5 and SamuraiWTF. These are both Linux distrobutions which have various hacking tools preinstalled and configured.
(SamuraiWTF is more focused specifically on Web attacks, where as I would consider Backtrack as "The Daddy" of Security Distros, covering pretty much every attack vector.)

Safely attacking target systems with known vulnerabilities

There are various applications and Linux distributions that have been released specifically to help security experts learn about vulnerabilities, and practice exploitation. These deliberately-vulnerable test systems often come as VMs or Live CDs which you can fire up and attack. Some of the more popular ones include:

Damn Vulnerable Web Application (DVWA)
WebGoat (included with WS Dojo below)
Maven Web Security Dojo
Damn Vulnerable Linux (DVL)

I would consider all of these worth downloading, as they are quick to set up and attack in a virtual lab, so are great to practice your skills on. However, as these are all designed to be vulnerable, and the exploits are often documented, so they are typically easier targets than real applications.

However, there is quite a lot there to keep you whist you are learning the tools.

Potentially exploitable systems with unknown status

There are also many free virtual appliances and web applications that you can download and test in your own virtual environment. For example, there are thousands of free and evaluation virtual appliances on the vmware virtual-appliance marketplace site (check the T's and C's first ;o)

Though the above are mostly Linux systems, in my lab I also have various virtual Windows systems, where I can install free and evaluation applications to test them out.

Testing unknown apps can help sharpen your techniques; as when you don't know what you are looking for, you have to map the application properly, and try lots of options see what you can find.

You can also help the IT community as a whole if you find and report issues to try to get them fixed by the software vendor, so that is good for everyone.

Thursday, 12 May 2011

Vmware still promoting a very old "browser-appliance.1.0.0"

I was on the vmware site earlier this week, and noticed that they are still hosting a very old "browser-appliance.1.0.0". (I got this in a "promoted link" when I was looking for virtual appliances).

Back in 2006, this was intended to be a "safe" virtual browser environment.

"The Browser Appliance allows users to securely browse the Internet using Mozilla Firefox. Run the Browser Appliance with VMware Player to - Protect Against Adware and Spyware and Safeguard Personal Information"

 You would use the browser in the VM, instead of your own browser, to improve your internet security:
...but it is way too old, and if you were to use this now, you are reducing your security a great deal.

Attacking this platform

I took a look at this version, from an attack perspective:
  • It is an Ubuntu 5.10, with a 2.6.12 kernel, and Firefox 1.0.7.
  • It also has no inbuilt security features, such as antivirus, anti-spyware, or script detection
  • These type of appliances have known default passwords, and it doesn't prompt you to change them
There are many known vulnerabilities against these versions, enabling complete system compromise.

If you use it, the VM can easily be compromised, and any subsequent browsing you do through it will be at risk (not to mention that; once the VM is pwned, it can be used to pivot an attack against your internal network)

I can imagine someone downloading this, (or still using this from yester-year) to do their internet banking.

vmware recommending this to me this week is craziness!

I wonder how many other problem VMs are getting promoted on the site. Does anyone clear old ones off?

Here is a more up-to-date equivalent.

However, I question whether this is a valid approach for web security. It's a kind of cheap way of running a web-security proxy, but the platform is soon going to be out of date, so the average user would have to keep replacing the VM, to get a secure version, and if they forget, they become an easy target.

Bootnote: This is a handy platform for practicing your Metasploit hacking skills, but use it "Host-only" and don't surf the web with it!

Wednesday, 11 May 2011

Backtrack 5 released - my first look at it

After much anticipation Backtrack 5 is here, as promised and on schedule. I've downloaded and run up a VM. Here's my first screenshot of it. It looks cool:

I've gone with the Gnome VM, as I used to use Ubuntu, so I thought I would try it out with the Gnome desktop first. However, I am so used to KDE now, I may go back to that - not sure, too much choice!

I usually use Backtrack as my main OS (total immersion is good for learning all the tools). I will run this VM for a few days, before taking the plunge, blowing away BT4 and installing BT5.

One thing to note on the VMs is that they are packed with 7zip, so you will need to do the following to unpack them (if you are using BT4 as your main OS)

apt-get install p7zip
7z x BT5-GNOME-VM-32.7z

This is a very short post, as I am going to be busy today (My SANS 542 course-ware arrived this morning as well, so lots to do!)

(I can already see that more things work well straight out of the box)

Saturday, 7 May 2011

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 ( 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:

(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 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 ( 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:   login: enable   password: secret
[STATUS] attack finished for (waiting for childs to finish)
Hydra ( 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:


Starting Nmap 5.35DC1 ( ) at 2011-05-07 12:30 BST
Nmap scan report for
Host is up (0.0019s latency).
Not shown: 999 closed ports
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 -u bob -P ./passlist.txt -M ssh -F -m BANNER:SSH-2.0-ssh-client -v 4
Medusa v2.0 [] (C) JoMo-Kun / Foofus Networks

ACCOUNT FOUND: [ssh] Host: 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 and

R3(config)#access-list 101 permit tcp host any eq 22 log
R3(config)#access-list 101 permit tcp host 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:

Monday, 2 May 2011

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
ifconfig tap0

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
*Mar  1 00:33:28.903: %SYS-5-CONFIG_I: Configured from console by console

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, 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:


Starting Nmap 5.35DC1 ( ) at 2011-05-02 13:20 BST
Nmap scan report for
Host is up (0.0053s latency).
Not shown: 998 closed ports
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)#enable password cisco

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

hydra 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 ( 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:   login:    password: cisco
[STATUS] attack finished for (waiting for childs to finish)
Hydra ( 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 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 ( 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:   login: cisco   password: cisco
[STATUS] attack finished for (waiting for childs to finish)
Hydra ( 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:

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

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(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]

*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:


Starting Nmap 5.35DC1 ( ) at 2011-05-02 15:01 BST
Nmap scan report for
Host is up (0.0058s latency).
Not shown: 997 closed ports
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.


Starting Nmap 5.35DC1 ( ) at 2011-05-02 15:19 BST
Nmap scan report for
Host is up (0.0020s latency).
Not shown: 998 closed ports
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:

Sunday, 1 May 2011

Cost effective study for CCNA

Cisco's CCNA is a very useful qualification for an Ethical Hacker or Penetration tester, as it helps gain a good basic understanding of most LAN and WAN technologies, as well as configuration of Cisco routers and switches, which are commonly used in many networks.

Here are a few tips for studying for a CCNA on a limited budget.

Self study is best
For me, I usually find that self-study is the most effective, as it can be a waste of time listening to a tutor going over material I already know, just for a few gems that I don't.

I feel that I can usually cover more ground in less time with, Google,, some practical examples in a virtual environment, and a few books or articles on the web.

When studying for CCNA, I recommend using multiple study materials, including books, CBT, lots of real or simulated practice, and test material with realistic example questions.

Cisco website
First sign up for an account on the Cisco website. This gives you access to a fair bit of material, including the following syllabus and useful links for CCNA

CCNA Books
You can usually pickup cheap CCNA books on Ebay. I have various books that I bought on Ebay very cheaply. Some were a little old and focused on the 640-801 exams, but most of the core material is the same as for 640-802
(There is a digest of the differences between the 640-801 and 640-802 exams at the following location

I read the ExamCram books. I had some Cisco books as well, but those seem to be very verbose and cover a lot of basics and irrelevant material.

There are some great free cheat-sheets I found here:

Most important - Simulated routers and switches GNS3

I feel this part is essential. When studying for a CCNA you really need an environment that you can hack around with, build lots of different setups, break it, fix it, and generally get your hands deep in the command-line.

GNS3 is a great piece of software, which can enable you to replicate pretty much any type of Cisco router configuration. This is a great help when studying CCNA.

More information here::

I installed my copy of GNS3 on a copy of Backtrack Linux (which I often use as my main OS). You can do this with the following command (don't bother with the Linux compile and install instructions that you may find online)

apt-get install gns3

GNS3 is not totally intuitive to begin with, and it takes a few hours to get used to it, but once you do it is an incredibly powerful tool for real world experience of configuring different protocols and topologies.

One tweak you might want to make on Backtrack is to change the terminal emulator command in GNS3 as follows:

(Backtrack 5)
/usr/bin/konsole --new-tab -e /usr/bin/telnet %h %p > /dev/null 2>&1

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

Other than that, there is a great tutorial on how to use it at the following location which contains information about setup on both Linux and Windows, connecting virtual machines, and various test configurations:

Here is an example network I quickly created with a WAN and LAN:

Of course this network is completely simulated, so you can also try to secure it, and attack it to your hearts content (try cracking the Telnet or SSH passwords, or uploading malicious configs, to sabotage the routers and switches to intercept traffic for example - or is that just me ;o)

Anyway it's a good idea to use this environment to practise lots of cisco commands and configurations.

This is a useful guide to the basic commands required for the CCNA