[Dshield] New critical Windows vulnerabilities

Rick Klinge rick at jaray.net
Thu Oct 16 00:54:03 GMT 2003

But if the service is disabled, ie: 'not listening' isn't it moot?


-----Original Message-----
From: list-bounces at dshield.org [mailto:list-bounces at dshield.org]On
Behalf Of John Hardin
Sent: Wednesday, October 15, 2003 6:59 PM
To: General DShield Discussion List
Subject: Re: [Dshield] New critical Windows vulnerabilities

On Wed, 2003-10-15 at 14:44, Bjorn Stromberg wrote:
> If I recall correctly... it was possible to get messenger traffic through
> even if you blocked 135 - 139 because the data portion of the traffic was
> accepted some ports directly above 1024 (1025-1027 if memory serves).
> I'm not sure if this vulnerability is valid on ports other than 137-139 I
> would assume any communication with Windows Messenger is vulnerable.

Broadly (apologies in advance to pedants):

RPC (13x) is a service-locating service. A network service such as
messenger listens on a high (>1024) port randomly assigned by the OS,
and then tells the RPC service which port it got assigned. Clients
wishing to talk to that service send a request to RPC to get the port
number, then contact that port number to do useful work.

For example:

net send client -> RPC server 13x "where is messenger listening?"
RPC server 13x -> net send client "messenger is listening at 1026"
net send client -> messenger 1026 "MAKE MONEY FAST!!!"

The port the messenger service gets assigned is based on when it starts
relative to when the computer boots. The consistent use of 1026
indicates messenger is one of the first network services to be started
by the OS. If you restart the messenger service it should be assigned a
different port to listen on. You can play around with "netstat -na -p
udp" to see what's going on.

The spammer net send client can be "ill behaved" and skip the first two
steps of the above process and *assume* messenger is listening at 1026
to break the dependency on the 13x RPC server and the possibility of
being blocked.

Thus: the messenger BO is not dependent on RPC (13x). I could see a
messenger worm scanning 1025-1050 looking for vulnerable messengers. If
it's a one-packet UDP exploit, maybe even simply spew it at the range
1025-32767 as fast as possible (god forbid!)

Virus Scanned and Filtered by http://www.FamHost.com E-Mail System.

More information about the list mailing list