Vulnerabilities in Firewalls

 

Vincent Law 014-68-0083

Courtesy of UC Davis Computer Science Department ECS 289M Spring 2002

 

 

Abstracts

 

Nowadays businesses, as many of 80 percent of all the sites, have been employing firewalls as the means of protection for themselves against potential attacks. They see firewalls as entrance guards for any incoming traffic. Therefore, it makes firewall as the only entrance. However, misusing firewall can still be dangerous to a network and the consequence can also be very disastrous. Therefore, good configuration and effective security testing are necessary in order to ensure the security policies are properly implemented in the firewall. This article describes some effective steps in testing the firewall and outlines the vulnerabilities currently discovered in firewalls by systematically classifying them based on Aslam’s vulnerability taxonomy scheme.

 

 

Introduction

 

Before Internet’s emergence, blocking network traffic is a totally ridiculous idea. Network interoperability, efficiency and traffic transparency are what everybody wants. This all changed once Internet became its dominant usage for general public use. Internet was no longer an internetworking medium only for the researchers and academic personnel, but to everyone in public. This means that researchers can no longer use the Internet as a “playground” to freely include any untested feature that can potentially harm not only the network itself but also its users. This started the firewall concept.

 

Firewall Controversies

 

Firewall security is a very controversial Internet topic. While some feel the firewall is very secure because it aggregates security functions in a single place, thus simplifying management, installation, and configuration. On the other hand, others feel that firewall can cause damages for the same reason simply because it provides "a hard, crunchy outside with a soft chewy center", which means firewall can give users a false sense of security, leading to lax security within the firewall perimeter. They observe that most of the “computer crime” in corporate environments is actually perpetrated by insiders who are immune to the perimeter defense strategy. Firewall advocates counter that firewall is so important that it can still act as an additional safeguard instead of as a substitute for careful security management within the perimeter. Yet, firewall detractors are also concerned about the difficulty of using firewalls, requiring multiple logins and other out-of-band mechanisms, and their interference with the usability and vitality of the Internet.

 

Firewall concepts and classification

 

The general firewall architectural model should separate policy, which is determining whether to grant service access to service requester or not, from control, i.e., limiting resource access to the service users. Earlier firewalls were router-based, using the routers to filter out unwanted packets based on the header information and the access control list rules inside the routers, by means of association, which matches a combination of fields such as source and destination addresses, protocols used, other source and destination information etc with the policy rules in the router. Based on the TCP/IP level (OSI layer 3), if the destination address is permitted by the rules, then the packet can go through, otherwise the packet is dropped and the router will also notify the sending system not to send any more related packets. This is why it is also called packet filtering. However, this handling scheme was so inefficient because of the filtering and the maintenance and updating of the rules within the routers, and it did not have memory to store past events in order to act as an influence of future events, i.e. stateless and no detailed logging. Worst of all, since it does not prevent any direct connections to internal hosts by external clients without authentications, it remains vulnerable to attacks such as source address spoofing. As a result, the concept of TCP/IP security approach, a.k.a. application gateways or proxy servers, began to emerge. The application gateway itself, operating at OSI layer 7 (application layer), serves as the “server” to the client user, and the “client” to the remote server. Therefore, it can control over what a client can do and cannot do, not only based on service but also on time-of-day controls. Authentication therefore is supported at the user-level. It also has an advantage in which the gateway becomes an excellent location for comprehensive logging because it can recognize, capture and interpret the client commands and activities in great details, thus making the gateway itself the “representative” of all the internal clients. However, application gateways suffer the overhead whenever every incoming data packet is checked. One other concern is the lack of instant allowance of any packet from a completely new application even though that application is not expected to pose any harm, but this concern has been somewhat addressed by the introduction of tools enabling the creation of “generic” proxies that are application-aware. Still, gateways themselves are application programs, thus they have to suffer the overhead of swapping memory between the program and the OS. Fortunately most industry products are capable enough to handle this problem through hardware, plus they provide prevention of the support of dangerous protocols. A newer technique was later derived from the original router filtering concept, and is called stateful inspection (or sometimes referred to stateful packet filtering, an enhancement to dynamic packet filtering as opposed to static packet filtering mentioned earlier), and it is installed and running as part of the OS. Like packet filtering (also at OSI layer 3), it loads the stateful inspection module just as the packet enters the router and before the OS begins processing the packet in the higher layers, thus eliminating the need of copying the data from the OS into the user space. Instead of examining each packet independently of previous traffic, it keeps track of the past history by treating the first packet of the new transaction the “representative” of the whole stream, and the decision, no matter whether the packet is permitted or not, will be stored as the more current state information or the current session. Subsequent packets will then be handled the same way as the first packet, thus eliminating the overhead of per-packet checking. A various, and more flexible, version developed by Check Point even enhanced it by allowing the peeking of each packet only at the application protocol, simply because of the fact that one transaction may lead to dynamic changes to this or other transaction’s state. Both static router-filtering and stateful inspection can be fooled by protocol tunneling, especially for the case of stateful packet filtering because it does not examine the data which may be dangerous. Protocol tunneling is the cooperation of data exchange through the use of one permitted protocol to transmit another protocol which is prohibited, and sometimes it can be disastrous if the application poses any threat to the network. One example is that the DNS port could be used to transfer file data. Another is the sendmail attack. So it is vulnerable to packet-based attacks given the fact that the packet will be allowed to pass or be forwarded as long as the first packet satisfies the security rules. Application gateways also cannot prevent this from happening, but at least they can log and authenticate (at OSI layer 7), allowing the inspectors to locate the abused protocol. Yet its flexibility allows the dynamic configurations, such as using the INSPECT language to add new services, of which applications to support provided careful configurations, and most of these applications involve in communicating with the OS module to modify the rule base and control operation, logging, and authentication if supported via application gateway. Based on the tradeoffs on both packet filtering scheme and application gateway model, hybrid firewalls are available in the market currently as a compromise of both advantages. Since firewall represents what kind of data and traffic inspections the network is employing, it can be viewed as a representation, or implementation, of the network’s security policies, and therefore the selection and comparison of both firewall schemes will continue to be an ongoing issue.

 

 

Common attacks against, as well as attack precautions for, firewalls

 

There are always methods to attack a firewall. Here are some of the popular ones

  • Normally, both the source and the destination determine the packet route. The packet itself only stores the destination address, but nothing about how it expects to get there. Sender has an option to include information in the packet that tells the route the packet should take to get to its destination. There comes the name source routing. For a firewall, source routing is noteworthy, since an attacker can claim his/her own generated traffic to be from a host “inside” the firewall. In general, such traffic wouldn't route to the firewall properly, but with the source routing option, all the routers between the attacker's machine and the targeted host will return traffic along the reverse path of the source route. On the other hand, in practice, source routing is very little used. In fact, generally the main legitimate use is in debugging network problems or routing traffic over specific congestion control links for specialized situations. When building a firewall, source routing should be either disabled or blocked at some point. Besides faked traffic, attacks can also be directed to a wrong router.
  • In ICMP, an ICMP Redirect tells the recipient system to override something in its routing table. Routers use it to tell hosts that the host about the use of a non-optimal or defunct route to a particular destination, i.e. the host is sending it to the wrong router. The wrong router sends feedback to the host by an ICMP Redirect packet telling the host what the correct route should be. Forging ICMP Redirect packets to a host that pays attention to them can alter the routing tables on the host and possibly subvert the security of the host by causing traffic to flow via an unintended path or even causing denial of service attacks.
  • DoS attacks happen simply because of the distributed nature of the network, in which every network node is connected via other networks which in turn connect to other networks etc. Only a few of local elements within reach are under the control by a firewall administrator or ISP. An attacker then can always disrupt an upstream connection from where the victim controls it. In other words, if someone wanted to take a network off the air, they could do it either by taking that network off the air, or by taking the subsequent networks it connects to off the air.
  • SMTP server hijack happens when a spammer takes many thousands of a message copies and sends it to a huge email address list. As these lists are often already so bad, and in order to increase the speed of spam operation, many have resorted to simply sending all of their mails to an SMTP server that will take care of actual mail delivery. All of the bounces, spam complaints, hate mail, and bad PR come for the site that was used as a relay.
  • Any application software cannot avoid the existence of bugs. There are bugs allowing remote users to do things ranging from gaining unauthorized machine control and even making that application crash. This risk exposure can be reduced by running only necessary services, keeping up to date on patches, and using products that have been around a while.
  • Besides application bugs, OS also has bugs. These are also typically initiated by users remotely. OSs relatively new to IP networking tend to be more vulnerable and problematic, because most mature operating systems have had enough time to locate and eliminate these bugs. An attacker can often cause the target equipment to continuously reboot, crash, lose the ability to talk to the network, or replace with harmful files on the machine. In this regard, running as few OS services as possible can help and having a packet filter in front of the OS can reduce the exposure to a large number of these types of attacks.

 

 

Auditing is necessary because firewalls are still vulnerable

 

Approach for the early days of firewalls is more conservative and more for rigorous defenses, and that is why these firewalls are more difficult to install, configure, and use. On the other hand, contemporary firewalls, while more user-friendly and easier to use, are generally considered as more susceptible to vulnerabilities. Survey by the Computer Security Institute at the end of 1997 indicated that about 30 percent of security breaches happened in places with firewalls installed. Among them, over half of them (about 51 percent) reported firewall mis-configuration and as high as 41 percent cited product weakness. Some of these firewalls even allow users to make them less secure. The inclusion of GUI to the firewalls no doubt increases the user-friendliness of the firewalls, but the main approach of firewalls is not the ease-of-use but security. In fact, the introduction of GUI is one of the reasons firewalls may not seem as secure as before, simply because GUI has integrated a lot of insecure options into the products, and most of them should not even be included for considerations. These inclusions make the firewall administrators think that these are designed as part of the safety features. In additions, because of this misunderstanding, auditors will usually skip detailed investigations as long as the firewalls exist (“Does firewall exist? Yes. Next item”), as a result ignoring the potential loopholes undetected assuming firewalls to be safely-configured enough to catch and handle them. As for protection, firewalls cannot prevent any attack by tunneling over most application protocols. For example, tunneling ``bad'' and offensive things over HTTP, SMTP, and other protocols is quite simple and trivially demonstrated. There are also some other known backdoors allowing an attacker to get past the firewall without being noticed. Examples include:

  • using remote administration tools which can effectively become backdoor access tools if used maliciously
  • prompting email recipients to run a test program provided by the sender where the test program is indeed an installation program for perhaps a virus
  • executing a rootkit to gain root access under a magic password or a discard port
  • running LOKI through the use of ICMP Echo Response packets, which normally are simply response packets as a reply to, for example, ping, to bypass the firewall checking freely, but in LOKI these packets may include illegal piggyback commands
  • emulating a remote web server so that it can gain access behind a targeted firewall, and
  • converting or encoding a malicious request to a usually firewall-permitted request, such as web browser request.

Hence, in order to use firewalls properly and safely, correct firewall auditing procedures should be regularly conducted. These auditing steps are as follows:

  • requiring and acquiring a hard copy of security policies, because without a written policy, it means there are no clear goals in mind and firewalls are relegated to be just another network-based devices which are not only costly but also hindering network traffic performance
  • listing of permitted services based on the policies
  • checking, comparing and correcting the compliance of the firewall with the service list, including the handling of accesses and interactions with untrusted sources
  • checking the patches
  • investigating the necessities and risks of the existence of the excessive services not included in the list, and ensuring the shut-down of these services, which may include negotiations with involved department or personnel, if found unnecessary
  • scanning of the firewall upon the service appearances
  • probing the hosts protected behind the firewall
  • examining the log maintenance, and
  • paying attentions on who check(s) the daily reports.

Documenting the firewall configurations is recommended, because it will be easier to perform some of the above steps such as the compliance checking to find out why unlisted services are included, and it is also easier to identify who may need these unlisted services according to the information revealed in the logs. One more important practice to ensure security is to frequently check to see if the firewall is functioning. Crashing the firewall software is one of the most traditional methods to break into the firewall. Without periodic monitoring, there is no guarantee that the firewall is present for defense against any sudden attack.

 

 

Testing Firewall

 

Although the firewalls currently available in the market are very advanced in designs and implementations, their vendors have not been able to provide as advanced firewall testings. Some of the firewall testing teams have some knowledge on the technology of firewall testing, yet few of them genuinely understand the whole firewall testing process. After all, firewall testing is not like other security testing such as penetration testing. Knowing the technology well is not good enough to provide adequate firewall tests. Therefore, Dr. E. Eugene Schultz proposed a scheme to effectively test the firewalls. The scheme includes the followings:

  • covering the nature of firewall testing
  • the goals of firewall testing
  • proper firewall testing procedures
  • proper persons to perform the testing

 

Nature of Firewall Testing

 

Firewall test is first and foremost viewed as a kind of penetration test, which uses techniques designed to attempt to defeat and bypass current security settings, in order to figure out how effective of the current security mechanisms. The test team members act as intruders to try to simulate a real-life attack to the targeted system, which in turns exploit any security breach and security inadequacies. The tests have to be performed properly so that no catastrophic consequence will result. To meet this requirement, planning is necessary and it is in fact the most basic step to effectively test the firewalls. First, ground rules for testing have to be established in much the same way as developing firewall policy before developing the firewall. Issues to be considered include:

  • rationale: proper testing is necessary to determine, through empirical methods, the firewall’s ability to prevent likely attacks by intruders
  • management cognizance and approval: without management approval, the test, like obtaining password files from a corporate machine, can be both catastrophic to the company and may result in felony charges against the testers
  • disruption: test script may be able to attack the network to halt any network service if planning is mishandled
  • pre-notification: large amount of time may be wasted if the test is not noticed and the test attack can lead to timely investigations, not to mention the absence of preparations to possible damage to the targeted network’s utilities
  • supervision: an advantage of supervising testing activity is to learn how it is done and how the firewall withstands attacks, and to ensure that the person conducting the test does not do anything unethical, as long as the supervising does not slow down the testing considerably or cause any misleading to the tester.
  • use of results: before testing begins, management and technical personnel should determine how to learn from and use the test result in deciding whether to continue using or replacing the firewall or not.
  • safeguarding results: careful planning has to be made on protecting and keeping the test results long before the test commences, so that the results will not end up in the hands of a malicious person who can use it as the leverage against the organization.

 

Firewall Test Goals

 

After deciding to test the firewalls and setting up the ground rules for the tests, specific goals for the tests have to be determined. The highest level of the goal is to observe whether the firewall is secure enough to withstand attack situations under current configurations. However, specific goals have to be made because these specific goals will be used as the functional guidelines for the tests and how to interpret the results. Specific goals are usually formulated from these questions:

  • Is the firewall implementation and configuration reflecting the security policy?
  • How well can the firewall resist and withstand particular types of attacks, especially those new ones?
  • Does the leakage or bypass occur in the security perimeter created by the firewall and how does it occur?
  • How adequate is the logging capability and can the log help effectively in discovering and locating attacks?
  • Can the firewall trigger and send an alarm after penetration test commences?
  • How well can the firewall hide information and addresses from the protected network so that potential attackers cannot retrieve them?

 

Proper Firewall Test Procedures

 

Security testing will not be effective and efficient without clearly-stated, detailed, written procedures that can be easily followed. Firewall security testing is no exception. In order to ensure proper firewall security testing, no prevention omission, and replicability of the test procedures and findings, the following steps are encouraged to perform:

  • Create a test plan, including test scope specifications, targeted firewall(s) and host(s), test goals, required steps to achieve the goal.
  • Develop specific procedures used for the test, like what traceroute commands to use, the steps needed for interactive tests, and the attack scripts for automated tests.
  • Carefully determine which parts require interactive tests due to possible out-of-control situations or necessity of step-by-step observations, and which parts need automated tests due to time-saving reasons. Besides, the tests have to be made sure to be conducted in a non-production because any failure will not cause damage or disruption.
  • A decision has to be made on how thorough and deep the tests should be performed before a proof of protection or penetration is achieved. The decision has to be rule-based and depend on the goals, as long as no significant disruption or damage will be resulted in the network operations.
  • Exact and proper firewall security test documentations not only helps the record-keeping of every action taken, results, location of the source and targeted host, and other critical information on the data and observations, but also ensure that no planned steps will be missed. This requirement also allows the addition of any missing details and actions if they are found to be missing during the tests.
  • Careful documentations also produce conclusions and recommendations for future improvements on the firewalls, even though some details or vulnerabilities may seem insignificant because they may turn out to be significant themselves or lead to other significant details. A good report reflects the value of a well-planned and well-executed test. The report should have these criteria included:
    • Objectivity in methodology and findings helps avoid any confusion or speculation.
    • Thoroughness helps its usefulness in archiving the report for targeted reviewers who will refer to the report later for decision-making.
    • Clarity enables the report easy enough to understand by those who are not technically proficient enough. Using footnotes on some technical terms is also helpful.
    • A well-organized report is more understandable and easier to keep the readers’ interest in continuing the reading, and as a result increase the usefulness of the report. Also avoid any tedious descriptions so that the reviewers can locate sections such as backgrounds, methodology, findings, conclusions, and recommendations, from the report.
    • A solution-oriented report possibly with priority for each found security weakness helps the administrators in looking for solution(s) because some solutions for certain vulnerabilities may already be suggested in the report.
    • Credits are provided so that no matter whether the test is successful or not those who review the report may turn to those credited people for references.

 

Firewall Tester Selection Criteria

 

Many people incline to turn to the original firewall vendors for firewall security test. However, the vendors often only test the firewalls they have recently installed, thus making the test not quite complete. For example, running a port scanning tool to determine whether traffic to certain ports is blocked or not can provide useful information, but is lacking feedback concerning how the allowed connections are security-wise managed. Besides, they are frequently not aware of their products’ vulnerabilities, and even if they know about some vulnerabilities, they may not be motivated enough to reveal that to the public. Firewall developers are also not a good choice either, simply because they are usually not the ones who use the firewalls, as well as the fact that they are in most cases not the most expert users. In additions, sometimes their tests are also biased because they may test the firewalls in a way such that they want the firewalls to work on the basis of their own creations but not on the basis of public interests, and the biases can result in the tests being conducted in limited scope only and steps that the intruders may take in breaking in the firewall may be overlooked. Hiring a network attacker, an ex-network attacker, or a close associate to a network attacker may seem tempting, but the personal integrity and trustworthiness to the person becomes questionable, and an institute hiring this kind of person as tester is possible to cause a lot of damages, and sometimes financial losses, to the institute. On the other hand, hiring a “cybercop” as a tester is also not good enough as the person may still not be able to provide guaranteed expertise in firewall testing. Therefore, to carefully select the right person(s) for firewall testing, there are also some consideration criteria:

  • The first and foremost thing is to make sure the tester(s) are honest and trustworthy enough.
  • The reason why vendors and their internal employees are not good candidates for firewall testing is that they are not motivated enough to prove how adequate the security is for the firewall.
  • Experience is very important as the tests are very rigorous and involves a lot of plans, procedures, and knowledge that only known from experienced personnel knows.
  • The tester also should have adequate knowledge on how to attack the targeted firewall in order to make the test credible and useful.
  • Those who can demonstrate strong firewall security test planning and preparations should be considered as the front-runners for the tester works.
  • Testers’ communication skill is also an important criterion, especially in terms of inter-personal communication skill and presentation skill. Otherwise the test may not be going smoothly, and the test result may not be clearly presented, and suggestions may not be precisely brought up, and thus making the test ineffective and less valuable, and may even lower the motivations for further testing in the future.
  • Cost is always a factor in making tester selection to avoid over-the-budget firewall security testing.

 

 

Archiving vulnerabilities

 

There are currently several websites that actively archive the reported vulnerabilities once they are confirmed by the board advisors. Most of them are for distributions for researchers and developers, and are CVE (Common Vulnerabilities and Exposures)-compatible. CVE (Common Vulnerabilities and Exposures) from MITRE (http://www.cve.mitre.org) is defined as a list or dictionary of common names for publicly known information security vulnerabilities and exposures. They believe that it is easier to use a common name to share data across separate databases and tools that until now were not easily integrated. This makes CVE the key to information sharing. They feel that the term vulnerability can be interpreted differently, for example, it can refer to causes for security breaches, but it can also refer to a program behaving not as properly as it is designed, and merely these two requirements can contradict to each other. One example is the finger command in UNIX. It can be viewed as a vulnerability because it reveals other users’ information, which is supposingly a secret according to some systems’ security policies. On the other hand, it can also be regarded not as a vulnerability because it is exactly designed the way it is required to do. Therefore, CVE introduces the term exposure, and regards it as an exposure if the scenario is not considered as a vulnerability by everyone. An advantage for the CVE list is that it is well established and referenced by a lot of research and industry people. If the security tool incorporates according to CVE format to produce reports, it can fix the faults more easily, more quickly, and more accurately by obtaining the vulnerability information from one or more separate CVE-compatible databases. Being CVE-compatible also allows interoperability and cross-references with other CVE-based security tools. Here are some popular CVE-compatible archived vulnerability sites:

  • MITRE’s own CVE site is already having an archive.
  • CERT (Computer Emergency Response Team)
  • SecurityFocus Online (http://online.securityfocus.com) is another popular site which stores vulnerability data according to vendor, product or technology name, keyword, impact, Bugtraq ID number, and CVE number. It also offers discussion forums, other users’ suggestions, and solutions if available, for the reported vulnerabilities.
  • National Institute of Standards and Technology’s ICAT metabase (http://icat.nist.gov) also keeps a searchable index of information on CVE-compatible vulnerabilities.
  • CERIAS from Purdue University (http://www.cerias.purdue.edu/coast/projects/vdb.html) adopts a model proposed first by Taimur Aslam and later enhanced by Ivan Krsul.

 

 

Classifying Firewall vulnerabilities

 

Vulnerabilities are mathematically expressed in terms of security states, which are comprised of multiple authorization levels. In one definition, a state is considered to be vulnerable if this authorized state can be accessed by an unauthorized user due to possible bugs in the security policies. To classify vulnerabilities found in the firewalls, like for other kinds of security vulnerabilities, an easy-to-comprehend, systematic, and scalable scheme is essential for the purposes of efficiency, helpfulness and manipulations and analyses, and manageability. An additional factor is to have at least a majority of related people agree on and adopt the scheme, so that the scheme can be effectively used and vulnerability information can be practically shared among each other, and sometimes can even learn and derive a behavioral pattern which causes the faults as a result of the vulnerabilities. Aslam’s model, one of the most sophisticated models adopted for the vulnerability database, bases on factors like coding, environment, and configuration. Meanwhile, Krsul’s model develops further by referencing from a multi-dimensional state-space set, where each dimension in the set represents a feature, including such obvious ones like impact, threat, system vendor, application, detection, patches, and even Aslam classification etc. However, since Krsul’s model can be situationally complex and even Krsul himself could not provide any guarantee the usefulness for the analysis of a particular feature, which itself can also be too abstract and subjective, in the state space, Aslam’s model became a preferred model to use here for the classification of firewall vulnerabilities.

 

Overview of Aslam’s model of vulnerability taxonomy

 

In 1995, Taimur Aslam proposed a model to classify UNIX vulnerabilities due to the existences of common various drawbacks, such as inconsistencies in complications, identification troubles, non-systematic natures, and ambiguities, in previous attempts of the formalizations of vulnerability classifications. In his scheme, Aslam defined three main classes of vulnerabilities, namely coding, operational, and environment, and related the vulnerabilities using entity relation model. Coding vulnerabilities are those that can introduce faults because of making certain calls in a program, such as race conditions happening between the UNIX system calls access() and write(). Operational vulnerabilities emerge when configuration errors, for example, lead to possible faults, and one good example is the permission to root access to the machine running tftp. An example of environmental vulnerabilities is the ability to create an interactive shell by running “exec –i” with a setuid shell script file. Figure 1 shows a flow chart on how a vulnerability can be classified based on Aslam’s scheme. There are two unclassified error nodes, indicating the purpose of scalability. The flow chart approach uses pure iteration method, in which a question with answers of either Yes or No is asked, and given an answer the flow will move to either the next question or a leaf is reached, in which case a vulnerability is successfully classified. Even though this model is for UNIX vulnerabilities at the time proposed the scheme, it can be generalized to be applied to classify other vulnerabilities, including those for the firewalls.

 

 

 

Fig 1: A flow chart illustrating how a vulnerability is classified under Aslam scheme

 

 

 

 

 

Firewall vulnerabilities based on Aslam’s model of vulnerability taxonomy

 

As of June 19, 2002, there are 90 known firewall vulnerabilities, mostly vendor-specific and a few are actually replicated. Below is the Aslam classification of these vulnerabilities, sorted with most recent finding first in each vulnerability class:

  • Coding:
    • Boundary conditions (11)
      • June 18, 2002: Heap overflow in the KTH Kerberos 4 FTP client 4-1.1.1 allows remote malicious servers to execute arbitrary code on the client via a long response to a passive (PASV) mode request.
      • June 18, 2002: Buffer overflow in OpenSSH before 2.9.9, and 3.x before 3.2.1, with Kerberos/AFS support and KerberosTgtPassing or AFSTokenPassing enabled, allows remote and local authenticated users to gain privileges.
      • June 18, 2002: Buffer overflow in tcpdump 3.6.2 and earlier allows remote attackers to cause a denial of service and possibly execute arbitrary code via an NFS packet.
      • May 16, 2002: Heap overflow in sudo before 1.6.6 may allow local users to gain root privileges via special characters in the -p (prompt) argument, which are not properly expanded.
      • March 15, 2002: Off-by-one error in the channel code of OpenSSH 2.0 through 3.0.2 allows local users or remote malicious servers to gain privileges.
      • December 6, 2001: Buffer overflow in internal string handling routines of xinetd before 2.3.1 allows remote attackers to execute arbitrary commands via a length argument of zero or less, which disables the length check.
      • November 18, 2001: Buffer overflows in gzip 1.3x, 1.2.4, and other versions might allow attackers to execute code via a long file name, possibly remotely if gzip is run on an FTP server. This vulnerability can also be treated as an environmental vulnerability because the involved program, gzip, is a third-party program which technically does not belong to the firewall itself.
      • September 21, 2001: Buffer overflow in the GUI authentication code of Check Point VPN-1/FireWall-1 Management Server 4.0 and 4.1 allows remote attackers to execute arbitrary code via a long user name.
      • February 12, 2001: Buffer overflow in NetScreen Firewall WebUI allows remote attackers to cause a denial of service via a long URL request to the web administration interface.
      • November 14, 2000: Buffer overflow in Getkey in the protocol checker in the inter-module communication mechanism in Check Point VPN-1/FireWall-1 4.1 and earlier allows remote attackers to cause a denial of service.
      • May 18, 2000: Buffer overflow in the CyberPatrol daemon "cyberdaemon" used in gauntlet and WebShield allows remote attackers to cause a denial of service or execute arbitrary commands.
    • Access validations (14)
      • March 15, 2002: The decompression algorithm in zlib 1.1.3 and earlier, as used in many different utilities and packages, causes inflateEnd to release certain memory more than once (a "double free"), which may allow local and remote attackers to execute arbitrary code via a block of malformed compression data.
      • September 8, 2001: The Log Viewer function in the Check Point FireWall-1 GUI for Solaris 3.0b through 4.1 SP2 does not check for the existence of '.log' files when saving files, which allows (1) remote authenticated users to overwrite arbitrary files ending in '.log', or (2) local users to overwrite arbitrary files via a symlink attack.
      • July 30, 2001: IRC DCC helper in the ip_masq_irc IP masquerading module 2.2 allows remote attackers to bypass intended firewall restrictions by causing the target system to send a "DCC SEND" request to a malicious server which listens on port 6667, which may cause the module to believe that the traffic is a valid request and allow the connection to the port specified in the DCC SEND request.
      • July 2, 2001: ip_conntrack_ftp in the IPTables firewall for Linux 2.4 allows remote attackers to bypass access restrictions for an FTP server via a PORT command that lists an arbitrary IP address and port number, which is added to the RELATED table and allowed by the firewall.
      • March 26, 2001: Firewall-1 4.1 with a limited-IP license allows remote attackers to cause a denial of service by sending a large number of spoofed IP packets with various source addresses to the inside interface, which floods the console with warning messages and consumes CPU resources.
      • December 11, 2000: The client authentication interface for Check Point Firewall-1 4.0 and earlier generates different error messages for invalid usernames versus invalid passwords, which allows remote attackers to identify valid usernames on the firewall.
      • December 11, 2000: The mailguard feature in Cisco Secure PIX Firewall 5.2(2) and earlier does not properly restrict access to SMTP commands, which allows remote attackers to execute restricted commands by sending a DATA command before sending the restricted commands.
      • November 14, 2000: The OPSEC communications authentication mechanism (fwn1) in Check Point VPN-1/FireWall-1 4.1 and earlier allows remote attackers to spoof connections, aka the "OPSEC Authentication Vulnerability."
      • November 14, 2000: The inter-module authentication mechanism (fwa1) in Check Point VPN-1/FireWall-1 4.1 and earlier may allow remote attackers to conduct a denial of service, aka "Inter-module Communications Bypass."
      • March 11, 2000: Firewall-1 3.0 and 4.0 leaks packets with private IP address information, which could allow remote attackers to determine the real IP address of the host that is making the connection.
      • February 12, 2000: Firewall-1 allows remote attackers to bypass port access restrictions on an FTP server by forcing it to send malicious packets which Firewall-1 misinterprets as a valid 227 response to a client's PASV attempt.
      • August 31, 1998: Cisco PIX firewall manager (PFM) on Windows NT allows attackers to connect to port 8080 on the PFM server and retrieve any file whose name and location is known.
      • June 1, 1998: An account on a router, firewall, or other network device has a default, null, blank, or missing password.
      • May 11, 1998: Check Point Firewall-1 does not properly handle certain restricted keywords (e.g., Mail, auth, time) in user-defined objects, which could produce a rule with a default "ANY" address and result in access to more systems than intended by the administrator.
    • Origin validations (8)
      • November 28, 2001: Cisco IOS Firewall Feature set, aka Context Based Access Control (CBAC) or Cisco Secure Integrated Software, for IOS 11.2P through 12.2T does not properly check the IP protocol type, which could allow remote attackers to bypass access control lists.
      • February 16, 2001: WatchGuard SOHO FireWall 2.2.1 and earlier allows remote attackers to cause a denial of service via a large number of GET requests.
      • December 11, 2000: The web administration interface for IBM AS/400 Firewall allows remote attackers to cause a denial of service via an empty GET request.
      • November 14, 2000: Check Point VPN-1/FireWall-1 4.1 and earlier improperly retransmits encapsulated FWS packets, even if they do not come from a valid FWZ client, aka "Retransmission of Encapsulated Packets."
      • April 24, 2000: ZoneAlarm 2.1.10 and earlier does not filter UDP packets with a source port of 67, which allows remote attackers to bypass the firewall rules.
      • January 1, 1999: A router or firewall forwards packets that claim to come from IANA reserved or private addresses, e.g. 10.x.x.x, 127.x.x.x, 217.x.x.x, etc.
      • January 1, 1999: A router or firewall forwards external packets that claim to come from inside the network that the router/firewall is in front of.
      • January 1, 1997: A router or firewall allows source routed packets from arbitrary hosts.
    • Input validations (14)
      • April 22, 2002: The printf wrappers in libsafe 2.0-11 and earlier do not properly handle argument indexing specifiers, which could allow attackers to exploit certain function calls through arguments that are not verified by libsafe.
      • April 22, 2002: libsafe 2.0-11 and earlier allows attackers to bypass protection against format string vulnerabilities via format strings that use the "'" and "I" characters, which are implemented in libc but not libsafe.
      • July 16, 2001: slapd in OpenLDAP 1.x before 1.2.12, and 2.x before 2.0.8, allows remote attackers to cause a denial of service (crash) via an invalid Basic Encoding Rules (BER) length field.
      • July 12, 2001: Format string vulnerability in Check Point VPN-1/FireWall-1 4.1 allows a remote authenticated firewall administrator to execute arbitrary code via format strings in the control connection.
      • July 9, 2001: Check Point VPN-1/FireWall-1 4.1 base.def contains a default macro, accept_fw1_rdp, which can allow remote attackers to bypass intended restrictions with forged RDP (internal protocol) headers to UDP port 259 of arbitrary hosts.
      • December 19, 2000: Format string vulnerability in x-gw in TIS Firewall Toolkit (FWTK) allows local users to execute arbitrary commands via a malformed display name.
      • November 14, 2000: The seed generation mechanism in the inter-module S/Key authentication mechanism in Check Point VPN-1/FireWall-1 4.1 and earlier allows remote attackers to bypass authentication via a brute force attack, aka "One-time (s/key) Password Authentication."
      • June 6, 2000: Check Point Firewall-1 allows remote attackers to cause a denial of service by sending a large number of malformed fragmented IP packets.
      • March 20, 2000: Cisco Secure PIX Firewall does not properly identify forged TCP Reset (RST) packets, which allows remote attackers to force the firewall to close legitimate connections.
      • January 29, 2000: Firewall-1 does not properly filter script tags, which allows remote attackers to bypass the "Strip Script Tags" restriction by including an extra < in front of the SCRIPT tag.
      • August 9, 1999: Firewall-1 can be subjected to a denial of service via UDP packets that are sent through VPN-1 to port 0 of a host.
      • January 1, 1999: A filter in a router or firewall allows unusual fragmented packets.
      • January 1, 1999: Some filters or firewalls allow fragmented SYN packets with IP reserved bits in violation of their implemented policy.
      • August 18, 1998: Cisco PIX firewall and CBAC IP fragmentation attack results in a denial of service.
    • Race conditions (1)
      • May 26, 2000: Race condition in IPFilter firewall 3.4.3 and earlier, when configured with overlapping "return-rst" and "keep state" rules, allows remote attackers to bypass access restrictions.
  • Operational:
    • Setup parameters (10)
      • June 18, 2002: Snapgear Lite+ firewall 1.5.3 and 1.5.4 allows remote attackers to cause a denial of service (crash) via a large number of packets with malformed IP options for connections to either the HTTP web management port or the PPTP port.
      • April 1, 2002: Check Point Firewall-1 3.0b through 4.0 SP1 follows symlinks and creates a world-writable temporary .cpp file when compiling Policy rules, which could allow local users to gain privileges or modify the firewall policy.
      • November 11, 2001: Vulnerability in Postfix SMTP server before 20010228-pl07, when configured to email the postmaster when SMTP errors cause the session to terminate, allows remote attackers to cause a denial of service (memory exhaustion) by generating a large number of SMTP errors, which forces the SMTP session log to grow too large.
      • July 18, 2001: Squid before 2.3STABLE5 in HTTP accelerator mode does not enable access control lists (ACLs) when the httpd_accel_host and http_accel_with_proxy off settings are used, which allows attackers to bypass the ACLs and conduct unauthorized activities such as port scanning.
      • February 12, 2001: Check Point VPN-1/FireWall-1 4.1 SP2 with Fastmode enabled allows remote attackers to bypass access restrictions via malformed, fragmented packets.
      • December 11, 2000: Cisco Secure PIX Firewall 5.2(2) allows remote attackers to determine the real IP address of a target FTP server by flooding the server with PASV requests, which includes the real IP address in the response when passive mode is established.
      • October 20, 2000: Checkpoint Firewall-1 with the RSH/REXEC setting enabled allows remote attackers to bypass access restrictions and connect to a RSH/REXEC client via malformed connection requests.
      • October 21, 1999: Denial of service in Axent Raptor firewall via malformed zero-length IP options.
      • July 29, 1999: Firewall-1 sets a long timeout for connections that begin with ACK or other packets except SYN, allowing an attacker to conduct a denial of service via a large number of connection attempts to unresponsive systems.
      • January 1, 1997: IP forwarding is enabled on a machine which is not a router or firewall.
    • Access permissions (10)
      • March 8, 2002: IRC connection tracking helper module in the netfilter subsystem for Linux 2.4.18-pre9 and earlier does not properly set the mask for conntrack expectations for incoming DCC connections, which could allow remote attackers to bypass intended firewall restrictions.
      • October 10, 2001: Cisco PIX firewall manager (PFM) 4.3(2)g logs the enable password in plaintext in the pfm.log file, which could allow local users to obtain the password by reading the file.
      • August 31, 2001: Check Point FireWall-1 allows remote attackers to cause a denial of service (high CPU) via a flood of packets to port 264.
      • March 26, 2001: Watchguard Firebox II firewall allows users with read-only access to gain read-write access, and administrative privileges, by accessing a file that contains hashed passphrases, and using the hashes during authentication.
      • November 14, 2000: Check Point VPN-1/FireWall-1 4.1 and earlier allows remote attackers to redirect FTP connections to other servers ("FTP Bounce") via invalid FTP commands that are processed improperly by FireWall-1, aka "FTP Connection Enforcement Bypass."
      • November 14, 2000: Check Point VPN-1/FireWall-1 4.1 and earlier allows remote attackers to bypass the directionality check via fragmented TCP connection requests or reopening closed TCP connection requests, aka "One-way Connection Enforcement Bypass."
      • October 20, 2000: Gnome Lokkit firewall package before 0.41 does not properly restrict access to some ports, even if a user does not make any services available.
      • October 20, 1999: Firewall-1 does not properly restrict access to LDAP attributes.
      • June 29, 1999: WebTrends software stores account names and passwords in a file which does not have restricted access permissions.
      • May 25, 1999: The fwluser script in AIX eNetwork Firewall allows local users to write to arbitrary files via a symlink attack.
    • Policy (1)
      • June 18, 2001: Configuration error in Axent Raptor Firewall 6.5 allows remote attackers to use the firewall as a proxy to access internal web resources when the http.noproxy Rule is not set.
    • Installation ordering (1)
      • October 18, 1999: When BSDI patches for Gauntlet 5.0 BSDI are installed in a particular order, Gauntlet allows remote attackers to bypass firewall access restrictions, and does not log the activities.
  • Environmental:
    • Proxy (3)
      • May 31, 2002: SMTP proxy in Symantec Enterprise Firewall (SEF) 6.5.x includes the firewall's physical interface name and address in an SMTP protocol exchange when NAT translation is made to an address other than the firewall, which could allow remote attackers to determine certain firewall configuration information.
      • September 20, 2001: SMTP proxy in WatchGuard Firebox (2500 and 4500) 4.5 and 4.6 allows a remote attacker to bypass firewall filtering via a base64 MIME encoded email attachment whose boundary name ends in two dashes.
      • June 30, 2000: Check Point Firewall-1 4.0 and 4.1 allows remote attackers to cause a denial of service by sending a stream of binary zeros to the SMTP Security Server proxy.
    • Daemon (1)
      • May 31, 2002: The Notify daemon for Symantec Enterprise Firewall (SEF) 6.5.x drops large alerts when SNMP is used as the transport, which could prevent some alerts from being sent in the event of an attack.
    • OS or Kernel (3)
      • December 6, 2001: Linux kernel 2.0, 2.2 and 2.4 with syncookies enabled allows remote attackers to bypass firewall rules by brute force guessing the cookie.
      • June 2, 2001: Borderware Firewall Server 6.1.2 allows remote attackers to cause a denial of service via a ping to the broadcast address of the public network on which the server is placed, which causes the server to continuously send pings (echo requests) to the network.
      • July 10, 1997: Windows NT 4.0 before SP3 allows remote attackers to bypass firewall restrictions or cause a denial of service (crash) by sending improperly fragmented IP packets without the first fragment, which the TCP/IP stack incorrectly reassembles into a valid session.
    • Encryption and authentication (3)
      • June 18, 2001: SonicWALL Tele2 and SOHO firewalls with 6.0.0.0 firmware using IPSEC with IKE pre-shared keys do not allow for the use of full 128 byte IKE pre-shared keys, which is the intended design of the IKE pre-shared key, and only support 48 byte keys. This allows a remote attacker to brute force attack the pre-shared keys with significantly less resources than if the full 128 byte IKE pre-shared keys were used.
      • June 18, 2001: Cisco PIX Firewall 515 and 520 with 5.1.4 OS running aaa authentication to a TACACS+ server allows a remote attacker to cause a denial of service via a large number (approximately 426) of authentication requests.
      • April 1, 1998: An account on a router, firewall, or other network device has a guessable password.

 

 

Conclusions

 

As shown in the list above, most firewall vulnerabilities belong to buffer size handlings, access controls on both implementation and operational levels, the nature of the input packets, and the settings and handlings of the setup parameters. Some of these vulnerabilities can actually be easily classified in more than one classes, which is a big reason why Aslam’s model itself needs further enhancements. The majority of the vulnerabilities found in firewalls proved that both proper software design/development and installation are very important to ensure security for the network intended to be protected by the firewall or otherwise disadvantages will outweigh the advantages.

 

 

References

 

Hosted by www.Geocities.ws

1