totse.com | Methodoloy of Firewall Penetration Testing

NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.

Indirect information collection
Direct information collection
Attack from the outside
Packet filtering Firewalls
Proxy Firewalls
Attack from the inside of the network

The methodology that I will discuss in the next section on how to perform firewall penetration testing is not THE methodology in this field. As this is a quite new field, a lot of approaches are valid and I leave it to the reader to come up with something different. For me, this methodology worked best from the few I found existing. For a different approach see for example [7].

Indirect information collection
Direct information collection
Attack from the outside
Attack from the inside

First, we want to find out as much as possible about our target. To do so, we collect information first in a way that can not be detected by any logging or alarming system. For this step, we use publicly available information from sources outside the network. These are services like nslookup or whois to get an idea about the structure of the targeted network. This should principally not reveal inside information on the network but sometimes topologies are exported although this should not be the case. Another source of information is to search on the internet. We can also access the targets anonymous FTP and WWW servers if they are available and hope we find something there (try to list directories on WWW servers if this is not disabled). We also search newsgroups for postings made by employees of the target. If mail headers are not rewritten, we may find more specific sender addresses than just the general e-mail address. This would be for example [email protected] instead of [email protected]. We also search for peoples e-mail address in white page databases for the same reason.

The above approaches are quite simple but can give us a first idea of the target and its security implementation. By far the best resources for this type of data gathering are mailing lists. Here, I would like to point out specially to the firewall mailing list [4].

I was recently testing a XXXXXX firewall 1 (release-2) and discovered the following:

With setting up the firewall's filter rules, I block all inbound traffic. This includes ICMP packets. However, when I am pinging the firewall with ping -l XXXXX, the firewall -1's GUI seems somehow to crash and so do all the filter rules.

During the time that I did the pinging, I was able to telnet to the firewall and with this to bypass the filter rules that seem to have crashed with the GUI. The filter rules and the GUI came back to life several minutes later but too late.

As I did more tests, it seems that there is also a logging problem. The firewall was so busy logging the ping, it forgot to do anything else.

Comment: While the text describes an actual posting, I changed the structure of it so don't waste your time using a search engine to find out who did the posting and crack this firewall.

If the guys from evil.com are also reading this newsgroup, this site is easy pray if the administrator did not take the right precautions before making this posting. Mails like this help also in our testing task as we could have the same configuration to test or maybe the origin of this mail is even our targeted network.

This step can sometimes not easily be separated from the last. The main difference would be that we are now approaching the targeted network and that most of our steps should be detected. We would typically begin with looking for additional information that the company's name server could have been stored on the network topology. Valuable information can also be discovered in bounced mail headers. If we want to get more information on vital systems in our target network, we can send an e-mail message to a non-existent user. The bounced mail header could contain valuable topographic information as you can see in the following example:

Received: from planet.solar.com ([email protected] [128.164.9.3]) by mars.planet.solar.com (8.7.1/8.7.1) with ESMTP id NAA29812 for < [email protected] >; Sat, 16 Nov 1996 13:56:44 -0500 (EST)

Received: from evil.satan.com (lucifer@evil [128.104.9.3]) by planet.solar.com (8.7.1/8.7.1) with SMTP id NAA29804 for < [email protected] >; Sat, 16 Nov 1996 13:56:40 -0500 (EST)

By sending just one e-mail message (from [email protected] to [email protected]), we got in this case information on three hosts, of which one will be their main e-mail gateway.

To get other topological information, we will launch in addition a scan of the entire address space of the targeted network. To do so, we use automated tools like SATAN that perform this task for us. We can there define network classes or even just the network name which would be in this case solar.com. Principally, we should only be able to see the firewall or even nothing when using this approach. When additional hosts are detected by this scan, they are not protected by the firewall and therefore we can probably enter through these systems.

While we used network scanning to determine if the security parameter is intact, we use stealth scanning to determine which ports of the firewall are open and are therefore a potential point of entry. The difference between stealth scanning and the way security scanners do scanning (what we used before) is that the scanners are invoking a complete TCP session which can be detected by the targeted systems. At this point, we are still interested that as little as possible of our actions get detected and therefore we are interested in an alternative way to do scanning.

Due to a bug in most existing TCP implementations [13], we can use the following approach to see if a port is open or not

A -!- T if no message is returned to A, the port is probably listening and an attack can be launched.

The following stealth scanning approach takes advantages of a different bug in the Linux (TTL-bug) or BSD (non-zero window) UNIX implementations.

if now the TTL (Time To Life) is low or the window is not 0, the port will be probably listening.

Most of the activities that I described in this section should be detected from the targeted systems. However, the information collections should still be on such a level that the alarming of the firewall was not set off.

This section now discusses direct attacks from the outside. Our targets are on one hand the firewall but also other designated systems like WWW server or hosts that seems to have a connection to the outside world and are not protected with a firewall.

Although if the main target is the firewall, we want to try overtaking the WWW server (or FTP server, outside mail-server) first. This can give us additional advantages if the firewall (which should principally not be the case) trust these hosts or there were also examples that the filesystem of the firewall was mounted to the WWW server for easier maintenance. To have one of these systems (lets take the WWW server for example) under our control has also its advantages when we are later (following section) trying to launch an IP spoofing attack.

Another general idea is, that we are launching our attacks from different subnets as the firewall could trust on of these addresses. Quite a small chance but worth a shot.

When we now begin with the testing of the firewall, we have to ask ourselves what the best approach is. This is now influenced by the design of the firewall. We have principally two different types of firewalls. The packet filtering firewall and the application layer firewall (proxy). Both demand a different approach.

This firewall type uses the IP addresses to do authentication. That is the point where we base our attack. A lot of software based firewalls cannot tell from which network interface a packet is coming. Therefore they have no means to tell if a packet is really coming from our side of the network or is just pretending to be by having an IP address that belongs to this network

This lack of verification can be exploited by IP spoofing attacks. I will describe a blind and a non blind IP spoofing attack more in detail but before this, we have to have deeper knowledge on how a TCP connection is established.

A TCP connection is established by a connection request from Host A to Host B. This connection request bears its own Initial Sequence Number (ISN) from Host A.

Host B will then acknowledge the ISN from Host A with the ACK flag and sends its own ISN to Host B with the SYN flag enabled.

As for the last handshake in this connection establishment phase, Host A acknowledges back the ISN that Host B sent in the previous message.

We want to know in addition how this Initial Sequence Number is created. Principally, it is a 32 bit counter. This counter is then advanced every second by 128,000 units. In addition, every TCP connection advances this counter by an additional 64,000 units.

This predictability of the initial sequence number makes it possible to launch IP spoofing attacks.

For this attack, the attacker is located outside of the firewall and takes advantage of the before discussed circumstance that the firewall cannot determine from what side an IP packet is coming.

The Attacker wants to establish a TCP connection with the target host. This TCP connection is typically a r* service (mostly a rlogin) that uses the IP address as authentication and no password is needed. Therefore, we need a pattern of trust. The host that the attacker pretends to be must be trusted by the target. To determine this, we can use tools as rpcinfo or showmount -e (the latter one shows mounted filesystems and indicates therefore a trusted relationship). Another method would be brute force guessing of neighbors of the target host.

The first step in the IP Spoofing attack is to disable the trusted host. For this, we can typically use a TCP Syn Flood attack [3]. The trusted host has to be disabled so that the targeted host thinks that the traffic that the attacker will generate emanates from there. If the trusted host is still reachable, it will interfere in our attack and send RST packets to indicate that it did not start a connection and the target will ignore further packets with our ISN.

Next, we have to prepare for guessing the targets ISN. For this, we take advantage that the SMTP port (25) is often open so that mail can be passed through the firewall. Through this port we open a TCP connection to the target host and get back his initial sequence number. We are repeating this several times to get an idea on the roundtriptime so that we can guess the target's ISN more precisely. After doing so, we are sending a connection request (SYN) to the target where we are using the IP address of the disabled trusted host.

The target sends now its response with its ISN to the trusted host as this appears to be the sender. This host is still busy waiting that the connections that we opened with our SYN flood are continued and drops all incoming TCP traffic. Therefore, the target does not get a response back from the trusted host.

The attacker sends now the acknowledgment to the dropped response and acknowledges the predicted sequence number (+1) of the target.

When we were correct with our guessed initial sequence number of the target then we have now a session established. If our guessed ISN is too low in relation to what the target was expecting, then the packet will be discarded. If our guessed ISN is too high, the packet will be regarded as a future one and held in the queue. We established this way a login to the target where we need no further authentication with the rights of a standard user. We will typically try if the target accepts root logins over the network as this would give us complete power over this system. Still, we never see an output from the target and have to guess what our commands are provoking.

non-blind IP Spoofing attack One of the main disadvantages with the previous described IP Spoofing attack is, that we never see the actual output of our target. We can guess in a lot of cases what this output could be but we are restricted in the use of commands. This problem can be solved in a few cases where we can actually launch a non blind IP Spoofing attack. To do so, we need a similar topology as that described in the above picture. The firewall has to be unable to detect on which interface a packet is arriving and therefore can not tell if a packet comes from the inside network or the outside world. This may sound as a quite basic feature but a lot of today's firewall don't have this capability. In fact, a software based firewall is mostly not capable of distinguishing between the inside and the outside interface and makes the decision based upon the IP address. Our attack approach takes advantage of this. Another restriction for this attack is, that our target and the WWW server are not separated with a router (or an intelligent bridge) that filters the traffic.

The attack is quite straight forward. We are attacking and overtaking the WWW server (normally enough security holes there). In addition, we have to gain root access on this machine. As the web server is freely accessible from the internet we don't have problems connecting to it. After we have gained root access, we change the servers IP address to an unused IP address from the same C class network that our target belongs to and that our target potentially trusts. To make the change active, we now reboot the server after we set up an account for us to come back. After rebooting, the server will now have the new IP address. As this address belongs to the inside network, all traffic to and from this host can now freely pass the firewall. We are still able to connect for example with telnet to the server and launch an attack from there to the target. As the traffic will pass the firewall, we have now established a non-blind IP spoofing attack.

Filter rules on packet filtering firewalls are typically based on source and destination port addresses. On a TCP/IP enabled host, we have 65,535 possible virtual ports. Some of these ports are assigned to specific services and a lot are for general use. While we could have the policy that we allow FTP services but not telnet services to pass our firewall, when source porting is enabled, an attacker can modify telnet to make the connection come from source port 20 (port 20 is assigned to the FTP service).

Source routing is an option in the IP protocol that allows defining how packets are routed between source and destination. If source routing is allowed, we are often able to bypass the filter rules of the firewall. We could also probably turn a blind-IP-spoofing attack into a non-blind attack if we can define how the packets are routed.

Both options, source porting and routing, pose a threat to our network security and should not be allowed.

Proxy type firewalls require a different approach as the authentication is not based on IP addresses. Proxies are demons and don't have much code that could have bugs to exploit in them. To my knowledge, no proxy exploitation due to a programming error is known to date. Authentication is normally quite strong by using hardware tokens and one-time passwords so that also brute force attacks are not very dangerous. However, to check for default accounts and passwords or simply password guessing is still a valid tool.

However, I came up with a possible attack if a firewall is running the NTP (network time protocol) service in combination with the one-time password SecurID. SecurID uses hardware tokens in combination with passwords to authenticate users. The one-time password is time based. The user enters an 8 digit code before the assigned password. This 8 digit code changes every 60 second. Normally, this prevents from sniffer attacks where passwords are collected. If the attacker could install a sniffer, he could store the login sequence with a timestamp. If the hacker can launch his attack from a high level (penetrated the targets service provider first), he can try to shut down the firewall (e.g. ping with oversized packets, flooding…). When the firewall comes up again, it will ask the current time through NTP. The attacker can now forge the NTP responses and set the time of the firewall back. When the attacker now replays the SecurID login sequence at the right time, he should be able to gain access our network. I never heard that this attack was described or used but it is still a valid threat and shows us that critical hosts should not rely on any information (in this case the time) from outside our trusted network.

Most of the tests that we run when testing a proxy firewall will be tests for wrong configurations or poor implementation of the security policy. SOCKs can serve here as an example. SOCKs is a library for proxy application firewalls that was designed to allow certain services to pass the firewall. Unfortunately, SOCKs is often misconfigured in a way that the administrator established the rules to allow certain services through the firewall but forgot to define the rules necessary for denying access to intruders. The firewall will seem to work fine until a hacker finds this misconfiguration or it is discovered in a firewall test.

Another test will be if we can connect to the network without going through the firewall (additional connections).

The following list covers the most dangerous threats that a firewall should block. It is not complete at all and a longer list can be accessed at http://www.iss.net/vd/ , the vulnerability database of ISS (Internet Security Systems)[15].

SOCKs misconfigured
bad policy (or poorly implemented)
brute force attacks
anonymous FTP allowed
tftp allowed
r-commands allowed
X-Windows / Open Windows allowed
Portmapper
NFS world mountable
Win95/NT file sharing allowed
Open ports (hint, check Real Audio port 7070)

A method that can possibly lead to success is the combination of attacks or trying to keep the firewall busy (e.g. ping it with large packets) during an attack. The firewall can be so busy handling the ping requests that it "forgets" its filtering rules.

However, while being creative is a good thing - we shall never forget that we are probably not allowed to shut down the firewall. Therefore our probing should not lead to denial of service attacks. If possible and during a very specified time window of the testing, we can also try if denial of service attacks can force the firewall into a failure condition. After a denial of service attack, we are interested in the state of the firewall. There are four potential states:

Survived the attack and continues to operate normally
Shut down and restart - reset to normal operation
Shut down and stopping all traffic
Shut down and allowing all traffic through

While we would like to see the firewall in the first state after a denial of service attack, the next two can be still acceptable, while we definitely want to avoid the latest one.

While our previous approaches were concentrated on attacks from the outside, we are trying to attack the firewall from the inside in our last part of the firewall penetration testing.

Why should anyone try to attack a firewall from the inside- you might ask. There may be different reasons. With additional security (what a firewall provides) access has been made more difficult. Before the firewall was installed, an employee could telnet into its computer during non office hours and check the mail or send his newest papers to a friend using FTP. Even worse, access to the internet (surfing) can be disabled (or audited) for a group of users. There are a lot of reasons that someone is not too happy with this firewall and he (or she) can try to disable it to gain back the old capabilities.

In this case, the target is the firewall or probably more often the operating system on which the firewall is running. This belongs now not any more to network security but more to host security as this specific host (the firewall) is attacked. There are a few quite good tools that you (and anyone else!) can use to test for OS vulnerabilities (SATAN, ISS..).

Until now, I have described the methodology on firewall testing and how we are doing it in theory but I have not discussed how to perform an actual test.

While manual probing and interactive testing are related to each other, the latter two approaches are more or less automated. With manual tests, you have the big advantage that you really know what is going on at the target system. You see the output/response that your probing and testing creates and you can react accordingly. This is much more flexible than using automated tools or hacking scripts. The danger of disrupting services is also not as great as with the other approaches. Unfortunately, this takes a lot of time and needs a considerable degree of knowledge. You are sitting behind your terminal equipped with a checklist of vulnerabilities that you want to test and you certainly spend a lot of time typing and searching for possible entry points. This method requires in addition also good knowledge of the security problems of your target system.

A possibility to get results faster is the use of security scanners. Until now, there is not much available that target firewalls and scans for problems. Although a lot of scanners are declared as "network security tools", they target more host security and scan mostly for operating system vulnerabilities and dangerous enabled services. While this can help when testing a firewall, its not enough. At this moment (Dec 96), the only available package that has an option for firewall testing is the firewall scanner of ISS [14]. Even if this option is available, it means that it adds a number of firewall security checks (we discussed all of these in this paper) to the Internet Security Scanner.

Hacking tools can be easily found on the internet. Just go to Alta Vista (or your favorite search engine) and do a search for "UNIX hacking" and you will get links to around 250 so called "underground" pages where self defined "hackers" make their knowledge (sometimes knowledge and a lot of noise) openly available. With a little time, you will find tools for exploiting a lot of vulnerabilities. However, the use of these tools is not without problems. Before using them, analyze the source code thoroughly until you know what the program is really doing and then test it in a closed environment on one of your own machines before letting it free. You never will be really sure what these tools are doing so be extremely careful.

In my opinion, automated tools can make a firewall test more efficient and take care of lengthy tasks but cannot replace them. To run just ISS against a firewall and declare it as a firewall penetration test is not an option in my point of view and should not be accepted by the client.

Methodoloy of Firewall Penetration Testing

by Reto Haeni