Issue metadata
Sign in to add a comment
|
Security: Insuficience punycode handling leading to address spoofing
Reported by
rnmx...@gmail.com,
Sep 30 2017
|
||||||||||||||||||||||||
Issue descriptionDear google security team, I have an issue related to punycode handling in chromium browser which I would like to report to you. This issue is somehow related to https://www.аррӏе.com/ (basically the domain is similar to apple.com however cyrilic characters are used there and as the result this leads to users confusion who believe he is indeed visiting apple.com). Google and Microsoft patched this behaviour by rendering punycode characters in URL if mix of different alphabets is detected. However my testing shows that very probably Chromium implements this check only for particular alphabets (I guess those considered harmful as Greek and Cyrilic). There are still edge cases where punycode is not rendered in URL, instead the spoofed character is rendered in it's real form. To demonstrate this issue we will consider following domain: http://sportacentrs.com/ (all characters are in us-ascii) Now we will take a role of evil attacker who wants to execute very effective phishing campaign against this host. For this goal having domain name as close as original one is desired. Attacker goes to http://jrgraphix.net/r/Unicode/0530-058F where he can find Armenian alphabet. It is matter of seconds to realise there is letter "ո" which looks very similar to latin small "n" letter. As next step attacker changes "n" to "ո" in URL: http://sportaceոtrs.com/ The flaw is obvious as soon as you take this URL and paste it to new tab and click go. You will see punycode is NOT rendered. Instead domain name very similar (almost identical) to original is displayed. Because ".com" allows domain registration with Armenian characters next steps are very easy. An attacker goes to domain register (I chose namecheap for my demo), register this faked domain and all is ready for very effective phishing campaign. Attached screenshot shows two information: - Google address bar when accessing malformed domain name (with Armenian character) - Namecheap screenahot to show that registration of this domain is indeed possible VERSION Chrome Version: Version 62.0.3202.38 (Official Build) beta (64-bit) Operating System: Windows 8.1, all updates installed REPRODUCTION CASE Reproduction is very easy in this case - it is enough to copy malformed URL from this report and access it in Chrome browser. Of course much more domains are vulnerable to this attack, not only the one used in demonstration. Thank you very much for taking your time resolving this issue, Jan
,
Oct 4 2017
Well, this is a subset of bug 726958 and is being addressed by https://chromium-review.googlesource.com/c/chromium/src/+/688825 . > Because ".com" allows domain registration with Armenian characters next steps are very easy. An attacker goes to domain register (I chose namecheap for my demo), register this faked domain and all is ready for very effective phishing campaign. This is not true. Verisign does NOT allow the registration of domains with mixed Latin and Armenian. So, your example cannot be registered. See bug 726958 for details.
,
Oct 4 2017
,
Oct 4 2017
> Verisign does NOT allow the registration of domains with mixed Latin and Armenian. So, your example cannot be registered. So, the risk is rather low. Some non-major gTLDs do allow mixing Armenian and Latin, but in those gTLDs, there are only few (if any) domains worth spoofing.
,
Oct 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fd34ee82420c5e5cb04459d6e381944979d8e571 commit fd34ee82420c5e5cb04459d6e381944979d8e571 Author: Jungshik Shin <jshin@chromium.org> Date: Wed Oct 04 23:25:49 2017 Change the script mixing policy to highly restrictive The current script mixing policy (moderately restricitive) allows mixing of Latin-ASCII and one non-Latin script (unless the non-Latin script is Cyrillic or Greek). This CL tightens up the policy to block mixing of Latin-ASCII and a non-Latin script unless the non-Latin script is Chinese (Hanzi, Bopomofo), Japanese (Kanji, Hiragana, Katakana) or Korean (Hangul, Hanja). Major gTLDs (.net/.org/.com) do not allow the registration of a domain that has both Latin and a non-Latin script. The only exception is names with Latin + Chinese/Japanese/Korean scripts. The same is true of ccTLDs with IDNs. Given the above registration rules of major gTLDs and ccTLDs, allowing mixing of Latin and non-Latin other than CJK has no practical effect. In the meantime, domain names in TLDs with a laxer policy on script mixing would be subject to a potential spoofing attempt with the current moderately restrictive script mixing policy. To protect users from those risks, there are a few ad-hoc rules in place. By switching to highly restrictive those ad-hoc rules can be removed simplifying the IDN display policy implementation a bit. This is also coordinated with Mozilla. See https://bugzilla.mozilla.org/show_bug.cgi?id=1399939 . BUG= 726950 , 756226 , 756456 , 756735 , 770465 TEST=components_unittests --gtest_filter=*IDN* Change-Id: Ib96d0d588f7fcda38ffa0ce59e98a5bd5b439116 Reviewed-on: https://chromium-review.googlesource.com/688825 Reviewed-by: Brett Wilson <brettw@chromium.org> Reviewed-by: Lucas Garron <lgarron@chromium.org> Commit-Queue: Jungshik Shin <jshin@chromium.org> Cr-Commit-Position: refs/heads/master@{#506561} [modify] https://crrev.com/fd34ee82420c5e5cb04459d6e381944979d8e571/components/url_formatter/idn_spoof_checker.cc [modify] https://crrev.com/fd34ee82420c5e5cb04459d6e381944979d8e571/components/url_formatter/url_formatter_unittest.cc
,
Oct 4 2017
,
Oct 5 2017
,
Oct 16 2017
Thanks for the report! I'm afraid this isn't eligible for a reward as the fix was under way because of earlier reports when this bug was filed.
,
Jan 11 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 19
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by infe...@chromium.org
, Sep 30 2017Labels: Security_Severity-Medium Security_Impact-Stable M-62 Pri-1
Owner: js...@chromium.org
Status: Assigned (was: Unconfirmed)