Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google-hosted malvertising leads to fake Keepass site that looks genuine

arstechnica.com

Post reply on HN
Print view View original

81–90 of 197 posts

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#81

Post by shiroiuma »

ykonstant wrote: post #60
mschuster91 wrote: post #35

Earlier quoted context omitted.

> 2) In advertisements, Google shouldn't allow the advertiser to modify the domain that is displayed. Really, why do they even do this? Because advertisers usually want to send links to a tracker site of their own first so that they can verify if their numbers match up with what Google reports. No one trusts anyone in the advertising space, and for good reasons. Advertising has always been a space filled to the brim…

>Advertising has always been a space filled to the brim with crooks and fraudsters. If I ever work at a cubicle, I will hang this sentence on a large frame over my desk, then stay silent and stare every time someone comes and complains about my ad blockers.

Unless you're working at an adtech company, why would anyone complain about your ad blockers at work? Or even notice?

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#82

Post by Tostino »

beeboobaa wrote: post #75

While Google is waging war against adblockers on YouTube they are once again showing they absolutely cannot be trusted with the responsibility of showing safe ads. That, and them showing war videos in ads to little kids.

While stopping journalists from using any footage of war regardless of context.

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#83

Post by SenAnder »

jowea wrote: post #73
SenAnder wrote: post #57

The root cause is alphabets/fonts with lookalike characters being permitted in security-critical contexts. Tracing further, it's the mindset that this is a valuable feature, and not a reckless risk, that is to blame. Browser designers should have been feverishly working to further disambiguate Il1O0, not add more risk by allowing a multitude of whole new alphabets!

It sucks but doing that would be unfair to the majority of the world not using the Latin alphabet. Maybe restricting those characters to the relevant top level domains? At least you'd notice you're on ķeepass[.]lv

> that would be unfair

They can install a browser plugin to convert punycode to their alphabet if they care so much for using it in URLs. There is no need to inflict this on peoples with safe alphabets. Alternately, highlight non-safe-ASCII-subset characters in a different color, as VS Code does.

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#84

Post by SenAnder »

yorwba wrote: post #78
SenAnder wrote: post #57

The root cause is alphabets/fonts with lookalike characters being permitted in security-critical contexts. Tracing further, it's the mindset that this is a valuable feature, and not a reckless risk, that is to blame. Browser designers should have been feverishly working to further disambiguate Il1O0, not add more risk by allowing a multitude of whole new alphabets!

When you're at a point where you're relying on a display name to make security-critical decisions, you've already lost. Character substitutions like ķeepass or ƙeepass or keypass are at least possible to spot if you know the name of the product, but not the full URL. But there are many ways to create lookalike domains that don't change the product name: https://keepass.org https://keepass.net https://keepass.info htt…

> When you're at a point where you're relying on a display name to make security-critical decisions, you've already lost.

This obscures how dramatically worse the situation is if you can't even trust display names. Does the ubuntu.com link on wikipedia lead to an ubuntu.com, or something entirely unrelated? Does a script you're reviewing actually pull images from debian.org, or somewhere else?

At some point you have no choice but to trust what they pixels on your screen are telling you.

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#86

Post by dspillett »

rapind wrote: post #54
rob74 wrote: post #47

Earlier quoted context omitted.

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.

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

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#87

Post by makeitdouble »

GoblinSlayer wrote: post #56
makeitdouble wrote: post #49

Earlier quoted context omitted.

One of the issue with ascii domains is the phonetic mapping for CJK languages. For instance right not asahi.com is taken by 朝日 (Asahi shibun, the newspaper), thus the Asahi town (旭) cannot use it. Mind you, the town could take asahi-town.co.jp or something like that, but there is other Asahi towns and places with different writings (including 旭日, 朝陽、浅緋 etc.) Wanting all of them to have some random ascii diversificati…

Ambiguity exists in all languages, e.g. what mail.com refers to?

There isn't as much ambiguity in the cjk writing though.

It would be similar to mail.com, mel.com, meil.com, mehl.com, melle.com and all other variations that sound roughly the same getting all mapped to meɪl.com

We could live in a world where all words are written phonetically, but we don't. Expanding that courtesy to non alphabetical languages would be a pragmatic and sane approach.

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#88

Post by tialaramex »

Semaphor wrote: post #71
Semaphor wrote: post #25

Earlier quoted context omitted.

Ah, that is interesting, thank you.

Also apparently wrong.

https://kb.mozillazine.org/Network.IDN.whitelist.*

Disappointingly .info is whitelisted, if it wasn't (like .com) then Firefox would use Punycode here instead. Perhaps Mozilla should re-consider the decision for info, or, perhaps they have and they decided that .info is doing enough (though clearly not in this case) to say that on balance it's acceptable.

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#89

Post by hkt »

beeboobaa wrote: post #75

While Google is waging war against adblockers on YouTube they are once again showing they absolutely cannot be trusted with the responsibility of showing safe ads. That, and them showing war videos in ads to little kids.

My seven year old kept being advertised shaving equipment, including razors. Obviously they know dad has a massive beard. Jokes aside though, I'd rather nobody be piqueing his interest in blades so I've adblocked the entire house.

Re: Google-hosted malvertising leads to fake Keepass site that looks genuine

#90

Post by gnfargbl »

jasode wrote: post #30

>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 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...

Post reply on HN