<<< Date Index >>>     <<< Thread Index >>>

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@xxxxxxxxx>
To: sanjaynaik@xxxxxxxx
CC: bugtraq@xxxxxxxxxxxxxxxxx
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@xxxxxxxxxxx> 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@xxxxxxxxxx

_________________________________________________________________
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/