Re: ICMP pokes holes in firewalls...

From: H D Moore (sflist_at_digitaloffense.net)
Date: 09/25/03

  • Next message: Dragos Ruiu: "Re: Ruh-Roh SOBIG.G?" 
    To: <bugtraq@hackerfactor.com>, bugtraq@securityfocus.com
Date: Thu, 25 Sep 2003 15:57:27 -0500

    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

  • Next message: Dragos Ruiu: "Re: Ruh-Roh SOBIG.G?"

    Relevant Pages

    • Re: Strange UDP Socket problem
      ... You can catch that exception and move on. ... never get any udp reply back to post an exception. ... >> I suspect you would get the same response if you used one thread to send ... >> thread on same socket. ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: site to site VPN CISCO PIX
      ... doggedpuppy's response is incorrect. ... images of each other in order for response packets ... and then do NOT permit anything from the 501 LAN to the 515 LAN ... Note that if you did configure this way, then some UDP would fail between the ...
      (comp.dcom.sys.cisco)
    • Re: Strange UDP Socket problem
      ... thread on same socket. ... > It's my understanding of UDP sockets that if there is a thread blocked on ... my "recvFrom" call throws an exception. ... It may or may not get a response to the ...
      (microsoft.public.dotnet.languages.csharp)
    • RE: DNS ACL ?
      ... > Not all DNS clients automatically try to negotiate bigger UDP ... The same goes for DNS servers. ... as a part of the response, but could not be included in its entirety. ...
      (Pen-Test)