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 |
|
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 |
|
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.
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 |
|
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. |
| | ||
| | ||
| | ||
EAN: 2147483647
Pages: 117