Attacker with access to XML config can trigger keepass.exe to obtain passwords

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24055

by pieter_mj • 3 years ago

57 103 3 years ago

cve.mitre.org

moritonal3• 3 years ago

Got to agree with the developer on the dispute.

If someone can edit the XML they could also just add a plugin that exports everything on load? Plugs are trivial to write and have access to everything automatically if they exist on disk in the plugins directory.

jonathanstrange4• 3 years ago

That feature is extremely insecure and makes no sense for a password manager. It ought not be possible to trigger anything in an unencrypted document or install/run anything over plaintext data without first providing the master passphrase for that password document. That should be obvious.

adlpz2• 3 years ago

I'm just guessing here, but I'd assume this vulnerability does happen once the master password is input.

So, the attacker modifies the config file, then the user eventually uses the password manager as usual, and then a file in disk with all plain text passwords is generated and subsequently read by the attacker.

I guess the point here is you don't need a memory read vulnerability.

Can someone more knowledgeable confirm?

_puk• 3 years ago

Am I reading that right, that if you point Keepass.exe at any .kdbx and simply add an export option to the XML config it'll export it without the master password?

Granted you need local access to modify the config, but generally the .kdbx is stored (securely) on some shared environment. Grabbing that would mean you could export passwords at your leisure in this setup?

tinus_hn• 3 years ago

I would hope that the password manager application does not itself have access to the unencrypted passwords, without the user providing the master password.

LeifCarrotson• 3 years ago

But users are constantly providing the master password to use the application normally. The only complaint is that after first providing the master password to cause the application to decrypt the document, the application decrypts the document, and if someone has modified the application to do other stuff after decrypting the document, it does that stuff.

They're proposing that the author change the application so that it pops up a dialog whenever the KeePass application is directed to export the decrypted document.

I'm not a KeePass dev, but with a bit of search and pattern recognition, it looks like this export feature is implemented in KeePass-2.53-Source\KeePass\DataExchange\ExportUtil.cs:

   public static bool Export(PwExportInfo pwExportInfo, FileFormatProvider fileFormat,
       IOConnectionInfo iocOutput, IStatusLogger slLogger)
   {
       PwDatabase pd = pwExportInfo.ContextDatabase;
       ...
       // [IF CONFIG FILE DOESN'T ALLOW EXPORTING WITHOUT KEY]
       if(!AppPolicy.Current.ExportNoKey && (pd != null))
       {
           // [THEN ASK FOR IT AGAIN]
           if(!KeyUtil.ReAskKey(pd, true)) return false;
       }
       ...
       Stream s = (bFileReq ? IOConnection.OpenWrite(iocOutput) : null);
       try { bResult = fileFormat.Export(pwExportInfo, s, slLogger); }
       finally { if(s != null) s.Close(); }
    }

They're complaining that an evil maid attack can turn off `AppPolicy.Current.ExportNoKey` and set it up to export the document silently. They want it to read:

   public static bool Export(PwExportInfo pwExportInfo, FileFormatProvider fileFormat,
       IOConnectionInfo iocOutput, IStatusLogger slLogger)
   {
       PwDatabase pd = pwExportInfo.ContextDatabase;
       ...
       // [ALWAYS ASK FOR MASTER PASSWORD AGAIN BEFORE EXPORTING]
       if(!KeyUtil.ReAskKey(pd, true)) return false;
       ...
       Stream s = (bFileReq ? IOConnection.OpenWrite(iocOutput) : null);
       try { bResult = fileFormat.Export(pwExportInfo, s, slLogger); }
       finally { if(s != null) s.Close(); }
    }

They've even gone so far as to ask the author to create a "KeePass Essentials" version, which removes the export feature, plugins, and configuration files entirely:

https://sourceforge.net/p/keepass/feature-requests/2704/#b3c...

But they ignore that with write access to the application directory, an attacker can just change the application to not show that dialog at all.

H4ZB74• 3 years ago

you extremely have no idea what you're talking about. the password exists because that's how encryption works, and no other reason. if your hard drive is stolen, they need the password. there is not one single other reason that the password exists

that_guy_iain3• 3 years ago

I would expect to be able to give someone access to my computer let them do random things without them having access to things that are passworded within the computer.

Being able to sliently make my password manager insecure is a big issue. It should be right up there with the LastPass hacks.

vgalin7• 3 years ago

This 'someone' could also, on most computers, install a keylogger to get your master password, or passwords that aren't registered in a password manager. Would you consider this a vulnerability coming from the password manager?

usrusr7• 3 years ago

There's an option to disable plugins, for that very reason. But that's the core of the issue, if you're unsafe by default adding lockdown options which may or may not work is a very weak improvement. That entire attitude seems more security toy than security tool.

moritonal3• 3 years ago

But, isn't it more dangerous to give a false sense of security?

Wouldn't you prefer a tool that doesn't try to defend against scenarios it knows it isn't strong enough to handle?

wheybags2• 3 years ago

To quote Raymond Chen: this exploit "rather involved being on the other side of this airtight hatchway"

If they didn't modify the config, they could presumably use one of a plethora of tactics to extract data directly from keepass.exe's memory.

Cthulhu_• 3 years ago

I want to believe reading memory from another process is more difficult in modern operating systems than reading a configuration file in a user's home directory. That said, I'm a layperson so I don't actually know what protections are in place for either memory or filesystem access.

moritonal3• 3 years ago

The dev does quite a lot actually to protect the program, including using things such as SecureString. However, even Microsoft have a comment against this saying:

"When porting code to .NET Core, consider that the contents of the array are not encrypted in memory. The general approach of dealing with credentials is to avoid them and instead rely on other means to authenticate, such as certificates or Windows authentication."

Which I read as: "If writing a program in C#, assume the memory can be read by apps on the same device."

wheybags2• 3 years ago

It's pretty easy[1] if you're running as the same user, or higher privilege

1: https://learn.microsoft.com/en-us/windows/win32/api/memoryap...

vgalin7• 3 years ago

About data stored in-memory, see KeePass.info > Security > Process Memory Protection [0]

While KeePass is running, sensitive data is stored encryptedly in the process memory. This means that even if you would dump the KeePass process memory to disk, you could not find any sensitive data. For performance reasons, the process memory protection only applies to sensitive data; sensitive data here includes for instance the master key and entry passwords, but not user names, notes and file attachments. Note that this has nothing to do with the encryption of database files; in database files, all data (including user names, etc.) is encrypted. [...]

[0] https://keepass.info/help/base/security.html#secmemprot

tialaramex• 3 years ago

On a Linux system, for example, if you're allowed to look inside the process, which would be for similar reasons to why you're allowed to look inside a configuration file belonging to the user, then it's pretty much just as easy.

Suppose we want to look inside process #1234, we just open the file /proc/1234/mem and suppose we know we want the value at address #003e0f20 we just seek to that address and read however much we want.

Unlike a typical data file the memory map has holes in it, so we do need to know where we're going, but that's OK the Linux kernel also provides information about what is in there and where it is, so e.g. we can root around specifically in the program's heap.

DethNinja• 3 years ago

Unfortunately if you can read a configuration file in a user's home directory, you can also get local admin rights very easily via various simple exploits.

This is why RCE type exploits are super dangerous.

There probably won't ever be a solution for this unless we get a completely rewritten Windows / Linux with pure security in mind.

I wonder if any VC would invest in a startup to build a secure OS.

arp242• 3 years ago

Replacing the keepass binary is probably easier than reading the memory. Even if you don't have access to write to /usr/bin/keepass or C:/Program Files/..., you can probably still replace the desktop icon, start menu shortcut, etc. to point to a different binary, or frob with the user's shell config to put ~/.bin in the PATH and/or set up an alias.

Basically, as soon as local access has been gained by an attacker you can not longer trust anything unless you have unusual protections such as locking down the shell/desktop configuration, or disallowing running binaries from ~, which isn't the case for most systems, and even those protections are tricky to be 100% foolproof. That you can't change the system itself is irrelevant if you can trick the user in to running something outside of the usual system, which is usually quite easy.

Macha6• 3 years ago

Writing*

Macha6• 3 years ago

Another example of if you already have user-level access:

Attach a debugger to the browser, intercept password field input events.

Or KeePass doesn't have browser integration by default so just listen to clipboard events at an OS level.

Ensorceled5• 3 years ago

Attaching a debugger to a process on my OS requires me to enter my system password.

Listening to global clipboard events at the OS level is a permission I have to explicitly grant.

paulryanrogers3• 3 years ago

KP2 can interleave among clipboard and keyboard when it is auto-typing. The feature is meant to mitigate either attack when used alone.

didntreadarticl5• 3 years ago

Right but on windows editing a config file is substantially easier than installing a keylogger or messing with the signed executable

Run_DOS_Run• 3 years ago

an attacker, who has write access to the XML configuration file

If an attacker already has write-access to local files he could also replace keepass.exe or install a keylogger.

If this happens, it's already too late.. this CVE is a joke!

ntauthority• 3 years ago

There's a lot of CVE submissions lately that seem badly sourced and derived from 'disagreements' at best.

Another recent example is https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-2405... which is for a purely theoretical exploit - not even a PoC - with the only 'sources' being Reddit/Twitter scaremongering, and 'support forum posts' that quote these exact same Twitter threads.

usrusr7• 3 years ago

Unsafe defaults like "we run all plugins, unless someone goes through all the right motions of closing that door in all the right ...config.xml, ...config.enforced.xml" (and who knows what others) is just terrible. Terrible for any software, and worse for a piece of software that has no purpose at all besides security. What if there's a typo in your lockdown incantations? Not locked down.

That CVE isn't just a disagreement, it's a warning. Avoid security related software from people who enjoy keeping a security edge over the unwashed masses who aren't in the know, who don't get a kick out of locking down. Because that's why they keep the unsafe defaults, they keep them because they enjoy going the extra mile for their own safety. That is, unless they (also) have worse reasons for keeping unsafe defaults, but, well, Hanlon to the rescue.

usrusr7• 3 years ago

That's answered in the SourceForge discussions linked from the CVE: if you assume the password manager to be only as secure as the user's configuration files, why don't you just skip the hassle and put your passwords in a csv?

raziel2p• 3 years ago

an argument could be made that it's more likely for the password manager file to end up in a malicious actor's hand (in which case an unencrypted csv would be worse), than it is for a malicious actor to get access to your local filesystem.

someguydave• 3 years ago

why don't you just skip the hassle and put your passwords in a csv?

What threats did you think keepass was defending against exactly?

Macha6• 3 years ago

A .csv file on an encrypted hard drive, in a single user system or with proper user permissions arguably does provide 90% of the security benefit of KeePass.

But:

1. Ease of use is a security concern - if it's a pain in the ass to use a security measure, users won't.

2. There's also attacks that for whatever reason aren't able to achieve persistence, but are able to obtain files. Let's imagine a browser or scp or rsync or whatever exploit that tricks it into uploading unintended files. These cases will be blocked by KeePass but not by your .csv

3. Users want to sync their password database via untrusted means (e.g. cloud providers). This is easier when the database is itself encrypted. (This attack targets the application config, not the database config, which is a strange choice to sync).

PurpleRamen• 3 years ago

Has the configuration the same permissions as the exe? IIRC, binaries under windows are often saved with different permissions than the user-profile.

Similar, a virus-scanner will look intensively at exe-files and access to keyboard-input, but not so much at some random configuration, which is supposed to change all the time anyway.

mik1998• 3 years ago

If you have local access to the user's account, couldn't you just switch the keepass executable to a modified version that just sends the database along with the master password to anywhere you want?

I don't see how you can protect from this kind of "attack".

usrusr7• 3 years ago

It's not uncommon at all to see configuration less protected than executables.

Ensorceled5• 3 years ago

At least on the Mac, I get a warning about unsigned executables. If my 1Password.app got replaced by a hacked version, I would get a very suspicious looking popup from my OS.

I need to explicitly grant my IDE permission to debug other processes every time, so reading the passwords is memory isn't a slam dunk either.

And I can assure you, I have full write access to my files.

newaccount742• 3 years ago

I've been wondering how to prevent attacks like this.

I'm a Mac app developer, so I can store secrets in the Keychain. The keychain is pretty secure, and it's hard for an attacker to extract information from the keychain.

But there are a number of ways that could be used to trick my app into revealing passwords if the attacker could change configuration files.

Of course, when the attacker has full access to the local computer, then there are other ways the attacker could extract the data. But what if the attacker only had a way to write a file to an arbitrary path? Then they could use that to reveal passwords.

The only way I can think of to avoid security holes like this is to use configuration files that are signed with a key derived from the password, but that may cause different issues.

ano-ther• 3 years ago

Where is the XML config stored?

If it is backed up with, say, Dropbox, then someone getting access to that could trigger a data export when the user enters the master password next time. And then pick up the data from the synced folder.

This would widen the attack surface from needing local access. Am I missing anything?

vgalin7• 3 years ago

The XML config file is by default stored locally, as KeePass doesn't support cloud-backup or sync out of the box. If the XML config file is on DropBox, that is because you allowed it (either by uploading it manually or because you enabled sync on a whole directory / directory tree).

Ambolia3• 3 years ago

If you want to backup or to use the same password file on different computers it's not uncommon to have it uploaded somewhere.

On the other hand a lot of people store dotfiles on the cloud, at which point if somebody gets access it's probably easier to stole the information by modifying something like the .bashrc file.

Ambolia3• 3 years ago

Does it affect KeepPassXC[1] in any way? It's not the same program but they both use the same KDBX format.

[1] https://keepassxc.org

TruthWillHurt• 3 years ago

me too

Macha6• 3 years ago

My understanding is it is configuring the KeePass application configuration (~/.config/Keepass/KeePass.config.xml) to perform an export via KeePass' own scripting/configuration mechanism. It's not the kdbx file itself being modified here.

KeePassXC has not replicated the automation ("Triggers") system of KeePass, so there's unlikely to be a similar action to take using KeePassXC's config file

menzoic• 3 years ago

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.

Such a trash response from a provider of software thats supposed to protect sensitive data.

vgalin7• 3 years ago

If 'someone' (an attacker), introduced themselves physically in your house or workplace (thus obtaining a high level of access) to place hidden cameras and to record you typing your master passwords. And if that someone later retrieved the footage and a copy of your password manager database... Would you blame your password manager for being insecure?

Ensorceled5• 3 years ago

I don't think these two things are equivalent...

Ensorceled5• 3 years ago

Quite a few security experts in here that think being able to update a text file, one that this often shared across systems (rightly or wrongly), is of equivalent difficulty to stealth updating binaries or reading process memory.

It ludicrous that the relevant bits of this XML file are not protected by the master key.

blincoln3• 3 years ago

It's a little trickier than that, because a KeePass user may work with multiple password databases (e.g. one for themselves, a shared one for their team, etc.), and the user almost certainly wants one configuration that applies to all of them.

Maybe something like the first time a particular database is opened, KeePass could ask the user to approve the settings in the config file, and if so, add a cryptographic signature based on the config file hash and the database's master key to a separate config file that stored a list of those signatures and the config settings that were present when they were generated.[1] The next time the same database is opened, KeePass would only re-prompt if the signature no longer matched. That way, if the config file changed separately, the user could get a warning popup highlighting what had changed.

[1] Alternatively, have everything in one file, and strip the "existing signatures" block before generating the hash, but it seems safer to use a separate file.

e38383• 3 years ago

I'm unsure under which thread I should post, so here is a new one.

Most responses look at one installation of keepass and that you already need to have access to a user. On the other hand in an enterprise environment it is most likely way easier to modify a configuration file than changing anything (without being monitored/alarmed) in the context of the user.

An possible attack scenario might be to change the default startup-script to generate (or manipulate) the xml and after a few minutes try to upload the exported file to a remote location. Sounds like a promising way to get passwords from many users without the need to do anything on a per user basis.

I'm not saying that with the same rights you might also have the right to do stuff as the user, but it might be less prone to detection this way.

aunlead2• 3 years ago

A user needs to enter their "master password" before database is unlocked - after which the silent export can be triggered. Just changing values inside the XML does not expose the passwords.

lukeschlather2• 3 years ago

EDIT: I misunderstood. You need write access to a config file that should only be on the local filesystem, not the kdbx.

So if I'm understanding, a common usage pattern for Keepass is keeping the kdbx on a shared drive (OneDrive, Dropbox, etc.) Someone with read/write access to a bunch of Dropbox shares could perform this exploit on a bunch of kdbx files so that it will write plaintext files to the share, then wait and collect the passwords. It would be hard to hide the attack but it would be incredibly damaging.

So I'm not sure the assertion that this requires local access is correct. It sounds like it only needs access to a shared filesystem that contains a kdbx, and I think it is reasonable to expect Keepass to be secure against that.

Macha6• 3 years ago

This is _not_ modifying kdbx files. It is modifying the application config file (~/.config/KeePass/keepass.config.xml or your OS equivalent).

lukeschlather2• 3 years ago

Oh I see. That is very different.

billpg2• 3 years ago

If I have write access to the machine's files, I could install a key-logger.

newaccount742• 3 years ago

I don't think Windows lets you do that without requiring you to authenticate.

billpg2• 3 years ago

I've installed and run applications that run out of my user folders (not Program Files) without having to UAC.

didntreadarticl5• 3 years ago

So why use Keepass over a plain text file?

syeare• 3 years ago

Uhh of course, this doesn't affect keepassXC right?

didntreadarticl5• 3 years ago

This is quite confusing. For this export to happen someone still needs to enter the password, right? So while 'at rest' yout kbdx file is still protected?

H4ZB74• 3 years ago

witch hunt level nonsense.

windows and linux desktops are just a bunch of programs running in shared memory and disk space. every program can read or modify the data of any other (see ReadProcessMemory, WriteProcessMemory (ptrace for linux)). simple. all these people claiming that there is an issue simply don't realize this simple fact (well, some do, but they're just even more wrong). the worst part is that devs often give into this nonsense, like they did in all those nightmarish hellscape 2003 pseudosecurity laden programs. gotta love when some program prevents me from doing something for "security" when it actually does not make security any better but is just pandering to some charlatans' concerns.

coding1232• 3 years ago

We're probably better off mitigating away from usernames and passwords anyway and start getting everything on pub/private key pairs.

Attacker with access to XML config can trigger keepass.exe to obtain passwords

Related Stories