Activity for BK834
-
BK834 modified a comment on discussion Open Discussion
Breaking VeraCrypt: Obtaining and Extracting On-The-Fly Encryption Keys VeraCrypt Unencrypted Data in RAM Certainly better than no disk encryption at all. But VeraCrypt will still have the problem of needing it's keys sitting in RAM (although you can enable memory encryption and take a significant performance hit). If your concern is having your laptop stolen while it contains a hibernation memory dump, then FDE can certainly be a benefit. The better solution is to disable swap and hibernation and...
-
Breaking VeraCrypt: Obtaining and Extracting On-The-Fly Encryption Keys VeraCrypt Unencrypted Data in RAM Certainly better than no disk encryption at all. But VeraCrypt will still have the problem of needing it's keys sitting in RAM. You can enable memory encryption and take a significant performance hit. If your concern is having your laptop stolen while it contains a hibernation memory dump, then FDE can certainly be a benefit. The better solution is to disable swap and hibernation and don't have...
-
any machine that is compromised enough for it to be possible has already had everything stolen This is a bad security philosophy. Defense in Depth is a better security posture to adopt. There are many, many possible attack scenarios where the attacker can obtain the database file and a memory dump from a crash, hibernation or swap... without a full system compromise. As I wrote previously regarding February's security flaw, there are different levels of access, and you should not always assume "game...
-
Breaking VeraCrypt: Obtaining and Extracting On-The-Fly Encryption Keys VeraCrypt Unencrypted Data in RAM Certainly better than no disk encryption at all. But VeraCrypt will still have the problem of needing it's keys sitting in RAM. You can enable memory encryption and take a significant performance hit. If your concern is having your laptop stolen while it contains a hibernation memory dump, then FDE can certainly be a benefit. The better solution is to disable swap and hibernation and don't have...
-
Breaking VeraCrypt: Obtaining and Extracting On-The-Fly Encryption Keys VeraCrypt Unencrypted Data in RAM Certainly better than no disk encryption at all. But VeraCrypt will still have the problem of needing it's keys sitting in RAM. You can enable memory encryption and take a significant performance hit. If your concern is having your laptop stolen while it contains a hibernation memory dump, then FDE can certainly be a benefit. The better solution is to disable hibernation and don't have your user...
-
Criticality depends on your risk profile. A person in the US might not have the threats that say, a journalist in Russia would have. LE threat vectors are still a significant concern. People all around the world trust Keepass to secure passwords to things they don't want the state to know. When a suspect is raided, it happens when the computer is unlocked and disk encryption is meaningless. With default settings, it is general practice to keep the keepass database locked when not actively using it....
-
Criticality depends on your risk profile. A person in the US might not have the threats that say, a journalist in Russia would have. LE threat vectors are still a significant concern. People all around the world trust Keepass to secure passwords to things they don't want the state to know. When a suspect is raided, it happens when the computer is unlocked and disk encryption is meaningless. With default settings, it is general practice to keep the keepass database locked when not actively using it....
-
Prompt added in 2.53.1 https://keepass.info/news/n230109_2.53.html
-
some people won´t even know why their password is requested a 2nd time The prompt says why. You will always have someone who disagrees with the font size or color. But this software still requires that people read the prompts.
-
This would have to be something implemented as part of a new open standard. KDBX version 5 is still being worked out. And it can't be just keepass, it'll have to be agreed upon by the majority of opensource projects that all use the open KDBX standard format. What will probably make this a non-starter... is that this will NEED to break backwards compatibility to have any security benefit. Right now, the client program controls policy and execution. If you move that function to the database, yes,...
-
I would say that certainly at least 50% people will still be fooled. That is way exaggerated IMO. If that were actually true, it runs the risk of developers not wanting to fix anything, because half the user base cannot be trusted at all. If I were a dev on this project and half my users were this susceptible, I would quit. Can we consider that CVE-2023-24055 is resolved by the fix proposed? I vote for no as it does not reduce enough the risk in my opinion. CVE's are not subject to a vote. They are...
-
I see your point. The prompt to export, if run by a trigger, should be big and bold to accommodate all users. Give the user the information they need. It's still a stretch to call this, "no fix at all". @dreichl did what we asked, and it was a big win. Now, it's just a matter of optimizing the UX for all users. Even the users who aren't paying attention. But where will the developers draw the line?
-
Yubikey is a hardware device that adds another key of encryption to your database. Keepass2 has an old plugin that supports this and KeePassXC supports it natively. It still won't protect you from malware on the PC. The decryption has to occur somewhere, and there will always be point where the passwords are exposed to the malware. To truly limit the damage, you can make sure every service you have a password for, also has 2FA enabled so you can use your phone or other hardware device while authenticating....
-
The vulnerability that is being discussed, is that not even an attentive user could detect anything was wrong. After this fix, at least the responsibility has shifted back to the user, to at least pay attention when typing a master password. There is nothing that can be done for a PEBKAC.
-
https://onlykey.io/
-
https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/microsoft-defender-antivirus-compatibility?view=o365-worldwide#how-microsoft-defender-antivirus-affects-defender-for-endpoint-functionality Yes, if you want/need to run a 3rd party AV, then Defender will need to be disabled or run in Passive Mode. In which case, CFA doesn't work. I usually recommend that users don't use non-Microsoft AV. It's been a while since the time when Microsoft wasn't the preferred method to protect...
-
3) Do not share the KeePass executable. It can be used by an attacker to automatically dump your database in plaintext when you use it. The executable and it's config file are meant to be trusted. A database file is encrypted, so if someone gets access to it, they can't decrypt it. But if you expose your executable, they could replace it with something malicious that can export your database silently. Or worse, infect your host. Recent discussion and huge topic of concern this past week. https:/...
-
Yes, this was my recommendation from last week. Today, 2.53.1 is signed with a new digital signature with a cert from Feb 8 2023. So now all you have to do is revoke previous signatures in your Windows install.
-
It is a confusing help page. I think that cli option is just for opening databases that are not protected by any password (rare, but some only use yubikey or key file), so that option just won't expect a password. If you try it, it'll fail to open the database. There is no possible way to for the cli to decrypt a database by ignoring a set password. There's a clue that there are different options for setting a new password for an unlocked database in the db-edit section. --unset-password Removes...
-
I'd like to think we all contributed a bit.
-
If that is what you mean... then you are just wrong. That's not how security works. That's not how computers work. You're free to do whatever, use whatever, and call whatever you want "death". But it should have no bearing here.
-
Not realistic. I would not expect people to knowingly enter a master password for a completely different looking application.
-
Not realistic. I wouldn't not expect people to knowingly enter a master password for a completely different looking application.
-
You keep saying database. But you mean configuration xml file. They aren't the same. The keepass database is an open standard and has nothing to do with this. It's like saying you can never use PDF files because Adobe 9 had weaknesses. This vulnerability is solely in the KeePass2 application versions 2.53 and lower. It's the client software that has the issue, not the database file which is still secure.
-
Yes, this was my recommendation from last week. Today, 2.53.1 is signed with a new digital signature with a cert from Feb 8 2023. So now all you have to do is revoke previous signatures in you Windows install.
-
You keep saying database. But you mean configuration xml file. They aren't the same. The keepass database is an open standard and has nothing to do with this. It's like saying you can never use PDF files because Adobe 9 had weaknesses.
-
It is a confusing help page. I think that cli option is just for opening databases that are not protected by any password (rare, but some only use yubikey or key file), so that option just won't expect a password. If you try it, it'll fail to open the database. There is no possible way to for the cli to decrypt a database by ignoring a set password. There's a clue that there are different options for setting a new password for an unlocked database in the db-edit section. --unset-password <path> Removes...
-
It's finally fixed. But I doubt we'll see an explanation.
-
That is not possible. KeepassXC cannot use the configuration of Keepass2. The database file doesn't not handle Export functions, only the client program can do that. KeePassXC does not support Plugins and does not support Triggers, which means there is nothing that could export the database silently. If you use KeepassXC, and an attacker copies/replaces it with an old installation of Keepass2... and you are tricked into running that different application... it'll look very different, and you'll know...
-
That is not possible. KeepassXC cannot use the configuration of Keepass2. The database file doesn't not handle Export functions, only the client program can do that. KeePassXC does not support Plugins and does not support triggers, which means there is nothing that could export the database silently. If you use KeepassXC, and an attacker copies an old installation of Keepass2... and you are tricked into running that different application... it'll look very different, and you'll know you've been hacked....
-
See my previous post from last week. I was also worried about keepassxc-cli, which has an export feature that can run in the background. But it still requires the key to be typed into the command line. So not as bad as piggybacking on the main UI unlocking process. I tested it out using a powershell script. It would have to steal focus from the KeepassXC main GUI program, to the CLI terminal window. If the user is paying attention to the screen, they'll notice the keystrokes not going to where they...
-
Finally fixed. I might have stayed with this application if it was at least acknowledged sooner.
-
No contradition. Replacing KeepassXC with a completely different looking app like Keepass2,... has no chance of fooling me into entering my master password. This attack scenario boils down to phishing. Using built in functions, but still decrypting using the credentials that the user provides to a program unknowing that it triggers an export.
-
I'm really glad for the change. But unfortunately the reputation is damaged permanently. I'd still be worried about a shortcut changing to a downgraded copy. I hadn't looked at alternatives before this debacle. But now that I've seen KeePassXC, there's no going back.
-
Plugins are still a risk. Although as you said, not nearly as trivial as 'Export - No Key Repeat' https://keepassxc.org/docs/#faq-general-plugins It comes down to a difference in security philosophy. KeePass still makes big assumptions about the security posture and user. And thus allows extremely risky conditions to occur. KeePassXC takes a better approach IMO. Which is why they never allowed triggers or 3rd party plugins to begin with.
-
I've tried to think of a legitimate use for this "feature". It appears to be for automation, but a very niche case. It boggles the mind to think why the developer would make it part of the main program by default. KeepassXC-CLI has an export function that can be scripted, but it's a separate command-line program that cannot piggyback on the main GUI program. So it doesn't carry the same phishing risk as Keepass2.
-
Yet there are people like you who deny there is a vulnerability. So yes, people need to be shown. There needs to be accountability. Attacking whistleblowers is the same kind of attitude. You don't know what I am building, I haven't published yet. KeePwn is already out. If Keepass were so secure, there would be no need to be so scared of a couple of scripts.
-
The backwards compatibility issues is why I have little faith that @dreichl will do anything.
-
The whole reasons for PoCs of exploits, is to show people that it's not some hypothetical, impractical attack that could never happen to them. @dreichl had years to fix this and make it better. But he chose to pretend it isn't his vulnerability and redefine security best practices. I do bug bounties and pen testing. This is totally ethical. Hiding a vulnerability from the public by gaslighting users about security, now That is unethical.
-
There is no argument that any password manager is vulnerable on a compromised computer. Where is the method to compromise Windows? This discussion is NOT about a full system compromise with an attacker running code as SYSTEM. It's about a relatively basic level of intrusion with only file write access to a user's profile. See my previous post There are different levels of access. Read, write, and execute. The whole point of an encrypted database of passwords, as opposed to a plaintext file on the...
-
There is no argument that any password manager is vulnerable on a compromised computer. Where is the method to compromise Windows? This discussion is NOT about a full system compromise with an attacker running code as SYSTEM. It's about a relatively basic level of intrusion with only file write access to a user's profile. See my previous post There are different levels of access. Read, write, and execute. The whole point of an encrypted database of passwords, as opposed to a plaintext file on the...
-
Yes, it is true. You need to read the entire Security section here Please note that an enforced configuration file only applies to the KeePass program in the same directory. If the user runs another copy of KeePass without an enforced configuration file, this copy does not know the enforced configuration file that is stored elsewhere, i.e. no settings are enforced. Only the user shortcut used to open keepass.exe need be ovewritten to a new path. That is located in the user profile (desktop, start...
-
Yes, it is true. You need to read the entire Security section here Please note that an enforced configuration file only applies to the KeePass program in the same directory. If the user runs another copy of KeePass without an enforced configuration file, this copy does not know the enforced configuration file that is stored elsewhere, i.e. no settings are enforced. Only the user shortcut used to open keepass.exe need be ovewritten to a new path. That is located in the user profile (desktop, start...
-
Enforced Config is not really a solution. Even if an attacker has only file write permissions on a user's profile directory to change a config, they could also copy the entire keepass application directory from Program Files, to the user's profile directory, which will bypass the enforced config. It's just a few extra steps.
-
Can't phish a user if they are expecting to see the KeePassXC window, and you show them them a Keepass2 program. If the user isn't fooled, they won't enter their password.
-
Can't phish a user if they are expecting to see the KeePassXC window, and you show them them a Keepass2 program. If they user isn't fooled, they won't enter their password.
-
There are different levels of access. Read, write, and execute. The whole point of an encrypted database of passwords, as opposed to a plaintext file on the desktop... is that an attacker with Read access still cannot access your passwords. Most of the excuses for this particular security concern, revolve around this basic axiom: "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore". "... we are assuming that there is a spyware program running on the...
-
There are different levels of access. Read, write, and execute. The whole point of an encrypted database of passwords, as opposed to a plaintext file on the desktop... is that an attacker with Read access still cannot access your passwords. Most of the excuses for this particular security concern, revolve around this basic axiom: "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore". "... we are assuming that there is a spyware program running on the...
-
There are different levels of access. Read, write, and execute. The whole point of an encrypted database of passwords, as opposed to a plaintext file on the desktop... is that an attacker with Read access still cannot access your passwords. Most of the excuses for this particular security concern, revolve around this basic axiom: "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore". "... we are assuming that there is a spyware program running on the...
-
This is where application whitelisting can absolutely save us. Attackers are known to trojanize apps that users are using. A password manager app is the crown jewels and makes a tempting target. So admins have fought this threat by only allowing applications signed by a whitelist of certs, to run. Even just a warning instead of a full block, would be enough for a user to think twice about unlocking a database of passwords. But with Keepass, the "export silently" feature/backdoor... exists natively...
-
Switch to KeePassXC and have your admins add @dreichl's digital signature to the revocation list.
-
Trusting admins is a different threat level than trusting code run as a user. It is far more common for an attacker to first gain low level privileges. If they can run a simple script as the user, as I describe above, they can get the entire plaintext database. The scenario is that admins can be trusted, but regular users should not be trusted. In that case, if a new keepass version comes out (without the unnecessary feature of "export without re-key"), and is signed with a new cert. Admins can revoke...
-
Nice Python script. I built a powershell version that does the same. Based on this previous outline My version doesn't use C$ shares to auth to remote machines, but rather WinRM remote powershell. Also, it looks for shortcuts to the KeePass.exe file in the default places (Start Menu Programs, Taskbar, and the Desktop). Then copies the existing keepass directory to a writeable one, so it can bypass Enforced Config. I won't publish until later. Hopefully @dreichl will reconsider.
-
Requiring an attacker to get their own valid cert is definitely a good security control. It puts the responsibility onto Windows, the Domain Admins, and the User... and off @dreichl. Those of us with concerns about this kind of attack, could now use Windows built in tools to alert or block suspicious applications (like an old version of keepass) as a PUP.
-
Once the keypass executable is compromised, there is nothing anyone can do. Not a single program can guarantee security if the program itself is modified. That is not in anyone's threat model. You're absolutely correct. The program itself cannot be trusted to verify it's own integrity. But Windows has all this done already. Digital signatures for applications. Anyone with a high security risk model, should be doing this already. Enterprise admins have this in their threat model. The security control...
-
There are different levels of access. Read, write, and execute. For this attack, execute is not needed, since the user is tricked into code execution (like a typical phishing attack). Only write access needed, which is a much easier task for an attacker. The sad thing for Keepass, is that they include all the functionality needed to execute this malicious code built in. Their excuse seems to conflate and confuse about the access level needed. An attacker would need execute permissions to run keyloggers,...
-
There are different levels of access. Read, write, and execute. For this attack, execute is not needed, since the user is tricked into code execution (like a typical phishing attack). Only write access needed, which is a much easier task for an attacker. The sad thing for Keepass, is that they include all the functionality needed to execute this malicious code built in. Their excuse seems to conflate and confuse about the access level needed. An attacker would need execute permissions to run keyloggers,...
-
Once the keypass executable is compromised, there is nothing anyone can do. Not a single program can guarantee security if the program itself is modified. That is not in anyone's threat model. You're absolutely correct. The program itself cannot be trusted to verify it's own integrity. But Windows has all this done already. Digital signatures for applications. Anyone with a high security risk model, should be doing this already. Enterprise admins have this in their threat model. The security control...
-
This is where application whitelisting can absolutely save us. Attackers are known to trojanize apps that users are using. A password manager app is the crown jewels and makes a tempting target. So admins have fought this threat by only allowing applications signed by a whitelist of certs, to run. Even just a warning instead of a full block, would be enough for a user to think twice about unlocking a database of passwords. But with Keepass, the "export silently" feature/backdoor... exists natively...
-
I understand the sentiment. But password managers and handwritten notes are in two completely different worlds. I too advise retirees who don't have many online accounts, to use a notepad. But this is a very niche demographic. They don't use their phones for logging into anything. No 2FA. They have a Social Security account, a single bank, and maybe an email. Keepass was never meant for them. The rest of the modern world... needs portability to mobile phones, needs to store 2FA codes, browser auto-fill,...
-
Unfortunately its too risky to ever use Keepass again. If an attacker can alter your config file, they can just overwrite your version of Keepass to a vulnerable version. The only hope is to just start using a completely different looking client like KeepassXC. That way, if you are every attacked with this, you'll notice the old version of keepass.
-
Nice Python script. I built a powershell version that does the same. Based on this previous outline My version doesn't use C$ shares to auth to remote machines, but rather WinRM remote powershell. Also, it looks for shortcuts to the KeePass.exe file in the default places (Start Menu Programs, Taskbar, and the Desktop). Then copies the existing keepass directory to a writeable one, so it can bypass Enforced Config. I won't publish until later. Hopefully Dominik will reconsider.
-
Nice Python script. I built a powershell version that does the same. Based on this previous outline My version doesn't use C$ shares to auth to remote machines, but rather WinRM remote powershell. Also, it looks for shortcuts to the KeePass.exe file in the default places (Start Menu Programs, Taskbar, and the Desktop). Then copies the existing keepass directory to a writeable one, so it can bypass Enforced Config.
-
Spyware or PUPs can be caught by AV or EDR. That's a fight that Windows admins have to fight. But when you make the attack surface so wide and easy, that non-privileged code need only change a single config file, or also maybe a shortcut file too... that is not acceptable. Having this "Export - No repeat Key" feature can be considered a spyware backdoor. It does the attackers job for them. What people are asking is for a new version of KeePass without spyware built in. Nobody legitimately needs that...
-
But KeeShare is disabled by default and the real user must first set it up explicitly after unlocking with the key. I was also worried about keepassxc-cli, which has an export feature that can run in the background. But it still requires the key to be typed into the command line. So not as bad as piggybacking on the main UI unlocking process.
-
KeePassXC doesn't have this feature (Trigger on Open, Export silently without repeating the Key). However, they do have a CLI program that can basically do the exact same quiet export. It's a bit more difficult than someone just editing your config.xml to add a trigger automation. It would require writing a wrapper script in powershell that will launch the GUI KeePassXC but stealing focus to the terminal running the script. So when the user sees the GUI window, they don't know they are really typing...
-
KeePassXC doesn't have this feature (Trigger on Open, Export silently without repeating the Key). However, they do have a CLI program that can basically do the exact same quiet export. It's a bit more difficult than someone just editing your config.xml to add a trigger automation. It would require writing a wrapper script in powershell that will launch the GUI KeePassXC but stealing focus to the terminal running the script. So when the user sees the GUI window, they don't know they are really typing...
-
KeePassXC doesn't have this feature (Trigger on Open, Export silently without repeating the Key). However, they do have a CLI program that can basically do the exact same thing. It's a bit more difficult than someone just editing your config.xml to add a trigger automation. It would require writing a wrapper program that will launch the GUI KeePassXC but stealing focus to a terminal running a script. So when the user sees the GUI window, they don't know they are really typing into the script. It's...
-
Switch to KeePassXC and have your admins add Dominik's digital signature to the revocation list.
-
Not sure how many people understand that this keepass app is one of many. And is the only one with this vulnerability. Other apps have a different philosophy to security. Does KeePassXC support (KeePass2) plugins? No, KeePassXC does not support plugins at the moment and probably never will. KeePassXC already provides many of the features that need third-party plugins in KeePass2 out of the box, so for most things you don't even need plugins, nor should you ever want them. Plugins are inherently dangerous....
-
Yeah. Not sure if most people know this. Very different philosophy on security. Does KeePassXC support (KeePass2) plugins? No, KeePassXC does not support plugins at the moment and probably never will. KeePassXC already provides many of the features that need third-party plugins in KeePass2 out of the box, so for most things you don't even need plugins, nor should you ever want them. Plugins are inherently dangerous. Many KeePass2 plugins are barely maintained (if at all), some have known vulnerabilities...
-
you can only use what admins have installed on your computer. Exactly my point. If there were a version of keepass that did not have this easy to abuse feature, the admins can just install that safer version and block any other version as a PUP.
-
Trusting admins is a different threat level than trusting code run as a user. It is far more common for an attacker to first gain low level privileges. If they can run a simple script as the user, as I describe above, they can get the entire plaintext database. The scenario is that admins can be trusted, but regular users should not be trusted. In that case, if a new keepass version comes out (without the unnecessary feature of "export without re-key"), and is signed with a new cert. Admins can revoke...
-
Requiring an attacker to get their own valid cert is definitely a good security control. It puts the responsibility onto Windows, the Domain Admins, and the User... and off Dominik. Those of us with concerns about this kind of attack, could now use Windows built in tools to alert or block suspicious applications (like an old version of keepass) as a PUP.
-
I don't think that it is possible to put settings inside the database. The client binary could just ignore it once the database is decrypted. The only possibility would be to add an additional key required to decrypted the database, that is contingent on the integrity of the client app and configuration. But that would break all portability.
-
Well, there is KeePass the official client software, and there is keepass the standard format. There are other clients out there. It may be the end for this version. If someone starts using a different app, with a different look, they avoid this issue.
-
Requiring an attacker to get their own valid cert is definitely a good security control. It puts the responsibility onto Windows, the Domain Admins, and the User... and off Dominick. Those of us with concerns about this kind of attack, could now use Windows built in tools to alert or block suspicious applications (like an old version of keepass) as a PUP.
-
That's the threat scenario. If an attacker has write permissions on your user profile, they can swap the executable for one with the ability to export invisibly. I can see how Dominik doesn't want to bother with a half solution that won't work. The only way to really do what that feature request was asking, is to completely revoke the digital signatures of the existing versions with that "Export - No Key Repeat" function. That way Windows itself will warn the user if an attacker replaced the bin...
-
At least Print to File would prompt the user. Export without repeat Key, is totally invisible.
1