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

[Marc <marc () EEYE COM>]

| -----Original Message-----
| From: VULN-DEV List [mailto:VULN-DEV () SECURITYFOCUS COM]On Behalf Of Matt
| Conover
| Sent: Thursday, August 03, 2000 5:56 AM
| To: VULN-DEV () SECURITYFOCUS COM
| Subject: Re: ImpersonateNamedPipeClient -- "How Named Pipe Security
| Works"
|
| > Mikael Olsson 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.
<snip>
| >   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).

No gain? I think you might be miss understanding Mikael Olsson's theory. The
theory being that if you can find a way to make a remote host connect to a
named pipe on your system then you have a _really_ good chance of taking
control of that remote machine.

The remote process making the connection to your machine's named pipe
doesn't need to be a service running as SYSTEM (although that would be nice)
but any user really.

For example I wrote some code so when a remote computer connects to a
certain named pipe on my system that it spawns a cmd.exe (basically like how
most windows buffer overflow shellcode works) with the access rights of that
remote user. So I find some idiot working at a company, send them the
trojan, and then have a dos prompt to that remote users machine which I can
then use to locally exploit their NT server to then become SYSTEM.

Now if someone could find a way that would allow an attacker to force a
remote machine to connect to a named pipe on the attackers machine, then
that would be a very fun(read:bad) hack.

One of the ways of doing this would be via NetBIOS name hi-jacking, as
Mikael Olsson already pointed out.

<snip>

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

There are security risks with named pipes beyond local named pipes. Clients
can be vulnerable.

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

Microsoft has thought about a lot of things but one of the biggest problems
with the whole NetBIOS, Named Pipes, bla bla bla wad of crap is that
Microsoft only "co-programmed" a lot of it and when shit hit the fan they
rewrote parts of it instead of a complete rewrite. So it is now basically a
half assed insecure mechanism that is the backbone for almost all major
forms of Windows Networking communications.

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

If you really want to see some "shit hit the fan" go mangle some mailslot
broadcasts. :-]

Signed,
Marc Maiffret
Chief Hacking Officer
eCompany / eEye
T.949.675.8160
F.949.675.8191
http://eEye.com