Message-ID: <BAY108-F2806D307C16FECC1CDCA06CCA10@phx.gbl>
Date: Wed, 17 May 2006 01:41:15 -0400
From: "sanjay naik" <sanjaynaik@...mail.com>
To: feofil@...il.com
Cc: bugtraq@...urityfocus.com
Subject: Re: Checkpoint SYN DoS Vulnerability



Hi Chris,

This is almost similar to what I notice with the scans. The URL you provided 
is similar except for a few differences. The scans are being done from the 
inside interface to the outside from the firewall. The scan is a complete 
TCP Connect scan.

However, what you have pointed out is really appreciated. There definitely 
is a problem with this erratic behavior of Checkpoint which is being called 
as a feature. The same scans work perfectly fine on our PIX firewalls.

Regards,
Sanjay Naik, CISSP
Sr. Security Consultant

----Original Message Follows----
From: "Christian Swartzbaugh" <feofil@...il.com>
To: sanjaynaik@...e.org
CC: bugtraq@...urityfocus.com
Subject: Re: Checkpoint SYN DoS Vulnerability
Date: Tue, 16 May 2006 16:14:35 -0700

i've seen this behavior recently too. the reason it does this is the
checkpoint device is replying to a session startup before receiving a
legitimate response from the actual endpoint.

you probably should read this thread
http://mail.nessus.org/pipermail/nessus/2005-June/msg00096.html

feofil


On 5/16/06, sanjay naik <sanjaynaik@...mail.com> wrote:
>
>Hello,
>
>I have recently come across a strange behavior observed on the Nokia
>Checkpoint Firewall. Nokia as well as Checkpoint have no clue as to why
>this
>is occuring and have not provided any resolution to this.
>
>We have been having multiple Vulnerability Scanner failures on the
>Intranet
>of the company XYZ. A careful study using NMAP and Netcat revealed that
>the
>scans failed only when the scanned IPs had to be reached through the
>firewall. This confirmed our doubt that the Checkpoint Firewall was the
>the
>issue for the scanner failures.
>
>When a scan is intiated from the Inside interface of Checkpoint firewall,
>the firewall responds with bogus information intermittently. I would like
>to
>submit the following bug for Checkpoint:
>
>Checkpoint SYN DoS Vulnerability
>A TCP/IP session is established using three-way handshake in compliance to
>the TCP protocol. A three-way handshake starts with a Source host sending
>a
>SYN and the destination host acknowledging the SYN with a SYN/ACK if the
>port is in the listening or open state. A port that is closed would result
>in a RST being sent back by the destination host. A SYN/ACK reported back
>to
>NMAP would be an open port and a RST will be assumed to be a closed port.
>This is apparently not followed by Checkpoint as it checks the rulebase,
>creates a statetable entry and responds with a SYN/ACK on behalf of the
>destination host for all ports irrelevant of their actual state.
>Checkpoint
>creates a connection table entry for all SYN connects from the scanner and
>responds with a SYN/ACK even though a RST should have been actually sent.
>The results of the NMAP scan were inconsistent and inaccurately reported
>by
>Checkpoint.
>The test was done on hosts that were beyond the firewall and also on the
>Interface of the firewall. In both cases, the scans results were
>inconsistent. Both SYN and ACK scans had similar issues.
>The reason for this is not known to Checkpoint but this is apparently due
>to
>a bug in Checkpoint where the statetable is created for destination ports
>that do not exist. This leads to a DoS condition as the firewall starts
>showing performance degradation until the statetable timeouts.
>An example of the checkpoint bug –
>[user]$ nmap -sT -P0 -v -p 1-1023 10.x.x.x
>
>Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-04-06 19:55
>GMT
>Initiating Connect() Scan against 10.x.x.x [1023 ports] at 19:55
>Interesting ports on 10.x.x.x:
>(The 1017 ports scanned but not shown below are in state: closed)
>PORT    STATE SERVICE
>21/tcp  open  ftp
>22/tcp  open  ssh
>80/tcp  open  http
>111/tcp open  rpcbind
>199/tcp open  smux
>443/tcp open  https
>
>On scanning again, this is the response received:
>[user]$ nmap -sT -P0 -v -p 1-1023 10.x.x.x
>Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-04-06 19:55
>GMT
>Initiating Connect() Scan against 10.x.x.x [1023 ports] at 19:55
>Interesting ports on 10.x.x.x:
>PORT     STATE SERVICE
>1/tcp    open  tcpmux
>2/tcp    open  compressnet
>3/tcp    open  compressnet
>4/tcp    open  unknown
>5/tcp    open  rje
>6/tcp    open  unknown
>7/tcp    open  echo
>.
>.
>.
>.
>1017/tcp open  unknown
>1018/tcp open  unknown
>1019/tcp open  unknown
>1020/tcp open  unknown
>1021/tcp open  unknown
>1022/tcp open  unknown
>
>Regards,
>Sanjay Naik, CISSP, CHSS
>Information Security Advisor
>IBM Security & Privacy Practices
>IBM Global Services
>Business Phone # 978-878-3246
>Internet: sanjnaik@...ibm.com
>
>_________________________________________________________________
>Don't just search. Find. Check out the new MSN Search!
>http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
>

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Powered by blists - more mailing lists