Page History

The CERT Coordination Center publishes incident notes to provide
information about incidents to the Internet community.

<h2>Exploitation of Unprotected Windows Networking Shares</h2>

Updated: Friday, April 7, 2000<br/>
Date: Friday, March 3, 2000<br/>
<hr/><br/>
<h3>Overview</h3>
<p>
Intruders are actively exploiting Windows networking shares that are
made available for remote connections across the Internet. This is not
a new problem, but the potential impact on the overall security of the
Internet is increasing.
<p>
<h3>Description</h3>
<p>
We have received reports indicating a rise in activity related to a
malicious Visual Basic Script (VBScript) known as "network.vbs". The
malicious script is similar to a harmless example script distributed
with some versions of Windows 98, found as:
<p>
<dl>
<dd>c:\windows\samples\wsh\network.vbs
</dd></dl>
<p>
The malicious network.vbs script attempts to do the following
things:
<p>
<ul>
<li>Open C:\network.log on the local machine<p>
<li>Generate a random /24 network address block. The algorithm 
  we have seen used to generate addresses is:<p>
<ul>
<li>the first octet will be randomly selected between 199 and 214
    the first 50 times, after which is it randomly selected between 
    1 and 254
    <li>the second and third octet are randomly selected 
    between 1 and 254
    <li>the fourth octet begins at 1
  </li></li></li></ul>
<p>
<li>The generated /24 address is written to C:\network.log<p>
<li>For each host address from 1 to 254 in the generated /24 range,
  network.vbs attempts to remotely mount a share named "C" from the
  remote computer as J: on the local computer.<p>
<li>If the "C" share of a remote computer is mounted successfully,
  copies network.vbs to the following locations on the remotely mounted
  filesystem:
  <dl>
<dd>"j:\"
    <dd>"j:\windows\startm~1\programs\startup\"
    <dd>"j:\windows\"
    <dd>"j:\windows\start menu\programs\startup\"
    <dd>"j:\win95\start menu\programs\startup\"
    <dd>"j:\win95\startm~1\programs\startup\"
    <dd>"j:\wind95\"
  </dd></dd></dd></dd></dd></dd></dd></dl>
  If the first copy is successful, the address of the target system is
  written to C:\network.log.<p>
<li>network.vbs then generates a new random /24 network
  address range and starts the process over. It will continue to cycle
  through random address space implanting copies of itself onto
  vulnerable computers until administrative intervention prevents
  further execution.
</li></p></li></p></li></p></li></p></p></li></p></li></ul>
<p>
When configuring the C: drive of a Windows 9x machine to be shared,
the default share name assigned is "C". If this default share name is
used on a vulnerable computer, network.vbs performs it's file copies
on the C: drive of the remote system. If network.vbs is successfully
copied into a Windows startup folder on a remote system, the remote
system could execute network.vbs when the system reboots or a new user
logs into the system.
<p>
We have also seen variations of network.vbs that perform different
actions, such as:
<p>
<ul>
<li>Create deceptively titled malicious items in the Windows startup
    folder and in the user start menu
<li>Deploy distributed encryption cracking tools on vulnerable systems
</li></li></ul>
<p>
The network.vbs script demonstrates one pervasive method of
propagation intruders can leverage to deploy tools on Windows-based
computer systems connected to the Internet. We are aware of one
infected computer that attempted to infect a range of at least
2,400,000 other IP addresses before being detected and stopped. There
may also be denial of service issues due to packet traffic if
network.vbs is able to infect and execute from a large number of
machines in a concentrated area.
<p>
Abe Singer from the San Diego Supercomputer Center has also published
an analysis of network.vbs, available at:
<dl>
<dd><a href="http://security.sdsc.edu/publications/network.vbs.shtml">
    http://security.sdsc.edu/publications/network.vbs.shtml</a>
</dd></dl>
<p>
<h3>Impact</h3>
<p>
Unprotected Windows networking shares can be exploited by intruders in
an automated way to place tools on large numbers of Windows-based
computers attached to the Internet. Because site security on the
Internet is interdependent, a compromised system not only creates
problems for the system's owner, but it is also threat to other sites
on the Internet. The greater immediate risk to the Internet community
is the potentially large number of systems attached to the Internet
with unprotected Windows networking shares combined with distributed
attack tools such as those described in
<p>
<dl>
<dd><a href="http://www.cert.org/incident_notes/IN-2000-01.html">
      IN-2000-01</a>, Windows Based DDOS Agents
</dd></dl>
Another threat includes malicious and destructive code, such as
viruses or worms, which leverage unprotected Windows networking
shares to propagate. One such example is the 911 worm described in
<p>
<dl>
<dd><a href="http://www.cert.org/incident_notes/IN-2000-03.html">
      IN-2000-03</a>, 911 worm
</dd></dl>
<p>
There is great potential for the emergence of other instances of
intruder tools that leverage unprotected Windows networking shares on
a widespread basis.  
<p>
<h3>Solutions</h3>
<p>
Removing the network.vbs script from an infected computer involves
removing the running image from memory and deleting the copies of
network.vbs from the hard drive. Other tools installed using the same
method of propagation may be more difficult to detect and remove.
<p>
You may wish to insure your anti-virus software is configured to test
file names ending in .VBS to help detect virus outbreaks involving
malicious VBScript code.
<p>
Several steps can be taken to prevent exploitation of the larger
problem of unprotected Windows networking shares:
<p>
<ul>
<li>Disable Windows networking shares in the Windows network control
  panel if the ability to share files is not needed. Or, you may
  choose to entirely disable NETBIOS over TCP/IP in the network
  control panel.

  <li>When configuring a Windows share, require a password to connect
  to the share. The use of sound password practices is encouraged.
  It is also important to consider trust relationships between systems.
  Malicious code may be able to leverage situations where a vulnerable
  system is trusted by and already authenticated to a remote system.

  <li>Restrict exported directories and files to the minimum required
  for an application. In other words, rather than exporting an entire
  disk, export only the directory or file needed. Export read-only
  where possible.

  <li>If your security policy is such that Windows networking is not
  used between systems on your network and systems outside of your
  network, packet filtering can be used at network borders to prevent
  NETBIOS packets from entering and/or leaving a
  network. Alternatively, use packet filtering to allow NETBIOS
  packets only between those sites with whom you want to do file
  sharing. The following ports are commonly associated with Windows
  networking:
  <p>
<pre>
        netbios-ns      137/tcp      # NETBIOS Name Service
        netbios-ns      137/udp 
        netbios-dgm     138/tcp      # NETBIOS Datagram Service
        netbios-dgm     138/udp
        netbios-ssn     139/tcp      # NETBIOS session service
        netbios-ssn     139/udp
  </pre>
<p>
  Keep in mind that packet filtering alone may not provide complete
  protection. Malicious code can enter a network through portable 
  code downloaded from web sites or through email containing portable 
  code or executable file attachments. For more information about
  Trojan horses and suggested strategies, please see
  <p>
<dl>
<dd><a href="http://www.cert.org/advisories/CA-99-02-Trojan-Horses.html">
         CA-99-02</a>, Trojan Horses
  </dd></dl>
<p>
  In the case of a tool like network.vbs, packet filtering may be most
  effective against preventing the exit of malicious packets from your
  network, thus preventing malicious code like network.vbs from
  spreading from your site to others.
</p></p></p></p></li></li></li></li></ul>
<p>
<h3>Acknowledgments</h3> 
We thank Abe Singer and the San Diego Supercomputer Center for
contributions to this Incident Note.
<p>
<b>Author</b>: Kevin Houle<br/>
<p><!--#include virtual="/include/footer_nocopyright.html" --> </p>
<p>Copyright 2000 Carnegie Mellon University.</p>
</p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p>