Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 3 down vote favorite

I'm considering using the Windows DPAPI to protect an ECDH key I use to encrypt some data in a local database in a Windows desktop application. I'm new to DPAPI, but its my understanding that DPAPI can use a users credentials to secure the keys it protects.

Wouldn't this be vulnerable to malware, that a user inadvertently installs, or does DPAPI provide some protection in this instance?

share|improve this question

2 Answers

up vote 2 down vote accepted

You don't need process injection to access the data.

I think it is clearly stated in DPAPI documentation on Microsoft website: its role it to tie the data to be protected with the user account. So as soon as the code is executed with the same account (and not the same process) it should be considered unprotected.

Indeed, if a malware gets executed, it can retreive all those secrets without any specific rights. That's typically how password recovery software work !

It can also be decrypted offline but I guess that is not the attack scenario you are considering here.

share|improve this answer
You're thinking of CryptProtectData. If you call CryptProtectMemory with the CRYPTPROTECTMEMORY_SAME_PROCESS flag set, only the process that protected the memory can unprotect it. – Polynomial Jan 27 at 23:35
The question was about DPAPI and CryptProtectMemory is not labelled as part of this. By the way I have not reversed this one yet but maybe ReadProcessMemory should be enough to retreive the data from another process. SeDebugPrivilege is required though. – Jean-Michel Jan 27 at 23:56
up vote 4 down vote

DPAPI is designed to protect memory in scenarios where a limited account is used. The only way to decrypt data protected by DPAPI is to inject code into the process that protected the data. That operation (specifically the use of WriteProcessMemory and CreateRemoteThread) requires administrative privileges. As long as the malware doesn't manage to escalate its privileges to an administrative level, it cannot inject a thread into the process, and therefore cannot decrypt the DPAPI data.

The other benefit of DPAPI is that it doesn't matter if the encrypted memory regions are written to disk as part of a swapping, hibernation or crash dump operation. The DPAPI keys are stored in areas of kernel memory that don't get copied to disk, so it's impossible to recover the data from such a file.

share|improve this answer
4  
The operative words being in a limited account scenario. If the app is running as the currently logged in user then it doesn't add any protection. – SteveS Jan 27 at 2:17
@SteveS That's not true. You have to have administrative privileges to inject a thread into a process. As such, if you run as a limited user, two processes running under your user account cannot interfere with each other via injected threads or WriteProcessMemory, unless you grant one of them administrative privileges via UAC escalation. – Polynomial Jan 27 at 9:31
@Polynomial I'm pretty sure you can manipulate other processes of the same user as a process running on a limited user. The target process can change its ACLs, but that doesn't work reliably if the malware process started before the target process. – CodesInChaos Jan 27 at 13:36
@CodesInChaos You may be right, though it's not clear. The CreateRemoteThread won't work on any process running on a different user account, regardless of ACLs - that's specified in the MSDN docs. From Vista and later, the PROCESS_ALL_ACCESS process access flag also cannot be attained by limited users. The SACL / DACL cannot be set on a process unless you have the rights to it, which might be possible if it's running as the same user. I'm not entirely sure. I think it largely depends on the OS you're running. – Polynomial Jan 27 at 18:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.