Message-ID: <BAY108-F31379179E33C828FE3116CCCA00@phx.gbl>
Date: Tue, 16 May 2006 11:09:24 -0400
From: "sanjay naik" <sanjaynaik@...mail.com>
To: bugtraq@...urityfocus.com
Subject: Checkpoint SYN DoS Vulnerability


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/

Powered by blists - more mailing lists