Impersonating the brave.com website to deliver malware(arstechnica.com)
arstechnica.com
Impersonating the brave.com website to deliver malware
https://arstechnica.com/gadgets/2021/07/with-help-from-google-impersonated-brave-com-website-pushes-malware/#p3
39 comments
In Firefox, it used to show the punycode when clicked on the lock icon. Now I just checked one such domain(https://www.xn--80ak6aa92e.com/) and it didn't show the punycode until I clicked the lock icon > Connection Secure > More Information > View certificate button. I didn't know that the behavior was changed... I would have clicked the lock icon, saw `www.аррӏе.com` and would have believed I was visiting apple.com. I think it should not take more than one click to see the punycode, let alone a couple of clicks and opening a new dialog box.
Google Ads and Play store are impossible to deal with what comes to scams. I contribute to an open source project and we need to have scam support channel in Discord, because scamming is so rampart. Google offers no avenue for any meaningful manual resolution.
https://mobile.twitter.com/moo9000/status/138419716439861658...
https://mobile.twitter.com/moo9000/status/136785214503120896...
https://mobile.twitter.com/moo9000/status/138419716439861658...
https://mobile.twitter.com/moo9000/status/136785214503120896...
In the future, we might have some crypto based web of trust that prevents this.
Every page will be signed by a key and our browser will show the popularity and karma of that key.
The popularity and karma of a key will probably be readable on a blockchain, similar to the account balance of a Bitcoin address.
If one was to download a popular software and then sees the website is not signed by a popular key, they would double check if they are on the right site.
Karma will probably be a customized value. Counting the opinions of my friends over the opinions of my friends friends etc.
Every page will be signed by a key and our browser will show the popularity and karma of that key.
The popularity and karma of a key will probably be readable on a blockchain, similar to the account balance of a Bitcoin address.
If one was to download a popular software and then sees the website is not signed by a popular key, they would double check if they are on the right site.
Karma will probably be a customized value. Counting the opinions of my friends over the opinions of my friends friends etc.
What's the difference between what you propose and the (PGP) web of trust?
https://en.wikipedia.org/wiki/Web_of_trust
https://en.wikipedia.org/wiki/Web_of_trust
It is related but not the same.
WOT: "The owner of this key is Joe Doe as confirmed by Susi Dusi and Lars Lampert".
What I mean: "The ownder of this key has a popularity of 23 (as can be seen on chain) and a karma of 75 (as calculated from my personal social graph or interests and on chain data)".
Looking at a Bitcoin address you can see that the owner of that address owns at least X bitcoin. But you don't know who he is. This is what I propose for popularity and karma.
WOT: "The owner of this key is Joe Doe as confirmed by Susi Dusi and Lars Lampert".
What I mean: "The ownder of this key has a popularity of 23 (as can be seen on chain) and a karma of 75 (as calculated from my personal social graph or interests and on chain data)".
Looking at a Bitcoin address you can see that the owner of that address owns at least X bitcoin. But you don't know who he is. This is what I propose for popularity and karma.
I see. Though you still need a way to prevent rogue actors exploiting or gaming the system. The popularity (on chain) has no meaning if it's trivial to grow it (see google's page rank), or if it's not transparent where it's coming from (for example I would not trust a bitcoin address if I knew its inputs are coming from criminal activities).
How does my grandmother translate this into "is this safe to click on"?
She doesn’t. You’d have to have a browser that programmatically utilizes the info to allow or deny the link.
I think it should go one step further - if Google determines a link is a Apple ID phishing link it just silently redirects it to Apple’s real ID login page. Anything that presents a barrier that you can apparently solve is going to be bypassed.
The largest providers could register their login page look and feel with the biggest browsers and nobody would be allowed to mimic them.
I think it should go one step further - if Google determines a link is a Apple ID phishing link it just silently redirects it to Apple’s real ID login page. Anything that presents a barrier that you can apparently solve is going to be bypassed.
The largest providers could register their login page look and feel with the biggest browsers and nobody would be allowed to mimic them.
> The largest providers could register their login page look and feel with the biggest browsers and nobody would be allowed to mimic them.
Lol, amazon would in a heartbeat declare any page which has two input fields and a button as a 'login page' (regardless of the actual styling).
Lol, amazon would in a heartbeat declare any page which has two input fields and a button as a 'login page' (regardless of the actual styling).
Ransomware shops with plenty of affiliates should rank well on it
Or simply not having to download and install app from webpages and have a distribution system that is easier to monitor for suspicious activity like there is for linux distibutions.
On Windows there's the Windows Store, Chocolatey and Scoop. Of those three, Choco has the Brave browser.
Of course all three options fail to gain significant traction. The Windows Store tries to change the entire concept of a Windows application, while Choco and Scoop are command line applications targeted at IT admins.
Of course all three options fail to gain significant traction. The Windows Store tries to change the entire concept of a Windows application, while Choco and Scoop are command line applications targeted at IT admins.
User education is the only long-term solution that also retains the freedom to use general purpose computation. Otherwise the market will differentiate into hyper-locked down, curated devices like the iOS but even stricter, and customisable ones targetting tech folk.
In the meantime browsers can include a list of all popular software vendor domains and flag users navigating to similar but different domains. This will not be the first or the last whitelist that browsers include.
In the meantime browsers can include a list of all popular software vendor domains and flag users navigating to similar but different domains. This will not be the first or the last whitelist that browsers include.
User education is not going to happen. Half of the population have an IQ of less than 100, and 100 isn't enough to understand half of the issues. A large majority of users needs extensive support; general purpose computing isn't for them.
I don't think it automatically leads to "hyper lock-down". An environment like the browser can do almost anything users want, and can be made safer. But if the tech sector refuses to cooperate, or is inept, then we might head down lock-down road.
I don't think it automatically leads to "hyper lock-down". An environment like the browser can do almost anything users want, and can be made safer. But if the tech sector refuses to cooperate, or is inept, then we might head down lock-down road.
> Half of the population have an IQ of less than 100
IQ is normalized on averages, not medians.
That makes quite a difference. E.g. you could have a massive number of people at 99.9 against a few of 150.
IQ is normalized on averages, not medians.
That makes quite a difference. E.g. you could have a massive number of people at 99.9 against a few of 150.
Isn't IQ normal distributed? Average and median are the same in a normal distribution.
It is. Average is 100, standard deviation 15.
This yes. Users are stupid. I count myself among them.
You cannot educate your users. You need to solve this some other way.
You cannot educate your users. You need to solve this some other way.
Users are NOT stupid. This perpetuates the myth that if you’re smart you’ll have no problem.
It’s too easy to blame the users for not checking everything - but nobody has the time to check everything. Not everyone can be a domain expert in everything.
Do you verify that the building claiming to be your bank is still your bank and wasn’t replaced overnight?
I agree that it can’t be solved by “making people smart” - the solution has to be something else. Things like “sign in with Apple” that are engineered so that they sign in CANNOT work at a non Apple domain (because the username the phone sends is based on the certificate sent by the website or something) are things we’ll need.
It’s too easy to blame the users for not checking everything - but nobody has the time to check everything. Not everyone can be a domain expert in everything.
Do you verify that the building claiming to be your bank is still your bank and wasn’t replaced overnight?
I agree that it can’t be solved by “making people smart” - the solution has to be something else. Things like “sign in with Apple” that are engineered so that they sign in CANNOT work at a non Apple domain (because the username the phone sends is based on the certificate sent by the website or something) are things we’ll need.
This is something that should be possible to detect through certificate transparency logs, right?
The article says that the site has a valid certificate and it should have been possible to detect that domain certificate generation through one of the CT logs? The website hosting company took the domains down in this case but maybe there needs to be a good automated solution which would help most companies report when they did find phishing sites using lookalike domains. Not a trivial problem to solve, I guess.
The article says that the site has a valid certificate and it should have been possible to detect that domain certificate generation through one of the CT logs? The website hosting company took the domains down in this case but maybe there needs to be a good automated solution which would help most companies report when they did find phishing sites using lookalike domains. Not a trivial problem to solve, I guess.
A quick browser based fix: punycode should be displayed as punycode unless the browser is setup such that the language the charecters belong to is the same language the OS uses.
I refer you to this much more, um, nuanced solution already in place in a number of top browsers:
https://chromium.googlesource.com/chromium/src/+/main/docs/i...
https://wiki.mozilla.org/IDN_Display_Algorithm#Algorithm
Safari (implicitly) bans scripts with letters that look like Latin characters. https://support.apple.com/kb/TA22996
https://en.wikipedia.org/wiki/IDN_homograph_attack#Client-si... also indicates that Edge, Opera use Chrome's algorithm (makes sense, being built on Chromium).
https://chromium.googlesource.com/chromium/src/+/main/docs/i...
https://wiki.mozilla.org/IDN_Display_Algorithm#Algorithm
Safari (implicitly) bans scripts with letters that look like Latin characters. https://support.apple.com/kb/TA22996
https://en.wikipedia.org/wiki/IDN_homograph_attack#Client-si... also indicates that Edge, Opera use Chrome's algorithm (makes sense, being built on Chromium).
What’s interesting is much of this is designed to protect the English-compatible world - I don’t know the problem set for confusingly similar Han characters (and even if it’s a thing).
It is probably already too late to put this in practice, as it is a breaking change, but...
Wouldn't applying Unicode normalization on domains solve this issue? For example, if a site attempts to send me to “ápple.com”, my user-agent would send me to the correct domain. Domains in Japanese, for example, would still work just fine.
Ideally, this would be handled at the DNS spec level (“no two domains shall map to the same normalized form”), but that would be even more “too late” to change.
Wouldn't applying Unicode normalization on domains solve this issue? For example, if a site attempts to send me to “ápple.com”, my user-agent would send me to the correct domain. Domains in Japanese, for example, would still work just fine.
Ideally, this would be handled at the DNS spec level (“no two domains shall map to the same normalized form”), but that would be even more “too late” to change.
This could be done at the client level using some normalization plus a bit of reputation.
"Did you intend to go to “ápple.com” (suspected malware host), or “apple.com” (100b visitors a year)?
"Did you intend to go to “ápple.com” (suspected malware host), or “apple.com” (100b visitors a year)?
[deleted]
Things like this is why i try to block all ads on my machines and my routers. Turned it off a few days ago to debug my new setup and holy batman, its as night and day the different experience of browsing the net with and without adblock.
Punycode should be permanently disabled. No upsides at all.
Did you read the text at all? The world speaks more then english.
Just 13% of the world speaks english. It is not a reference for how we do or should write on the web.
It would maybe make sense to restrict url display to the computers language setting.
Just 13% of the world speaks english. It is not a reference for how we do or should write on the web.
It would maybe make sense to restrict url display to the computers language setting.
The software world is dominated by English language, especially American English.
It does make sense to permanently disable Punycode.
It does make sense to permanently disable Punycode.
That's good in theory. The reality is that punycode never took off anywhere in the world.
Unless you're proposing we let it live in case someone somewhere ever uses it. Then, sure.
Unless you're proposing we let it live in case someone somewhere ever uses it. Then, sure.
How does the popularity of https://en.wikipedia.org/wiki/.%D1%80%D1%84 square with your theory that it "never took off anywhere in the world" ?
Of course that registry actually has a sane punycode policy, so such impersonations are impossible there, whereas they're happening all the time in .com. Maybe time to re-evaluate your idea of "reality" versus "theory".
Of course that registry actually has a sane punycode policy, so such impersonations are impossible there, whereas they're happening all the time in .com. Maybe time to re-evaluate your idea of "reality" versus "theory".
Not for English speaking people, as a Dane it is nice to be able to use our actual alphabet to spell words, even if the letters weren't in the ASCII alphabet.
Though why you should be able to purchase .com domains with punycode, I don't know.
Though why you should be able to purchase .com domains with punycode, I don't know.
Each TLD gets to set its own rules for name registration under that TLD. In particular they all have punycode policies. For example a country which uses a Latin alphabet with a handful of extra characters might requires names under its ccTLD to be from that alphabet, and not, for example, Cyrillic. Or a TLD operated on behalf of a region dominated by one writing system might require names to use that writing system. The attention of TLD registry operators was drawn to the need to prevent the exact types of fraud we're seeing here.
The .com TLD registry's priority is profit at any cost. A crook's money is just as good as anybody else's, right?
The .com TLD registry's priority is profit at any cost. A crook's money is just as good as anybody else's, right?
It's funny that both in the Ars comments and here someone talks about punycode.