Machines using the NetBIOS protocol over a TCP/IP network use UDP packets sent from and to UDP port 137 for name resolution and management. NetBIOS names consist of 15 uppercase characters followed by a one-byte value (the service value). Many service values are used as NetBIOS networks to identify well-known services and other applications, but any application can register and use any name and value if that name isn't a unique name and already in use on the network. The NetBIOS service broadcasts a NAME REGISTRATION REQUEST to determine if a name is in use before it attempts to use it. If the name is already in use, the machine owning that name will DENY the name registration request, and the registration attempt will fail. Each NetBIOS node (machine or interface) on the network maintains a list of names that it owns and that node is responsible for defending any unique names that it owns by denying other nodes' name registration requests. If a NetBIOS node detects a name conflict it will mark the name in its local table as being in conflict. RFC 1001 has this to say about names in conflict:
Logically, a marked name does not exist on that node. This means
that the node should not defend the name (for name claim purposes),
should not respond to a name discovery requests for that name, nor
should the node send name refresh messages for that name.
Furthermore, it can no longer be used by that node for any session
establishment or sending or receiving datagrams. Existing sessions
are not affected at the time a name is marked as being in conflict.
The only valid user function against a marked name is DELETE NAME.
Any other user NetBIOS function returns immediately with an error
code of "NAME CONFLICT".
Machines which do not react as the NetBIOS protocol dictates can disable NetBIOS networks by causing the names in other NetBIOS name tables to become in conflict. By denying all name registration requests, NetBIOS nodes will always think that their names are already in use on the network. Windows machines display the message that the chosen machine name is already in use and direct the user to change the name and reboot. By sending a NetBIOS node NAME RELEASE REQUESTS for each name in its table, a machine will stop responding to name requests, not be able to create or receive any new NetBIOS connections or datagrams and become isolated from the NetBIOS network.
Because the protocol is entirely unauthenticated, any machine can respond to broadcast queries for any name it sees queries for, possibly even beating legitimate name holders to the response. The address of the responding node will be returned and whatever type of connection was attempting to be made will attempt to connect to that address instead. In fact, in ANY place in windows that is expecting a host name, even an internet address like www.crap.edu, if the system is unable to resolve the address via DNS it will attempt to resolve it via a broadcast NetBIOS name packet if it is 15 characters or less. So if someone on the network tried to connect to www.crap,edu (a common unnoticed typo, a comma instead of a period) after the DNS request failed it will broadcast a name query for WWW.CRAP,EDU. If fake services were set up, such as telnet, ftp or whatever, most users wouldn't notice the mistake until it were too late.
Block UDP 137 on your firewall or router. If NetBIOS networking is not required, for God's sake uninstall it!
Microsoft recommends using IPSec for UDP 137.
I first sent a copy of NBName.cpp along with an extensive description of the problems to secure@microsoft.com on June 20th. I have since learned that they were notified about similar and same issues some time in March. They were very responsive throughout the entire exchange, although their response throughout has basically been "Thanks for the info, we're just about to release a patch".
On July 28th Microsoft released this bulletin which provides a patch for Windows 2000. As of September 1st, the Windows NT 4.0 patch info still reads:
Windows NT 4.0 Workstation, Server, and Server, Enterprise Edition: Patch to be released shortly. Windows NT 4.0 Server, Terminal Server Edition: Patch to be released shortly.
Apparently Microsoft is having trouble "packaging" their NT 4.0 patch. Interestingly, nowhere in the bulletin does it mention Windows 9x, even though it is just as affected as any other platform using the NetBIOS protocol over TCP/IP. I asked them why this was and their response was basically that anyone concerned with "security" wouldn't be running Windows 9x anyawy. I would LOVE to not have to run Windows 95 anymore, but I have several thousand dollars worth of hardware and software (MP3 player that uses a propriatery parallel interface, video capture cards that only have 9x drivers due to promised then abandoned DirectX support for NT 4, Lego Mindstorm, tons of games etc!) that ONLY work under 9x! Is this is a sign that Microsoft is preparing to abandon these platforms? They sure do like Win2000...
On August Second, there was this report:
Private Sector - (U) (CERT/CC, 2 August) The CERT/CC has issued Special Communication SC-2000.65 - NetBIOS, NBName, and the Cult of the Dead Cow (cDc). As reported in yesterday’s NIPC Daily Report, a new tool exploiting several NetBIOS vulnerabilities has been released by a member of the cDc. Source and binary has been posted to the Web site www.securityfocus.com. Microsoft had previously released MS00-047 to help mitigate against the effects of being attacked via these vulnerabilities and suffering denial of NetBIOS services. The CERT/CC has not received any reports of the tool being used at present to attack sites, but given the nature of the exposure surrounding past cDc tool releases, CERT/CC is preparing to publish some document to give people more information about the nature and scope of future activity involving NBName and exploitation of these vulnerabilities.
On August 10th, CERT published this Vulnerability Note which outlines the problem and basically reccomends to block the appropriate ports, and install the patches that Microsoft has yet to provide, although it does note:
Check the source for current version and changes.
NBName decodes and displays all NetBIOS name packets it receives on UDP port 137. Using the /DENY * command line option it will respond negatively to all NetBIOS name registration packets it receives. Using the /CONFLICT command line option it will send a name release request for each name that is not already in conflict to machines it receives an adapter status response from. The /QUERY * command line option causes a wildcard name query request to be broadcast at startup and each machine that responds to the name query is sent an adapter status request. The /ASTAT command line option causes an adapter status request to be sent to the specified IP address, which doesn't have to be on your local network. Using /QUERY * /CONFLICT /DENY * will disable your entire local NetBIOS network and prevent machines from rejoining it.
NBName is much more than just a NetBIOS DoS tool:
Usage: NBName [/CONFLICT] [/REVERSE] [/NOLOCAL|/NOLOCALNET] [/ASTATBACK]
[/ASTAT TargetIP] [/SWEEP StartIP EndIP] [/SCAN IPList] [/SVCDESC]
[/TO ms] [/DELAY ms] [/PORT Port] [/RETRY Trys] [/QUERY Name IP]
[/LOCALIP LocalIP] [/NETMASK Netmask] [/EXAMPLES] [/ASOUT Outfile]
[/ALLOW|/DENY NameOrFile] [/RESPOND NameOrFile] [/RESPONDIP RespIP]
[/OUTSVC SvcNum OutFile] [/SPAWN SvcNum CmdExe "Args"] [/NOUNIX]
[/DESTPORT Port] [/PROXYIP ProxyIP] [/PROXYPORT ProxyPort]
[/PROXYUSER Username] [/PROXYPASS Password] [/BCASTIP BcastIP]
/HELP Command displays extended help for commands. Do not include the /
/LOCALIP will bind to LocalIP instead of the default system IP
/NETMASK will use Netmask to determine local net addresses
/BCASTIP will use BcastIP as the destination for broadcast packets
/PORT will bind to Port instead of 137
/DESTPORT will send packets to Port instead of 137
/PROXYIP will use the SOCKS 5 proxy at address ProxyIP to route UDP packets
/PROXYPORT will connect to tcp port ProxyPort rather than 1080
/PROXYUSER and /PROXYPASS let you supply authentication info to the proxy
/QUERY will cause a name query for Name to be broadcast
/ASTAT will send an adapter status (astat) request to TargetIP
/ASTATBACK will send astat requests to nodes that respond to queries
/SWEEP will send adapter status requests to all IPs from StartIP to EndIP
/SCAN will send adapter status requests to first IP listed in on each
line of IPList
/DELAY will pause for ms milliseconds between each packet sent durring a
scan or sweep, default 100 ms (10 packets per second)
/REVERSE will send an astat request in response to astat requests
/ASOUT will output received adapter status responses' contents to Outfile
/OUTSVC will output machines that respond to an adapter status request
and have service SvcNum running to OutFile in the format of lmhosts
/SVCDESC will display a description of each known service in astat responses
/SPAWN will spawn CmdExe with the commandline: CmdExe Args SrvrIP SrvrName
when an astat response is received with service SvcNum running
/NOUNIX will prevent machines with no mac address from triggering spawns
/NOLOCAL will prevent packets from the local host from being processed
/NOLOCALNET will prevent packets from the local subnet from being processed
/TO causes NBName to exit if no packets are received for ms milliseconds
/RETRY changes the number of times failed packets are resent from 3 to Trys
/CONFLICT* will send name release packets for each name in the remote name
table of machines who respond to adapter status requests
/RESPOND* will respond to name queries for NameOrFile
/RESPONDIP will return RespIP for queries responded to if /RESPOND is
used with a name or wildcard. Defaults to LocalIP
/DENY* will cause the name(s) specified by NameOrFile to be denied if a
node tries to register it (them)
/ALLOW* will deny all names _except_ NameOrFile
NameOrFile can be a single name, the path to a file containing a list of
names or * for all names (/ALLOW * is not valid).. Names can include a
service value by adding a backslash followed by the hex service value
* These options may be damaging to network stability, use with caution!
Using /SWEEP or /SCAN you can spew packets to blocks or lists of IPs, those machines with NetBIOS name services running will respond with their adapter status (including the contents of their name table). Using /OUTSVC you can have discovered machines appended directly to an lmhosts file, and using /SPAWN as well, you can use a batch file to run a program which gathers information from found NetBIOS servers or audits them for open shares, dumb passwords etc (NAT)... Adapter status request packets are 96 bytes, so using the /DELAY option you can tune NBName to send packets as fast as the available bandwidth allows. If you send packets too fast some of them will simply get lost and not reach their destination. The default delay is 100 milliseconds or 10 packets per second, or 960 bytes per second. a 128kb DSL or cablemodem connection can probably safely handle delays as low as 10 ms, or 100 packets, or about 10k/s. At this speed you could scan an entire class C (65k IPs) in about 11 minutes, having a NetBIOS auditor or other program spawned in parallel each time a server is found.
Listening on the default port 137 and using /REVERSE, when someone queries your machine for NetBIOS adapter status it will display the request and respond instead with a request for the querying machine's status. It is important to realize that Windows machines will generate such a request AUTOMATICALLY if an application on that computer calls gethostbyaddress() and is unable to resolve an IP address's name via DNS, it will send an adapter status request directly to the address attempting to retrieve the NetBIOS name... So just because a machine requested your adapter status does not necessarily mean that they are trying to hack you or running nbtstat.exe... this fact however can be quite useful in detecting IDS systems on Windows machines by listening for NBNAME packets and probing a machine from an IP address that does not resolve to a name via DNS, if there is an IDS which is configured to immediately resolve the names of attacking addresses, you will see an adapter status request after the DNS lookup fails.
One of the most common problems with WANs is locating the NetBIOS machines that you can not send broadcast packets to (nodes on the far end of the WAN) if there is not a WINS server in use. Microsoft's sollution is to add the machines on the far end of the WAN to your lmhosts file which will be used to resolve a name to its address before a broadcast query is broadcast, but this is a pain for any large sized network, especially if IPs change at all. Using /OUTSVC in combination with /SCAN or /SWEEP you can quickly and easily create an lmhosts file.
NBName should compile on Win32 and Unix platforms, but will not be able to run on Win2k if NetBIOS is already bound to the IP interface being used. This is because Microsoft created a new socket flag which prevents other applications from re-binding in front of the socket. This flag was implemented in NT 4.0 SP4 but apparently not used except in Win2k.
While you can bind to any port using the /PORT command (except as noted above), old Win95 boxes (pre-OSR2) will always respond to UDP 137. This means that unless you use the default port you will not see the responses from those machines. However, this method can also be used to locate pre-osr2 win95 machines which may be vulnerable to a few known exploits.
Many Unix platforms seem to have issues receiving broadcast UDP packets. This may prevent the many options from working as NBName will not be able to receive the normal NetBIOS traffic, options like /ALLOW /DENY /RESPOND.. Obviously you must be listening on the default port (137) for these options to work.
On my NT box after binding in front of the system to UDP 137 I have repeatedly seen it bind without error but then never receive the packets destined for that port. It seems to fix itself most of the time. Using the /PORT option you can bind to other ports (which may also allow you to get UDP packets through a firewall by binding to a "trusted" port such as 53) and MOST Windows machines will respond to that port, but some old Win95 boxes will always respond to UDP 137 no matter the source port.
There may be some issues related to the end node types which may cause NBName to function improperly on networks that do not use B-nodes.
Using /REVERSE without /NOLOCAL(NET) may cause NBName to send packets to itself as fast as it can. That would be a bad thing.
Names, either supplied with the option or in the filename, can include a service value by appending a backslash (\) followed by the hex service value (such as SERVER\20). If no service value is supplied, 00 is used (workstation service). The most commonly used service values are 00 (workstation) and 20 (server).
Names with spaces in them can be specified on the command line by putting quotes around the name, such as NBName /QUERY "THE NAME" ...and may even include a service value like NBName /DENY "THE NAME\20"
Here is an example batch file which you might execute with the /SPAWN option. It uses NetE to extract information from found machines and writes a log to c:\logs\ for each NetBIOS server that can be connected to. A sample commandline for using this batch file might be:
NBName /NOLOCALNET /SWEEP 123.231.123.1 123.231.129.255 /DELAY 25 /TO 20000 /OUTSVC 20 %windir%\system32\drivers\etc\lmhosts /SPAWN 20 donete.bat TestSweep1
The above commandline would sweep 7 class C networks sending 40 packets per second, exiting automatically after 20 seconds of not having received any responses, appending machines with the server service running to the system lmhosts file, spawning donete.bat for each server found which will create a file for each machine that could be connected to with names in this format:
TestSweep1-123.231.123.99-HOST1 TestSweep1-123.231.126.123-HOST2 ... etc