CISCO FIREWALL PENETRATION

A properly configured and up-to-date PIX firewall is practically impossible to penetrate . Typically, a remote attacker would start by trying to identify the device performing the firewalling functions and trying to exploit the device itself, gradually moving toward mapping out the rules of the firewall and finding an exploitable niche that was unnoticed by the firewall administratormost likely a misconfiguration.

Apart from the specialized PIX firewall device, every major hardware device in the Cisco product range offers some form of blocking the hostile traffic. Most often, an attacker would face a firewall guarding the perimeter of the network, and in most cases, the key element in a Cisco-centric end-to-end security solution would be the Cisco Secure PIX firewall.

Even though one would expect Cisco Secure PIX firewalls to be flawless with regard to security, this is not exactly the case. During the life of this product, several vulnerabilities were discovered that could lead to DoS conditions or tricking the firewalling functions of the device. We have paid closer attention to the DoS- related flaws in Chapter 11; here we focus specifically on the other types of vulnerabilities that might allow us to bypass the protection offered by the device.

Attacking PIX Protocol Fixups

An internal part of the PIX advanced protocol handling process is performed via a mechanism called protocol fixups . Such fixups operate as an application-aware agent rather than a true proxy, and in most cases the fixup protocol monitors the control channel of the application to prevent known protocol violations and respond to the dynamic needs of the protocols when necessary.

Attacking PIX MailGuard

Attack 

Popularity:

6

Simplicity:

8

Impact:

8

Risk Rating:

7

One of the vulnerabilities discovered in 2000 allows tricking the MailGuard functionality of the mail server. Such functionality can be useful to protect the mail server that supports execution of potentially dangerous SMTP commands such as VRFY or EXPN . The PIX protecting the mail server intercepts requests directed to the mail server, allowing only the minimal necessary SMTP commands, as described in the RFC 821 subsection 4.5.1, to pass through, returning the response of "500 command unrecognized" to the client. This way, even the security-unaware system administrator configuring the SMTP server is protected against making basic mistakes in its configuration. It is possible to bypass this fixup in the earlier versions of the PIX OS by sending out a DATA command before submitting the minimal necessary information required to process the message.

For example, you can enter DATA before specifying the rcpt to and the server would return "503 valid RCPT command must precede DATA," requiring you to fill in header information; however, the fixup assumes that you are already typing the body of the message, thus allowing an extended set of potentially dangerous SMTP commands to pass through.

An example of such a communication is shown here:

 220 mail.arhont.com ESMTP Exim 4.50 Fri, 12 May 2005 23:15:40 +0100 hello arhontus 250 mail.arhont.com Hello arhontus.arhont.com [xxx.xxx.xxx.xxx] mail from: kos@arhont.com 250 OK data 503 valid RCPT command must precede DATA rcpt to: andrew@arhont.com 250 Accepted data 354 Enter message, ending with "." on a line by itself 

PIX MailGuard Countermeasures

Countermeasures 

Although this vulnerability is rather oldaffected PIX OS versions should be older than 4.4(7.204), 5.1(4.209), 5.2(5.207), 5.3(1.206), and 6.0(1.101)it is still possible to find some firewalls running vulnerable versions of the firmware. You should upgrade to the latest version of the PIX OS; best of all, keep your SMTP server secure.

Attacking PIX FTP Fixup

Attack 

Popularity:

6

Simplicity:

8

Impact:

8

Risk Rating:

7

Another vulnerability present in the earlier versions of the PIX OS and related to the advanced protocol handling modules is found in the fixup protocol FTP. In particular, it is related to the way passive FTP is handled by the firewall. The FTP protocol is a two-channel communication, in which one channel is used for FTP control commands while the other is utilized for an actual data transmission. While the FTP control channel is predetermined and is established to port 21 of the FTP server, the data channel is negotiated between the client and server in each particular case. During the standard (or active) FTP mode, the client tells the server a high-order port that it opened is ready to receive the data; then the server initiates the connection to this high-order port from the source port 20. The passive mode FTP uses a different mechanism of setting up the data channel (see Figure 13-2). When the data is requested from a server, the client asks the server if it accepts the PASV connections, and the server returns a high-order port to which the client should initiate the connection from its own high-order port.

image from book
Figure 13-2: An overview of the active and passive FTP connection exchange

If the fixup protocol ftp configuration is applied, it is possible to exercise the vulnerability to alter the state table of the firewall utilizing an error message returned by the internal FTP server, thus opening a separate unauthorized connection through the firewall and circumventing defined security policies. During the passive mode data channel negotiation, the firewall extracts the information about which port the server expects the client to connect to transfer the data by listening to the 227 message with the port number specified in the first 4 bytes of the packet. It might be possible for an attacker to manipulate the FTP session in such a way that the error returned by the FTP server would have the string 227 as the first 4 bytes of the packet. The easiest way to achieve this is by decreasing the MTU of the connection. In this way, the firewall would interpret the actual error response of the FTP server as the passive reply that specifies the port number and would allow direct connections to this port.

PIX FTP Fixup Countermeasures

Countermeasures 

It is fair to say that PIX Secure firewall was not unique and other firewall manufacturers, such as Firewall-1, suffered from the same vulnerability. This vulnerability was fixed in PIX OS versions starting from 4.2(5)205**, 4.4(4)202**, 5.0(3)202**, and 5.1(1)207**, so make sure that you don't use obsolete and vulnerable PIX OS.

TCP RESET Attacks Against PIX Firewalls

Attack 

Popularity:

9

Simplicity:

6

Impact:

6

Risk Rating:

7

A common vulnerability found in pretty much all the lines of Cisco products that have a TCP stack is the ability to reset established TCP connections that are terminated on a device. Such a vulnerability could be of paramount importance to the IOS-based routers that are involved in Border Gateway Protocol (BGP) communications that rely on a persistent TCP session between BGP peer entities. An attacker can potentially use this vulnerability to disrupt the underlying TCP session, causing routing tables to be rebuilt or causing "route flapping." This has a lesser effect on PIX firewalls, since you would not find many situations in which the PIX acts as a terminating node of the TCP connection, but it can be a nuisance to the system administrator by constantly kicking her off the firewall administrative session if remote access is allowed from the same side from which the attack has originated.

For such an attack to be executed, the attacker needs to know the source and destination IP as well as the TCP source and TCP destination port number. In most cases, a person attacking the firewall would have a pretty clear idea of the IPs involved in the communication as well as the destination port number, while the remaining source port would have to be known or guessed. Since the majority of the operating systems use a rather predictable algorithm for assigning a source port number of the connection, it is possible to send out various port number combinationsor, in other words, bruteforce the TCP source port of the connection. Additionally, an attacker needs to know or guess the matching sequence number that would fall within a window specified by the acknowledgment identifieralso not a trivial taskbut the sequence number would have to be bruteforced by an attacker for the attack to succeed. By using various fingerprinting techniques, an attacker might tune the bruteforcing task by optimizing the parameters specific to different implementations of the TCP stack in the different Cisco operating system versions. By sending a single packet with the correct information and a SYN or RST flag set, an attacker can reset an established TCP session. The impact of such a vulnerability varies depending on the situation and protocols used over TCP. Cisco recommends upgrading vulnerable versions of the OS to mitigate this vulnerability. Consult http://www.cisco.com/en/US/products/products_security_advisory09186a008021bc62.shtml for more information.

You can use several utilities to send custom TCP packets. One of the most widely used tools is hping2 , which can be obtained from http://www.hping.org.

You can change various parameters of the generated packet; the help output is shown next :

 arhontus / # hping2 --help usage: hping host [options]  -h --help        show this help  -v --version     show version  -c --count       packet count  -i --interval    wait (uX for X microseconds, for example -i u1000)     --fast        alias for -i u10000 (10 packets for second)  -n --numeric     numeric output  -q --quiet       quiet  -I --interface   interface name (otherwise default routing interface)  -V --verbose     verbose mode  -D --debug       debugging info  -z --bind        bind ctrl+z to ttl        (default to dst port)  -Z --unbind      unbind ctrl+z Mode  default mode     TCP  -0 --rawip       RAW IP mode  -1 --icmp        ICMP mode  -2 --udp         UDP mode  -8 --scan        SCAN mode.                   Example: hping --scan 1-30,70-90 -S www.target.host  -9 --listen      listen mode IP  -a --spoof       spoof source address  --rand-dest      random destination address mode. see the man.  --rand-source    random source address mode. see the man.  -t --ttl         ttl (default 64)  -N --id          id (default random)  -W --winid       use win* id byte ordering  -r --rel         relativize id field          (to estimate host traffic)  -f --frag        split packets in more frag.    (may pass weak acl)  -x --morefrag    set more fragments flag  -y --dontfrag    set dont fragment flag  -g --fragoff     set the fragment offset  -m --mtu         set virtual mtu, implies --frag if packet size > mtu  -o --tos         type of service (default 0x00), try --tos help  -G --rroute      includes RECORD_ROUTE option and display the route buffer  --lsrr           loose source routing and record route  --ssrr           strict source routing and record route  -H --ipproto     set the IP protocol field, only in RAW IP mode ICMP  -C --icmptype    icmp type (default echo request)  -K --icmpcode    icmp code (default 0)     --force-icmp  send all icmp types (default send only supported types)     --icmp-gw     set gateway address for ICMP redirect (default 0.0.0.0)     --icmp-ts     Alias for --icmp --icmptype 13 (ICMP timestamp)     --icmp-addr   Alias for --icmp --icmptype 17 (ICMP address subnet mask)     --icmp-help   display help for others icmp options UDP/TCP  -s --baseport    base source port              (default random)  -p --destport    [+][+]<port> destination port(default 0) ctrl+z inc/dec  -k --keep        keep still source port  -w --win         winsize (default 64)  -O --tcpoff      set fake tcp data offset    (instead of tcphdrlen / 4)  -Q --seqnum      shows only tcp sequence number  -b --badcksum    (try to) send packets with a bad IP checksum                   many systems will fix the IP checksum sending the packet                   so you'll get bad UDP/TCP checksum instead.  -M --setseq      set TCP sequence number  -L --setack      set TCP ack  -F --fin         set FIN flag  -S --syn         set SYN flag  -R --rst         set RST flag  -P --push        set PUSH flag  -A --ack         set ACK flag  -U --urg         set URG flag  -X --xmas        set X unused flag (0x40)  -Y --ymas        set Y unused flag (0x80)  --tcpexitcode    use last tcp->th_flags as exit code  --tcp-timestamp  enable the TCP timestamp option to guess the HZ/uptime Common  -d --data        data size            (default is 0)  -E --file        data from file  -e --sign        add 'signature'  -j --dump        dump packets in hex  -J --print       dump printable characters  -B --safe        enable 'safe' protocol  -u --end         tell you when --file reached EOF and prevent rewind  -T --traceroute  traceroute mode          (implies --bind and --ttl 1)  --tr-stop        Exit when receive the first not ICMP in traceroute mode  --tr-keep-ttl    Keep the source TTL fixed, useful to monitor just one hop  --tr-no-rtt      Don't calculate/show RTT information in traceroute mode ARS packet description (new, unstable) --apd-send        Send the packet described with APD (see docs/APD.txt) 

The following command would generate a single TCP SYN packet with source port 1037, destination port 22, with a sequence number 15:

 arhontus / # hping2 -I eth0 -a 192.168.50.5 -s 1037 -p 22 --syn -c 1 -d 0xF00 -- setseq 0x0000000f 192.168.50.7 

A vulnerability of similar nature affecting only PIX firewalls is caused by the inability of the PIX firewall to distinguish between a genuine and a forged TCP RST packet. The connections originating or terminating at the firewall device are unaffected; it is possible to reset a connection that passes through the PIX. Again, the source and destination IP as well as the TCP source and TCP destination port numbers have to be known for the attacked connection. When a firewall receives a packet with a set RST flag, it searches for a match in the state table and if a match is found, the associated connection is reset. The attacker does not need to know the relevant sequence number, since it is not stored in the state table. The consequences of this attack are similar to what we described earlier, and all PIX OS versions prior to 4.4(5) and 5.1(2) should be upgraded to more recent versions to avoid this. Although the vulnerability is rather old, the upgrade to the newer versions was postponed by quite a few system administrators, since the attack on the state table was considered to be impractical and the upgrade required an additional investment of upgrading firewall RAM to the amount necessary to run the newer PIX OS versions. So you are quite likely to meet such vulnerable systems in the wild.

Progressing to the higher end device classes, Cisco Catalyst 6500 series switches and Cisco 7600 series routers with Firewall Services Module (FWSM) blades are affected by the vulnerability that allows TCP traffic to bypass certain access list entries that are intended explicitly to filter out this particular traffic.

A sample configuration provided by Cisco in its advisory to illustrate the vulnerability is shown here:

 FWSM#show filter filter https except 0.0.0.0 0.0.0.0 10.1.3.0 255.255.255.0 filter ftp except 0.0.0.0 0.0.0.0 10.1.3.0 255.255.255.0 filter url except 0.0.0.0 0.0.0.0 10.1.3.0 255.255.255.0 filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 filter ftp 21 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 filter https 443 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 

In this example, an administrator applied filtering of HTTP, HTTPS, and FTP protocols for all bypassing traffic. However, the hosts on the 10.1.3.0/24 network are exempt from this filtering. Providing an attacker has a way of determining the excepted IP range, he can generate custom malicious packets that would match the except rules on the FWSM; thus, such TCP traffic can bypass access-list entries intended to filter them explicitly on any interface.

TCP RESET Attack Countermeasure

Countermeasure 

To resolve this vulnerability, you would need to upgrade the FWSM firmware to version 2.3(2) or later.



Hacking Exposed Cisco Networks
Hacking Exposed Cisco Networks: Cisco Security Secrets & Solutions
ISBN: 0072259175
EAN: 2147483647
Year: 2005
Pages: 117

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net