An attack that uses homographic characters to impersonate domain names and launch convincing but malicious websites takes minutes and a bare modicum of skill — while reaping high rates of success in luring victims, according to an independent researcher.
Researcher Avi Lumelsky set out to see how easy it would be to set up a phishing page that used homographics to impersonate legitimate sites. As he explained in a posting this week, “homographic characters look like ASCII letters, but their encoding is different, in a way that is usually not noticeable for the human eye.”
As an example, this URL uses a homographic character as its first character: “ɢoogle.news.” That can be compared to the legitimate “google.news” font — there’s a barely discernable difference.
Lumelsky noted that a few years ago someone bought the homographic-including “ɢoogle.com” to use it for phishing purposes.
“I wondered to myself: There are new top-level-domains every year. Did the world learn from the ɢoogle.com acquisition? How hard is it to create a good Google phishing website from scratch?”
Setting out to find out, the researcher turned to the main domain registrars – GoDaddy, Namecheap and even Google Domains – to first see if he could snag appropriate URLs. He found the process to be so simple that a basic search resulted in a dozen suggestions for available domain names, including ɢoogle.company; ɢoogle.email; ɢoogle.tv; ɢoogle.life and even ɢoogletranslate.com, all for what Lumelsky said was a “great” price. He purchased a handful of them, using an obviously fake identity that included “Not Google :)” as the company name.
After that, he was able to set up a virtual private server in the cloud to host the domains; and he also requested a LetsEncrypt certificate to “safeguard” traffic to and from the sites – and get around security red flags from browsers. Chrome for instance showed the domains as “Secure” (with a lock icon) thanks to the certificate.
“Now, one can use https:// links to gain trust, while providing malicious content,” Lumelsky said.
The next step was routing the sites’ domain name server (DNS) traffic to the cloud server. DNS translates human-readable website names to machine addresses, which enables most internet interactions between sites, plugins and the like. He also set up a nginx proxy, masking the true destination of any request to the site’s DNS server. And to seal the deception, he also used Google’s JavaScript code from the legitimate site as the code for his own.
“The great thing about using a proxy is that my domain’s links previews, in every single platform, fetches Google Translate’s exact description while pointing to my link,” the researcher explained. “[Also,] Google’s JS runs normally from my domain.”
In all, Lumelsky said that it was a simple affair to set up a very convincing fake domain – it took minutes, with no coding, he explained. Further, “on mobile phones, the ‘ɢ’ in my domain looks like an actual ‘G,'” he said.
From there he completed his trial with some social-engineering forays that he said were successful in luring visitors to the sites, “with very little effort,” he said. He also posted links to the sites in security threads on Reddit and elsewhere to see if security-minded targets would notice the discrepancy in the domain name. That too was successful, he added.
“Eventually, without much work, I ended up with hundreds of unique visitors (excluding the bots and security scanners or the platforms in which I posted),” he explained. “It looks and acts just like any google single-page application.”
The next step in the proof-of-concept was to weaponize the domains. Aside from the obvious route of creating a phishing functionality, it’s also possible to execute a man-in-the-middle attack, the researcher explained.
“I am making the SSL handshake with the user,” he said. “The original Google application is served, it functions an expected, but I am exposed to the user’s traffic with the domain. Therefore, I can change the body of Google’s response.”
This man-in-the-middle (MiTM) attack technique can be used in a few different ways, he said. For instance, with a little effort, it’s possible to extract login credentials or tokens.
“Google uses the domain accounts.google.com for authentication,” Lumelsky explained. “I can, for example, override all the <a> tags in the HTML. Instead of pointing them to a subdomain in google.com (e.g accounts.google.com) we can point them to a custom phishing login page, within ɢoogletranslate.com domain. We can steal the user’s login credentials to Google by overriding the links within the page, and pointing them to [the maliciously registered domain] accounts.ɢoogletranslate.com (The sign-in button’s HTML tag’s href attribute).”
Further, an attacker could inject a malicious <script> tag into the hijacked HTTP body and execute code on a client browser connecting to the fake website.
“A majority of the user agents that visited the links were old browsers that haven’t been updated for a long time,” the researcher concluded. “Many of the Chrome, Firefox and Safari user agents from my access logs are devices which are vulnerable to one-day attacks (including sandbox escape).”
To protect oneself, site surfers should always be suspicious of off letters inside domains in links; and admins should implement rules within their security protocols that flag homographic hosts.
Lumelsky also filed a bug report with Google, identifying all of the places in the kill chain where this attack method could be thwarted. This includes not allowing “ɢoogle” top-level domains to be sold; or, if they are, to at least not allow them to be auto-suggested as they were by the Google Domains registrar. Another weak point the fact that Google’s JavaScript did not check that “(window.location” was a legitimate Google domain before allowing the script to be loaded.
The discussions are ongoing, but Google’s response, the researcher said, was: “Thank you for the considerable material, the thought behind it, as well as the actual money used to secure those domain names in creating this report. Homographic attacks are always interesting in their social-engineering application, but more challenging is deploying an attack that will trick not only the user, but also the infrastructure.”
Threatpost reached out to Google for further comment.
The attack method isn’t limited to Google, of course, and there are other weaknesses that it exploits. For instance, Lumelsky pointed out that people should not be able to request an SSL certificate from LetsEncrypt for homographic domains.
“Until there is a solution out there, every big company or service will have to secure their domains and assets, by spending lots of money on similar domain names,” he said. “The steps to reproduce this kind of attack are pretty simple for anyone with basic Linux and networking knowledge.”
Interested in security for the Internet of Things and how 5G will change things? Join our free Threatpost webinar, “5G, the Olympics and Next-Gen Security Challenges,” as our panel discusses what use cases to expect in 2020 (the Olympics will be a first test), why 5G security risks are different, the role of AI in defense and how enterprises can manage their risk. Register here.
