Hi,

I first tried nmap -vO -p 22 |grep IPID directed against BOTH the
internal and external PIX interface (from each side) and received:

IPID Sequence Generation: Incremental on both.

Ok, checking the tcpdump the Cisco definitily is using incremental ipids for your IP address. It is possible that it maintains per-destination counters, so you should try an nmap idle scan to discount that - nmap -P0 -sI <zombie> <target>

e.g. here I am using risk, a windows box as my zombie, and scanning fester - and it correctly identifies the open port.

[EMAIL PROTECTED] paul]# nmap -P0 -p 70-90 -sI risk fester

Starting nmap 3.45 ( http://www.insecure.org/nmap/ ) at 2003-11-06 09:36 GMT
Idlescan using zombie risk (192.168.XXX:80); Class: Incremental
Interesting ports on fester (192.168.XXX):
(The 20 ports scanned but not shown below are in state: closed)
PORT   STATE SERVICE
80/tcp open  http

Nmap run completed -- 1 IP address (1 host up) scanned in 5.225 seconds

If I try again with Pugsley, a Linux 2.4 box I get this:

[EMAIL PROTECTED] paul]# nmap -P0 -p 70-90 -sI pugsley fester

Starting nmap 3.45 ( http://www.insecure.org/nmap/ ) at 2003-11-06 09:42 GMT
Idlescan zombie pugsley (192.168.XXX) port 80 cannot be used because IPID sequencability class is: All zeros. Try another proxy.
QUITTING!


Very strange! So - It appears that the PIX is not randomizing IP IDs and
I'm not sure what to make of the Linux results since when I Nessus scan
it with either itself or another Linux Nessus system (from the outside
or inside of the PIX firewall) I get the same Nessus warning that the
remote system does not randomize TCP results. Well, now that I think
about it - they are not random, they are all zeros! Anyone have any idea
why?

As the ipid is only used for reassembling fragmented packets, Linux zeros it out for packets with the DF bit set, which is why you were getting the "all zeros" result. This approach does solve the vulnerability (at least for DF packets) and the nessus plugin is prone to false positives against these hosts.

BTW - be careful not to confuse the ipid field with the tcp initial sequence number (isn) - they are not the same thing.

What do you think? Time to call Cisco?

Well, wait until you have done a successful idle scan - that proves the vulnerability by exploiting it, but I suspect your PIX needs upgrading.

Paul

--
Paul Johnston
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: [EMAIL PROTECTED]
web: www.westpoint.ltd.uk




Reply via email to