Attacker with access to XML config can trigger keepass.exe to obtain passwords(cve.mitre.org)
cve.mitre.org
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
105 comments
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.
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.
KP2 can interleave among clipboard and keyboard when it is auto-typing. The feature is meant to mitigate either attack when used alone.
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.
Listening to global clipboard events at the OS level is a permission I have to explicitly grant.
Which OS is this?
The first rules out Linux (unless this is a SELinux thing?).
The second rules out Windows/Mac OS/Linux with X11.
The upstream KeePass application does not support mobile operating systems. It barely supports non-Windows, which is why when most people say they use KeePass they mean KeePassXC
The first rules out Linux (unless this is a SELinux thing?).
The second rules out Windows/Mac OS/Linux with X11.
The upstream KeePass application does not support mobile operating systems. It barely supports non-Windows, which is why when most people say they use KeePass they mean KeePassXC
In Linux you can't attach to arbitrary processes depending on configuration. You can start a program with gdb, but not attach to a running one by default. It was a security upgrade a few years ago https://www.kernel.org/doc/Documentation/security/Yama.txt
Maybe NixOS? I've barely played with it, but this seems like the level of isolation/paranoia that NixOS seems to offer (as far as a layman like myself understands - could be completely wrong on all counts, as usual).
I think you might be misunderstanding nixos, the tree separation will not improve security for this kind of scenario, the only guarantee that nixos offer is that the package is exactly as it’s described on nixpkgs if the store is untainted.
Wouldn't be shocked at all, I mostly think of it as "Linux but with a bunch of inherent security separations introduced", which is why I thought it might be what the...grandparent at this point? is using.
gotta love how every discussion pertaining to program isolation in the last 20 years is just "well all these years i thought this thing isolates processes like it ought to do", followed by a quick, "nope, it actually doesn't". i blame UN*X
Eh, it's a field/domain I am definitely ignorant of - at least I'm not out there confident in my wrong beliefs X)
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.
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.
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.
> 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
On recent Linux distros, by default you can't ptrace (or read memory via /proc/x/mem etc) of non-child processes https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama....
On recent Linux distros, by default you can't ptrace (or read memory via /proc/x/mem etc) of non-child processes https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama....
I just feel that eventually Linux will have to move to the sandboxed model for apps like Android and, recently, Windows.
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."
"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."
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.
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.
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
> 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
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.
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.
I’m all for more funding for OpenBSD. I doubt we would be able to really tackle the usability hindrance of security first though.
As a huge openbsd aficionado I don't think openbsd is more secure than any other operating system, or more correctly speaking, I think openbsd definition of security is different than most peoples definition of security. If anything, by most peoples definition of security openbsd may be less secure.
Most peoples definition of security is to have improved access control such that unauthorized access cannot happen. The openbsd definition of security is closer to "build it correctly so that it operates correctly". openbsd access control is actually fairly limited and rudimentary.
Most peoples definition of security is to have improved access control such that unauthorized access cannot happen. The openbsd definition of security is closer to "build it correctly so that it operates correctly". openbsd access control is actually fairly limited and rudimentary.
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...
1: https://learn.microsoft.com/en-us/windows/win32/api/memoryap...
[deleted]
Writing*
Right but on windows editing a config file is substantially easier than installing a keylogger or messing with the signed executable
>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!
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!
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.
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.
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.
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.
Convenience and tradeoffs are inevitable. KP is meant for regular users with moderate risk tolerance and profile. Without plugins KP is much less useful. If the alternative is no password manager or trusting a SAAS then it may be worthwhile.
I'm all for convenience trade-offs, but they need to be opt-in, not opt out.
Defaults are usually built for the widest market.
Full disclosure, I sell a premium KP2 plugin and would hate for users to have to reinstall KP2 or go through extra hoops to use my plugin.
Full disclosure, I sell a premium KP2 plugin and would hate for users to have to reinstall KP2 or go through extra hoops to use my plugin.
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?
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).
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).
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.
> 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?
What threats did you think keepass was defending against exactly?
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.
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.
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
[1] https://keepassxc.org
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
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
me too
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.
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.
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.
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?
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?
As I understand it, if you modify the xml, Keepass will silently export entries in the database once you load it (by providing the password).
Keepass will (by default) not ask for the password a second time before exporting - but you have to decrypt the database once before it can be exported.
So this is not a risk if your threat model is "attacker obtains a copy of my .kdbx", but it is a risk if your threat model is "attacker can modify .kdbx without me noticing, and can access my local computer or a mounted network disk to read the exported passwords".
Keepass will (by default) not ask for the password a second time before exporting - but you have to decrypt the database once before it can be exported.
So this is not a risk if your threat model is "attacker obtains a copy of my .kdbx", but it is a risk if your threat model is "attacker can modify .kdbx without me noticing, and can access my local computer or a mounted network disk to read the exported passwords".
The point is that the password manager application ought to allow a configuration change which affects document X's plaintext only after the master passphrase has been entered by the user for document X. It's not hard to implement that for configuration files and plugins in a multi-document setting, you just need to store suitable authorization secrets in the documents. In a single-document application it's more trivial, of course, you'd encrypt the configuration file and plugins with keys derived from the master passphrase or check their signatures.
[deleted]
It's actually less of a risk than I thought, because the configuration is on your local install of KeePass, not in the database file.
If an attacker can modify your local install, you've lost anyway....
If an attacker can modify your local install, you've lost anyway....
You have to think about security as being layered. There is a huge difference between creating a mock copy of an application or injecting code into an existing binary, and toggling a setting in a human-readable XML configuration file. Most operating systems also monitor executables more carefully than document files.
My understanding is that the attacker doesn't need to inject code, they can simply take screenshots or recordings programmatically and when that shows the password manager all passwords are exposed.
> So this is not a risk if your threat model is "attacker obtains a copy of my .kdbx", but it is a risk if your threat model is "attacker can modify .kdbx without me noticing, and can access my local computer or a mounted network disk to read the exported passwords".
No, the threat model is "the attacker can modify config file", which for default installation also means "the attacker can modify the executable".
No, the threat model is "the attacker can modify config file", which for default installation also means "the attacker can modify the executable".
The export would only be triggered when a database is opened, so the master password is required.
So this makes no sense. Someone that works at Dropbox has access to millions of kdbx files, and doesn't need any master passwords, just their own copy of keepass.exe?
To perform an export of a KeePass database, the database needs to be opened using (at least) a master password. A database file without its master password is still worthless on its own.
But you don't know that you are entering the password to release all your passwords into cleartext, all you wanted to do is check wether your farmville cows still exist.
That's my biggest quirk. There shouldn't be any way to export plaintext data without explicit user feedback and confirmation in the first place. That this is triggered by an unprotected global configuration file is just the icing on the cake.
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?
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?
The point is that the file itself should be encrypted or at least signed with the master password.
For a general configuration file, there is not "the" master password, since it is independent of password database files.
I guess it's an issue of UI.
Given that dumping a cleartext password list is a legitimate thing you might want to do, and being a plugin (or setting) a somewhat acceptable way of achieving this, the issue here is that, as it is, the user is not being unequivocally made aware of what happened.
So yeah, I agree, in any case the feature, as it is implemented, is completely unacceptable.
Given that dumping a cleartext password list is a legitimate thing you might want to do, and being a plugin (or setting) a somewhat acceptable way of achieving this, the issue here is that, as it is, the user is not being unequivocally made aware of what happened.
So yeah, I agree, in any case the feature, as it is implemented, is completely unacceptable.
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:
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.
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(); }
}
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(); }
}
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.
Application directory and Application Settings directory are not the same thing, usually. (Indeed usually on Windows and Linux, the former isn't writeable to the user account without elevating privileges, the latter is)
I checked where the relevant files are when installing KeePass 2 for windows.
There is a global configuration file at "C:\Program Files\KeePass Password Safe 2\KeePass.config.xml" but by default, this one just contains a directive to use the user's configuration. This one also needs elevated privileges to edit.
The user's configuration file is at "C:\Users\<username>\AppData\Roaming\KeePass\KeePass.config.xml"
So if you want to avoid an attacker being able to change the user's configuration without elevation, then you can just change the security settings of that last file, e.g. by taking away the user write permission.
However, the user is probably launching the KeePass executable via some sort of shortcut. For example, a pinned shortcut on the taskbar. This would also be a user file, at "C:\Users\<username>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\KeePass 2.lnk"
So if the attacker can modify the user's files, then they can probably also modify that shortcut, e.g. to point at a modified copy of keepass. This shows that the behavior of the "real" KeePass application is probably not very relevant here. It is difficult to defend against an attacker with that level of access.
There is a global configuration file at "C:\Program Files\KeePass Password Safe 2\KeePass.config.xml" but by default, this one just contains a directive to use the user's configuration. This one also needs elevated privileges to edit.
The user's configuration file is at "C:\Users\<username>\AppData\Roaming\KeePass\KeePass.config.xml"
So if you want to avoid an attacker being able to change the user's configuration without elevation, then you can just change the security settings of that last file, e.g. by taking away the user write permission.
However, the user is probably launching the KeePass executable via some sort of shortcut. For example, a pinned shortcut on the taskbar. This would also be a user file, at "C:\Users\<username>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\KeePass 2.lnk"
So if the attacker can modify the user's files, then they can probably also modify that shortcut, e.g. to point at a modified copy of keepass. This shows that the behavior of the "real" KeePass application is probably not very relevant here. It is difficult to defend against an attacker with that level of access.
> They're complaining that an evil maid attack can turn off `AppPolicy.Current.ExportNoKey` and set it up to export the document silently.
If an evil maid has access to make such a change, wouldn't it be easier to just replace keepass.exe with custom version? The source is already available. Just call this function after successful login - ignoring XML configuration, "KeePass Essentials" version, etc.
If an evil maid has access to make such a change, wouldn't it be easier to just replace keepass.exe with custom version? The source is already available. Just call this function after successful login - ignoring XML configuration, "KeePass Essentials" version, etc.
business logic
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
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.
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?
Wouldn't you prefer a tool that doesn't try to defend against scenarios it knows it isn't strong enough to handle?
False sense of security is exactly what they did: a sturdy looking lock with a main mechanism that would give the lockpickinglawyer a challenge, but with a number of hidden bypass options that are easy enough for you and I do use (if we know about them).
Bypass options that are considered enough of a problem to give the legitimate user ways to disable then and they are just as hidden as the bypasses themselves. And default to not disabled.
Bypass options that are considered enough of a problem to give the legitimate user ways to disable then and they are just as hidden as the bypasses themselves. And default to not disabled.
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.
Being able to sliently make my password manager insecure is a big issue. It should be right up there with the LastPass hacks.
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?
In most cases they wouldn't be able to do that. Because there are security measures to prevent that.
What security measures do you think would protect against someone installing a keylogger or extracting saved passwords from your browser data files if you let them use your computer?
Also, are you envisioning setting up a new, non-administrative user account for that person, or just logging on using your own account and then handing over the keyboard and mouse like most people would do?
Also, are you envisioning setting up a new, non-administrative user account for that person, or just logging on using your own account and then handing over the keyboard and mouse like most people would do?
Anti-virus systems...
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?
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?
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).
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.
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.
Then it would be an attack vector of course, but whether it is a vulnerability of the password manager itself would be debatable.
Seems like I was wrong, according to this comment[1] you also need local access to get the passwords after modifying the KDBX file.
[1] https://news.ycombinator.com/item?id=34545504
[1] https://news.ycombinator.com/item?id=34545504
The passwords store is not the same as the configuration file. It's common to upload the password store, not the configuration.
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".
I don't see how you can protect from this kind of "attack".
It's not uncommon at all to see configuration less protected than executables.
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.
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.
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.
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.
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.
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.
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.
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.
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.
If I have write access to the machine's files, I could install a key-logger.
I don't think Windows lets you do that without requiring you to authenticate.
I've installed and run applications that run out of my user folders (not Program Files) without having to UAC.
Doubt you could do it with keylogger though
I was curious, so I threw the code from https://hackmag.com/coding/diy-keylogger/ into a C# project and ran it without admin rights. It captured the text I entered into a PowerShell terminal with no issues. So looks like the evil maid could definitely launch a keylogger (and/or clipboard monitor, which can be equally devastating with password managers) regardless of the user not having admin rights.
Interesting! thanks
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.
It ludicrous that the relevant bits of this XML file are not protected by the master key.
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.
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.
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.
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.
This is _not_ modifying kdbx files. It is modifying the application config file (~/.config/KeePass/keepass.config.xml or your OS equivalent).
Oh I see. That is very different.
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?
We're probably better off mitigating away from usernames and passwords anyway and start getting everything on pub/private key pairs.
>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.
Such a trash response from a provider of software thats supposed to protect sensitive data.
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?
I don't think these two things are equivalent...
Uhh of course, this doesn't affect keepassXC right?
So why use Keepass over a plain text file?
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.