Re: ICMP pokes holes in firewalls...
On Thursday 25 September 2003 02:21 pm, bugtraq@xxxxxxxxxxxxxxxx wrote:
[ snip ]
> These are UDP services that open the firewall for inbound traffic.
> Basically, a home firewall that does not manage connections at
> layer-4 will be unable to stop this type of attack.
This also applies to Linux NAT gateways. Any outbound UDP packet creates
an opening in the NAT firewall where any external source can fire packets
back the client port. To make things worse, this UDP gateway stays open
for a period of time after the initial response. It is exploitable in at
least the following situations:
1) A malicious attacker knows that users in MediumCorp use a Linux NAT
gateway and host their DNS server externally. They are able to send
arbitrary responses back to the DNS client ports on internal systems,
potentially exploiting one more resolver vulnerabilities.
2) There are a fairly small set of published public NTP servers. Many
organizations synchronize internal systems (and routers) directly to
these servers. Many of these servers have been configured so that it is
possible to obtain a list of all clients who have recently polled this
service. This list can then be checked for interesting organizations.
Once a nice target has been identified and their NAT gateway has been
detected as a ignore-the-source UDP forwarder, a malicious attacker could
exploit any of the NTP client-side bugs.
Client applications that make use of the recvfrom API call (vs connect and
recv) can have arbitrary responses sent back to them through a NAT
gateway with this problem. Applications using the connect API will simply
respond back with an ICMP port unreachable, the response will be received
by the attacked and can easility be differentiated from the responses
from unused NAT gateway ports.
> Again, this is low risk, fairly minor, and a trivial attack method.
> But, I've not seen anyone mention this.
I posted about this in March of 2000, the kernel development team response
was that many RPC services require this functionality and it would not be
fixed. The reason is that many UDP-based RPC services will respond back
to requests from an alternative interface using a different IP address
entirely.
http://lists.insecure.org/lists/bugtraq/2000/Mar/0324.html
-HD