Hot Take Researcher Exposes Zero-Day Clickjacking Vulnerabilities in Major Password Managers

[Trident]

If the webform itself is malicious and/or there is clipboard hijacking, it does not matter. Enter the credentials manually/copy-pasta and that goose gets deep fried.

What @Andy Ful was talking about is useful against the cases where malware is running on the system.

Yes, fragmenting passwords (partially auto-fill, partially keyboard will help).

But what was initially discussed here is malicious site with a script. As soon as you debounce from the field (or potentially every few milliseconds) the script takes what is in the form and sends to the attackers (amongst other things).

How the information will end up on the form is not important @Parkinsond

 

[ForgottenSeer 114717]

How the information will end up on the form is not important @Parkinsond

 

[Parkinsond]

What @Andy Ful was talking about is useful against the cases where malware is running on the system.

Yes, fragmenting passwords (partially auto-fill, partially keyboard will help).

But what was initially discussed here is malicious site with a script. As soon as you debounce from the field (or potentially every few milliseconds) the script takes what is in the form and sends to the attackers (amongst other things).

How the information will end up on the form is not important @Parkinsond

so clickjacking is not detectable, not stoppable, and not even bypassable

 

[Trident]

so clickjacking is not detectable, not stoppable, and not even bypassable

You can not do anything. There are several factors which may play a keyrole, keyword is may.

A legitimate site should employ various security mechanisms and scans. Even if compromised, a reputable site is expected to get rid of malicious scripts quickly.
In contrast, some minor store that sells woollen socks could remain compromised for months.

Your security solution may kick in—either real time analysis on your device may detect the script, or the AV vendor, when scanning the site on their end (which they do periodically, with heavier analysis not suitable for your device) could detect the malicious script and change the rating to “malicious”.

Other than that, there is nothing on your end that you can do.

It is vey important to take measures as website owner to prevent XSS and domain takeover (unescaping content if react is involved, self-hosting scripts or using integrity checks, sanitising input, protecting your email that you use to login to the domain properly and so on). In addition, there are services that constantly scan the site.

 

[Andy Ful]

You can not do anything. There are several factors which may play a keyrole, keyword is may.

A legitimate site should employ various security mechanisms and scans. Even if compromised, a reputable site is expected to get rid of malicious scripts quickly.
In contrast, some minor store that sells woollen socks could remain compromised for months.

Your security solution may kick in—either real time analysis on your device may detect the script, or the AV vendor, when scanning the site on their end (which they do periodically, with heavier analysis not suitable for your device) could detect the malicious script and change the rating to “malicious”.

Other than that, there is nothing on your end that you can do.

One cannot stop all clickjacking methods, but some of them can be stopped on the user end (like methods in the OP).

 

[ForgottenSeer 123960]

Users are not helpless against clickjacking. The most effective defense is a combination of good habits and smart tool usage.

First, always be vigilant and aware of what you are clicking on. If a website seems odd, confusing, or asks you to do something unexpected, it's a good idea to close the tab and leave.

Use a modern web browser that is kept up-to-date with the latest security patches, as these browsers are designed to recognize and enforce security rules put in place by legitimate websites.

To add another layer of protection, consider installing a reputable ad-blocker or security-focused browser extension like uBlock Origin. While these tools won't specifically target clickjacking, they can block many of the scripts and malicious elements used to set up these kinds of attacks.

For users seeking the highest level of security, an extension like NoScript can be an excellent choice. NoScript works by blocking all scripts on a website by default, which is highly effective against the JavaScript used in clickjacking attacks.

The trade-off is that it may "break" certain websites until you manually allow their scripts to run. In short, your best defense is a combination of personal caution and using the right, up-to-date software.

 

[Parkinsond]

For users seeking the highest level of security, an extension like NoScript can be an excellent choice. NoScript works by blocking all scripts on a website by default, which is highly effective against the JavaScript used in clickjacking attacks

Yes, it is, but blocking scripts will leave the website functionless, with no possibility to log in.

 

[Trident]

I’m confused though what we are talking about here… what was discussed in the post was based on XSS vulnerabilities or domain takeover…

A malicious script was running on the page, it copied the dimensions of the password manager prompt, covered the prompt with a fake one and the password was filled on a malicious form.

The malicious form as well, is legitimate form bellow, malicious one on top. User inevitably and without knowing at all places information on the malicious form—attackers create event listeners/time-based events to get the input submitted.

This is the attack described on the original post, it is nothing new and innovative, the only thing is instead of skimming payment details, which was the golden standard, the prompt gets the details from the password manager.

Updating the browser will not help you - the up-to-date browser will still run the malicious script.

Not using password mabager will not help you - one way or another, the user needs the compromised website—they will put the credentials in.

NoScript is not gonna help you - the user will see that the site doesn’t work and will enable the scripts. Attackers can lure you with fake prompts too.

XSS and domain takeover prevention responsibilities are in the hands of the web owners.
The user can only enable script scanning and hope for the best.

 

[Andy Ful]

Users are not helpless against clickjacking. The most effective defense is a combination of good habits and smart tool usage.

First, always be vigilant and aware of what you are clicking on. If a website seems odd, confusing, or asks you to do something unexpected, it's a good idea to close the tab and leave.
(...)
For users seeking the highest level of security, an extension like NoScript can be an excellent choice. NoScript works by blocking all scripts on a website by default, which is highly effective against the JavaScript used in clickjacking attacks.

Unfortunately, many (average) users cannot use those precautions.

 

[Parkinsond]

One cannot stop all clickjacking methods, but some of them can be stopped on the user end (like methods in the OP).

Authors suggest two mitigations:

• Set only exact URL match for autofill credentials
• On click site access

1. The compromised website is legitimate, so URL will match.
2. On click will not make a difference; even automatic fill or even manual fill (as in Keepassxc without extension) will not keep credentials entered from waiting clickjacking script.

 

[Andy Ful]

1. The compromised website is legitimate, so URL will match.
2. On click will not make a difference; even automatic fill or even manual fill (as in Keepassxc without extension) will not keep credentials entered from waiting clickjacking script.

Those suggestions will work when the subdomain is compromised.
Autofilling a partial password will work without those suggestions.

 

[ForgottenSeer 123960]

Yes, it is, but blocking scripts will leave the website functionless, with no possibility to log in.

Learning to use a security tool like NoScript effectively isn't about simply turning it on, it requires understanding its options to strike a balance between security and website functionality. The key is its whitelisting feature, which gives you granular control over what scripts run on your browser.

Start by Identifing the Scripts.

The pop-up menu will list every domain from which the current website is trying to load scripts.

You will typically see two types of domains.

The "top-level" domain: This is the main website you are visiting (e.g., name of bank ).

Third-party domains.

These are scripts loaded from other sources, such as analytics services (google-analytics.com), content delivery networks (CDNs) (cloudflare.com), or social media widgets (facebook.com).

Next learn The "Allow" Options.

Next to each domain, you'll see options to control its behavior.

The most important ones are "Temporarily Allow": This is your primary tool for testing. Clicking this will allow the scripts for that domain, but only for your current browsing session. When you close your browser or the specific tab, the setting will be reset.

"Trust" or "Permanently Allow", Once you've determined a website is safe and you want it to always work, you click this. This adds the domain to your permanent whitelist. It will remember your choice, and the website will function normally on all future visits.

Let's use an example of a secure banking website that requires scripts to log in.

Initial Visit: You go to name of bank . NoScript blocks everything. The login button is gone, and the page looks broken.

First Whitelist Step: You click the NoScript icon. The list shows mybank.com and maybe a few others like a CDN.

"Temporarily Allow" the Main Domain: You click "Temporarily Allow" next to mybank.com. The page will reload. The login fields and buttons might now appear, but a new list of third-party domains might show up.

Identify Critical Scripts, If the login button still doesn't work, you look at the remaining blocked domains. It might be a script from mybank.com's image or resource domain.

You can temporarily allow those one by one, reloading the page each time to see if the functionality returns.

Final "Trust" Step, once the website is fully functional and you can log in securely, you return to the NoScript menu.

Now, instead of "Temporarily Allow," you select "Trust" for the necessary domains. This makes the setting permanent.

 

[ForgottenSeer 123960]

Unfortunately, many (average) users cannot use those precautions.

Regardless of technical skill, every user must develop strong security habits. This is the most powerful layer of defense. Always be vigilant about what they are clicking on. If a website looks odd, confusing, or demands unexpected actions, their safest bet is to close the tab and leave. They can also significantly improve their security by simply keeping their operating system and web browser (like Chrome, Firefox, or Edge) up-to-date, as these platforms have robust, built-in security features to protect them.

 

[Trident]

But the problem with XSS is that usually, some poorly protected CDN hosting a script necessary for the website functionality could be compromised…
Not sure how users will deal with the CDNs…

The website will not look odd… the only thing added to the website is one invisible form…
There is nothing unusual.

 

[ForgottenSeer 123960]

But the problem with XSS is that usually, some poorly protected CDN hosting a script necessary for the website functionality could be compromised…
Not sure how users will deal with the CDNs…

The website will not look odd… the only thing added to the website is one invisible form…
There is nothing unusual.

The main burden of preventing this lies with the website owner. They should use a Content Security Policy (CSP) with a Subresource Integrity (SRI) hash. SRI is a security feature that allows browsers to verify that a CDN-hosted script hasn't been tampered with. If the hash of the script doesn't match the one the website owner provided, the browser will refuse to execute it. This is the primary defense against a compromised CDN.

Modern web browsers are crucial here. They are the ones that enforce the security policies (like CSP and SRI) that developers have put in place. By keeping your browser up-to-date, you ensure it has the latest security features to protect you.

This is also where an advanced tool like NoScript would be useful. By blocking all scripts by default, it would prevent a malicious script from a compromised CDN from running unless the user explicitly whitelisted it, which is an unlikely scenario. However, as we've discussed, this is a very high-friction solution not suitable for most users.

 

[Trident]

OK, I just read the article again.

Very complicated explanations for the following (I had to read 3-4 times):

User will NOT go on compromised legitimate site. They will go on a malicious one.
E.g. Lloyds bank could Llloyds.com (very vague example). How users will go onto that website, perhaps phishing or SEO poisoning, or hoping that typo will occur.

The malicious website loads the real one as an iframe. The iframe opacity will be set to 0. Border will be removed and size will be set to 100%. The user will not see the real site, it is just a bait for the password manager to find the credentials.

The password manager sees the real site (iframe) which is invisible to the user and chimes in “do you wanna fill the credentials”. That’s because even though it is made transparent, any clicks go on the real site (iframe).

Attacker place fake prompt on top of the real one (accept cookies and so on).

The password manager fills the credentials on the real site (the invisible iframe).

Same Origin Policy prevents malicious site JS from reading the content that was filled in the iframe (real site). Because it is 2 different sources.

A vulnerability in the password manager itself is used to break the SOP and actually, the content from the real site (iframe) is being accessed by the malicious site, which should’t happen.

This is very different from XSS/Domain takeover.

In this case, manually typing credentials will still keep them safe—it is the password manager that is the problem.

 

[piquiteco]

In this case, manually typing credentials will still keep them safe—it is the password manager that is the problem.

Okay, I understand. But won't a script blocker like NoScript protect you against this type of attack? Like @Divergent said?

 

[Trident]

Okay, I understand. But won't a script blocker like NoScript protect you against this type of attack? Like @Divergent said?

If you do not allow the script, the script will not execute. If it does not execute, nothing that the attacker wants to achieve will happen, their magic is all in the script.

But if you choose “temporary allow”, thinking this is Lloyds Bank from my example, NoScript is out of the game, the script will execute…

 

[piquiteco]

But if you choose “temporary allow”, thinking this is Lloyds Bank from my example, NoScript is out of the game, the script will execute…

It's complicated, isn't it? Since you won't be able to tell whether a script is malicious or not, you end up allowing it so as not to lose the functionality of the website, and in the end the script ends up being executed, so it's difficult to identify this type of attack. I think it's better to go back to the old way, like copying and pasting login credentials. The clipboard will also be exposed if it is not cleaned within a certain time.

 

[simmerskool]

You can not do anything.... there is nothing on your end that you can do.

is NoScript extension any help?

EDIT seeing some of the posts about NoScript after the fact, MT jumped me ahead in this thread for some reason missing earlier posts...