It’s been talked much about lately since it went viral after a security researcher posted about the findings but it’s been known since last year.
Is the Kee extension for Chrome or Firefox vulnerable to this?
Kee is not vulnerable to the specific one-click vulnerability recently described at https://marektoth.com/blog/dom-based-extension-clickjacking/ but it is of course vulnerable to clickjacking in some form or another, as is every browser extension that has to insert UI into the host page. One can always find a novel way to manipulate web technologies into a clickjacking vulnerability and I unfortunately do not foresee that situation changing any time soon.
Is it worth panicking over though? Not in my opinion. It’s not a new risk, although perhaps the specific techniques being discussed recently are relatively new to public knowledge. I expect such techniques will remain possible for years to come and that if directly addressed, similar variants will prove fruitful for any attacker that chooses clickjacking as part of their attack toolkit.
Marek Tóth has clearly spent a lot of time researching in this area and absolutely raises some important concerns that we should all pay more attention to. I haven’t had time to dig into the details of every statement in their recent report but can see that there are definitely things that most of us can do to further our defence against these (or at least similar) attacks.
I have outlined some information about the topic below and made a number of points relating to the issue but unfortunately don’t have time to fully construct this into a perfect and fully researched post so please take it as a starting point, feel free to continue your own research and forgive the inevitable technical jargon and acronyms.
Vulnerable data types
- Only login credentials
- TOTP is not yet autofilled
- Credit cards and other personal data are not supported
- PassKeys are also not supported
Vulnerability prerequisite
A compromise to the domain on which you hold credentials for (including its subdomains).
Also note that examples of user content subdomains may be misleading since such subdomains should always be considered part of a separate TLD and thus isolated from main domains by our use of the PSL - this may not always be the case, especially for newly launched user content areas on existing TLDs so it never hurts to have additional layers of protection but the impact may not be as widespread as first seems.
Potential concept invalidation
(with respect to a password manager like Kee, not necessarily for broader cross-domain data injecting extensions like credit card fillers, etc.)
The need for a vulnerability on the targeted domain raises the question that if this vulnerability exists, why is targeting a possibly installed browser extension likely to be more successful than just targeting the login form or other processes that will reveal the credentials of any user on the site, not just those using a password manager.
I’ve not fully explored all the possibilities here but in my experience this is the sort of thing that ultimately ends up being an overly complicated exploit method that would be rarely utilised when far easier and more lucrative approaches could be focused upon by any attacker with the necessary domain vulnerability in their hands.
Current mitigations
- Login credentials are not automatically displayed on the screen so any exploit is likely to require at least a couple of clicks.
- We attach our inline password list via a closed shadow root and apply various CSS !important tags to avoid many (inevitably not all) potential click-jacking techniques.
Future mitigations
Browser developers
I find it very frustrating that browsers have been so slow to adopt WebExtensions APIs that allow extension developers to defend against this ancient threat.
Defence against user content hosting subdomain (and other) vulnerabilities can be enhanced if extension developers are able to adopt the PSL proposal being actively considered in https://github.com/w3c/webextensions/pull/676
https://bugzilla.mozilla.org/show_bug.cgi?id=1364404 and https://bugzilla.mozilla.org/show_bug.cgi?id=1340930 both discuss a similar concept that allows extensions developers to isolate critical information in overlays that can’t be clickjacked by the host page - the only reason the requests aren’t even older is that there was an alternative way to write extensions in Firefox a long time ago.
Similarly, extensions used to be able to open their own popup displaying their UI when this was in the best interests of UX or security but Chrome and WebExtensions removed that option. It seems like we are closer to that being addressed (Ensure consistency of `action.openPopup` API across browsers · Issue #160 · w3c/webextensions · GitHub / 1799344 - Enable browserAction.openPopup without user interaction on all channels (Remove `extensions.openPopupWithoutUserGesture.enabled` preference)) than the secure overlay solution but it isn’t solving exactly the same problem so still either security or UX will suffer.
Browser developers have increasingly adopted an approach to extensions that “they can cause harm” so “let’s remove the tools they can use to do harm” rather than “let’s give them the tools they need to defend against harm themselves”. It’s the principle that they believe they are best suited to protect the users of their browsers from all possible harms. I’m not judging here; Maybe they are, maybe not, and maybe the answer varies across browser developers, but the result is that compared to previous decades, browser extension developers have far more limited options to address the sort of broad web technology abuse and social engineering attacks that remain pervasive.
Clickjacking via many methods has always, and I suspect always will be, a risk, but extension developers have fewer tools at their disposal now than those that are required to really address them. Maybe the alternative risks are even greater, and maybe the browser companies are therefore right to restrict the functionality they currently choose to restrict, or maybe there are other influences beyond security and privacy that guide their choices. Again, I suspect the reasons vary from browser to browser and I have no doubt that in every browser organisation there are at least some people that deeply care about these things. I can only hope that yet another example of this sort of vulnerability will spur the browser industry into action.
Extension developers
We need to take another look into whether it is worthwhile for Kee to attempt some defensive action when in the context of a compromised host page (e.g. inspecting opacity levels or using other visibility testing APIs and aborting the display of the list of password matches if we know something is obscuring the users view of our UI). We could also add an option to completely disable the inline Kee icon/panel and require all interaction to be through the main browser popup - that is likely to result in significant limitations on how effectively we can fill in forms though.
I am wary of suggestions and reactions that simply put the onus on individual extension / password manager developers to try to detect when a compromise is occurring - this is most likely going to become just another small step in a lengthy arms race, and thus divert attention and time from the more comprehensive fixes that browser manufacturers should be developing.
End users
How much do they want to sacrifice convenience for security? e.g. change default matching behaviour to exact host rather than domain?
Most users still choose the convenience of something like autofill over manual filling, let alone copy/paste or drag/drop into sign-in fields. That’s a greater risk than the described clickjacking vulnerabilities.
Since Kee links to an existing password database rather than incorporating it into the browser extension like so many password managers, there’s probably not much point in even using the extension if you don’t want to have at least manual form filling. That is certainly one strong argument I have heard against the entire concept of Kee for many decades and I am sure that some of those people are currently enjoying one of their fairly regular “I told you so” moments!
I’ve always recommended against storing TOTPs within a password manager. I’ve been fighting a loosing battle against the convenience that users understandably demand, and I doubt that battle is going to turn just because another security vulnerability highlights the risky nature of combining your two factors in one place. Although Kee is not vulnerable to this at the moment, I anticipate adding some autofill functionality for TOTP in the future since it’s seen as an important feature by so many users. Like other convenience methods, I will probably enable the feature by default but perhaps this will present a good opportunity to present a little user education about the sorts of risks the option might open up for them.
Thank you so much for clearing it up!