Vulnerability Development mailing list archives
Re: ImpersonateNamedPipeClient -- "How Named Pipe Security Works"
From: Marc <marc () EEYE COM>
Date: Thu, 3 Aug 2000 12:32:02 -0700
| -----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
Current thread:
- ImpersonateNamedPipeClient() vulnerabilities Mikael Olsson (Aug 02)
- Re: ImpersonateNamedPipeClient -- "How Named Pipe Security Works" Matt Conover (Aug 03)
- Re: ImpersonateNamedPipeClient -- "How Named Pipe Security Works" Mikael Olsson (Aug 03)
- Re: ImpersonateNamedPipeClient -- "How Named Pipe Security Works" Matt Conover (Aug 03)
- Re: "How Named Pipe Security Works" (update) Matt Conover (Aug 03)
- Re: ImpersonateNamedPipeClient -- "How Named Pipe Security Works" Marc (Aug 03)
- Re: ImpersonateNamedPipeClient Matt Conover (Aug 03)
- Re: ImpersonateNamedPipeClient -- "How Named Pipe Security Works" Mikael Olsson (Aug 03)
- Re: ImpersonateNamedPipeClient -- "How Named Pipe Security Works" Matt Conover (Aug 03)