Back to list
RE: [LSD] Critical security vulnerability in Microsoft Operating Systems
Jul 18 2003 10:35PM
Russ (Russ Cooper rc on ca)
Re: [LSD] Critical security vulnerability in Microsoft Operating Systems
Jul 19 2003 01:16AM
Todd Sabin (tsabin razor bindview com)
"Russ" <Russ.Cooper (at) rc.on (dot) ca [email concealed]> writes:
> o ncacn_http : if active, listening on TCP port 593.
> Finally, if ncacn_http is active, and COM Internet Services is
> installed and enabled, which is NOT the default in any configuration
> I'm aware of, then you can also talk to the endpoint mapper over port
> 80. Just to be clear, I think this is a very uncommon scenario, but
> the possibility does exist.
> Microsoft list RPC over HTTP as a mitigator. I checked with them and
> they've confirmed that it isn't vulnerable. Therefore fear of
> attacks via TCP 80, or against COM+, are IMO unfounded.
Responding to your points in order:
I don't know what exactly Microsoft mean by "RPC over HTTP". Given
their penchant for rebranding and renaming things, it's entirely
possible that it's completely different from ncacn_http and COM
Internet Services. Maybe they mean SOAP? Many people would call that
RPC over HTTP. Maybe they're talking about this:
? I don't know, but maybe they'll tell us if we ask them? Microsoft?
If they do mean to say that this can't be exploited via port 80 on a
machine that has COM Internet Services running on it, they're wrong.
As I type this email, I have a Windows 2000 SP3 VMware image, on which
I've previously installed and enabled COM Internet Services, with
RPCSS stopped in a debugger because of an access violation that I've
caused over port 80.
I'm not talking about COM+, I'm talking about COM Internet Services.
for an overview. The whole point of COM Internet Services is, as
the article says, to allow DCOM traffic to go over port 80 and bypass
firewalls and proxy servers. It works by having IIS act as a
proxy between the RPC client and RPC server, just shoveling packets
between port 80 and whatever port the RPC server is on.
Again, as I said originally, I don't think people should be overly
concerned about the COM Internet Services and port 80 scenario,
either. As far as I know, it's not widely deployed at all. But if
someone happens to know, "Hey, we use COM Internet Services.", they
need to get this patch applied ASAP. If you're paranoid and want to
check to be sure, it's pretty easy. Telnet to port 80 and enter
"RPC_CONNECT <ip address>:593 HTTP/1.0". If you get a "200 OK"
response, it's running. If not, it's not. Alternatively, you
can try running "ifids -p ncacn_http -e 593 <target>", with
the ifids from here:
If you get a list of interfaces, then it's running; otherwise, not.
> Further, what's the likelihood that a machine will have TCP139 or
> 445 open and not have TCP135 open too? While its certainly realistic
The point of mentioning 139 and 445 (and the others) is so people can
make an informed decision about this vulnerability with all the
relevant information. If, for whatever reason, they've decided they
could live with the risk of leaving them open in the past, they need
to be aware that this vulnerability is accessible over them, too. If
you're going to omit ports because people have been told to block them
in the past, then why even mention 135? People have been told to
block that for almost as long.
> to state attacks could come via named pipes, I personally think its
> unlikely. Given all of the activity we have on those ports already,
> none of it using named pipes, I'd think we'd have seen something
> else use them before now.
I have no idea what you're trying to say here. You do realize that
all of the null session enumeration stuff, sid2user, user2sid, RID
walking, etc. that people do over 139 and 445 uses named pipes, right?
RPC over named pipes? Normal SMB file sharing doesn't use named
pipes, but almost all of the "interesting" things people do over 139
and 445 do, and always have, all the way back to redbutton.
Todd Sabin <tsabin (at) optonline (dot) net [email concealed]>
BindView RAZOR Team <tsabin (at) razor.bindview (dot) com [email concealed]>
[ reply ]
Copyright 2010, SecurityFocus