Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security with Elevated Process #4

Open
brianhassel opened this issue Jul 31, 2024 · 3 comments
Open

Security with Elevated Process #4

brianhassel opened this issue Jul 31, 2024 · 3 comments

Comments

@brianhassel
Copy link

Thanks for the excellent list of security optimizations. I've approached this slightly differently, and I wanted to get some feedback/discussion:

Implementation:

  • Assuming you're on a device on which you have local admin privileges...
  • Edit the Program Files - Keepass.exe, Properties, Compatibility, For All users to 'Run this program as administrator'
  • Use a key file with a master password, change permissions on the keyfile to only read/write by Administrator
  • Password DB can remain user-level access to work with file sync (e.g. Google Drive) processes
  • Starting KeePass will prompt with UAC to elevate your low-privilege user to admin.
  • UAC prompt should be set to highest level (always prompt), which anyone concerned with security already has set

Rationale:

  • Passwords in Keepass are the most valuable thing on my computer
  • I (by necessity) trust the Authenticode signed KeePass.exe/author of Keepass with my valuable secrets, might as well give it high privilege on my device
  • Signed .exe file gives an easy-to-read/verify UAC prompt (not the 'scary' unsigned one). UAC prompt allows immediate verification of EXE's validity
  • Elevated processes get built-in protections from memory dumps without the need for DACL (only admins can dump)
  • Elevated process memory/handles are protected from user-level processes. No injection.
  • Keyfile is safe from user-level malware/scripts
  • Program files directory and EXE are protected from non-elevated users overwriting/DLL replacing

To me, the most likely threat is always some rouge/malware program/script running as a standard user. If malware was somehow able to elevate, it would be game over anyway. This procedure effectively gives the password manager the highest possible security, and it doesn't affect standard usage (it may break some plugins, but I don't use them)

@onSec-fr
Copy link
Owner

onSec-fr commented Aug 9, 2024

Hello, thank you for your feedback.

Your point of view is very interesting.

Indeed, using keepass with an elevated account enables you to benefit natively from Windows security features (UAC, process protection).
On the other hand, with this approach, you give absolute confidence to the keepass application, and expose yourself more to a compromise of your system if the binary is compromised (or unknown cve) because it is running with maximum integrity.
Also in my opinion, a desktop application should not be run with a privileged account, especially in a corporate environment where its use leaves secrets (NTLM, Kerberos) on the local machine.
In any case, with your approach, make sure that plugins are deactivated, otherwise it would allow an attacker to load a malicious plugin with administrator privileges!

@brianhassel
Copy link
Author

Good points for a corporate environment. In my home-use case, my user is a member of the admins group, and I rely on UAC to block admin-level actions (the typical Windows default user approach.) I also use the 'full installer' MSI for KeePass to install to the admin-restricted 'Program Files', since protecting the binaries and core config is a critical part of securing it. Since I elevated the installer, I've already accepted the risk of a malicious .exe/.dll or script in the installer, so it doesn't matter too much for subsequent runs of the KeePass.exe

I have been playing around with encryption using TPM-stored keys (certificates with the private key in TPM) with 'password', and something like that would be ideal. I'm not sure if the plugins allow it, but ideally on open, you'd need to decrypt the DB or keyfile with a TPM-backed certificate with passphrase where it would be loaded into memory. That would ensure only my device could decrypt, and be better than DPAPI, because it requires user-presence for the TPM interaction. Anti-hammering in the TPM means the passphrase could be short, like what Windows Hello does.

@onSec-fr
Copy link
Owner

Hello,

TPM encryption is strong but the big problem for me is that if you lose your device, you lose your passwords !

I think using a certificate file additionally to the password is the best choice as it provides a very good encryption and acts like a second factor. There is also some plugins which add OTP or Security Key but then you need to enable plugins.

Anyway any of those methods are protecting the database file from offline attacks, but not from a memory dump or process injection when it's in unlocked state.

There we are reaching the limits of any password vault.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants