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