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]
Message-ID: <200309251557.27020.sflist@digitaloffense.net>
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ