Onderwerp: Re: [LSD] Critical security vulnerability in Microsoft Operating

Last Stage of Delirium <contact@lsd-pl.net> writes:

> Hello,
>
> We have discovered a critical security vulnerability in all recent versions of
> Microsoft operating systems. The vulnerability affects default installations
> of Windows NT 4.0, Windows 2000, Windows XP as well as Windows 2003 Server.
>
> This is a buffer overflow vulnerability that exists in an integral component of
> any Windows operating system, the RPC interface implementing Distributed Component
> Object Model services (DCOM). In a result of implementation error in a function
> responsible for instantiation of DCOM objects, remote attackers can obtain
> unauthorized access to vulnerable systems.
> [...]

I think it's worth mentioning that Microsoft's advisory on this issue
is incorrect in stating that the only attack vector is port 135. The
vulnerability lies in one of the RPC interfaces that the endpoint
mapper/RPCSS services. As such, it is accessible over any RPC
protocol sequence that the endpoint mapper listens on. That includes:

o ncacn_ip_tcp : TCP port 135
o ncadg_ip_udp : UDP port 135
o ncacn_np : \pipe\epmapper, normally accessible via SMB null
session on TCP ports 139 and 445
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.

So if you want to be completely safe, block UDP 135, TCP 135, 139, 445,
and 593. And make sure you don't have COM Internet Services running.

--
Todd Sabin <tsabin@optonline.net>
BindView RAZOR Team <tsabin@razor.bindview.com>

"Russ" <Russ.Cooper@rc.on.ca> 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:
<URL:http://www.microsoft.com/office/ork/...tC07.htm#sub_1>
? 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.
See <URL:http://msdn.microsoft.com/library/de...m/html/cis.asp>
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:
<URL:http://razor.bindview.com/tools/desc....0-readme.html>
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@optonline.net>
BindView RAZOR Team <tsabin@razor.bindview.com>

Hello,

We confirm the existance of the following RPC attack vectors pointed out
by Todd Sabin with regard to the vulnerability described in MS03-026.
These are respectively:

- ncacn_np:\pipe\epmapper
- ncadg_ip_udp:135
- ncacn_ip_tcp:135
- ncacn_http:593

This means that at least:
- UDP port 135,
- TCP ports 135, 139, 445 and 593 can be used as remote attack vectors.

The possibility of using ncacn_http (and TCP port 80) for the purpose
of launching a remote attack depends on whether COM Internet Services
are enabled for DCOM on a Windows Server running IIS (as far as we know
they are not enabled by default).

Best Regards,
Members of LSD Research Group
http://lsd-pl.net


On Thu, 17 Jul 2003, Todd Sabin wrote:

>
> I think it's worth mentioning that Microsoft's advisory on this issue
> is incorrect in stating that the only attack vector is port 135. The
> vulnerability lies in one of the RPC interfaces that the endpoint
> mapper/RPCSS services. As such, it is accessible over any RPC
> protocol sequence that the endpoint mapper listens on. That includes:
>
> o ncacn_ip_tcp : TCP port 135
> o ncadg_ip_udp : UDP port 135
> o ncacn_np : \pipe\epmapper, normally accessible via SMB null
> session on TCP ports 139 and 445
> 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.
>
> So if you want to be completely safe, block UDP 135, TCP 135, 139, 445,
> and 593. And make sure you don't have COM Internet Services running.
>
> --
> Todd Sabin <tsabin@optonline.net>
> BindView RAZOR Team <tsabin@razor.bindview.com>
>