9 ms·

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

• moritonal 4y 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.
  • jonathanstrange 4y 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.
    • adlpz 4y 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?
      • Ensorceled 4y ago
        The point is that the file itself should be encrypted or at least signed with the master password.
        • detaro 4y ago
          For a general configuration file, there is not "the" master password, since it is independent of password database files.
        • adlpz 4y ago
          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.
    • _puk 4y 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?
      • coding123 4y ago
        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?
        • vgalin 4y ago
          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.
          • usrusr 4y ago
            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.
            • jonathanstrange 4y ago
              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.
      • gnud 4y ago
        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".
    • tinus_hn 4y 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.
      • notRobot 4y ago
        This is correct.
    • LeifCarrotson 4y 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/#b3cb 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.
      • detaro 4y ago
        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)
    • H4ZB7 4y 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_iain 4y 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.
    • vgalin 4y 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?
      • that_guy_iain 4y ago
        In most cases they wouldn't be able to do that. Because there are security measures to prevent that.
        • blincoln 4y ago
          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?
          • that_guy_iain 4y ago
            Anti-virus systems...
  • usrusr 4y 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.
    • moritonal 4y 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?
      • usrusr 4y ago
        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.
• wheybags 4y 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_ 4y 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.
    • moritonal 4y 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."
    • wheybags 4y 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/memoryapi/nf-memoryapi-readprocessmemory https://learn.microsoft.com/en-us/windows/win32/api/memoryap...
    • vgalin 4y 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 https://keepass.info/help/base/security.html#secmemprot
• Run_DOS_Run 4y 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 4y 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-24059 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.
    • usrusr 4y 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.
      • paulryanrogers 4y ago
        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.
• mik1998 4y 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".
  • usrusr 4y ago
    It's not uncommon at all to see configuration less protected than executables.
  • Ensorceled 4y 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.
• newaccount74 4y 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 4y 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?
  • vgalin 4y 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).
    • Ambolia 4y 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.
      • vgalin 4y ago
        Then it would be an attack vector of course, but whether it is a vulnerability of the password manager itself would be debatable.
        • Ambolia 4y ago
          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 https://news.ycombinator.com/item?id=34545504
      • marcosdumay 4y ago
        The passwords store is not the same as the configuration file. It's common to upload the password store, not the configuration.
• Ambolia 4y 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 https://keepassxc.org
  • TruthWillHurt 4y ago
    me too
  • Macha 4y 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 4y 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.
  • vgalin 4y 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?
    • Ensorceled 4y ago
      I don't think these two things are equivalent...
• Ensorceled 4y 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.
  • blincoln 4y 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 4y 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.
  • aunlead 4y 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.
• lukeschlather 4y 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.
  • Macha 4y ago
    This is _not_ modifying kdbx files. It is modifying the application config file (~/.config/KeePass/keepass.config.xml or your OS equivalent).
    • lukeschlather 4y ago
      Oh I see. That is very different.
• billpg 4y ago
  If I have write access to the machine's files, I could install a key-logger.
  • newaccount74 4y ago
    I don't think Windows lets you do that without requiring you to authenticate.
    • billpg 4y ago
      I've installed and run applications that run out of my user folders (not Program Files) without having to UAC.
      • didntreadarticl 4y ago
        Doubt you could do it with keylogger though
        • blincoln 4y ago
          I was curious, so I threw the code from https://hackmag.com/coding/diy-keylogger/ 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.
          • didntreadarticl 4y ago
            Interesting! thanks
• didntreadarticl 4y ago
  So why use Keepass over a plain text file?
• syeare 4y ago
  Uhh of course, this doesn't affect keepassXC right?
• didntreadarticl 4y 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?
• H4ZB7 4y 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.
• coding123 4y ago
  We're probably better off mitigating away from usernames and passwords anyway and start getting everything on pub/private key pairs.