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

[Mikael Olsson <mikael.olsson () ENTERNET SE>]

Matt Conover wrote:
> > 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.
> [huge snip]

I wasn't discussing the particulars of the SCM exploit. I'm
talking about ImpersonateNamedPipeClient() in general.

I thought that was obvious since I've been pondering about
this for a long time before the advisory got out.
Sorry for not making that more clear.

Just to be certain that we understand eachother:

The variation I'm talking about is getting a named pipe client
to connect to another server than the intended one, where the
serving pipe does nothing but impersonate the caller and
then use that identity for something else.
This is a game of network name resolution, not "guess the
pipe name"; the pipe name is most likely fixed (SQL server
connection, Exchange connection, some share, whatever)

> The client is in no way vulnerable.  First, the client can set its
> impersonation level to anonymous so that it CAN'T be
> impersonated.

Yes, I am aware of this option. ... But how many applications do this
before they connect somewhere using a named pipe? (Not the ones ones
that _rely_ on impersonation at the server end, for sure).

> Second, it's only a problem is when they are both
> on the same system and the client you are impersonating has higher
> privileges.

Are you asserting that a remote server cannot impersonate a remote
client? This goes fly in the face with how I've understood the
API docs. (?)

> 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.

I was thinking like this:

- User "joe" connects from machine A to \\hisserver\somepipe
- The \\hisserver name has been hijacked; joe will connect to some
  other machine instead.
- A low-priviledged process running on that machine (granting anyone
  access to the pipe) impersonates "joe", and uses this to have some fun.

I'm not entirely certain if this impersonation can be used to mount
other network resources, but even if it doesn't, I'm fairly certain that
the impersonation could be used to have fun in other ways.

Silly example: (can't think of a good one right now)'
- You manage to get access to a combined web/DNS server through the
  web server, but as a user with no privileges except read access to
  a bunch of static HTLM files. Useless.
- Crash the DNS server somehow (for the sake of argument, assume this
  is successful)
- Install a named pipe where the DNS admin interface used to sit
  (until it crashed)
- Wait until Administrator connects to modify DNS data
- Voila! You're administrator on the machine and can now do a lot
  more funky stuff than you could as the low-priv user. Install
  new network drivers for instance, and start sniffing network
  traffic flying by. :)

Okay, lame. Makes some assumptions (being able to crash the DNS
for instance, don't know how hard that is) and would probably take a
lot of time waiting for the administrator to connect. Relax, it's just an
example.

I still think this is worth looking into further (is network access
using the new identity possible?) and maybe find scenarios where local
impersonation would lead to more serious danger without having to
wait for ever.

/Mike

--
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK
Phone: +46 (0)660 29 92 00         Direct: +46 (0)660 29 92 05
Mobile: +46 (0)70 66 77 636        Fax: +46 (0)660 122 50
WWW: http://www.enternet.se/       E-mail: mikael.olsson () enternet se