NetBIOS Auditing Tool

[oliver () SECNET COM (Oliver Friedrichs)]

NetBIOS Auditing Tool Release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As of February 16th Secure Networks Inc. has released a free (GPL'd)
NetBIOS auditing tool for use both on WindowsNT and UNIX platforms.
The tool itself is designed to test NetBIOS file-sharing configurations as
well as Password integrity of remote stations.

The toolset is available via the following channels:

ftp://ftp.secnet.com/pub/tools/nat10/nat10bin.zip (For NT and Win 95 binaries)
ftp://ftp.secnet.com/pub/tools/nat10/nat10.tgz (For full source)

http://www.secnet.com/ntinfo/ntaudit.html

A technical description of how the NetBIOS auditing tool works follows.


The NetBIOS Auditing Tool (NAT) is designed to explore the NETBIOS file-sharing
services offered by the target system.  It implements a stepwise approach to
gather information and attempt to obtain file system-level access as though
it were a legitimate local client.

The major steps are as follows:

A UDP status query is sent to the target, which usually elicits a reply
containing the Netbios "computer name".  This is needed to establish a session.
The reply also can contain other information such as the workgroup and account
names of the machine's users.  This part of the program needs root privilege to
listen for replies on UDP port 137, since the reply is usually sent back to UDP
port 137 even if the original query came from some different port.

TCP connections are made to the target's Netbios port [139], and session
requests using the derived computer name are sent across.  Various guesses at
the computer name are also used, in case the status query failed or returned
incomplete information.  If all such attempts to establish a session fail,
the host is assumed invulnerable to NETBIOS attacks even if TCP port 139 was
reachable.

Provided a connection is established Netbios "protocol levels" are now
negotiated across the new connection.  This establishes various modes and
capabilities the client and server can use with each other, such as password
encryption and if the server uses user-level or share-level Security.  The
usable protocol level is deliberately limited to LANMAN version 2 in this
case, since that protocol is somewhat simpler and uses a smaller password
keyspace than NT.

If the server requires further session setup to establish credentials, various
defaults are attempted.  Completely blank usernames and passwords are often
allowed to set up "guest" connections to a server; if this fails then guesses
are tried using fairly standard account names such as ADMINISTRATOR, and some
of the names returned from the status query.  Extensive username/password
checking is NOT done at this point, since the aim is just to get the session
established, but it should be noted that if this phase is reached at all MANY
more guesses can be attempted and likely without the owner of the target
being immediately aware of it.

Once the session is fully set up, transactions are performed to collect more
information about the server including any file system "shares" it offers.

Attempts are then made to connect to all listed file system shares and some
potentially unlisted ones.  If the server requires passwords for the shares,
defaults are attempted as described above for session setup.  Any successful
connections are then explored for writeability and some well-known file-naming
problems [the ".." class of bugs].

If a NETBIOS session can be established at all via TCP port 139, the target is
declared "vulnerable" with the remaining question being to what extent.
Information is collected under the appropriate vulnerability at most of
these steps, since any point along the way be blocked by the Security
configurations of the target.  Most Microsoft-OS based servers and Unix SAMBA
will yield computer names and share lists, but not allow actual file-sharing
connections without a valid username and/or password.  A remote connection to
a share is therefore a possibly serious Security problem, and a connection
that allows WRITING to the share almost certainly so. Printer and other
"device" services offered by the server are currently ignored.

For more information about NAT see:
http://www.secnet.com/ntinfo/ntaudit.html

- Oliver Friedrichs

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Secure Networks Incorporated.  Calgary, Alberta, Canada, (403) 262-9211