Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

>A closer link at the link, however, shows that the site is not the genuine one. In fact, ķeepass[.]info —at least when it appears in the address bar—is just an encoded way of denoting xn--eepass-vbb[.]info, which it turns out, is pushing a malware family tracked as FakeBat. Combining the ad on Google with a website with an almost identical URL creates a near perfect storm of deception.

“Users are first deceived via the Google ad that looks entirely legitimate and then again via a lookalike domain,” Jérôme Segura, head of threat intelligence at security provider Malwarebytes,

Back in 2017, Google Chrome 59 supposedly fixed the Punycode phishing attack. E.g. story: https://www.engadget.com/2017-04-17-google-chrome-phishing-u...

Maybe a dedicated criminal studied the Chromium source code that checks Punycode and noticed a flaw where it would allow 'ķ' in place of 'k' ???

https://www.xn--80ak6aa92e.com/ --> fake "аррӏе.com" triggers phishing warning

https://xn--eepass-vbb.info/ --> fake "ķeepass.info" does not trigger warning

The relevant sections of the Chrome IDN rules [1] seem to be detection of "mixed script confusables" and "whole script confusables".

The character ķ (U+0137) is part of the Latin script [2], so I presume the string "ķeepass.info" won't trigger the mixed-script confusable test.

I don't see ķ listed in the "whole script confusable" glyphs [3]. Should ķ be included there? There's a comment in the Greek section of that file to the effect that "variants such as ά, έ, ή, ί" are ignored, so perhaps there is a general rule that accented characters are not considered to be confusables? If so, that makes some sense to me; French users would presumably be a bit disappointed if a domain name containing an é were rendered in the Punycode form, for instance.

[1] https://chromium.googlesource.com/chromium/src/+/main/docs/i...

[2] https://www.compart.com/en/unicode/U+0137

[3] https://source.chromium.org/chromium/chromium/src/+/main:com...

The first "punycode attacks" were using letters that were completely indistinguishable from the "real" ones (e.g. by using Cyrillic letters). I guess the assumption is that the user would be able to identify any letters with diacritics (even if they're indistinguishable from specks of dust on your screen) and avoid them - after all, you wouldn't go to "göogle.com" either?

ķ does look a lot like screen dirt though. ö not so much.

Yeah it's really frustrating for me to look at it because of such appearance.

Also the , may be somewhat obscured by link underlining, which additions atop a letter would not be.

Modern typography in Firefox and Edge (I can't speak to Chrome as I don't have it installed) has actually done a great job of skipping underlines across descenders of all sorts (as proper underlining is supposed to do).

http://test.xn--ifa.test

Ah, funny. HN renders the ķ as punycode in urls. In the interest of sharing negative results, I leave this here.

I tried to brush the dust off my screen before reading reading your comment. Can confirm, does look like dust

weird because the keepass example, on chrome + android, looks exactly like a regular k in the address bar.

>looks exactly like a regular k in the address bar.

Because there's a quick 302 redirect from "ķeepass.info" to "keepass.info" :

Chrome F12 Dev Tools network trace: https://imgur.com/a/vrxjsUV

Whether that redirect was there at the time of the Arstechnica article, I don't know.

EDIT ADD: around 12:57 UTC, the 302 redirect was changed to a Youtube video: https://imgur.com/a/TtLxafP

(Somebody is apparently having fun trolling the internet.)

ICANN lookup trivia says "ķeepass.info" domain was created 3 days ago:

  Domain Information
  Name: xn--eepass-vbb.info
  Internationalized Domain Name: ķeepass.info
  Registry Domain ID: a375f89abb384328a10460509f9f99f8-DONUTS
  Domain Status:
  clientTransferProhibited
  addPeriod
  Nameservers:
  leia.ns.cloudflare.com
  sevki.ns.cloudflare.com

  Dates
  Registry Expiration: 2024-10-16 10:21:45 UTC
  Updated: 2023-10-19 11:40:19 UTC
  Created: 2023-10-16 10:21:45 UTC

Well that's good news, I was a little worried that it would be impossible to tell on mobile

As a german I wouldn't go to göogle.com. If my native language didn't include ö? Then that might be a speck of dust to me as well.

A safer approach would be to only ever show a user the characters they expect to see (and are familiar with), e.g. based on their language setting. Assuming that every language has a finite list of characters used in its written form such a whitelist approach should be possible and much better than playing whack-a-mole with a blacklist for "potentially confusable" characters.

I don't think it's that easy. Most people A) use english as their system language, because troubleshooting menus / error messages in foreign languages is a nightmare, and B) my mom would not notice the difference between google and göogle.

> Assuming that every language

Oof.

Take for example, both 糉 and 糭 are valid characters in Chinese. One is a variant of the other. Which one is "canonical" depends on who (i.e. which authority, of which there are many) you ask. And FWIW the language and regional settings don't necessarily give an answer to the canonical representation.

Those characters mean the same thing with or without the specks of dust.

So, what's your solution here?

To be fair, Unicode domains are inherently a huge mess. The thing is that we don't need more armchair experts dreaming up Euro-centric solutions.

It still sounds like an improvement: while they might still fall for malicious URLs in their own language, they would not for other scripts.

But as someone said, tiny, valid differences are easy to miss anyway, and original URL attacks were replacing similar-looking ASCII graphemes (eg. l for 1), so this will all continue.

> while they might still fall for malicious URLs in their own language, they would not for other scripts.

That's totally backwards. If the assumption is that users of language X will legitimately visit sites of language Y with sufficient frequency, then all that language-specific filtering makes no sense.

If a browser implements single language decode-punycode, they could also support user specifying multiple languages (like they do for Accept-Language).

And seeing punycode in URL bar does not mean a site does not work, it's only a suboptimal experience.

Why wouldn't it make sense? If a chinese user e.g. specifies that they speak chinese and, say, french, all characters in those two language would show up as unicode and everything else as punycode. A malicious domain using e.g. cyrillic characters to create a domain that looks just like another french (or just plain-ASCII) one would show up as punycode. Sounds like a net improvement over what we have now.

What you mention here does not contradict my assumption that there is a finite set of valid characters in every language, unless there is a rule in chinese that lets you assemble an infinite set of meaningful characters/symbols (unicode could still represent only a finite subset of those, though).

Either one or both of the characters you mention are probably part of the script of the users language setting in chinese; if the character is then it should be rendered as unicode and if not as punycode. If the users language has this kind of ambiguity then they are the only ones to judge if the domain name is correct or not, but at least they are familiar with the language and do not see characters they might have never encountered before and/or need to deal with an ambiguity that they shouldn't even have to expect to begin with.

The idea I proposed would still protect someone with a chinese language setting from being tricked by e.g. a cyrillic character in an otherwise ASCII domain name. I don't see how that is euro-centric (apart from ASCII being inherently english-centric), it is an overall improvement over the status quo no matter where you live and what language you speak.

Reply on news.ycombinator.com