首頁‎ > ‎資通安全宣導‎ > ‎社交工程宣導‎ > ‎

釣魚網站實例

 

新北市政府專頁 山寨版唬人的!

 

網址「KUS0080」查罰單?山寨網頁恐釣個資

 

mobile01山寨版

 
 
_
 

chrome IDN homograph attack

張貼者:2017年11月26日 下午7:55黃景煌

https://www.chromium.org/developers/design-documents/idn-in-google-chrome

IDN in Google Chrome

Background

Many years ago, domains could only consist of the Latin letters A to Z, digits, and a few other characters. Internationalized Domain Names (IDNs) were created to better support non-Latin alphabets for web users around the globe.

Different characters from different (or even the same!) languages can look very similarWe’ve seen reports of proof-of-concept attacks. These are called homograph attacksFor example, the Latin "a" looks a lot like the Cyrillic "а", so someone could register http://ebаy.com (using Cyrillic "а"), which could be confused for http://ebay.comThis is a limitation of how URLs are displayed in browsers in general, not a specific bug in Chrome. 

In a perfect world, domain registrars would not allow these confusable domain names to be registered. Some TLD registrars do exactly that, mostly by restricting the characters allowed, but many do not. As a result, all browsers try to protect against homograph attacks by displaying punycode (looks like "xn-- ...") instead of the original IDN, according to an IDN policy.

This is a challenging problem space. Chrome has a global user base of billions of people around the world, many of whom are not viewing URLs with Latin letters. We want to prevent confusion, while ensuring that users across languages have a great experience in Chrome. Displaying either punycode or a visible security warning on too wide of a set of URLs would hurt web usability for people around the world.

Chrome and other browsers try to balance these needs by implementing IDN policies in a way that allows IDN to be shown for valid domains, but protects against confusable homograph attacks.

Google Safe Browsing continues to help protect over two billion devices every day by showing warnings to users when they attempt to navigate to dangerous or deceptive sites or download dangerous files. Password managers (like Google Smart Lock) continue to remember which domain password logins are for, and won’t automatically fill a password into a domain that is not the exactly correct one.

How IDN works

IDNs were devised to support arbitrary Unicode characters in hostnames in a backward-compatible way. This works by having user agents transform a hostname containing Unicode characters beyond ASCII to one fitting the traditional mold, which can then be sent on to DNS servers. For example, http://öbb.at is transformed to http://xn--bb-eka.at. The transformed form is called ASCII Compatible Encoding (ACE) made up of the four character prefix ( xn-- ) and the punycode representation of Unicode characters.

Google Chrome's IDN policy

Starting with Google Chrome 51, whether or not to show hostnames in Unicode is determined independently of the language settings (the Accept-Language list). Its algorithm is similar to what Firefox does. ( the changelist description that implemented the new policy.)

Google Chrome decides if it should show Unicode or punycode for each domain label (component) of a hostname separately. To decide if a component should be shown in Unicode, Google Chrome uses the following algorithm:
  • Convert each component stored in the ACE to Unicode per UTS 46 transitional processing (ToUnicode).
  • If there is an error in ToUnicode conversion (e.g. contains disallowed charactersstarts with a combining mark, or violates BiDi rules), punycode is displayed.
  • If any character is outside the union of the following sets, punycode is displayed.
  • If the component contains either U+0338 or U+2027, punycode is displayed.
  • If the component uses characters drawn from multiple scripts, it is subject to a script mixing check based on "Moderately Restrictive" profile of UTS 39 (starting with Chome 63, it will be "Highly Restrictive") with an additional restriction on Latin. Failing the check, the component is shown in punycode. 
    • Latin, Cyrillic or Greek characters cannot be mixed with each other
    • Up to Chrome 62, Latin characters in the ASCII range can be mixed with characters in another script as long as it's not Greek nor Cyrillic.
    • Starting with Chrome 63, Latin characters in the ASCII range can be mixed ONLY with Chinese (Han, Bopomofo), Japanese (Kanji, Katakana, Hiragana), or Korean (Hangul, Hanja). 
    • Han (CJK Ideographs) can be mixed with Bopomofo 
    • Han can be mixed with Hiragana and Katakana
    • Han can be mixed with Korean Hangul 
  • If two or more numbering systems (e.g. European digits + Bengali digits) are mixed, punycode is shown.
  • If there are any invisible characters (e.g. a sequence of the same combining mark or a sequence of Kana combining marks), punycode is shown. 
  • Test the label for mixed script confusable per UTS 39. If mixed script confusable is detected, show punycode.
  • If a hostname belongs to an non-IDN TLD(top-level-domain) such as 'com', 'net', or 'uk' and all the letters in a given label belong to a set of Cyrillic letters that look like Latin letters (e.g. Cyrillic Small Letter IE - е  ), show punycode.
  • If the label matches a dangerous patternpunycode is shown.
  • If the end of a hostname is identical to one of top 10k domains after removing diacritic marks and mapping each character to its spoofing skeleton (e.g. www.googlé.com with 'é' in place of 'e'), punycode is shown.  
  • Otherwise, Unicode is shown. 
(This is implemented by IDNToUnicodeOneComponent and IsIDNComponentSafe() in components/url_formatter/url_formatter.cc and IDNSpoofChecker class in components/url_formatter/idn_spoof_checker.cc )

April 2017 update

Specific instances of IDN homograph attacks have been reported to Chrome, and we continually update our IDN policy to prevent against these attacks. One specific instance of this general issue was reported to Chrome security on Jan 20, 2017. It was triaged as a medium-severity bug, and a fix landed on in Chrome 58 on March 23. The researcher whose report led to the fix was awarded $2,000 under Chrome's Vulnerability Reward Program.

This fix is an attempt to balance the needs of our international userbase while protecting against confusable homograph attacks. The fix shows punycode for domain names that are made entirely of Latin lookalike Cyrillic letters when the top-level domain is not an internationalized domain name, meaning that the check only applies to top-level domains like "com", "net", and "uk" but not applied for IDN TLDs like рф. We’re working on additional fixes, for example, for confusables within one script set -- “l” (lowercase L) could be confused with “I” (small dotless i character). We will keep this article updated with our current IDN policy above.

Consequences / Examples

[The old content here was completely inaccurate and has been removed.  TODO: add examples of the above]

Behavior of other browsers

IE

IE displays URLs in IDN form if every component contains only characters of one of the languages configured in "Languages" on the "General" tab of "Internet Options", similar to how Google Chrome worked prior to version 51.

Firefox

Firefox uses a script mixing detection algorithm based on the "Moderately Restrictive" profile of Unicode Technical Report 39. Domains of any single script, any single script + Latin, or a small whitelist of other combinations are displayed as Unicode; everything else is Punycode.

Opera

Like Firefox, Opera has a whitelist of TLDs and shows IDN only for these whitelisted TLDs.

Safari

Safari has a whitelist of scripts that do not contain confusable characters, and only shows the IDN form for whitelisted scripts. The whitelist does not include Cyrillic and Greek (they are confusable with Latin characters), so Safari will always show punycode for Russian and Greek URLs.


punycode phishing attack | IDN homograph attack

張貼者:2017年4月20日 下午6:14黃景煌   [ 已更新 2017年11月26日 下午7:54 ]

How to fix it?
    Chrome - 升級到版本 58以後 (https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/)
    Firefox - (1)網址列輸入 about:config (2)search network.IDN_show_punycode(3)value設為true.
   IE - 無須修改
   Edge - 無須修改 


Firefox Demo

 真正的www.apple.com 
 firefox
network.IDN_show_punycode=false

 
 firefox
network.IDN_show_punycode=true
 


IE 顯示punycode, 須restart ie


https://www.dcard.tw/f/3c/p/226201810

今天我想跟大家談談「釣魚網站攻擊(Phishing)」

以往我們會看到的釣魚網站攻擊
大部分是用在網址裡使用ASCII的易混淆字元來達成的
並模仿目標網站的網站模式來達成混淆使用者的效果

我們這裡只討論網址的部分(本文示範網址在「.」前後都用空格隔開以避免誤觸)
例如:www . goog1e . com

本例中使用數字「1」取代英文字「l」
一般使用者沒有仔細看的話可能就會被騙
但是只要你有仔細看
這個還是分辨得出來的

但是現在出現了一種新的混淆方式
由於現在的網址可以使用Punycode(域名代碼)
所以本來只能使用ASCII的網址
變成可以使用Unicode了

而這個技術是利用將Unicode轉換成一串ASCII的代碼來達成的
例如:「短 . co」會被轉換成「xn--s7y . co」

利用Punycode
我們可以將ASCII字元以看起來幾乎沒有差別的其他語言文字代替
例如:аpple . com

乍看之下看起來是Apple的官方網站對吧
但其實最前面的「а」是西里爾文(Cyrillic)
如果用純ASCII網址看就會變成「xn--pple-43d . com」

這種攻擊方法有一個名詞
「IDN欺騙(IDN homograph attacks)」

不過雖然人類肉眼沒辦法分辨
但是最新的瀏覽器都有分辨這種網址的功能
可以在瀏覽器的內部設定裡(通常不是一般的設定頁面)設定只用ASCII顯示網址

所以如果你想避免這種釣魚攻擊模式
你只要將瀏覽器的IDN欺騙保護打開就可以了
https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/

Chrome and Firefox Phishing Attack Uses Domains Identical to Known Safe Sites

This entry was posted in General Security on April 14, 2017 by Mark Maunder   142 Replies

Update on April 19th at noon Pacific time: Chrome has just released version 58.0.3029.81. We have confirmed that this resolves the issue and that our ‘epic.com’ test domain no longer shows as ‘epic.com’ and displays the raw punycode instead, which is ‘www.xn--e1awd7f.com’, making it clear that the domain is not ‘epic.com’. We encourage all Chrome users to immediately update to the above version of Chrome to resolve the issue. The original post follows:

This is a Wordfence public service security announcement for all users of Chrome and Firefox web browsers: 

There is a phishing attack that is receiving much attention today in the security community.

As a reminder: A phishing attack is when an attacker sends you an email that contains a link to a malicious website. You click on the link because it appears to be trusted. Merely visiting the website may infect your computer or you may be tricked into signing into the malicious site with credentials from a site you trust. The attacker then has access to your username, password and any other sensitive information they can trick you into providing.

This variant of a phishing attack uses unicode to register domains that look identical to real domains. These fake domains can be used in phishing attacks to fool users into signing into a fake website, thereby handing over their login credentials to an attacker.

This affects the current version of Chrome browser, which is version 57.0.2987 and the current version of Firefox, which is version 52.0.2. This does not affect Internet Explorer or Safari browsers.

We created our own example to demonstrate how an attacker can register their own domain that looks identical to another company’s domain in the browser. We decided to imitate a healthcare site called ‘epic.com’ by registering our own fake site. You can visit our demo site here in Chrome or Firefox. For comparison you can click here to visit the real epic.com.

Here is what the real epic.com looks like in Chrome:

Here is our fake epic.com in Chrome:

And the real epic.com in Firefox:

And here is our fake epic.com in Firefox:

As you can see both of these domains appear identical in the browser but they are completely different websites. One of them was registered by us, today. Our epic.com domain is actually the domain https://xn--e1awd7f.com/ but it appears in Chrome and Firefox as epic.com.

The real epic.com is a healthcare website. Using our unicode domain, we could clone the real epic.com website, then start emailing people and try to get them to sign into our fake healthcare website which would hand over their login credentials to us. We may then have full access to their healthcare records or other sensitive data.

We even managed to get an SSL certificate for our demonstration attack domain from LetsEncrypt. Getting the SSL certificate took us 5 minutes and it was free. By doing this we received the word ‘Secure’ next to our domain in Chrome and the little green lock symbol in Firefox.

How is this possible?

The xn-- prefix is what is known as an ‘ASCII compatible encoding’ prefix. It lets the browser know that the domain uses ‘punycode’ encoding to represent Unicode characters. In non-techie speak, this means that if you have a domain name with Chinese or other international characters, you can register a domain name with normal A-Z characters that can allow a browser to represent that domain as international characters in the location bar.

What we have done above is used ‘e’ ‘p’ ‘i’ and ‘c’ unicode characters that look identical to the real characters but are different unicode characters. In the current version of Chrome, as long as all characters are unicode, it will show the domain in its internationalized form.

How to fix this in Firefox:

In your firefox location bar, type ‘about:config’ without quotes.

Do a search for ‘punycode’ without quotes.

You should see a parameter titled: network.IDN_show_punycode

Change the value from false to true.

Now if you try to visit our demonstration site you should see:

Can I fix this if I use Chrome?

Currently we are not aware of a manual fix in Chrome for this. Chrome have already released a fix in their ‘Canary’ release, which is their test release. This should be released to the general public within the next few days.

Until then, if you are unsure if you are on a real site and are about to enter sensitive information, you can copy the URL in the location bar and paste it into Notepad or TextEdit on Mac. It should appear as the https://xn--….. version if it is a fake domain. Otherwise it will appear as the real domain in its unencoded form if it is the real thing.

Spread the word

The concept of an IDN homograph attack has been around since 2001when Israeli researchers Evgeniy Gabrilovich and Alex Gontmakher first wrote about it.

Web browsers have attempted various fixes but the current implementations in Chrome and Firefox are clearly not doing a good enough job. To Chrome’s credit, they are about to fix that. Thankfully there is a manual fix for Firefox.

We would like to encourage you to spread the word. This new twist on phishing is getting a lot of attention today, Friday April 14th and is making the rounds currently in the security community. Xudong Zheng wrote about this earlier today and it is also being discussed on the netsec subreddit.

We think here is a high possibility that this may be exploited in phishing attacks before the Chrome fix is released to the general public, which is why we are posting this public service announcement.

https://www.xudongz.com/blog/2017/idn-phishing/

Phishing with Unicode Domains

Posted by Xudong Zheng on April 14, 2017

URL Bar

Before I explain the details of the vulnerability, you should take a look at the proof-of-concept.

Punycode makes it possible to register domains with foreign characters. It works by converting individual domain label to an alternative format using only ASCII characters. For example, the domain "xn--s7y.co" is equivalent to "短.co".

From a security perspective, Unicode domains can be problematic because many Unicode characters are difficult to distinguish from common ASCII characters. It is possible to register domains such as "xn--pple-43d.com", which is equivalent to "аpple.com". It may not be obvious at first glance, but "аpple.com" uses the Cyrillic "а" (U+0430) rather than the ASCII "a" (U+0061). This is known as a homograph attack.

Fortunately modern browsers have mechanisms in place to limit IDN homograph attacks. The page IDN in Google Chrome highlights the conditions under which an IDN is displayed in its native Unicode form. Generally speaking, the Unicode form will be hidden if a domain label contains characters from multiple different languages. The "аpple.com" domain as described above will appear in its Punycode form as "xn--pple-43d.com" to limit confusion with the real "apple.com".

The homograph protection mechanism in Chrome, Firefox, and Opera unfortunately fails if every characters is replaced with a similar character from a single foreign language. The domain "аррӏе.com", registered as "xn--80ak6aa92e.com", bypasses the filter by only using Cyrillic characters. You can check this out yourself in the proof-of-concept using Chrome, Firefox, or Opera.

Visually, the two domains are indistinguishable due to the font used by Chrome and Firefox. As a result, it becomes impossible to identify the site as fraudulent without carefully inspecting the site's URL or SSL certificate. This Go program nicely demonstrates the difference between the two sets of characters. Safari, along with several less mainstream browsers are fortunately not vulnerable.

Internet Explorer does not display native characters in domains unless it belongs to one of the computer's system languages. As a result, it suffers from the same vulnerability if the system has Russian (and other Cyrillic languages) enabled. Internet Explorer's documentation acknowledges that users are "increasing the risk of spoofing attack" when their system supports additional languages.

Screenshots: ChromeFirefoxFirefox SSLInternet ExplorerInternet Explorer SSL

This bug was reported to Chrome and Firefox on January 20, 2017 and was fixed in the Chrome trunk on March 24. The fix is included in Chrome 58 which is currently rolling out to users. The existence of the bug in Opera was brought to my attention only after the initial publication of this post. The problem remains in Firefox as they decided that it is a problem for domain registrars to deal with. You can find the detailed discussion in the Bugzilla issue.

Our IDN threat model specifically excludes whole-script homographs, because they can't be detected programmatically and our "TLD whitelist" approach didn't scale in the face of a large number of new TLDs. If you are buying a domain in a registry which does not have proper anti-spoofing protections (like .com), it is sadly the responsibility of domain owners to check for whole-script homographs and register them.

Firefox users can limit their exposure to this bug by going to about:config and settingnetwork.IDN_show_punycode to true. This will force Firefox to always display IDN domains in its Punycode form, making it possible to identify malicious domains. Thanks to user MARKZILLA from reddit for this temporary solution. Chrome 58+ users and Firefox users who apply this fix will see the Punycode domain rather than "apple.com".

Firefox Fix

A simple way to limit the damage from bugs such as this is to always use a password manager. In general, users must be very careful and pay attention to the URL when entering personal information. Until this is fixed, concerned users should manually type the URL or navigate to sites via a search engine when in doubt. This is a serious vulnerability because it can even fool those who are extremely mindful of phishing.


1-2 of 2