In the midst of LastPass’s repeated barrage of breaches, a pretty serious vulnerability was found in another common password manager — KeePass. This slid under most of our radars, including mine.
Professor Cyber Naught of the Mastodons suggested I comment on the situation. I’m so glad he brought this up, because it highlights several critical issues network admins and security teams are facing with secrets management.
Here’s my hot take on the situation.
A Bit About KeePass
If you’re not familiar with KeePass, it’s a free, open source password manager that’s not cloud hosted. Originally developed in 2003, the application, its management, configuration, and the key database are hosted locally. In this case “locally” may mean on any given on-prem system, server, or removable media. But, it’s not a cloud-hosted platform. This is going to be very relevant in a moment.
KeePass is wildly popular for individuals, small organizations, and teams looking to secure certain ‘keys to the kingdom’ without relying on a software-as-a-service application. Some make the decision to host locally for cost purposes, avoiding subscription fees, whereas others may make the choice for security purposes. LastPass of course bringing their theoretical nightmares of a SaaS breach to life, especially with today’s announcement of yet another breach through a DevOps engineer’s personal computer.
Like many others (probably many of you), I’ve used KeePass on and off for well over a decade.
The Vulnerability
The short version is that researchers uncovered a vulnerability where a malicious user can export all passwords in cleartext. The act requires a simple modification to a local config file. Once set, the next time an authorized user logs in, KeePass will silently generate the cleartext password file, the user never the wiser. Just in case that wasn’t clear — your passwords can all get output to cleartext without you knowing. No bueno.
Developer Denies Vulnerability
There’s been well-deserved outrage from the user population and a general response of “what the ****” from the security community. Yet, much to our collective surprise, the developer of KeePass has disputed the vulnerability, arguing that if a malicious user has write permission access to a system, there’s no way for anything to be secure, including KeePass. The developer was (until just days ago) also refusing to make changes to the application to operate in a more secure default mode, which is even more disappointing.
As a security architect living in a world of real zero trust, I have to call bull poopie on this counter-point. We have tools and architectures to secure against these things, they’re just not built into that application.
“If that’s the case, we may just as well use a password-protected Excel sheet,” was the backlash, and admittedly my first thought.
And I won’t even bother continuing this train of thought, because at the end, after much consideration, I’ve arrived at the same conclusion — it’s no better than a password-protected Office file. KeePass does at least offer a platform to better organize and track passwords than a text file or Excel sheet, but with its current vulnerability it’s hardly more secure. Encryption, no matter the strength, doesn’t help if a malicious user can simply edit text in a config file and dump the contents to cleartext.
And although this is being discussed in terms of a malicious “attacker” which puts the image in our heads of a bad actor physically on the network, we should keep in mind that scraping unprotected credentials is a fan fave of malware. We’ve seen off-the-shelf scripts crawling and gathering everything from unsecured Outlook notes to FileZilla FTP credentials, and more. I imagine KeePass exploits will be no different.
If the malware can bypass endpoint security protection, compromise or rewrite the config file, and go undetected, then this is certainly going to be a vulnerability that will find its way to the top of the headlines in the coming months.
For anyone using KeePass, the developer has issued statements and workarounds to increase security and prevent this exploit. Frankly, since you asked my opinion, Professor, I think it’s all rubbish! I suppose it’s better than nothing, especially if you’re a one-man-shop with only a single KeePass install to worry about.
Update: The changelog shows that version 2.53.1 of KeePass was released to patch the vulnerability by forcing the user to enter the master key or password again. While I’m very happy to see it, my personal opinion is that it was too little, too late.
Users of KeePass should update to the latest version and continue monitoring changelogs and CVEs.
The KeePass site (in my humble opinion) does a terrible job of sharing the security issues with dates and versions, which are very relevant. For example, you’ll notice on the Security Issues page no date, few details, and no reference to the patched version. I’m making a huge assumption here, but the CVE for this issue isn’t even referenced, presumably since the developer has disputed it. Similarly on the downloads page, dates are not included, so it’s nearly impossible to determine the current situation and in fact I had to search online and found information in this external post.
As security professionals, we rely on CVEs throughout our vulnerability management program. Organizations need to be able to scan, enumerate, and then address the found vulnerabilities. Not having that information on the site, and not including critical date and patch information would be enough for most security pros to rethink whether the application is allowed. And, yes, I fully acknowledge there’s a large gap between an organization with a mature vulnerability management program and Sally’s Tech Shop with five employees. But either way, whether automated or manual, the users should be able to easily find this information on the product site.
The Real Problem and The Real Remedy
Instead, I’m going straight to the heart of the issue to address the real problem — the architecture.
Earlier I noted that KeePass is a local solution, lacking any central management. Each user that accesses a KeePass key database file does so with a locally installed instance of the KeePass application. Securing the product by following their recommendations only impacts (secures) the one locally installed instance. And only in that directory and file. If the user installs another instance in another folder or re-installs the app for any reason, that security work is undone. If KeePass exists on another device, that security setting does not apply.
So the real crux of the matter is that we have a non-enterprise, not centrally managed, un-secured password manager that (from a risk perspective) is the equivalent of various administrators having credentials saved locally.
It’s every CISO’s worst nightmare, but it’s a very common practice, to allow administrators to store credentials locally. Let’s be real — we all do it. And, in fact, this is similar to what LastPass suffered from in its latest breach. If you haven’t seen that update from February 28, 2023, I highly recommend a quick read after this post.
CISO’s Answered “What’s Worse?”
This conversation is well-timed. About a week ago, I was on a CISO panel playing the game of “what’s worse?”. We were presented with scenario A versus B, and had to pick what was worse, and then explain why.
One involved password managers:
- Scenario A: You’re using a password manager that experiences a breach that may have exposed an encrypted copy of your password vault.
- Scenario B: You don’t use a password manager and you manage passwords the “old fashioned way” (with sticky notes under your keyboard).
While we (the panel) diverged on most topics in that session, I think we were unanimous in this one — that scenario B was worse than A. The justification is that, at least with scenario A, you have these advantages:
- You know what sites and credentials were impacted
- You know which email addresses were impacted
- You can centrally view and track the credential assets
- You can manage a response to the incident methodically
- You can verify and validate password changes
Conversely, in scenario B, you have no clue which users have access to what assets; no knowledge of who else may have access to those passwords; and you suffer from a fundamental blindless to the overall posture of the passwords.
Visibility is king in security. Sometimes what you have visibility into is a breach, but in scenario A, at least you know and you’re armed with the tools to respond.
On Free Open Source
We love free open source tools, and we greatly value the developers who do the thankless work of building and sharing those with the world.
There have been several requests for feature changes to KeePass, to remove the vulnerability by eliminating the feature, or (my favorite) requiring the master password to be entered again. The developer has argued he feels this is not necessary and, at least at time of writing, has no intentions of making changes to secure the product. Update: The developer has released patch 2.53.1 which enforces re-entry of the master key or password to execute the export.
At the end of the day, open source projects are a labor of love, and these brave developers put themselves and their work out there at no cost for the benefit of others. Donations, I imagine, may cover some of the coffee habits, but little else. The developer is under no obligation to update the product, and I want to acknowledge that and remain thankful that (albeit delayed) the update was made.
Summary
An easy resolution to this specific problem would have been to make any one of the many suggested changes to the application, much sooner. While that will triage today’s bleeding, it won’t address the underlying architecture, which is too distributed to be managed according to basic enterprise needs, and a far cry from today’s expectations for product security, and tomorrow’s strategy for zero trust.
Remember, sometimes you get what you pay for, and storing business critical credentials in a tool from 2003 with no protection mechanisms may (or may not) be the best choice.
So, what do YOU think? Comment below!
Thanks for listening! Errr… reading, and I look forward to more of your questions and #askjjx topics!
Join the Conversation!
Remember, you can ask me (almost) anything! Each month I’ll be responding to a reader’s question. If I don’t know the answer, I’ll either make up something incredibly amusing or I’ll phone a friend.
Submit your questions in any of these ways:
- My blog contact form https://securityuncorked.com/contact/
- Twitter @jjx with hashtag #AskJJX
- Mastodon @[email protected] and #AskJJX
- Packet Pushers follow-up form https://packetpushers.net/fu/
See more ways to interact and get ideas for topics at our intro blog.
