COMMAND
NetBIOS
SYSTEMS AFFECTED
Win9x, NT and 2000
PROBLEM
Following is based on COVERT Labs Security Advisory
(COVERT-2000-10). The Microsoft Windows implementation of the
NetBIOS cache allows a remote attacker to insert and flush
dynamic cache entries as well as overwrite static entries through
unsolicited unicast or broadcast UDP datagrams. As a result,
remote attackers either on the local subnet or across the Internet
may subvert the NetBIOS Name to IP address resolution process by
redirecting any NetBIOS Name to any arbitrary IP address under the
control of the attacker.
The NetBIOS Name resolution process resolves NetBIOS Names into IP
addresses for many operations, including session establishment.
RFC 1001 (15.1.8) suggests that "an end-node may maintain a local
cache of NetBIOS name to IP address translation entries". This
NetBIOS cache is examined before queries are passed to support
services. The current contents can be examined via "nbtstat -c".
The CIFS family of protocols includes a browsing protocol that
allows for the dynamic discovery of servers running particular
services. The CIFS Browsing protocol supplies a dynamically
generated Browse List of network resources. The Network
Neighborhood in Windows NT 4 and My Network Places in Windows
2000 provide a basic interface to some of the information provided
in a Browse List.
Interactions between Microsoft's implementation of NetBIOS and the
CIFS Browsing Protocols have created vulnerabilities allowing a
remote attacker either on a local subnet or across the internet to
subvert the NetBIOS Name resolution process.
The Microsoft designed CIFS Browser Protocol defines a number of
Browse Frames encapsulated within a NetBIOS datagram which is
defined in RFC 1002 (4.4). The NetBIOS datagram header contains a
source and destination NetBIOS name, as well as a second source IP
address, in addition to the IP headers.
When a Browse Frame Request is received on UDP port 138,
Microsoft's implementation extracts information from the NetBIOS
datagram header and stores the information in the NetBIOS cache.
The source NetBIOS Name and source IP address from the NetBIOS
datagram header are blindly extracted from the UDP datagram and
inserted into the NetBIOS cache.
As an interesting side note, when a Browse Frame Response is
generated the NetBIOS cache is examined to resolve the source
NetBIOS name of the previous request and delivered to that IP
address. Because the NetBIOS cache entry for the source NetBIOS
name is under control of the attacker, the response can be
delivered to an arbitrary host.
It is important to note that dynamic NetBIOS cache entries can be
inserted in addition to overwriting static entries imported from
the LMHOSTS file. Furthermore, the NetBIOS cache is corrupted
with an unsolicited UDP datagram, removing the requirement for
attackers to predict Transaction IDs. With the NetBIOS cache
under the control of a remote attacker many opportunities are
available, one of the most obvious is to subvert outbound SMB
connections to an arbitrary address. A rogue SMB server would
then be able to capture NT username and password hashes as
presented.
In addition to inserting entries into the NetBIOS cache it is also
possible to flush dynamic entries. RFC 1001 (15.1.8) states that
"a node ought to flush any cache information associated with an IP
address if the node receives any information indicating that there
may be any possibility of trouble with the node at that IP
address". One possible way to flush dynamic NetBIOS cache
entries is to deliver an unsolicited Positive Name Query response
that provides a different IP address to NetBIOS name mapping to
the entry in the NetBIOS cache.
In a manner similar to DNS, the NetBIOS name resolution process
utilizes a 16-bit Transaction ID to associate requests and
responses. The Microsoft implementation of NetBIOS contains an
easily predictable Transaction ID, although the previously
discussed vulnerability is a much more effective method of
inserting entries into the NetBIOS cache.
The discovery and documentation of this vulnerability was
conducted by Anthony Osborne at the COVERT Labs of PGP Security.
SOLUTION
COVERT Labs have worked with Microsoft in accordance with
Microsoft's Security Policies in an attempt to provide customers
with a patch to eliminate this vulnerability. Despite their best
efforts and extensive discussions, Microsoft believes that this
issue is a result of the unauthenticated nature of the NetBIOS
protocol and will not be providing a security patch.
To work around the NetBIOS cache corruption security vulnerability
there are a number of potential solutions. The most effective is
to upgrade to Windows 2000 and "Disable NetBIOS over TCP/IP".
Obviously, this is an impractical solution for many organizations.
Some other potential solutions include:
o Block ports 135-139 and 445, both UDP and TCP, at your
network perimeter to protect from external attackers.
o Because NetBIOS name resolution (either through broadcast or
WINS) is subject to this cache corruption attack, it should
not be relied upon to perform hostname to IP address
resolution.
o Disable the "WINS Client" binding including the NetBIOS
Interface, Server and Workstation services. It is important
to disable all services that register a NetBIOS name as
shown by nbtstat -n. Selectively unbinding the "NetBIOS
interface" or other specific services such as Server or
Workstation will still allow attackers to talk to a NetBIOS
name and corrupt the NetBIOS cache.
o It is important to note the Computer Browser Service is
independent of Browse Frame processing and generation (at
least within the bounds of this vulnerability). Disabling
the service has no impact upon this vulnerability.
Russ Cooper added following:
- Block UDP138 on internal networks. If WINS is being used its
unnecessary. This, coupled with the fact that broadcasts
across subnets should normally be blocked also and you've
ensured that poisoning can only happen on the same segment
(thereby minimizing the number of suspects should it ever
happen).
- SMB signing would prevent clients from attempting to
authenticate against rogue servers implanted in caches. The
poisoning then becomes a DoS.
- A better solution, and really the only secure solution for
anyone wishing to continue to use NetBIOS/SMB, is to use
IPSEC. IPSEC would obviously prevent this, and lots of
other vulnerabilities in NetBIOS.