|
|
|
|
|
|
|
|
 |
 |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [FW1] FW: Licensing Firewall-1 DoS Attack
I think that this report is correct even though I didn't have a chance to test it by myself. However, I can't see this as alarming exploit. You have to be in internal network to attack your own gateway. Source of this attack can be fairly easily discovered and remedy can be done fairly easily. As it is originally caused by malfunctioining Cisco box inside in this incident, it is rather of insignificant instability than vulnerability, IMO. Sun Yu NSE, Lucent Worldwide Services > -----Original Message----- > From: [email protected] > [mailto:[email protected]]On Behalf Of > Adams, Gavin > Sent: Thursday, January 18, 2001 2:09 PM > To: [email protected]; [email protected] > Subject: [FW1] FW: Licensing Firewall-1 DoS Attack > Importance: High > > > > Forwarded with permission of Tim Hall. > > If anyone has time and a lab, it would be great to see if it affects > other common platforms (Nokia, NT/2000). > > -----Original Message----- > From: Tim Hall [mailto:[email protected]] > Sent: Thursday, January 18, 2001 01:51 > To: [email protected] > Subject: Licensing Firewall-1 DoS Attack > > I have identified a denial of service attack > that can be launched against Firewall-1 that has > identical results to the IP fragmentation attack > identified by Lance Spitzner. > > Symptoms: Firewall CPU hits 100% utilization, console > locks up, a reboot only temporarily solves the problem. > > Vulnerable: All versions of Firewall-1 4.1 on Solaris 2.x > using a limited-IP license > > Probably Vulnerable: All versions of Firewall-1 4.1 using > a limited-IP license on Nokia IPSO, possibly other > variants of Unix > > Not vulnerable: Firewall-1 4.0 (all service packs) and > earlier > > Discussion: > > On firewall modules with a limited-IP license, Firewall-1 > counts the number of unique source IP addresses entering > all non-outside interfaces. The outside interface typically > is Internet-facing. If more IP addresses are counted > that the firewall module is licensed for, a warning > message is output to the firewall's console. In 4.1, the warning > includes a list of all IP addresses counted in the Firewall-1 > licensing calculation. The 4.0 message only included the number of > IP addresses corresponding to the licensed limit. > > By sending a large number of packets with spoofed source > addresses to any inside interface, enough addresses will be > included in the console output to cause a new warning > message to be issued before the previous one can finish. > As a result the console device will be overrun and begin > to consume large amounts of CPU time. This output > makes the console virtually unusable making it more difficult > to recover from this situation. > > There is no way to block this behavior in the rule base. Even > if the spoofed packets in question are dropped explicitly by > a rule or implicitly by antipspoofing they will still be > included in the license calculation. A reboot will not clear > this problem either, since Firewall-1 will begin sending > the license violation messages to the console immediately upon > rebooting. Clearing the license count as described at PhoneBoy's > site will help temporarily, but if the flood of spoofed packets > continues Firewall-1 will rapidly end up in the same state > again. > > Reproducing the Vulnerability: > > To reproduce this vulnerability these two conditions must both be > true: > > 1) The firewall module has to have a limited-IP license > 2) An attacker has to be able to route packets to any > inside interface of the firewall. Note that this > could include DMZ interfaces as well as the "inside" > network; only the single defined outside interface is > impervious. Also note that the packets do not > have to be accepted by the firewall's security policy. > > Any tool that can send a stream of packets with random, unique > source IP addresses can be used to reproduce this problem. > The SYN flooder synk4.c is an excellent example. In our > testing we found that once the firewall module was attempting > to output approximately 6,000 IP addresses to the console > it would be overrun. On a high-speed LAN a SYN flooder > could send this amount of traffic in seconds. > > Work Around/Fix: > > Similar to the IP Frag attack, issuing a 'fw ctl debug -buf' > will prevent this console logging from consuming excessive CPU. > While many firewall administrators installed this workaround > earlier to combat the frag problem, it was probably removed > from the fwstart script when they upgraded to SP2 or later. > > Vendor Reporting: > > I contacted CheckPoint immediately after discovering this > problem. They have confirmed that it is indeed a problem and > recommend using the 'fw ctl debug -buf' workaround as > an immediate solution. CheckPoint is currently researching > a more permanent solution to the problem and will include > the solution in a further release. > > Initial Discovery: > > I was called into a client site whose High Availability > Firewall cluster was hanging and crashing constantly. > A closer examination of the firewalls > revealed that they were 100% utilized spewing > license warnings onto the console port which > was overwhelmed with data. A "fw lichosts" > revealed thousands of bogus addresses being > counted in the license calculation and thus > pushing the customer over their license. > These bogus addresses were things like > 254.3.4.5, 0.0.3.4 and so on; the external > interface was defined properly so that > wasn't the problem. > > It turned out that a Cisco LocalDirector > was spewing packets with garbage source and > destination IP addresses on a DMZ interface. > This is a known Cisco bug and has Cisco bugID > #CSCdr08284. Then it occurred to me than one could > induce this situation by flooding the firewall with > IP datagrams carrying random source IP addresses. > Firewall-1 would be so busy spewing license > warnings to the console nothing else would get done. > > References: > > Lance Spitzner's original bugtraq post concerning the IP frag attack: > > http://www.securityfocus.com/archive/1/63478 > > CheckPoint's official page concerning the previous IP frag attack: > > http://www.checkpoint.com/techsupport/alerts/ipfrag_dos.html > > PhoneBoy's Firewall-1 FAQ site: > > http://www.phoneboy.com/fw1 > > Thanks: > > I'd like to thank Scott Walker Register of CheckPoint for his > prompt and courteous assistance in dealing with this matter. > > I'd also like to thank Geoff Hannam <[email protected]> for > his assistance in isolating this problem. > > Tim Hall > Senior Security Engineer > The Root Group > [email protected] > http://www.rootgroup.com > > > > > ============================================================== > ================== > To unsubscribe from this mailing list, please see the > instructions at > http://www.checkpoint.com/services/mailing.html > ============================================================== > ================== <<attachment: winmail.dat>>
|
||||||||||
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
