Hi,
There is also a little trick to find your PIX box or someone elses by
doing nmap -sP x.x.x.0/24 if you or someone is blocking ICMP packets.
----- Original Message -----
From: "mcoleman" <mcolemanat_private>
To: <vuln-devat_private>
Sent: Thursday, May 31, 2001 10:57 AM
Subject: PIX revealing Statics when hit with NMAP...
> Hi list,
>
> I originally submitted this to bugtraq proper, but it was rejected
with
> the following message:
>
> >>>>> -------------------- >>>>>
> Post to the vuln-devat_private mailing list. Once you or others
> have flushed out the details a little more post to bugtraq.
> <<<<< -------------------- <<<<<
>
> I am sorry to say that I am not subscribed to the vuln-dev list, so I
> would REALLY appreciate it if all posts on this topic were CC:'d to
> mcolemanat_private so that I can follow the discussion and answer any
> questions.
>
> I am also sorry to say that I just simply don't have time to follow
up
> on this right now, but have gotten so much from these lists that I feel
> obligated to post what I have found. I would be very interested to see
> anyone's results from testing. I may get back to it soon if nobody else
is
> able to. Thanks....
>
> Here is my original email to bugtraq:
>
> ---------------------------------------------------------
>
> I have been playing with NMAP and think I found a way to identify
> "statics" in a NATted PIX firewall.
>
> I don't know if this is a known thing, I did a quick search and
didn't
> see anything. If so, please ignore.
>
> Please be aware that I temporarily have ICMP enabled in the PIX's
> conduits, and when I run Eeye's M$ version NMAP (no Linux on my laptop
yet)
> using the following::
>
> nmapnt -O 123.123.123.2-254 -sX
>
> (IP address intentionally faked above)
>
> ...NMAP lists the following as part of its output among other things:
>
> Host (123.123.123.213) seems to be a subnet broadcast address (returned
1
> extra pings). Skipping host.
> Host (123.123.123.214) seems to be a subnet broadcast address (returned
1
> extra pings). Skipping host.
> Host (123.123.123.216) seems to be a subnet broadcast address (returned
1
> extra pings). Skipping host.
> Host (123.123.123.217) seems to be a subnet broadcast address (returned
1
> extra pings). Skipping host.
> Host (123.123.123.218) seems to be a subnet broadcast address (returned
1
> extra pings). Skipping host.
> Host (123.123.123.222) seems to be a subnet broadcast address (returned
1
> extra pings). Skipping host.
> Host (123.123.123.224) seems to be a subnet broadcast address (returned
1
> extra pings). Skipping host.
>
> (Again, addresses above changed to fake numbers)
>
> These are inclusively the EXACT same addresses of my static address
> translations in the PIX. These statics only permit very specific things
> inbound via the conduits (other than the ICMP that is), so the TCP
> interaction
> probably didn't occur through the PIX with other parts of the scan. While
> the conduit in the PIX is wide open for ICMP for this test:
>
> conduit permit icmp any any
>
> ...the NMAP seems to be able to identify the static'd NAT addresses.
>
> Those of you who are unaware of what static addresses do, they allow you
to
> permanently assign an address from the NAT pool to a certain host behind
the
> PIX. I use this to fix an address for access-list entries on our border
> router for a particular high UDP port for replies to our internal DNS
> server.
> It is very common for the static addresses to have conduits associated
with
> them that allow certain inbound traffic. Revealing the statics could give
> an
> attacker clues as to which NAT'ted IP addresses are servers behind the
PIX,
> or have open inbound conduits.
>
> My config is failover PIX 520 using 5.0(3), using NAT overflowing to PAT,
> with
> specific conduits on only specific Static'd addresses. I am using the
> conduit
> PERMIT ICMP ANY ANY, but have not yet had the time to remove that conduit
> to run NMAP again to see if removing that will eliminate the problem.
>
> During times of testing and troubleshooting, I will often enable ICMP in
the
> conduits, but will now be reconsidering this practice for extended periods
> of time.
>
> I won't have time to follow up on this issue at the moment, might get to
it
> later. I do know that using a sniffer, I do NOT see duplicate ping
replies
> when I do a simple M$ ping (you have to use a sniffer if you ping with M$,
> as M$ doesn't list any duplicate replies I don't think, as Linux does). I
> will likely run the sniffer in a week or two when things slow down to see
> exactly what NMAP did to generate "extra pings", and to identify these
> conduits. It might not even be ICMP for all I know right now. Thanks.
>
> -Mark Coleman
> -TNS
>
>
>
>
This archive was generated by hypermail 2b30 : Fri Jun 01 2001 - 19:29:33 PDT