NOTE: This vulnerability has been patched in Safari
Last week, Rafay blog wrote a short blog piece about the recently publicized browser URL spoofing vulnerability in Safari.
To summarize, the browser bar is considered the only reliable security indicator to validate the authenticity of the website. Looking at the browser URL bar at the top of your browser, and checking that the domain contained in the URL matches the domain of the site you expect to be visiting. If it says “google.com” or “facebook.com” you should be able to reliably tell that you are on the correct website. However, in addition, all browsers include a symbol to show whether the SSL/TLS certificates have been properly validated to authenticate the identify of the server you are communicating with, as well as initialize an encrypted connection to protect your data as it transits the internet.
Besides the recent publicized vulnerability in Safari, URL spoofing has been accomplished by attackers in several other ways including (1) type-o-squatting where a malicious actor registers a domain that is very similar to the target legitimate domain, and could potentially be accessed when a internet user mis-types the domain. For example, “faceboook.com” (with three Os) might catch a few butter-fingered netizens off-guard. (2) Homographic attacks, which also exploit the registration of a trap domain, instead attempt to get the user to click on a similar looking link without noticing that it is slightly mis-spelled, such as “facebooh.com” or “paypl.com”.
Finally, don’t forget about, (3) punycode attacks which leverage the URL protocol that allows Unicode characters to be displayed in a domain or URL. This opens up the same type of attack as the homographic attack except more powerful since the domain in some cases can look identical to the legitimate domain. For example “аррӏе.com”. The punycode used to register that domain would be: “xn--80ak6aa92e.com”, and you can create your own punycode translations here. Both Safari and Chrome have implemented measures to protect users from this type of attack buy warning visitors although it’s uncertain whether these measures go far enough to protect users from most punycode attacks.
Good internet security also tells us to check that the URL does not include a tricky subdomain attempting to to catch you off-guard such as “facebook.ripplesoftware.ca”.
For anyone who wants to see what this vulnerability could look like when spoofed, you can go to my demo spoofed Facebook page using the link below.
The vulnerability is effective on Mac Os and iPhone iOS Safari Browser. Since, eventually, Safari will be updated to prevent spoofing vulnerability, I will specify that I’m using the Mac Os Safari Version 13.12, so any version up to or before that will work fine.
It’s not hard to see that with a little social engineering such as leaving a public library computer on the spoofed page, an attacker make the page look very legitimate with the full spoofed URL bar and all and scrape credentials very easily.