Re: [Full-disclosure] Question for the Windows pros
Hello, The ImpersonateNamedPipeClient() risks have been fully documented by Blake Watts back in 2002. http://www.blakewatts.com/namedpipepaper.html The problem is basically that OpenFile() will accept either : - A file path (C:\toto.txt) - A share path (\\hacker\toto) - A named pipe path (\\hacker\pipe\toto) (Did you ever notice that you cannot create a share named pipe on a Windows system ? ;) So if you can open a file with a privileged application (such as a SYSTEM service), you can gain the privileges of the application. Real life example: take your antivirus, change the log file name from C:\Program Files\Antivirus\log.txt to \\mycomputer\pipe\toto while running a listener on the toto pipe. When the antivirus opens the log file, you become SYSTEM. Regards, - Nicolas RUFF Security Researcher @ EADS-CRC ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
--On Thursday, January 19, 2006 08:20:37 +0100 Bernhard Mueller [EMAIL PROTECTED] wrote: Hello, The ImpersonateClient API does not require that credentials are embedded into the program. A call to ImpersonateClient allow a server to impersonate the client when it receives a local connection, e.g. via a named pipe. It is mostly used by servers to DROP their privileges to that of the connecting user if they are running with administrative privileges. A security issue with ImpersonateClient arises if there's no error checking on the ImpersonateClient call and the process runs without realizing that it is still SYSTEM. Another issue would be an unprivileged client with the ImpersonateClient privilege, if an attacker manages to make a process with admin rights connect to that client. This is why normal users do not have this right by default. When you say manages to make a process with admin rights connect, you are referring to the Local Administrator account on the machine in question, correct? So far, from what I understand, granting this privilege to a User means that *if* a process with higher privileges can connect to the computer in question, the User's privileges will be elevated through impersonation. If this is the case, then the security risk is minimal, I would think. I would welcome suggestions regarding scenarios where this could be used to exploit a box. ISTM if the connecting process already has the admin rights, elevating the User's rights through impersonation merely elevates the User to the same level of privilege that the process already has. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
--On Thursday, January 19, 2006 10:32:44 +0100 Nicolas RUFF [EMAIL PROTECTED] wrote: The ImpersonateNamedPipeClient() risks have been fully documented by Blake Watts back in 2002. http://www.blakewatts.com/namedpipepaper.html Does the Impersonate a client after authentication privilege grant the account access to ImpersonateNamedPipeClient? Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
Applying the Principle of Least Privilege to User Accounts on Windows XP http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/luawinxp.mspx /JA ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
--On Thursday, January 19, 2006 18:54:29 +0100 Jerome Athias [EMAIL PROTECTED] wrote: Applying the Principle of Least Privilege to User Accounts on Windows XP http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/luawinxp.m spx I fully understand the principle of least privilege to users. I'm not sure how it applies to my question, though. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Question for the Windows pros
Win 2000 SP 4 and Win XP both incorporated two new security features; Create global objects and Impersonate client after authentication. Both are restricted to Administrators, SYSTEM or other privileged accounts. What are the risks associated with granting Authenticated Users (AD 2003) the Impersonate client after authentication privilege? I've googled and read endlessly repetitive explanations for what the privilege is (most of them nearly incomprehensible), but I have yet to find anyone who articulates the risks associated with such a change. ISS claims it's a HIGH risk but then gives no explanation why that is so. Would this expose a workstation to a Blaster-type worm, for example? Open it up to remote attack? If so, what is required to conduct the attack? What ports would be involved? Pointers to white papers or talks at conferences would be greatly appreciated. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
On 18/01/06, Paul Schmehl [EMAIL PROTECTED] wrote: What are the risks associated with granting Authenticated Users (AD 2003) the Impersonate client after authentication privilege? I've googled and read endlessly repetitive explanations for what the privilege is (most of them nearly incomprehensible), but I have yet to find anyone who articulates the risks associated with such a change. Assigning this privilege to a user allows programs running on behalf of that user to impersonate a client. Requiring this user right for this kind of impersonation prevents an unauthorized user from convincing a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created and then impersonating that client, which can elevate the unauthorized user's permissions to administrative or system levels. [1] regards stuartd [1] http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/fe1fb475-4bc8-484b-9828-a096262b54ca.mspx ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
--On Wednesday, January 18, 2006 16:54:38 + Stuart Dunkeld [EMAIL PROTECTED] wrote: On 18/01/06, Paul Schmehl [EMAIL PROTECTED] wrote: What are the risks associated with granting Authenticated Users (AD 2003) the Impersonate client after authentication privilege? I've googled and read endlessly repetitive explanations for what the privilege is (most of them nearly incomprehensible), but I have yet to find anyone who articulates the risks associated with such a change. Assigning this privilege to a user allows programs running on behalf of that user to impersonate a client. Requiring this user right for this kind of impersonation prevents an unauthorized user from convincing a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created and then impersonating that client, which can elevate the unauthorized user's permissions to administrative or system levels. [1] I can read. I need to know, from a practical application standpoint, what does this mean. What are the exposures? Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
On Wed, 2006-01-18 at 11:30 -0600, Paul Schmehl wrote: I can read. I need to know, from a practical application standpoint, what does this mean. What are the exposures? Sounds to me like that right allows a user to assume the security context of another user. Think of RunAs where a user runs a procedure as a different user. *That* ability should tell you a lot of what the exposures are. It's seems similar to allowing your *nix users to use su (without password check) to assume another user. (As root you can su username and you are that user. Imagine of your normal users could do that). I don't see why you would ever need to grant a normal user such a right. It may be of interest for service accounts, though. Regards, Frank -- It is said that the Internet is a public utility. As such, it is best compared to a sewer. A big, fat pipe with a bunch of crap sloshing against your ports. signature.asc Description: This is a digitally signed message part ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
--On Wednesday, January 18, 2006 11:40:00 -0600 Frank Knobbe [EMAIL PROTECTED] wrote: On Wed, 2006-01-18 at 11:30 -0600, Paul Schmehl wrote: I can read. I need to know, from a practical application standpoint, what does this mean. What are the exposures? Sounds to me like that right allows a user to assume the security context of another user. Think of RunAs where a user runs a procedure as a different user. *That* ability should tell you a lot of what the exposures are. It's seems similar to allowing your *nix users to use su (without password check) to assume another user. (As root you can su username and you are that user. Imagine of your normal users could do that). I understand *that*. My question is, what are you granting them su *for*? The entire kettle of fish? Or specific tasks. The privilege only allows you to impersonate a *client* (as in server-client), so (I would think) you can't do file browsing or http parsing (or can you?) IOW, what are the *servers* that you can impersonate the client for? Is Windows Explorer a server, for example? Does it allow clients to access it? Is IE a server? Obviously, all the *services* (or at least the majority of them) would be servers - such as the Computer Browsing service - but does that service allow clients to access it? Or the Alerter service. Does it allow clients? The explanations on MS's site are vague enough that they're meaningless. What services running on Windows allow clients to access them? And if they do, do they restrict access to the Local Machine? Or do they allow Remote Access? (For example, RPC is clearly remote. Is the Windows Time service?) Knowing the answers to those would go a long way toward answering the question - what exactly are the capabilities that this privilege grants you? I don't see why you would ever need to grant a normal user such a right. It may be of interest for service accounts, though. Unfortunately, in the context of my problem, the users must have this right. Before I grant it, I want to understand exactly what the ramifications of that are. If it's too severe a risk, then I'll have to find some other way to solve this problem. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
The explanations on MS's site are vague enough that they're meaningless. What services running on Windows allow clients to access them? And if they do, do they restrict access to the Local Machine? Or do they allow Remote Access? (For example, RPC is clearly remote. Is the Windows Time service?) Actually, the explanations are not vague or meaningless. It just helps to have an understanding of what this privilege governs. Lets start with the fact that in essence it only applies to Server operating systems, and only to Windows 2000 SP4, or Windows 2003. http://msdn.microsoft.com/library/default.asp?url=/library/en- us/secauthz/security/authorization_constants.asp Mike Howard also demonstrates the technique here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure03132003.asp RPC is not clearly remote. It is merely a mechanism which is capable of delivering remote calls. According to MSDN this is a list of API that require SeImpersonatePrivelege: RpcImpersonateClient ImpersonateAnonymousToken ImpersonateClient ImpersonateLoggedOnUser ImpersonateSecurityContext RpcGetAuthorizationContextForClient Reading the API, and the MSDN Documentation on IMpersonation and Delegation should illuminate this issue. The short story is though, that any case where any process or thread will execute, either locally or remotely, under another users security context, impersonation is required. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
--On Wednesday, January 18, 2006 13:25:55 -0600 Yvan Boily [EMAIL PROTECTED] wrote: The explanations on MS's site are vague enough that they're meaningless. What services running on Windows allow clients to access them? And if they do, do they restrict access to the Local Machine? Or do they allow Remote Access? (For example, RPC is clearly remote. Is the Windows Time service?) Actually, the explanations are not vague or meaningless. It just helps to have an understanding of what this privilege governs. Lets start with the fact that in essence it only applies to Server operating systems, and only to Windows 2000 SP4, or Windows 2003. This is incorrect. The privilege exists *and* functions on the Workstation operating systems Win2000 SP4 *and* WinXP. I have verified this through testing. http://msdn.microsoft.com/library/default.asp?url=/library/en- us/secauthz/security/authorization_constants.asp I've already been there and read the page - several times. I understand *in general* what an impersonation privilege is. I need to know *specifically* what server's clients can be impersonated when this privilege is applied to an account. So far, I've found nothing on the web that even attempts to address that issue. Mike Howard also demonstrates the technique here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/h tml/secure03132003.asp That's somewhat helpful, in a general way, but still doesn't answer my question. RPC is not clearly remote. It is merely a mechanism which is capable of delivering remote calls. Which is what I meant by clearly remote. IOW, it's capable of accessing resources remotely. According to MSDN this is a list of API that require SeImpersonatePrivelege: RpcImpersonateClient ImpersonateAnonymousToken ImpersonateClient ImpersonateLoggedOnUser ImpersonateSecurityContext RpcGetAuthorizationContextForClient Reading the API, and the MSDN Documentation on IMpersonation and Delegation should illuminate this issue. Unfortunately, it has not. Again, I understand *in general* what impersonation is, how it works and what it can mean in terms of security. I am looking *specifically* for what a user who has the privilege Impersonate a client after authentication has the right to do. Does it mean that *anything* that user runs runs under his/her privileges? Does it mean only *local* processes are affected? Does it mean a hacker can access the machine remotely and run under the user's privileges? IOW, if I have a domain account name Joe, and I grant Joe this privilege, what is placed at risk? The local machine he's logged in to? The entire domain? Only certain services? Saying it's a high risk (like ISS does) and then not defining *precisely* what the risks are is not helpful. And all I was really asking for is pointers to any white papers or conference presentations that even attempt to illuminate this issue. It's looking like there are none. The short story is though, that any case where any process or thread will execute, either locally or remotely, under another users security context, impersonation is required. Can you name one? For example, is the RPC Locater Service affected by this privilege? Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
On Wed, 2006-01-18 at 12:07 -0600, Paul Schmehl wrote: I understand *that*. My question is, what are you granting them su *for*? The entire kettle of fish? Or specific tasks. The privilege only allows you to impersonate a *client* (as in server-client), so (I would think) you can't do file browsing or http parsing (or can you?) Right. Unless the user can find a way of running as a logged on user or such. A user might be able to run an exploit script that takes advantage of the ImpersonateClient and launches a cmd.exe locally. Think of Attempted Privilege Execution rather than Attempted Privilege Escalation since you already have the privilege escalated through this right just need to find a way to put it to use. Remembering stunts like using the scheduler to run cmd.exe interactively or as a screensaver, getting to the point of doing something useful with that right shouldn't be too hard. What are you granting them su for? Perhaps for a mail migration utility that runs as administrator, but assumes the security context of a user to read email from his mailbox (yeah, admin can do that, this is just an example). Or for running a script remotely against a user workstation that sets certain things in the Registry in the user context (to gain access to the Secure Storage or such). Unfortunately, in the context of my problem, the users must have this right. What circumstance requires you to turn that right on, if you don't mind me asking? Cheers, Frank -- It is said that the Internet is a public utility. As such, it is best compared to a sewer. A big, fat pipe with a bunch of crap sloshing against your ports. signature.asc Description: This is a digitally signed message part ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
On Wed, 2006-01-18 at 16:16 -0600, Paul Schmehl wrote: This means that the exposure, when granting the privilege, is as follows: 1) If you can launch a process on the local machine AND 2) The process has embedded credentials that are different from the user launching the process THEN 3) The user gains those credentials' privileges ***for the length of that process*** Yup. So if your use has that right, any spyware the user downloads via IE can use that user right to elevate credentials **for the length of the malware installation**. Does that sound right? And does that sound like something you'd want to happen? You're caught between a rock and hard spot. You need to install software, but don't want to give admin rights. So you have to meddle with user rights in order to install the software, which would leave the user again vulnerable to other software taking advantage of that user right. If you give that right, or admin privs, why don't you limit that only to the duration of the software install? It sounded like you were planning on granting that user right and leaving it in place. If you only grant it temporarily, the exposure is not great, imho. (Remember, I've been liberated from Windows for a couple years now ;) So, why did M$ decide to remove this right from the user? Because it prevents them from installing software on the box. Right. But now you find yourself having to dish out that right again to make some software work. What's wrong with that picture? ;) Cheers, Frank -- It is said that the Internet is a public utility. As such, it is best compared to a sewer. A big, fat pipe with a bunch of crap sloshing against your ports. signature.asc Description: This is a digitally signed message part ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
--On Wednesday, January 18, 2006 17:07:23 -0600 Frank Knobbe [EMAIL PROTECTED] wrote: On Wed, 2006-01-18 at 16:16 -0600, Paul Schmehl wrote: This means that the exposure, when granting the privilege, is as follows: 1) If you can launch a process on the local machine AND 2) The process has embedded credentials that are different from the user launching the process THEN 3) The user gains those credentials' privileges ***for the length of that process*** Yup. So if your use has that right, any spyware the user downloads via IE can use that user right to elevate credentials **for the length of the malware installation**. Does that sound right? And does that sound like something you'd want to happen? The spyware has to bring the credentials with it. The user doesn't *have* the credentials. It *gets* them from the process in question. That's a bit different. The user has the right to impersonate within the context of a process. The process must already have the credentials to elevate, or the user gets nothing (if I'm understanding impersonation correctly.) If you give that right, or admin privs, why don't you limit that only to the duration of the software install? It sounded like you were planning on granting that user right and leaving it in place. If you only grant it temporarily, the exposure is not great, imho. (Remember, I've been liberated from Windows for a couple years now ;) Do you know a way to programmatically grant rights, on the fly, and then take them away? I know you can do this with RunAs, but that would require having an admin password, in the clear, and readable by Authenticated Users. That ain't gonna happen. As far as granting the privilege goes, *if* we do it, it will only be in place long enough to distribute the agents. Then it will be removed. But I'm reluctant to even do *that* until I'm certain I fully understand the ramifications. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Question for the Windows pros
Hello, The ImpersonateClient API does not require that credentials are embedded into the program. A call to ImpersonateClient allow a server to impersonate the client when it receives a local connection, e.g. via a named pipe. It is mostly used by servers to DROP their privileges to that of the connecting user if they are running with administrative privileges. A security issue with ImpersonateClient arises if there's no error checking on the ImpersonateClient call and the process runs without realizing that it is still SYSTEM. Another issue would be an unprivileged client with the ImpersonateClient privilege, if an attacker manages to make a process with admin rights connect to that client. This is why normal users do not have this right by default. Regards, Bernhard Paul Schmehl wrote: --On Wednesday, January 18, 2006 17:07:23 -0600 Frank Knobbe [EMAIL PROTECTED] wrote: On Wed, 2006-01-18 at 16:16 -0600, Paul Schmehl wrote: This means that the exposure, when granting the privilege, is as follows: 1) If you can launch a process on the local machine AND 2) The process has embedded credentials that are different from the user launching the process THEN 3) The user gains those credentials' privileges ***for the length of that process*** Yup. So if your use has that right, any spyware the user downloads via IE can use that user right to elevate credentials **for the length of the malware installation**. Does that sound right? And does that sound like something you'd want to happen? The spyware has to bring the credentials with it. The user doesn't *have* the credentials. It *gets* them from the process in question. That's a bit different. The user has the right to impersonate within the context of a process. The process must already have the credentials to elevate, or the user gets nothing (if I'm understanding impersonation correctly.) If you give that right, or admin privs, why don't you limit that only to the duration of the software install? It sounded like you were planning on granting that user right and leaving it in place. If you only grant it temporarily, the exposure is not great, imho. (Remember, I've been liberated from Windows for a couple years now ;) Do you know a way to programmatically grant rights, on the fly, and then take them away? I know you can do this with RunAs, but that would require having an admin password, in the clear, and readable by Authenticated Users. That ain't gonna happen. As far as granting the privilege goes, *if* we do it, it will only be in place long enough to distribute the agents. Then it will be removed. But I'm reluctant to even do *that* until I'm certain I fully understand the ramifications. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
