bugtraq - Re: ICMP pokes holes in firewalls...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 25 Sep 2003 15:57:27 -0500
From: H D Moore <sflist@...italoffense.net>
To: <bugtraq@...kerfactor.com>, bugtraq@...urityfocus.com
Subject: Re: ICMP pokes holes in firewalls...

On Thursday 25 September 2003 02:21 pm, bugtraq@...kerfactor.com 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