ISS Security Advisory: Snork

From: X-Force (xforceat_private)
Date: Tue Sep 29 1998 - 08:34:06 PDT

  • Next message: Steven Hearon: "Bay Accelar 1000 series"

    -----BEGIN PGP SIGNED MESSAGE-----
    
    ISS Security Advisory
    September 29, 1998
    
    "Snork" Denial of Service Attack Against Windows NT RPC Service
    
    Synopsis:
    
    The ISS X-Force has been researching a denial of service attack against
    the Windows NT RPC service.  This attack allows an attacker with minimal
    resources to cause a remote NT system to consume 100% CPU Usage
    for an indefinite period of time.  It also allows a remote attacker to
    utilize a very large amount of bandwidth on a remote NT network by
    inducing vulnerable systems to engage in a continuous bounce of packets
    between all combinations of systems.  This attack is similar to those
    found in the "Smurf" and "Fraggle" exploits, and is known as the "Snork"
    attack.
    
    This vulnerability exists on Windows NT 4.0 Workstation and Server.
    All systems with service packs up to and including SP4 RC 1.99 are
    vulnerable, including any hotfixes released prior to 9/10/98.  Patch
    information is provided below.
    
    
    Recommended Action:
    
    Microsoft has made a patch available for the "Snork" attack.  Patch
    information is available at
    http://www.microsoft.com/security/bulletins/ms98-014.htm .
    
    
    Network administrators can protect internal systems from external attack
    by adding a rule to a filtering router or firewall of the type:
         Deny all incoming UDP packets with a destination port of 135 and
         a source port of 7,19, or 135.
    
    Many firewalls or packet filters may already have more restrictive
    rulesets which already encompass this filtering rule, in which case the
    network is already protected from an external "snork" attack.  This would
    include filtering all incoming traffic to UDP port 135.
    
    There are NT applications which rely upon legitimate traffic passing
    between UDP ports 135 on a source and destination machine.  If this is the
    case on your network, it is strongly recommended you apply the Microsoft
    hot-fix to any systems that allow external access.
    
    Administrators of network intrusion detection systems, including ISS's
    RealSecure, can immediately detect snork attempts on their network by
    adding a filter rule that detects traffic with the following specifications:
    
    Name: Snork
    Protocol: UDP
    Source Address: Any
    Source Port: 135 (additional rules for ports 7 & 19 if desired)
    Destination Address: Any
    Destination Port: 135
    
    There may be third party software on your network that communicates to the
    NT RPC service with this source port.  If this is the case, you must add
    the rules listed earlier in this advisory with the source address of those
    systems that need legitimate source port 135 traffic to pass, specifying
    that traffic can be passed in the case of a firewall, or to be ignored in
    the case of an intrusion detection system, in order to maintain the
    connectivity of those applications.
    
    
    Description:
    
    In X-Force lab tests, a single UDP packet is able to raise the CPU
    utilization on a Windows NT system to 100% for a period of 5-120 seconds.
    A low bandwidth continuous attack of this sort is able to keep the CPU
    utilization at 100% for an unlimited period of time.
    
    This vulnerability can also be exploited as a network bandwidth consuming
    attack by creating UDP packets that result in a constant packet bounce
    between all combinations of Windows NT systems on a network.  This attack
    can quickly consume available bandwidth on even a small network.  The
    consumption rate between any two idle Windows NT systems on an idle
    network is approximately 224/RTT (round-trip time), which translates on a
    10Mbps Ethernet to approximately 3.4Mbps of traffic.  Increasing the
    number of systems involved in the packet bounce exponentially increases
    this traffic, and as collisions occur and packet loss begins the network
    bandwidth used by this attack very quickly approaches 100%.
    
    
    Additional Information:
    
    This vulnerability was primarily researched by David Meltzer
    (davemat_private), with assistance from Jon Larimer (jlarimerat_private), and
    David LeBlanc (dleblancat_private), all of the ISS X-Force.
    
    _______
    
    Copyright (c) 1998 by Internet Security Systems, Inc.
    
    Permission is hereby granted for the redistribution of this alert
    electronically.  It is not to be edited in any way without express consent
    of X-Force.  If you wish to reprint the whole or any part of this alert in
    any other medium excluding electronic medium, please e-mail xforceat_private
    for permission.
    
    Disclaimer
    The information within this paper may change without notice. Use of this
    information constitutes acceptance for use in an AS IS condition. There
    are NO warranties with regard to this information. In no event shall the
    author be liable for any damages whatsoever arising out of or in
    connection with the use or spread of this information. Any use of this
    information is at the user's own risk.
    
    X-Force PGP Key available at: http://www.iss.net/xforce/sensitive.html as
    well as on MIT's PGP key server and PGP.com's key server.
    
    X-Force Vulnerability and Threat Database: http://www.iss.net/xforce
    
    Please send suggestions, updates, and comments to:
    X-Force <xforceat_private> of Internet Security Systems, Inc.
    
    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.3a
    Charset: noconv
    
    iQCVAwUBNhD8CzRfJiV99eG9AQEnLwP8CWKvbPvBkQDFPtDttXesBvca1GdgLmtb
    ez4zooqDDGejomkuO3IslI/gK+1cRtUPyJppONXJ/7l2Y0QDhxok7C6KWcjmMj7S
    QCSViKsde08f+FGTKPCd3HVb7pD41MaHKZAT1pk7R5N9ee5PhakCyroctHPoCvkb
    R4pOi0c3kr8=
    =pVE2
    -----END PGP SIGNATURE-----
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:18:08 PDT