Menu

Security - Dumping Master Password from Memory, Even When Locked

vdohney
2023-05-01
1 day ago
1 2 > >> (Page 1 of 2)
  • vdohney

    vdohney - 2023-05-01

    Hello,

    First I'd like to thank Dominik and others for the great work they are doing on KeePass!

    I found a potential issue in the latest KeePass 2.X (default settings). Given a process memory dump, I am able to reconstruct the master password. It doesn't matter whether the workspace is locked or not, it works regardless. The memory source also isn't important - for example, it can be a pagefile (swap) or the hibernation file. No code execution is needed, just the memory alone.

    I haven't found a contact for responsible disclosure, so I am posting it here. Please let me know if I can post details here or send it somewhere else instead.

    Based on what I read on the website and this forum, it might not be considered a problem at all. However, this statement from the website would then be incorrect:

    "When locking the workspace, KeePass closes the database file and only remembers its path and certain view parameters.

    This provides maximum security: unlocking the workspace is as hard as opening the database file the normal way."

     
    ❤️
    1

    Last edit: vdohney 2023-05-01
  • Dominik Reichl

    Dominik Reichl - 2023-05-01

    You probably have displayed the master password (i.e. deactivated hiding using asterisks).

    For details, see
    https://keepass.info/help/base/security.html#secmemprot

    Best regards,
    Dominik

     
    • hotcryptos1

      hotcryptos1 - 4 days ago

      Is keepass1x affected?

       
      • Paul

        Paul - 3 days ago

        No.

        cheers, Paul

         
        👍
        1
  • vdohney

    vdohney - 2023-05-01

    Thanks for your quick response! No, that is not what I did. The password stays allways hidden.
    I take it that I can post here then.

    The problem is with SecureTextBoxEx. Because of the way it processes input, when the user types the password, there will be leftover strings. For example, when "Password" is typed, it will result in these leftover strings: •a, ••s, •••s, ••••w, •••••o, ••••••r, •••••••d

    It is surprisingly reliable, try it! POC here: https://github.com/vdohney/keepass-password-dumper

    I understand that this is likely time-consuming to fix, as it would probably require writing your own textbox instead of inheriting from Windows.Forms.TextBox.

     

    Last edit: vdohney 2023-05-02
    • P Shell

      P Shell - 3 days ago

      I'm on an all US English Windows 10 x64 22H2 system. Installed .NET v7.0.302
      Created a Projects folder, copied these files to the folder
      keepass_password_dumper.csproj
      Program.cs

      I also had had a c:\windows\memory.dmp file from two weeks ago. I copied that to the Projects folder. Then ran the following

      dotnet run MEMORY.DMP

      My password length might be right but the characters and layout are not even close
      Is the length of the password an issue? My password is 35 characters long.

      I also created a Keepass dump file with Task Manager and copied to the Projects folder and ran it that way too and it was not even close.

      dotnet run Keepass.DMP

      That one was only about 10 characters found

      Am I not running the program correctly or is there something else I should be doing to get the proper results?

       
      • vdohney

        vdohney - 3 days ago

        Hello, thaks for reporting the issue! I think we shouldn't clutter this thread with the PoC-related problems. Could you please create an issue here? https://github.com/vdohney/keepass-password-dumper/issues

         
  • Dominik Reichl

    Dominik Reichl - 2023-05-02

    Interesting, many thanks for reporting this issue!

    I have a few improvement ideas for it and will implement and experiment with them now. Details soon.

    Best regards,
    Dominik

     
    👍
    1
  • Dominik Reichl

    Dominik Reichl - 2023-05-07

    I've now implemented two enhancements:

    1. When running on Windows, KeePass now calls Windows API functions for getting/setting the text of the text box directly, in order to avoid the creation of managed strings. For most lengths, no "●...●?" fragments occur in the process memory anymore, but for a few lengths, there still is one (maybe Windows is occasionally allocating a new buffer for the text box content?).
    2. KeePass now creates some dummy fragments in the process memory (random number of fragments that contain a random character and have approximately the length of the current password). With this, it should be more difficult to determine the correct fragments.

    On Windows, both enhancements are used. With Mono on Linux/MacOS/etc., only the second enhancement is used.

    Here's the latest development snapshot for testing:
    https://keepass.info/filepool/KeePass_230507.zip

    Thanks and best regards,
    Dominik

     
  • vdohney

    vdohney - 2023-05-08

    Nice, that's a pretty creative fix! I've tested it and it seems to be doing the job, even the order in which the strings appear is useless now (the dummy strings can come both before and after the real character). I can no longer reproduce the attack.

    Thanks for fixing this, Dominik! Any estimate on when this is released?

     
  • Dominik Reichl

    Dominik Reichl - 2023-05-09

    Great, thanks for testing it!

    The enhancements will be included in the next KeePass release (2.54). Currently, I'm still working on a few other features (also related to security) and as soon as these are finished, I'm going to release it. There is no fixed date, but I'm confident that it'll be within the next two months.

    Thanks again and best regards,
    Dominik

     
    ❤️
    2
    • chris_uvic

      chris_uvic - 4 days ago

      There is no fixed date, but I'm confident that it'll be within the next two months.

      Given that there's starting to be press coverage of this problem, it might be a good idea to push out this fix quickly. Saying that a security fix will be released in the next month or two is not good PR, regardless of how serious it is.

       
  • Dan400Man

    Dan400Man - 4 days ago

    Since the next release is a few months out, is it your opinion that this is not an urgent issue? Does an attacker need physical access to the PC to carry out the attack? Either way, it does seem rather urgent. May I suggest a patch release 2.53.2 now to fix this issue?

     
  • vdohney

    vdohney - 4 days ago

    An attacker needs read access to your filesystem or your RAM. Realistically, if your computer is infected by malware that's running in the background, this doesn't make it much worse - for that you could already be attacked by e.g. KeeFarce etc. (and there's no protection against that without specialized HW).

    Unless you expect to be specifically targeted by someone sophisticated, I would keep calm. The issue here could be, say, someone stealing your computer and taking the HDD out. It's not eniterely unrealistic, after all that's what the police will try to do in a raid. You can find several companies developing special forensic software for these kinds of scenarios. But it's really not what most people should panic about. If you use full disk encryption with a strong password, it gets even more unlikely.

    This finding alone doesn't allow anyone to steal your passwords remotely over the internet.

     
    👍
    2
    • fritzophrenic

      fritzophrenic - 4 days ago

      I think the HDD is the most troublesome vector to consider. I'm not confident that the average consumer will be employing full-disk encryption, nor that they will securely destroy their HDD (or the data thereon) before disposing of an old computer. The fact that it works with the database locked is worse, that's perceived to be a "everything is safe, nothing sensitive is in memory" state. There was that issues a few years ago with several major password managers exposing decrypted passwords in memory after their database was locked that I recall KeePass was given some praise for, since it only exposed entries which had been recently used (and none when locked) while a lot of people got very upset over e.g. 1Password's implementation which didn't fully scub all traces of passwords from memory until the app exited. This seems similar.

       
      👍
      2
  • Kcnarf

    Kcnarf - 4 days ago

    hello all,
    what is the risk about keepass installed on smartphone?

     
    • Paul

      Paul - 4 days ago

      KeePass does not run on a phone. You will be using a 3rd party port and we have no control over that.

      As this issue is caused by the operating system, not KeePass, you would hope that your phone OS does not have the same issue.

      cheers, Paul

       
      • vdohney

        vdohney - 4 days ago

        As this issue is caused by the operating system

        It is not - you would have the same issue if you run the same code on Linux or macOS through Mono. But it is true that .NET isn't very helpful here...

        The proposed fix deals with this.

         
        • Kcnarf

          Kcnarf - 4 days ago

          is keepassdroid use same code as keepass ?
          otherwise instead of logical intrusion , for my personal usage of my computers I consider that another risk is if my remote laptop is stolen.
          instead of disk encryption, if pagefile.sys is deleted at each pc shutdown and hibernate funcion is not used risk is convered.
          what is your opinion about that ?

           
  • Phil G

    Phil G - 3 days ago

    if pagefile.sys is deleted at each pc shutdown and hibernate funcion is not used risk is convered.

    The pagefile won't be deleted if the power is disconnected, but you can and probably should enable pagefile encryption if this is a concern. This covers many other potential data leaks, known and unknown. Hibernation would still need to be disabled.

     
  • Paul

    Paul - 3 days ago

    if my remote laptop is stolen

    All laptops should use disk encryption, unless you really don't care about your stuff.
    Deleting the pagefile is much harder than using disk encryption and does not guarantee your data is safe.

    is keepassdroid use same code as keepass ?

    No, it is an Android app so the code and memory use will be different.

    cheers, Paul

     
    👍
    1
  • Dominik Reichl

    Dominik Reichl - 3 days ago

    To clarify, "within the next two months" was meant as an upper bound. The other features that I'm currently working on (which are also related to security and which I don't want to postpone) are almost finished; a realistic estimate for the KeePass 2.54 release probably is "in the beginning of June" (i.e. 2-3 weeks), but I cannot guarantee that.

    Best regards,
    Dominik

     
    👍
    2

    Last edit: Dominik Reichl 3 days ago
  • lasperber

    lasperber - 3 days ago

    Thanks for this discussion.

    Just to confirm again, that Keepass 1.xx is NOT vulnerable to this attack, and therefore not in need of any software fix/patch? The master password entry dialog is sufficiently different than that used with Keepass 2.xx that the exploited vulnerability doesn't exist?

    I notice that there is no momentary display of the "current last character" as each character of the master password is typed with Keepass 1.41 (which is what I use). So it's a different API used for this dialog than is used with Keepass 2.xx?

     
    • Paul

      Paul - 3 days ago

      V1 and V2 are different programming systems and have almost nothing in common.

      cheers, Paul

       
      • Nox Tageri

        Nox Tageri - 3 days ago

        Hi, what about the Linux version of KeePass2.XX?
        Is it also affected?

         
1 2 > >> (Page 1 of 2)

Log in to post a comment.