1655240 - homograph attack when some behavior are met.

Status: RESOLVED DUPLICATE of bug 1332714

(Firefox :: Address Bar, task)

Description

[Dan Fonte]

Attachment: poc.PNG

hi, i think it would be best to report this anyway.

There is a homograph attack in the latest update of Firefox
Version: Mozilla FIrefox 78.0.2 (64-bit)

This is due to lack of character blacklisting i guess.. the latest IDN protection blacklists only the separators such as "/", "." and invisible characters that can be use to spoof urls and by removing the whitelisted .com .net..

However there still that exists that can only be abuse when some conditions are met.
by simply abusing the whitelisted 'WWW' into IDN unicode encoding like www.*.site.com can lead into a homograph attack..

for example: https://ԝԝԝ.google.com/
https://ԝԝԝ.google.com/ = is an internationalized version of the real https://www.google.com and firefox would display it in its Unicode version rather the punycode one which the same behavior does not exist on the counterpart browsers such as Chrome, Brave, and more.

if attacker could somehow hijack this subdomains he/she could come up with the impression of compromising the core site to perform misinformation,phising, etc.. It is still a best practice to include 'WWW' in the blacklist to add more security feature that's in most modern browsers...

Unicode used= Cyrillic Small Letter We
character = w
Internationalized version = https://ԝԝԝ.google.com/
https://ԝԝԝ.google.com/ points to " xn--07aaa.google.com "

Kind regards,
and keep safe!

Comment 1

[Dan Fonte]

Attackers can utilize this aswell to trick users and evade Fraudulent/Phising Reports by utilizing the IDN version to perform phising attacks and displays a legitimate page on the real one effectively evading fraudulent reports ..

example:
IDN version= https://ԝԝԝ.site.com (PHISING PAGE)
where ԝԝԝ.site.com points to "xn--07aaa.site.com" an IDN of 'WWW' and subdomain of site.com
real adsress= https://www.site.com (real adress dressed as legit operating page)

*An ordinary user wouldn't actually know the weird difference and would report www.phising.com (the real address) as fraudulent instead of the IDN where the real adress has long-been prepared to look as innocent for such while all of the fishy activity has been happening on the IDN one targeting firefox users.

Comment 2

[Dan Fonte]

my bad, www.phising.com is supposedly www.site.com

kind regards!

Comment 3

[Daniel Veditz [:dveditz]]

This appears to be the "whole-script confusables" issue of bug 1332714. Slightly less bad in this case because you're using a sub-domain, and in order for that to be useful the domain you're spoofing it on would have to have registered that domain. If the victim has a non-TLS connection to that domain all bets are off anyway, but if it's a TLS connection you'd also need the cooperation of the victim domain to get a proper cert (or you've found a much bigger bug in the CA system than this spoofing issue). [In practice phishers don't even bother with IDN because people don't look at the URL bar; bad ASCII similars or even random names are apparently good enough.]

As far as reporting, if a user reported apparent www.site.com the SafeBrowsing folks would look and not find phishing. No harm done, but they'd miss a scam. If the victim used the Firefox Help menu "Report Deceptive Site..." item then the correct phishing URL would be correctly included. But the SafeBrowsing folks would probably still not consider it phishing because it's a legitimate *.site.com domain, with DNS and certificates under the control of site.com. To pull this off you'd have to hack site.com.