Re: ImpersonateNamedPipeClient -- "How Named Pipe Security Works"

[Matt Conover <shok () CAMEL ETHEREAL NET>]

> I've had a note in my cell phone for the better part of july
> reminding me to investigate the exact circumstances of the
> ImpersonateNamedPipeClient() API call, but I haven't gotten
> around to it, and will likely not in the near future.

Actually, that isn't the issue.  The issue is that a user can
create the server side pipe before the legitimate server (in this
case, services.exe) can.  The problem was that there was no way
with CreateNamedPipe to determine whether or not the pipe already
existed (until this recent fix--though it's still technically an
undocumented flag).  Previously (or with the usual CreateNamedPipe flags),
CreateNamedPipe succeeds even if you are attempting to create it and it
already existed.  Now, there is an undocumented (at least for the
moment) way to determine it (Blake Watts found the undocumented flag in
the fix).

The reason it isn't a remote vulnerability is that you can't create a pipe
on another machine (without locally executing code)--you can only connect
as a client to a pipe on another machine.  In which case, your credentials
would be used on that machine to determine access privileges.

>   The "Server End" of a named pipe doesn't necessarily imply that
>   it's sitting at a server. Instead, consider this:
>   The network administrator is about to reboot a server. He does
>   "net send * The server is rebooting in five minutes!" from the
>   server as the domain administrator and acts as a client, connecting
>   to every server (connected computer) in the network. (I could be wrong
>   here, this may not be named pipes,  but to my recollection, they are.)

You're right... all that defines the server end is the only that creates
the pipe (CreateNamedPipe("\\.\pipe\pipename", ...)), and the client is
the one that connects to it (using
CreateNamedPipe("\\server-name\pipe\pipename", ...).

>   It isn't altogether impossible to impersonate servers by fooling
>   around with NetBIOS name resolution, faking registrations to
>   WINS servers, etc. As soon as you get someone to connect to your
>   named pipe, you can impersonate that client.

However, there is no gain for doing this.  I, myself, was confused on this
for a while until Blake Watts and I had a talk on the whole named pipe
scheme (Blake being the NT guy--as most of you know, my background
predominantly Unix).

The server impersonates the client's credentials on its own machine.  If
you administrator a box, you are able to change the IP of a server to
point to yours, when the client connects, you'd be using its credentials
to determine access privileges on *your own machine*.  The reason
Guardent's named pipe issue worked, is because you, as a low privileged
user capable of starting various services, are able to beat the SCM
(Service Control Manager--services.exe) to creating the pipe.  At this
point, it's all over.  It's simply a matter of waiting for a client to
connect.  The clients connecting are services, which are going to be
running with local system (a high-privileged user account) to
connect.   Then, you are using the higher privilege's credentials on your
machine, which is also its machine (it's a local exploit), which is how
you make the jump from low privilege to high privilege (group
"Everyone" to "LocalSystem").  This is a hard thing to fix, because it
requires fixing all the programs which blindly attempt to create pipes.


> Well, that's about it. Do with this what you want (install packet
> filters everywhere that block ports 135-139?).

The client is in no way vulnerable.  First, the client can set its
impersonation level to anonymous so that it CAN'T be
impersonated.  Second, it's only a problem is when they are both
on the same system and the client you are impersonating has higher
privileges.  I don't believe there is any risk with using named pipe for
either client or server.  The only potential I can see is if the client
and server machines have common accounts, so that a low-privileged user on
the server-side could impersonate the credentials of the administrator on
the client machine.  That *might* give a low-privileged user on
the *server* elevated privileges on their *local* system, but I doubt even
this, because I would assume (not positive, though) the credentials are
based on GUID (globally unique id), or something that would distinguish
the administrator account between machine A and B.  If that's the case,
then impersonating administrator of machine A in the context of machine B,
wouldn't give any elevated privileges.  I'll verify this via friends later
on today, and if I'm right, I won't reply.  If I'm wrong, it would mean
potentially elevated privileges on the server-side based on client
credential, which is why I'm trying to put some confidence in Microsoft
and assume that they thought about this issue when developing named pipes
and addressed it.

Shok (Matt Conover)
shok () dataforce net, mconover () guardent com

NOTE: I didn't find the bug (just want to make sure I'm not falsely
accredited with that)