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 : Thu May 31 2001 - 11:57:34 PDT