KeePass 2.X Master Password Dumper (CVE-2023-32784)
The vulnerability was assigned CVE-2023-32784. It should be fixed in KeePass 2.54, which should come out in the beginning of June 2023. Thanks again to Dominik Reichl for his fast response and creative fix!
Clarification: the password has to be typed on a keyboard, not copied from a clipboard (see the How it works sections).
First, update to KeePass 2.54 or higher once available.
Second, if you've been using KeePass for a long time, your master password (and potentially other passwords) could be in your pagefile/swapfile, hibernation file and crash dump(s). Depending on your paranoia level, you can consider these steps to resolve the issue:
- Change your master password
- Delete crash dumps (depends on your OS, on Windows at least
C:\Windows\memory.dmp, but maybe there are others) - Delete hibernation file
- Delete pagefile/swapfile (can be quite annoying, don't forget to enable it back again)
- Overwrite deleted data on the HDD to prevent carving (e.g. Cipher with
/won Windows) - Restart your computer
Or just overwrite your HDD and do a fresh install of your OS.
Incomplete list of products that are not impacted (please create a pull request or an issue for adding more). Rule of thumb is that if it isn't the original KeePass 2.X app written in .NET, it's likely not affected.
KeePass Master Password Dumper is a simple proof-of-concept tool used to dump the master password from KeePass's memory. Apart from the first password character, it is mostly able to recover the password in plaintext. No code execution on the target system is required, just a memory dump. It doesn't matter where the memory comes from - can be the process dump, swap file (pagefile.sys), hibernation file (hiberfil.sys), various crash dumps or RAM dump of the entire system. It doesn't matter whether or not the workspace is locked. It is also possible to dump the password from RAM after KeePass is no longer running, although the chance of that working goes down with the time it's been since then.
Tested with KeePass 2.53.1 on Windows (English) and KeePass 2.47 on Debian (keepass2 package). PoC might have issues with different encodings (languages), but that's not confirmed as of now (see issue #3). Should work for the macOS version as well. Unfortunately, enabling the Enter master key on secure desktop option doesn't help in preventing the attack.
Finding was confirmed by Dominik Reichl, KeePass's author, here. I appreciate Dominik's fast response. Hopefully it will be fixed soon!
- Install .NET (most major operating systems supported).
dotnet run PATH_TO_DUMP
The easiest way to test this on Windows is to create a process dump in the task manager by right-clicking the KeePass process and selecting "Create dump file".
Depends on your threat model. If your computer is already infected by malware that's running in the background with the privileges of your user, this finding doesn't make your situation much worse. However, it might be easier for the malware to be stealthy and evade the antivirus, since unlike KeeTheft or KeeFarce, no process injection or other type of code execution is necessary.
If you have a reasonable suspicion that someone could obtain access to your computer and conduct forensic analysis, this could be bad. Worst case scenario is that the master password will be recovered, despite KeePass being locked or not running at all.
If you use full disk encryption with a strong password and your system is clean, you should be fine. No one can steal your passwords remotely over the internet with this finding alone.
KeePass 2.X uses a custom-developed text box for password entry, SecureTextBoxEx. This text box is not only used for the master password entry, but in other places in KeePass as well, like password edit boxes (so the attack can also be used to recover their contents).
The flaw exploited here is that for every character typed, a leftover string is created in memory. Because of how .NET works, it is nearly impossible to get rid of it once it gets created. For example, when "Password" is typed, it will result in these leftover strings: •a, ••s, •••s, ••••w, •••••o, ••••••r, •••••••d. The POC application searches the dump for these patterns and offers a likely password character for each position in the password.
Reliability of this attack can be influenced depending on how the password was typed and how many passwords were typed per session. However, I've discovered that even if there are multiple passwords per session or typos, the way .NET CLR allocates these strings means that they are likely to be nicely ordered in memory. So if three different passwords were typed, you are likely to get three candidates for each character position in that order, which makes it possible to recover all three passwords.
It's a quick POC, so likely not very reliable and robust. Please create a pull request if you happen to find an issue and fix it.
Allowed password characters are currently hardcoded like this: ^[\x20-\x7E]+$ (all printable ASCII characters and space)
- Python implementation of the PoC by CMEPW (haven't checked if it works)