r/cybersecurity • u/ianmuscat • 12d ago
News - General How we registered "apple.com"
We're sharing recent research we wrote about a fun new set of typosquatting domains that bypass Chromium's latest safeguards.
We originally wanted to point to one one of the domains; Reddit's filters didn't play along, so we are sharing a few examples below (try with a Chrome-based browser):
- "apple.com" https://xn--80a6aa68c8d.com/
- "spacex.com" https://xn--80a5aeq0fr0c.com/
Hope you find it interesting!
Full technical writeup: https://haveibeensquatted.com/blog/turning-idn-edge-cases-into-typosquats
49
u/NamedBird 12d ago
Opinion: When ascii and IDN are mixed, the IDN characters should be colored orange and underscored.
And when you have visited a website before and have stored credentials, turn the domain blue.
If you accidentally land on "microsoftonllne.com", seeing the domain not turn blue would be a red flag.
18
u/Not-ur-Infosec-guy Security Architect 11d ago
That’s a great idea especially to help with users unable to catch SEO poisoning
12
u/NamedBird 11d ago
I have more ideas like this, you can apply this to email as well, for example.
But the people who can make those changes don't care, so nothing will change.(Well, maybe i could make it using an add-on, but i doubt people would use it..)
1
32
u/SVD_NL System Administrator 12d ago
Lol, i was very hestitant to click that one... Especially because of the specific mention of a browser type.
I'm actually interested to see how third-party typosquatting web, dns and email filters handle this, time to test! I know they map the basic stuff like I vs l, but i'm curious to see if they also detect cyrilic, and specifically these encoded versions.
3
u/OEAXTAIL_SOUP 12d ago
>i was very hestitant to click that one... Especially because of the specific mention of a browser type.
still worried that firefox's section 31 is gonna pwn ya? ;-)
36
u/tetyys 11d ago
that's why i have https://github.com/AykutCevik/IDN-Safe
4
u/LordZuzurNC 11d ago
Is it still working? Last commit was 7 years ago, some ticket are over 9 years old and a 2 years old ticket even mention it is not compatible with chromium "yet".
3
4
11
u/spideyghetti 12d ago
I have heard of cyrillic characters in emails, but at least you could hover to see the URL underneath. This showing them in the address bar is a bit spooky.
10
u/skynetcoder 11d ago
I remember punycode was in the news few years ago, and those researchers also use apple.com as an example ?
4
u/ianmuscat 11d ago
Yep, a while back (2017!), here's more about that and why this is different -- https://haveibeensquatted.com/blog/turning-idn-edge-cases-into-typosquats#the-case-of-%D0%B0%D1%80%D1%80%D3%8F%D0%B5com
22
11
u/_Durs 12d ago
Thankfully doesn’t work on Safari.
9
u/ianmuscat 12d ago
yeah, Safari (WebKit) is a different story. WebKit doesn't do WSC checks at all. It just has a script allowlist for IDNs, and Cyrillic isn't on it (except under Cyrillic TLDs like `.рф`). So `ѕрасөх.com` shows as `xn--80a5aeq0fr0c.com` no matter what you do with `ө`.
The Latin edge-case in the blog post is still allowed through though, and `ƙ` isn't on WebKit's lookalike blocklist, so `niƙe.com` renders as Unicode just fine.
Here are a few registrations we made using the hooked Latin glyphs:
- `niƙe.com`
- `ƙicƙstarter.com`
- `oƙta.com`
- `vƙ.com`
3
u/NightmareTwily 12d ago
Doesn't work on any competent browser. They should all show the punycode to prevent against this attack.
3
0
u/DishSoapedDishwasher CISO 11d ago
Calling safari a competent browser is wild to me; it's like when people say windows is a well made operating system.
1
6
5
u/Swimming-Ask-4748 12d ago
That's really interesting how it shows up as apple, could fool a lot of people with this
6
u/Embarrassed-Fig-6576 11d ago
My Safari automatically replaced the variant letter with normal letter and it led me to official website.
4
u/ianmuscat 11d ago
Safari isn’t affected for the Cyrillic examples (see https://www.reddit.com/r/cybersecurity/s/mvo6qTEY6A), but I haven’t observed routing to the real site on Safari, haven’t replicated that 🤔
1
15
u/casper_trade 11d ago
Punycode domain squatting has been a tactic used by threat actors for years (like 10+ years now?), nothing new here.
2
u/castleinthesky86 11d ago
Yep. Over a decade this technique has been known and is not front page news.
4
u/RealVenom_ 11d ago
I see absolutely no harm in revisiting tactics like this. Not everyone was in the industry ten years ago. And if it can still be used today then awareness is just as important now as it was then.
3
1
u/castleinthesky86 10d ago
Yeah nothing wrong with revisiting tactics. But it’s not “recent research” if it’s been documented decades ago and been exploited for the same time period. It’s someone finding existing research.
1
u/RealVenom_ 10d ago
Wondering if you read the article though? It does acknowledge the 2017 research and fixes, but looks at what edge cases still apply today.
I feel anyone that takes the time to look into risks that apply today should be able to publish and share if it's relevant.
5
u/IAmYourFath 12d ago edited 12d ago
On both sites i get:
Your connection is not private
Attackers might be trying to steal your information from ѕрасөх.com (for example, passwords, messages or credit cards). Learn more about this warning
net::ERR_CERT_AUTHORITY_INVALID
Edit: It was nextdns blocking the site, nice
3
4
u/Circumpunctilious 11d ago
I could swear I knew about this significantly earlier than the 2017-April event (perhaps early notice due to cyber defense work), but it hardly matters as I completely forgot about the method.
Thanks for taking the time to put all this together—it’s a good reminder to use or lose.
4
5
u/ck3llyuk 12d ago
Interesting stuff - let's see if Google do anything about this!
1
u/danekan 12d ago
It’s not new so probably not
4
u/JDBHub 12d ago
Actually there's a Sept 11 patch that covers some of these cases. Suspect this will get fixed
2
u/ianmuscat 12d ago
Yeah Chromium added м into the Cyrillic lookalike list this September, so stuff like `мехс.com` shows as punycode now.
Also, Unicode 17 killed `ҏ` and `ӿ`, which would've been interesting WSC breakers to play around with.
1
2
u/Angrymilks 12d ago
Punycode. I have one too. xn--taget-kp1b.com
2
u/ianmuscat 12d ago
actually, `xn--taget-kp1b.com` won't work because Chromium normalizes `ṛ` to `r`, making its skeleton match `target.com`'s which will cause it to render punycode.
The pipeline is smth like:
- Strips the dot from `ṛ` when generating its Unicode comparison skeleton
- Produces `target.com` which is an exact match for the legitimate domain
- Chromium's popular-domain protection detects that match and displays punycode instead
4
u/Angrymilks 12d ago
Wow, thank you for the reply! It’s been so long since I registered this domain that such protections in browser were non-existent. Glad to see they shored that up a bit, but still extremely funny that it’s alive and well.
3
u/ianmuscat 12d ago
Interestingly, this _does_ still work in Geko (Firefox) and Webkit (Safari)... maybe be a topic for future research :)
2
u/ChiefStrongbones 11d ago
Is there a mitigation? Like, is it easy to set the font-family of the addressbar to a font with a minimal Latin character set?
3
u/ianmuscat 11d ago
Not really, IDNs increase the number of confusables, but its generally a tradeoff of make the internet usable for non-English users. So its not something that's easily "solved", because these glyphs are used in other languages for legit reasons.
If you're a Firefox user, you have the option to opt out of IDNs entirely by setting `network.IDN_show_punycode` to `false` (always shows punycode), but as far as I'm aware, Chrome and Chromium-based browsers don't have a similar flag.
1
1
u/Ularsing 11d ago
If you're a Firefox user, you have the option to opt out of IDNs entirely by setting `network.IDN_show_punycode` to `false` (always shows punycode), but as far as I'm aware, Chrome and Chromium-based browsers don't have a similar flag.
Don't you mean
true? On my Firefox browser, that's what caused http://xn--taget-kp1b.com/ to render as http://xn--taget-kp1b.com/ (network.IDN_show_punycode = true), rather than as https://taṛget.com/ (network.IDN_show_punycode = false).Setting it to
trueis also recommended here: https://rubenhortas.github.io/posts/how-to-avoid-punycode-attacks-firefox/
3
2
u/arepodesir 11d ago
Is nothing sacred?! Lol scary stuff thanks for the reminder about invisible ascii 🙃
1
u/McLainLove 11d ago
Quick correction I found, u/ianmuscat,
ә is permitted (alongside cyrillic), it's CYRILLIC SMALL LETTER SCHWA (U+04D9)
ə is NOT permitted, and it's LATIN SMALL LETTER SCHWA (U+0259)
1
11d ago
[deleted]
0
u/Designer_Hour2146 10d ago
Well since nobody is answering that probably means it wasn’t a smart thing for me to even ask about? Yeah so I guess I will just delete it then. Carry on everyone, nothing to see here…
1
u/Callie-Schultz45 9d ago
This is a great reminder that teaching people to "just check the url" isn't nearly as simple as it sounds anymore, most users aren't going to recognize suspicious unicode characters when the address bar makes a domain look completely legitimate, I'm curious whether the behavior differs significantly between chrome on desktop and mobile, especially when the address bar is shortened or partially hidden, also makes me wonder how effective browser side detection can be without relying on users to recognize characters they probably didn't even know existed
1
u/Henrieta_Awonusi 7d ago
In email, this usually shows up in the sender domain or the link text. In Exchange, you can set a mail flow rule to flag or quarantine senders matching u/xn--, since punycode senders are rarely legitimate for most companies. Abnormal also flags lookalike sender domains.
1
u/Callie-Schultz45 5d ago
This is a good reminder that recognizing a domain visually isn’t the same as verifying it, people are constantly told to check the URL before entering credentials but that advice gets complicated when the address itself can be misleading. The interesting question is how browsers could communicate these IDN edge cases to ordinary users without turning every address bar into a wall of warnings
164
u/abbydoubleb22 12d ago
Even though it is not a vulnerability. Researches showed that most of the people would not pay too much attention to the URL… Valuable piece!