Bugzilla – Bug 65566
VUL-0: CVE-2005-0238: cloaking domain names using IDN
Last modified: 2021-11-02 16:09:40 UTC
Subject: [Full-Disclosure] state of homograph attacks The state of homograph attacks I. Background International Domain Name [IDN] support in modern browsers allows attackers to spoof domain name URLs + SSL certs. II. Description In December 2001, a paper was released describing Homograph attacks [1]. This new attack allows an attacker/phisher to spoof the domain/URLs of businesses. At the time this paper was written, no browsers had implemented Unicode/UTF8 domain name resolution. Fast forward to today: Verisign has championed International Domain Names (IDN) [2]. RACES has been replaced with PUNYCODE [3]. Every recent gecko/khtml based browser implements IDN (which is just about every browser [4] except for IE; plug-in are available [5]). III. The details Proof of concept URL: http://www.shmoo.com/idn/ Clicking on any of the two links in the above webpage using anything but IE should result in a spoofed paypal.com webpage. The links are directed at "http://www.pаypal.com/", which the browsers punycode handlers render as www.xn--pypal-4ve.com. This is one example URL - - there are now many ways to display any domain name on a browser, as there are a huge number of codepages/scripts which look very similar to latin charsets. Phishing attacks are the largest growing class of attacks on the internet today. I find it amusing that one of the large early adopters of IDN offer an 'Anti-Phishing Solution' [6]. Finally, as a business trying to protect their identity, IDN makes their life very difficult. It is expected there will be many domain name related conflicts related to IDN. Vulnerable browsers include (but are not limited to): Most mozilla-based browsers (Firefox 1.0, Camino .8.5, Mozilla 1.6, etc) Safari 1.2.5 Opera 7.54 Omniweb 5 Other comment: There are some inconsistencies with how the browsers match the host name with the Common Name (CN) in the SSL cert. Most browsers seem to match the punycode encoded hostname with the CN, yet a few (try to) match the raw UTF8 with the CN. In practice, this makes it impossible to provide 'SSL' services effectively, ignoring the fact that IE doesn't yet support them. IV. Detection There are a few methods to detect that you are under a spoof attack. One easy method is to cut & paste the url you are accessing into notepad or some other tool (under OSX, paste into a terminal window) which will allow you to view what character set/pagecode the string is in. You can also view the details of the SSL cert, to see if it's using a punycode wrapped version of the domain (starting with the string 'xn-'. V. Workaround You can disable IDN support in mozilla products by setting 'network.enableIDN' to false. There is no workaround known for Opera or Safari. VI. Vendor Responses Verisign: No response yet. Apple: No response yet. Opera: They believe they have correctly implemented IDN, and will not be making any changes. Mozilla: Working on finding a good long-term solution; provided clear workaround for disabling IDN. VII. Timeline 2002 - Original paper published on homograph attacks 2002-2005 - Verisign pushes IDN, and browsers start adding support for it Jan 19, 2005 - Vendors notified of vulnerability Feb 6, 2005 - Public disclosure @shmoocon 2005 VIII. Copyright This paper is copyright 2005, Eric Johanson ericj@shmoo.com Assistance provided by: - The Shmoo Group - The Ghetto Hackers Thank you, you know who you are. References: [1] http://www.cs.technion.ac.il/~gabr/papers/homograph.html [2] http://www.verisign.com/products-services/naming-and-directory-services/naming-s +ervices/internationalized-domain-names/index.html [3] http://mct.verisign-grs.com/index.shtml [4] http://www.verisign.com/products-services/naming-and-directory-services/naming-s +ervices/internationalized-domain-names/page_002201.html#01000002 [5] http://www.idnnow.com/index.jsp [6] http://www.verisign.com/verisign-business-solutions/anti-phishing-solutions/
<!-- SBZ_reproduce --> see above
https://bugzilla.mozilla.org/show_bug.cgi?id=279099
speaking for mozilla/firefox: The only fix for now is to disable IDN. Unfortunately this doesn't work correctly with released versions. So we have to create updates where it can be disabled. The problem is, that we can change the default to disable IDN but the profiles out there may not follow the default. So we have to inform the customers in addtition to check this value if needed. @security-team: updates for all packages down to 8.2?
@security-team: could you please check if we have to fis both versions on NLD? NLD has Firefox 0.10 while SP1 has 1.0.
question is ... can we disable IDN support completely until a good fix is found? Like not compiling in IDN support for now? I will check with NLD
For kdelibs3, the patch to patch is kdecore-use-libidn.diff
We could patch it out IMHO. But I'm not sure if we really should do it. Maybe some of our customers rely on that feature?
but only disabling the patch would let libkdecore open the library via dlopen. 9.2 and later do link directly against libidn meanwhile, if course we could remove it from the build system, but the user has no chance to enable it again. So I would prefer a patch which allows to enable it again. Remember that there could be domains which can not be reached in a usable way anymore.
I wonder why someone can register xn--pypal-4ve.com - isn't this a problem of the domain control office?
most registries are automatic ... and no one reviews thousands of sites per day.
http://bugs.kde.org/show_bug.cgi?id=98788
wolfgang: yes, please prepare updates for all affected. if it is possible to set the default, try to set it to "off". :/
CAN-2005-0233 for IDN domain cloaking in Firefox 1.0, Camino 0.8, Mozilla 1.6 CAN-2005-0234 for IDN domain cloaking in Safari 1.2.5 CAN-2005-0235 for IDN domain cloaking in Opera 7.54 CAN-2005-0236 for IDN domain cloaking in Omniweb 5 CAN-2005-0238 for IDN domain cloaking in Epiphany Details: http://www.shmoo.com/idn http://www.shmoo.com/idn/homograph.txt
cite: Konqueror has an ID. Candidate: CAN-2005-0237 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0237 Reference: FULLDISC:20050206 state of homograph attacks Reference: URL:http://lists.netsys.com/pipermail/full-disclosure/2005-February/031459.html Reference: FULLDISC:20050206 Re: state of homograph attacks Reference: URL:http://lists.netsys.com/pipermail/full-disclosure/2005-February/031460.html Reference: MISC:http://www.shmoo.com/idn Reference: MISC:http://www.shmoo.com/idn/homograph.txt The International Domain Name (IDN) support in Konqueror 3.2.1 on KDE 3.2.1 attackers to spoof domain names using punycode encoded domain names that are decoded in URLs and SSL certificates in a way that uses homograph characters from other character sets, which facilitates phishing attacks. -- JB
swamp firefox: 355
For KDE 3.4 / SL9.3, IDN support is disabled by default but can be re-enabled by setting the KDE_USE_IDN environment variable. Patch available from http://bugs.kde.org/attachment.cgi?id=9711&action=view Above patch can be used for KDE 3.3 as well. On KDE 3.2 IDN support can be disabled by uninstalling libidn (not sure if that's a feasible solution for SUSE though). Opera in the meantime has adopted a whitelist approach for TLDs that review domain registrations and for IDN is safe. See http://www.opera.com/windows/changelogs/800b2/
we have a similar patch in our kdelibs3, but IDN is enabled by default. maybe I can change it to have it only enabled for the domains from the whitelist.
Created attachment 30243 [details] post-3.2.3-kdelibs-idn.patch Patch for KDE 3.2.x Note that this patch also addresses a problem with SSL certificate name matching of IDN names.
Created attachment 30245 [details] post-3.3.2-kdelibs-idn.patch Patch for KDE 3.3.x Note that this patch also addresses a problem with SSL certificate name matching of IDN names. These fixes are supposed tobe part of KDE 3.4 as well, but coolo should confirm that. security@kde.org has planned a public advisory for this issue for March 16, 2005, 14:00 CET A preliminary advisory will be released shortly to vendor-sec.
KDE Security Advisory: Konqueror International Domain Name Spoofing Original Release Date: 20050316 URL: http://www.kde.org/info/security/advisory-20050316-2.txt 0. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0237 http://bugs.kde.org/show_bug.cgi?id=98788 http://lists.netsys.com/pipermail/full-disclosure/2005-February/031459.html http://lists.netsys.com/pipermail/full-disclosure/2005-February/031460.html http://www.shmoo.com/idn http://www.shmoo.com/idn/homograph.txt http://xforce.iss.net/xforce/xfdb/19236 http://secunia.com/advisories/14162/ 1. Systems affected: All KDE versions in the KDE 3.2.x and KDE 3.3.x series. 2. Overview: Since version 3.2 KDE and it's webbrowser Konqueror have support for International Domain Names (IDN). Unfortunately this has made KDE vulnerable to a phishing technique known as a Homograph attack. IDN allows a website to use a wide range of international characters in its domain name. Unfortunately some of these characters have a strong resemblance to other characters, so called homographs. This makes it possible for a website to use a domain name that is technically different from another well known domain name, but has no or very little visual differences. This lack of visual difference can be abused by attackers to trick users into visiting malicious websites that resemble a well known and trusted website in order to obtain personal information such as credit card details. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0237 to this issue. For KDE 3.4 KDE and the Konqueror webbrowser have adopted a whitelist of domains for which IDN is safe to use because the registrar for these domains has implemented anti-homographic character policies or otherwise limited the available set of characters to prevent spoofing. 3. Impact: Users can be tricked into visiting a malicious website that resembles a well known and trusted website without getting any visual indication that this website differs from the one the user was expecting to visit. 4. Solution: Upgrade to KDE 3.4. For older versions of KDE Source code patches have been made available which fix these vulnerabilities. Contact your OS vendor / binary package provider for information about how to obtain updated binary packages. 5. Patch: A patch for KDE 3.2.x is available from ftp://ftp.kde.org/pub/kde/security_patches 611bad3cb9ae46ac35b907c7321da7aa post-3.2.3-kdelibs-idn.patch A patch for KDE 3.3.x is available from ftp://ftp.kde.org/pub/kde/security_patches fd484804064ddffe21eacbc45bb4574c post-3.3.2-kdelibs-idn.patch 6. Time line and credits: 07/02/2005 Issue raised by Eric Johanson on full-disclosure 03/03/2005 Patches applied to KDE CVS. 04/03/2005 Vendors notified 16/03/2005 KDE Security Advisory released.
no, this is prio 1 (urgent)
fine with me. I only changed the previous default P3 to the now default P5
reassigning to the KDE security expert
fixed packages submitted.
The fix somewhat breaks the URL handling in konqueror. From the QA report: test7: Bugzilla #65566 - VUL-0: cloaking domain names using IDN: ----------------------------------------------------------------- Go to http://www.shmoo.com/idn/ The "fake" links you see should be displayed as http://www.xn--theshmogroup-bgk.com/ and https://www.xn--theshmogroup-bgk.com/ NOT as http://www.theshmogroup.com/ and https://www.theshmogroup.com/ However, konqueror displays them as http:/idn/ An error occurred while loading http:/idn/: Could not connect to host www.shmoo.com -> FAILED
fixed packages for KDE ... done Missing: - Opera - Mozilla (not Firefox) - ?
Lukas, maybe you have already seen this one...
I'll see if the new Opera 8.0 fixes this problem
Lukas, any news for us?
Opera 8.0, which I submitted to STABLE a few days ago, contains fix for this problem. http://www.opera.com/support/search/supsearch.dml?index=788 http://www.opera.com/linux/changelogs/800/ Shall I backport 8.0 to older SL versions?
Yes, I think it is worth it. Thanks!
Fixed packages submitted
What about 8.2? Is it not affected or problematic?
SM-Tracker-1501 for opera
I'll do it shortly, currently Tomas Crhak is investigating problems with checking out sources for 8.2
Ok! Can you submit the patchinfo files when you are done please? I'll attach it ASAP.
Created attachment 38884 [details] patchinfo-box.opera
8.2 done; where should I submit the patchinfo file? Never did that before :)
just copy it to /work/SRC/done/PATCHINFO/ Thanks.
done
Opera released.
Ok, the only one missing is Mozilla.
released mozilla for all.
CVE-2005-0238: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N)