search

codenote / google-security-research

Automatically exported from code.google.com/p/google-security-research
0 stars 0 forks source link

Windows: Impersonation Check Bypass With CryptProtectMemory and CRYPTPROTECTMEMORY_SAME_LOGON flag #128

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Platform: Windows 7, 8.1 Update 32/64 bit
Class: Security Bypass/Information Disclosure

The function CryptProtectMemory allows an application to encrypt memory for one 
of three scenarios, process, logon session and computer. When using the logon 
session option (CRYPTPROTECTMEMORY_SAME_LOGON flag) the encryption key is 
generated based on the logon session identifier, this is for sharing memory 
between processes running within the same logon. As this might also be used for 
sending data from one process to another it supports extracting the logon 
session id from the impersonation token. 

The issue is the implementation in CNG.sys doesn't check the impersonation 
level of the token when capturing the logon session id (using 
SeQueryAuthenticationIdToken) so a normal user can impersonate at 
Identification level and decrypt or encrypt data for that logon session. This 
might be an issue if there's a service which is vulnerable to a named pipe 
planting attack or is storing encrypted data in a world readable shared memory 
section. 

This behaviour of course might be design, however not having been party to the 
design it's hard to tell. The documentation states that the user must 
impersonate the client, which I read to mean it should be able to act on behalf 
of the client rather than identify as the client.

Attached is a simple PoC which demonstrates the issue. To reproduce follow the 
steps.

1) Execute Poc_CNGLogonSessionImpersonation.exe from the command line
2) The program should print "Encryption doesn't match" to indicate that the two 
encryptions of the same data was not a match, implying the key was different 
between them. 

Expected Result:
Both calls should return the same encrypt data, or the second call should fail

Observed Result:
Both calls succeed and return different encrypted data

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.

Original issue reported on code.google.com by fors...@google.com on 17 Oct 2014 at 10:55

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 17 Oct 2014 at 9:40

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 28 Nov 2014 at 9:23

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 2 Dec 2014 at 11:10

GoogleCodeExporter commented 9 years ago 
Correspondance Date: 29 Oct 2014

< Microsoft confirm they've reproduced the issue and think it might constitute 
a security feature bypass. Further confirmation will be provided soon.

Original comment by fors...@google.com on 13 Jan 2015 at 12:42

GoogleCodeExporter commented 9 years ago 
Correspondance Date: 14 Jan 2015

< Asked Microsoft for information on whether they were going to fix this issue 
and timescales of it. Notified them that the current deadline is the 15th 
January.

Original comment by fors...@google.com on 14 Jan 2015 at 9:45

GoogleCodeExporter commented 9 years ago 
Correspondance  Date: 14 Jan 2015

> Microsoft informed us that a fix was planned for the January patches but has 
to be pulled due to compatibility issues. Therefore the fix is now expected in 
the February patches.

Original comment by fors...@google.com on 15 Jan 2015 at 8:57

GoogleCodeExporter commented 9 years ago 
Deadline exceeded - automatically derestricting

Original comment by haw...@google.com on 15 Jan 2015 at 8:34

GoogleCodeExporter commented 9 years ago 
Note that the bug tracker is intended for technical analysis and bookkeeping 
related to the specific issue described. In this instance, we're looking to 
keep comments strictly about the technical aspects of this issue.

Thanks!
Ben

Original comment by haw...@google.com on 16 Jan 2015 at 12:55

GoogleCodeExporter commented 9 years ago 
I cannot imagine any circumstance in which it would be desirable for this 
feature to behave this way. If there's a compatibility issue, this means that 
some poorly written code is relying on this bug to function correctly and, 
therefore, those components might be a ripe opportunity for further security 
bug exploration.

Just my thoughts on the matter. Great find!

Original comment by kobrasre...@gmail.com on 16 Jan 2015 at 4:23

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
on Windows 10 i got Encryption doesn't match, impersonated session?

Original comment by jbrek...@gmail.com on 17 Jan 2015 at 2:03

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
on my Windows 8.1 i got:
"Encryption doesn't match, impersonated session?"

What does it mean?

Original comment by nunocorr...@gmail.com on 19 Jan 2015 at 3:12

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Can someone point me to an explanation of what exactly this does?

Is this vulnerability relevant to EFS? Does it allow a simultaneously logged-on 
user to use a different user's EFS key?

Original comment by NickBorg...@gmail.com on 19 Jan 2015 at 5:16

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Ok, I have read it is a privilege escalation, but this still isn't entirely 
clear to me.
Acquiring an impersonation token doesn't necessarily mean you have really 
escalated privilege does it? My understanding was that system-level functions 
are supposed to check if your token is legitimate and so would not let you use 
this impersonation token to perform privileged functions, unless they 
themselves were bugged.
Looking at the "Encryption doesn't match, impersonated session?" from an EFS 
perspective I again don't necessarily see this as problem. If you impersonated 
a user and gained access to their EFS public key there is no problem, and that 
could produce data reasonably described by "Encryption doesn't match". Only 
private key access, and subsequent ability to decrypt data would be a real 
problem.
Anyway, I'm not reading that EFS is involved here; just going back to it as an 
example.

Original comment by NickBorg...@gmail.com on 20 Jan 2015 at 4:35

GoogleCodeExporter commented 9 years ago 
OK, nevermind; I think I got a better explanation now, but please tell me I'm 
wrong if this is not it:
"a normal user can impersonate at Identification level and decrypt or encrypt 
data for that logon session"

So processes in your user space may be encrypting their memory such that only 
processes in your user space can read their content. This vulnerability breaks 
this protection, allowing other simultaneous users to read the encrypted memory 
of processes in your user space that attempted to encrypt their memory.

So this would have an impact in situations like:
*) A web server with an SSL certificate storing it in encrypted memory could 
have the private key stolen by another process running on the computer
*) A password database program, if they even use this function, could have 
passwords stolen from memory by programs running in other users' spaces

I keep talking about EFS because it concerns me; but it doesn't look 
particularly likely that it is affected here: that another user on the computer 
could use this vulnerability to extract an EFS private key from memory.

Original comment by NickBorg...@gmail.com on 20 Jan 2015 at 4:41

GoogleCodeExporter commented 9 years ago 
This isn't related to EFS, that's a separate system service. The 
CryptProtectMemory is an API which you're supposed to use to protect ephemeral 
data, such as passwords in memory or encryption keys. The actual key for the 
memory is stored in the kernel so user-mode programs shouldn't be able to 
access it directly. There are three levels of protection:

1) The current process only
2) The current logon session
3) The current computer

This issue only affects 2, the PoC demonstrates that if you impersonate using 
the token which is tied to another logon session (such as Local System's 
session) you can encrypt and decrypt memory. The kernel driver's missing the 
impersonation level check so a normal system user can impersonate at 
Identification level and decrypt data encrypted in the local system's logon 
session. This impersonation level doesn't provide the normal user any 
additional privileges. The issue description does not provide a concrete 
example of accessible encrypted data but there could be many places it might 
leak such as shared memory sections or temporary files. The ultimate severity 
of the issue therefore depends on what data could be decrypted or encrypted and 
what you might be able to do with it (think if the data was another user's 
password).

Original comment by fors...@google.com on 20 Jan 2015 at 4:50

GoogleCodeExporter commented 9 years ago 
Great description, thank you!

Original comment by NickBorg...@gmail.com on 20 Jan 2015 at 5:12

GoogleCodeExporter commented 9 years ago 
Bulletin: https://technet.microsoft.com/library/security/MS15-010

Original comment by cev...@google.com on 10 Feb 2015 at 7:15

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
can be explained in more detail ga I do not understand 
http://tricajus-asli.com/obat-kanker-payudara-tanpa-operasi-terampuh/

Original comment by htrica...@gmail.com on 21 Mar 2015 at 4:27