HTTPS Spoofing – How Phishing Websites Use HTTPS to Fool Mobile Users
As a safeguard against the activities of fraudsters and malicious actors who engage in email phishing, social engineering scams, “malvertising” (malicious advertising), and other forms of online mischief, security analysts often prescribe setting your browsers and connected apps to only visit secure websites – those generally designated by the https (or HTTPS, HTTP Secured) protocol header.
But evidence came to light earlier this year that makes even this precaution a precarious one, as there’s a new exploit doing the rounds which enables phishing fraudsters to cloak their bogus websites in seemingly secure credentials by using HTTPS spoofing.
In the earlier days of the internet, domain names could only be written in variants of the Latin alphabet, such as the English language. But as of 1998, it became possible to construct URLs out of the characters from other alphabets, like Cyrillic, Arabic, or Chinese. This was especially useful and appropriate as the internet expanded its reach and players from non-Western markets began to gain influence.
Extension of the domain name possibilities made it necessary for a mechanism to be developed so that URLs created in different regions could be interpreted by English language web browsers (which remain the dominant force, for now). This was done through the use of an encoder named Punycode, which renders each character from a standardized library of character codes maintained by Unicode, the body that sets standards for online text.
HTTPS Spoofing : Homograph Attack
Increased inclusion came with an increase in risk, however. Under the Punycode mechanism, any character set which can be represented with the Unicode standard may be registered. This includes emoji, and characters in other alphabets that have a similar appearance to Latin ones.
Expanding the range of available characters like this had made it possible for malicious actors to manipulate domain names for several years now, substituting similar-looking characters for Unicode in what are known as homograph attacks.
In the words of security researcher Xudong Zheng, who highlighted the recent issue with https spoofing:
“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+0041)…”
Besides the letter and character manipulation made possible through Punycode, there’s also been a mass market development which was designed to extend security protection to the largest number of websites – but has also given fraudsters an avenue to extend their reach.
Encryption for Everyone
The HTTP Secured or HTTPS standard aims at securing websites and online resources through the use of strong TLS (Transport Layer Security) encryption. This ensures that attackers and eavesdroppers can’t immediately see or unscramble any information you submit to a website having the https protocol and address bar padlock icon. The encryption also hides the location of the specific pages you visit (besides their top-level domain) from your Internet Service Provider (ISP).
To make it easier for online resources other than the standard financial institutions, social media platforms, eCommerce sites, and news aggregators to enjoy https protection, Mozilla partnered with Cisco, Akamai, EFF, and the University of Michigan in December 2015 to launch Let’s Encrypt. The project is a free, automated, and open Certificate Authority (CA) capable of issuing SSL/TLS Certificates required to encrypt, authenticate, and validate websites under the https protocol.
The problem is of course that Let’s Encrypt is open and available to everyone: Legitimate organizations, cyber-criminal networks, and individual fraudsters alike.
In early 2017, using homograph attack techniques on the Punycode workaround, security researcher Xudong Zheng put together a proof-of-concept domain illustrating the way in which domain names can be manipulated by fraudsters to create genuine-seeming https destination sites where phishing lures can more effectively entrap their victims.
Zheng was able to create the spoof domain xn--pple-43d.com – equivalent to the URL https://?????.com which Punycode translation on unsecured web browsers interprets as the website for Apple.com.
Apple’s Safari and Microsoft’s Edge were both able to spot that Zheng’s spoof domain is fraudulent. Google Chrome and Mozilla Firefox didn’t flag it, instead displaying the domain name in Cyrillic characters.
Zheng reported this flaw to Chrome and Firefox on January 20, 2017, and Google subsequently included a fix for it in Chrome 58 (April 2017). Mozilla declined to offer a fix, arguing that the vulnerability was purely Apple’s problem. They, however, went on to say that: “We continue to investigate ways to further address visual spoofing attacks, which are complex to fix with technology just in the browser alone.”
Some browsers have been designed to identify homograph tricks, and display the underlying domain name if an anomaly is suspected. Domain names containing multiple alphabets are routinely excluded – but this defense falls down if a spoofed URL is written in all of one language.
HTTPS Spoofing – Protecting Yourself
Though instances of the https Punycode exploit have yet to be confirmed in the wild, it’s likely just a matter of time before dedicated phishing artists latch on to this new technique.
Xudong Zheng advises using a password manager when browsing and using due diligence (alternate communication methods to directly contact the supposed source of a suspicious message, etc.) and common sense to spot phishing attacks before you’re tempted to click on any links.
Generally speaking, auto-fill mechanisms and password managers won’t auto-complete address input on spoofed sites, as the tools are designed to identify when a URL is not familiar.
Users are also advised to manually type a URL when a link is in doubt or to navigate to the website via an external search engine.