[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [FW1] Blackhat's disclosure: and so what ?!
Gregory,
Yea... Here is my post from last summer about FW-1 providing all of its'
IP addresses to potential attackers. I actually wrote a small program back
in the fall of 1998 that would go out and gather all the IP addresses from
the firewalls in my lab...
I let Checkpoint know about this back in 1998, but they didn't seem to
care. That was about the same time I reported a management denial of
service attack (the box would enforce the current policy, but I could keep
an administrator from being able to connect to his firewall with the GUI and
change the security policy). The original idea came from Lars Troen --
apologies if I have misspelled your name. Checkpoint addressed that issue
with patch 3072, I think. Radio Flyer... ;)
-----Original Message-----
From: iden fw [mailto:[email protected]]
Sent: Wednesday, August 11, 1999 09:16
To: [email protected]; [email protected]
Cc: [email protected]
Subject: Re: [FW1] DOS, 256/tcp - The Phantom Menace
If this port is open, the firewall will also spill all of it's IP addresses
to an attacker...
>From: "Olaf Selke" <[email protected]>
>Reply-To: [email protected]
>To: [email protected] (Firewall-1 Mailing List)
>CC: [email protected]
>Subject: [FW1] DOS, 256/tcp - The Phantom Menace
>Date: Tue, 3 Aug 1999 13:50:26 +0200 (MET DST)
>
>
>tested on platform:
>===================
>attacker: Linux 2.0.35, nmap V. 2.12
>victim: Solaris 2.6, FireWall-1(R) Version 4.0 Build 4064 [VPN + DES]
>
>
>In the last few days there's been a discussion on this list about DOS
>attacks against a FireWall-1 system, basing on Lance Spitzner's idea
>to fill up the state table with tcp connections completely. This means
>that until the tcp session timeout which defaults to 1 hour no new
>session through the firewall can't be established. As a prerequisite at
>least one rule must permit tcp packets. Usually outbound traffic will
>be permitted, so an attacker sitting on the inside will be able to
>disable the firewall.
>That issue has been discussed at length on this list and is not really
>new.
>
>
>The Challenge:
>==============
>How could a misguided individual exploit this feature from an untrusted
>network, even with a properly configured firewall?
>
>Supposed we've only one rule on our firewall system:
>
>Source Destination Service Action Track Install On Time
>any any any drop long firewall any
>
>
>that sounds very secure, eh?
>
>
>
>Before we can think about how to fill up the state table we need to
>find at least one open tcp port. The rule above doesn't look like
>there're open ports, but if you've enabled 'Accept FireWall-1 Control
>Connections' in your properties setup, port 256/tcp will be open
>locally to the firewall.
>
>* Port 256/tcp is the key!
>
>according Phoneboy's FAQ http://www.phoneboy.com/fw1/
>TCP Port 256 is used for three important things:
>
>- Exchange of CA and DH keys in FWZ and SKIP encryption between two
> FireWall-1 Management Consoles.
>- A SecuRemote Client uses this port to fetch the network topology and
> encryption key from a FireWall-1 Management Console
>- When instaling a policy, the management console uses this port to
> push the policy to the remote firewall.
>
>
>In a second step we need to find some kind of exploit how to fill up
>the state table via 256/tcp. Inspired by Lance Spitzner I tried nmap
>with all kind of fancy flags. It took some time to find out what
>kind of packets will generate entries in the state table, remaining
>until tcp session timeout.
>
>Finally I've found tcp Null scans, turning off all flags, generated by
>'nmap -p256 -sN <firewall>' doing this job. This command will generate
>only one entry in the state table, so we'd need to issue this command
>typically 25.000 times. More efficient is
>
>'nmap -D[a large number of decoys] -p256 -sN <firewall>' which will
>generate as much entries as you like, remaining in the state table.
>
>Because this kind of attack relies on certain behaviour of the
>firewall software *and* the underlying operating system, I don't know
>if it works on other platforms as Sun Solaris 2.6. Maybe there's
>somebody outside who may penetrate a NT based FW-1, providing us with
>feedback.
>
>
>Management Summary :-)
>==================
>If FireWall-1 Control Connections are enabled, even a properly
>configured FireWall-1 V4.0 can be vulnerable to DOS attacks launched
>from untrusted networks.
>
>
>Olaf
>--
>Olaf Selke, [email protected], voice +49 5241 80-7069
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================