It's explained in replies to the tweet, Google apparently lets you specify a "display URL", that's updated immediately but only verified within 24h for trusted accounts. (https://eligrey.com/blog/link-fraud/)
I think this came up before in the context of scammy Google ads. Apparently you can set any vanity URL you like to be displayed, which indeed seems like the perfect invitation for scammers if it works without any restrictions.
The intent is clear, yes. But given how well-known this problem is by now, I would expect a company of the size of Google to have a practical solution to combat this sort of scam, e.g. requiring that the vanity URL points to page containing a specific advertiser ID in the HTML source, or that the canonical URL of the URL with tracking parameters points to the vanity URL, etc...
There's so many solutions to this problem that allow vanity URLs to continue to work. Google just doesn't care.
Yeah, agreed. Or even that the advertiser has a subdomain of the target, like set your DNS of stats.brew.sh (I know they weren't actually buying ads, but just as an example) to be an IP of the tracking system, and then you can just verify the domain names match again.
I don't get what non-malicious reason there would be for not automatically verifying domain ownership of display urls as an advertising network. The advertiser is highly likely to already have a Search Console account in which they'd have had to verify it, and URL verification is easily done by all kinds of systems via meta tags, CNAME or TXT entries, etc. Why not for ads?
The attack vector for scams seems immediately apparent, so this just seems very negligent.
It also reduces the risk for advertisers as the profit from taking over an ad account is less if you can't direct users to malware from an account with good standing (of course there are still other ways to show malicious ads).
Ugh, I've seen this before with Todoist. I got as far as downloading the app package before realizing it was spelt incorrectly, and so was the domain. (Though the domain was correct in the ad, and the ad was identical to the actual search result below it.)
SEO is also damaging the search engines, and IMHO should be considered as a viral activity.
It is not uncommon to find a legitimate software site on the second page of a search, while all the hits on the first page are crap, often with malware added.
It's not even SEO here. It's Google ads from hijacked accounts. You can just run ads on open source software keywords and bam, top result is your malware. Since very few others will advertise on oss.
We had to deal with attacks on freecad and kicad last year via dozens of hijacked AdWords accounts and had to use a back channel at Google to get them removed.
That has to be the most suspicious possible alternative they could have chosen to "blindly pipe curl into bash," which most developers would probably run without a second thought.
Apparently, it was collecting passwords from victim machines. So, step one would be to remove everything the script put onto your machine. Step two would be to change your passwords.
Step one is to unplug the machine from the internet. Step two is to use another machine to change all your passwords, starting with the “pivot” passwords - your password manager master password, your email accounts, your AppleID, your mobile provider - followed by financial accounts and then all others. While changing passwords, make sure to “invalidate all sessions” where possible.
Only after you’ve done all this should you move onto Step 3: reformat your computer and install the OS from scratch.
Is there any way to check if you're affected? I just happened to install Homebrew while the malicious site was up and now I'm not sure if I installed the legit version.
I'd isolate the machine from the internet, change my passwords from a trusted machine, save the media and documents from the isolated machine, and then reinstall the OS / factory reset the isolated machine. Still, I'm sure that there are technical possibilities that this doesn't account for, but I think I would be okay with the procedure nevertheless.
How is it possible that in this screenshot, the URL shown on the sponsored result / ad is "https://www.brew.sh"?
Can a Google search ad display a different value there than the actual origin of the page?
It's explained in replies to the tweet, Google apparently lets you specify a "display URL", that's updated immediately but only verified within 24h for trusted accounts. (https://eligrey.com/blog/link-fraud/)
Ah thank you! Replies are not visible without a Twitter account so I didn't see that.
Seems like an absolutely terrible idea.
fyi you can modify the URL to xcancel.com to view replies
I think this came up before in the context of scammy Google ads. Apparently you can set any vanity URL you like to be displayed, which indeed seems like the perfect invitation for scammers if it works without any restrictions.
Presumably it's so you see the nice destination URL, and not the link tracking URL.
The intent is clear, yes. But given how well-known this problem is by now, I would expect a company of the size of Google to have a practical solution to combat this sort of scam, e.g. requiring that the vanity URL points to page containing a specific advertiser ID in the HTML source, or that the canonical URL of the URL with tracking parameters points to the vanity URL, etc...
There's so many solutions to this problem that allow vanity URLs to continue to work. Google just doesn't care.
Yeah, agreed. Or even that the advertiser has a subdomain of the target, like set your DNS of stats.brew.sh (I know they weren't actually buying ads, but just as an example) to be an IP of the tracking system, and then you can just verify the domain names match again.
Yes! This is working as intended, because it earns more money.
I don't get what non-malicious reason there would be for not automatically verifying domain ownership of display urls as an advertising network. The advertiser is highly likely to already have a Search Console account in which they'd have had to verify it, and URL verification is easily done by all kinds of systems via meta tags, CNAME or TXT entries, etc. Why not for ads?
Well… marketing and web development are often at war with one another inside individual organizations.
And the person running the ads almost never has domain-verification authority.
So Google doesn’t want to introduce a major barrier to accept money. I think that makes sense without being malicious.
The attack vector for scams seems immediately apparent, so this just seems very negligent.
It also reduces the risk for advertisers as the profit from taking over an ad account is less if you can't direct users to malware from an account with good standing (of course there are still other ways to show malicious ads).
I mean, Google is incentivized here to reduce friction on advertisers instead of protecting losses they wouldn't even incur from a malicious ad
in other words, a malicious ad doesn't do much for them but actively increasing security is bad. yay capitalism
Every time there's this kind of news, there's always other comments with similar news: https://x.com/alexrozanski/status/1881043544204599330 (or https://www.reddit.com/r/Bitwarden/comments/1cwc0r9/caution_...)
And then some people here attacked content blocker users with:
> Why would I, as a developer whose income stream is based on advertising, intentionally cater to users who are costing me money?
> you're destroying the open web
If even the FBI calls out your industry[1], sorry, your AdTech industry, your source of income is beyond broken now.
[1]: https://www.ic3.gov/PSA/2022/PSA221221
Ugh, I've seen this before with Todoist. I got as far as downloading the app package before realizing it was spelt incorrectly, and so was the domain. (Though the domain was correct in the ad, and the ad was identical to the actual search result below it.)
It has to be deliberate by Google at this point.
SEO is also damaging the search engines, and IMHO should be considered as a viral activity.
It is not uncommon to find a legitimate software site on the second page of a search, while all the hits on the first page are crap, often with malware added.
It's not even SEO here. It's Google ads from hijacked accounts. You can just run ads on open source software keywords and bam, top result is your malware. Since very few others will advertise on oss.
We had to deal with attacks on freecad and kicad last year via dozens of hijacked AdWords accounts and had to use a back channel at Google to get them removed.
That has to be the most suspicious possible alternative they could have chosen to "blindly pipe curl into bash," which most developers would probably run without a second thought.
Any advice on what to do if you might be a victim to this?
Apparently, it was collecting passwords from victim machines. So, step one would be to remove everything the script put onto your machine. Step two would be to change your passwords.
Step one is to unplug the machine from the internet. Step two is to use another machine to change all your passwords, starting with the “pivot” passwords - your password manager master password, your email accounts, your AppleID, your mobile provider - followed by financial accounts and then all others. While changing passwords, make sure to “invalidate all sessions” where possible.
Only after you’ve done all this should you move onto Step 3: reformat your computer and install the OS from scratch.
Step 3 should probably be reinstalling the OS, and restoring data from backup (ideally from before the malicious version was installed).
And install ublock origin going forward.
Is there any way to check if you're affected? I just happened to install Homebrew while the malicious site was up and now I'm not sure if I installed the legit version.
Check if /tmp/update exists. If it does, you’re infected.
I think the malware tries to delete this file. So, it won't be a reliable method to identify whether you were infected.
I'd isolate the machine from the internet, change my passwords from a trusted machine, save the media and documents from the isolated machine, and then reinstall the OS / factory reset the isolated machine. Still, I'm sure that there are technical possibilities that this doesn't account for, but I think I would be okay with the procedure nevertheless.