Google AMP – The Newest of Evasive Phishing Tactic | Hacker News Reader

Google AMP – The Newest of Evasive Phishing Tactic

cofense.com

211 pointsskilled84 comments

> Cloudflare CAPTCHA – The abuse of Cloudflare’s CAPTCHA service has become a popular anti-analysis tactic. Cloudflare is a legitimate domain security service used to keep websites secure from bots or other automated visitors. This has proven to be a very effective tactic at evading email security because the CAPTCHAs often come prior to any actual-malicious URLs.

Besides the obvious schadenfreude at AMP being abused, this stood out to me. It's just so delicious, malicious actors thwarting automated analysis of their shady links by including CAPTCHAs...

I've been complaining about this for a while. Everything I try to test with urlscan.io (as a safe sandbox to view a phishing site) has for a while just given me a Cloudflare captcha. Everything I submit to certain automated malware services just come back as "not malicious" despite being clearly malicious, I'm guessing because automation doesn't get past the catpcha.

This is going to get 10x as 'fun' once Web Environment Integrity means that malware developers can demand attestation that you're a real victim and not a URL scanner

That is exactly my worry. It's hard enough as it is with VPN / IP detection, headless detection, Captchas, etc. WEI would probably mean game over for all but a handful of Google-sanctioned bots.

I believe they simply need to integrate a captcha provider and write rules for detecting these captchas on various websites.

Many scraping products and the internal scraping systems of companies (especially retailers) implement such mechanisms.

CEO of urlscan.io here: We will be evaluating the use of captcha bypass services soon, we are fully aware of the growing problem of captchas being abused by threat actors to hide their malicious websites from automated analysis tools such as ours.

It's honestly a frustrating problem as we're effectively in an arms race with the likes of Cloudflare, Google et al, and we're in the same boat with less reputable services like scrapers and bots. The recent developments around Web Environment Integrity are concerning to us for the same reasons. Feel free to reach out with any questions or suggestions you might have!

Check https://docs.google.com/forms/d/e/1FAIpQLSdqYNuULEypMnp4i5pR... (linked from https://blog.cloudflare.com/friendly-bots/) if you didn’t already.

Disclaimer: I work at CF

Given the volume of automated link scraping that you do, would it be possible for your company to arrange for a deal with Cloudflare allowing your servers past their Captcha gate, at least around the free-tier Captcha which the scammers most likely use?

This right here is just such a scandal waiting to happen.

I am not familiar with your product but that won't stop me from suggesting that maybe a Y/N API needs a 3rd answer: N/A.

A captcha might serve as a strong negative signal.

So is there a solution to this? Kind of feels like the bad guys win.

The bad guys did win. Cloudflare is used by everything now. They're becoming a single point of failure.

Why do you need a safe sandbox to view a phishing site? Afraid the site's design could hypnotise you into entering your credit card details?

I would say that you don't absolutely need a service like urlscan.io to look at a single suspicious URL, but running a URL through our sandbox will create a point of time snapshot that you can share with others, compare to existing scans and use as evidence for further actions like takedown.

Disclaimer: I'm the CEO of urlscan.io

Multiples reasons actually.

1. To bypass your corporate proxy (ok, not the best reason);

2. urlscan also allows you to pivot easily and find the same phishing kit as they have a nice database of scans;

3. urlscan also allows you to see the website from different proxies, which can be useful if there is geofencing.

It isn't that simple and threat actors are far from being dumb :)

Phishing sites are often also loaded with malware

If you don't run adblocker pretty much any website is loaded with malware. New York Times was infecting people with Bahama botnet some years ago. What's stopping other (non)shady websites from doing just the same?

I want to browse the net with only bitmaps being sent to me. I do not want to execute your javascript or markup or make requests other than what i have initiated. Please god someone make a docker container i can spin up on a throwaway computer that renders pages and sends bitmaps of the site to my main computer

Edit: even better, every tab is a separate container instance, i close tab, it nukes the container

To render pages on a throwaway computer and send only bitmaps, connect to the throwaway computer via VNC and run an ordinary browser.

As for improving on tab isolation over what existing browser sandboxes already offer, lightweight virtualization a la Firecracker seems like a more useful increment than containerization, and, assuming each tab has a similar VNC-like connection to its browser VM, virtualization would also make the whole "throwaway computer" setup less necessary to provide a meaningful security improvement.

Sounds a bit like WebRenderingProxy.

Afraid the site's design could hypnotise you into double clicking the exe and accepting the browser's, MotW and smartscreen warning dialogs?

More worried about 0-day browser exploits. If you know a site is malicious, why risk it?

And the malware magically gets installed on your computer...how?

Here are 3 CVEs I randomly found from just this year. There are a handful of these every year.

https://nvd.nist.gov/vuln/detail/CVE-2023-3079

https://nvd.nist.gov/vuln/detail/CVE-2023-37450

https://nvd.nist.gov/vuln/detail/CVE-2023-32439

I guess you've never heard of browser exploits?

Didn't think about that, good point

the phishing attempt from the url that looks like it comes from your bank can also have exploits to attack your browser, other than getting you to enter your credit card details.

I would be worried about CSRF and other potential exploits..

See, that's why we need DRM aka Private Access Tokens [0]! /s

[0] https://blog.cloudflare.com/eliminating-captchas-on-iphones-...

Yes, great idea. And to be safe you could turn on Enhanced Google Safe Browsing so Google can scan the URLs in real-time to protect you against malicious Google AMP URLs.

Remember: Letting Google* decide what software you can run is for YOUR safety. Report anyone you see running unsafe software. Be safe. Let big Google watch over you.

* Applies to any other walled garden megacorp.

One more step Please complete the security check to access Why do I have to complete a CAPTCHA? Completing the CAPTCHA proves you are a human and gives you temporary access to the web property. What can I do to prevent this in the future? If you are on a personal connection, like at home, you can run an anti-virus scan on your device to make sure it is not infected with malware. If you are at an office or shared network, you can ask the network administrator to run a scan across the network looking for misconfigured or infected devices.

Ironic pop-up chat window: "Welcome <<wavy-hand emoji>>

Thank you for being a Cofense customer.

We <<heart emoji>> working with you and your team at Allianz. How can we help you today?"

I do not work at Allianz, but at another large German company that appears to share a web proxy service with Allianz, who are apparently Cofense customers (or Cofense believes they ought to be).

Web proxy service? You browse through a web proxy? I thought this was an obsolete piece of protocol.

It's not obsolete at all. It's more relevant than ever, imo. I do all of my browsing through a proxy (so that I can strip DoH requests out of the stream).

Any recommendations for my personal use? I have no control over the one at work, and am pretty ok with that.

You probably don't want to do it my way -- I've cobbled it together and it works, but it's not pretty.

In essence, what I've done is set up my router to intercept all HTTPS traffic and direct it to a proxy program that I wrote myself. All the program does is look for DoH traffic and drop it on the floor, just passing the rest on to its proper destination. This requires installing a custom cert on each browser so the proxy can decrypt the HTTPS stream.

If I were to do this today, I'd look into formal tools to do this, such as mitmproxy or somesuch. That's not a specific recommendation, I've never used it. But there are a number of similar tools available. One of them is likely to be a good solution!

Why? Do you have some black boxes that keep calling some DoH and you can't control that but they accept user CAs?

Happens often in enterprise, where all web traffic is intercepted via TLS MITM and screened for malware, DLP, phishing, etc.

Thats fair, but an enterprise instalation I saw used a transparent proxy and certs on client machines. By transparent proxy I mean a DPI firewall that somehow "hijacked" normal TLS sessions. I don't really know why, a HTTP proxy would be the obvious solution ...

Google tried to solve this by having the URL bar show the cryptographic origin of the page being displayed, rather than the URL it was fetched from (the delivery provider).

There was strong pushback here on HN - people cared more about who delivered the page than who wrote it. To me that argument is non-sensical - if you take it to the extreme, the URL bar should always just display 'data from Comcast via 192.168.0.1'

This is a strawman argument. You're misrepresenting the pushback and then argue against that misrepresentation.

A large part of the pushback can be summerized as such: "Google created a technology that is incompatible with the open web. Now they want browsers to change their behavior to solve some of the ways this breaks the web."

Google is the only company that can get away with this, due to their incredible market share in browser, mobile and web. Browser vendors serve as the gatekeepers deciding what the operating space is for web developers. As a result, web developers can't fundamentally change how the web works, for better or for worse. Google can, and did, and is now cleaning up the mess this left behind.

The entire argument comes down to whether you think AMP is a good or a bad thing. Either you believe it's good, and you believe browsers should change to make it work, or you believe it's bad, and it's a problem that google has so much leverage to push this tech onto us.

Signed exchanges don't prove that that is the CURRENT content from the purpoted website while hiding the true (hosting) URL would give that impression.

Within epsilon yes it does because the signer chooses the signature expiration and it's no more than 7 days.

If you don't like this you should also take issue with Cache-Control.

You, the website operator, opt in to signed exchanges and define exactly what resources are valid for how long. If you're okay with the browser caching pages there really should be no reason to be weirded out by any 3rd party caching them too.

I feel like that was just an exploit waiting to happen. Showing a different URL than the page was delivered from.

> URL bar show the cryptographic origin

Chrome’s URL bar? When was this?

Meta commentary:

I'm unable to browse that site without turning JavaScript off.

On mobile there's a cookie notification that takes up two thirds of the screen and only has an Accept option (yeahnah from me), and if I scroll down the page ever so slightly I get some kind of subscription advertising pop up.

visiting not well known infosec related sites without JS is good form in general. Especially if they ask to click on something, I recall user interaction is necessary for some exploits to work

read mode in firefox :)

I know that it's kind of OT, but why does this website force the user to accept third-party cookies? There's only the "Accept" button with no possibility to reject anything. Is this even legal?

>Is this even legal?

Not in the EU it's not.

It hasn’t been legal since 2009, and there’s only a handful of enforcement actions.

EU regulators are a joke.

I'm not surprised, this is exactly what everybody warned Google prior to deployment.

Fiddling up with the server addresses in an unintended way opens-up new doors for scams.

I don't think anyone at Google is surprised either.

I also saw this as Google feeling threatened by users knowing the url and going directly to websites other than Google. Remove the URL and all browsing is on Google.

It's because they're a web-based, thus fairly open platform. Facebook et al do far more things to keep you in because most use is app-based. Google isn't threatened by users. It's threatened by competitors.

Threatened by their users knowing what they are doing. Never had a FB account.

Serving a Scam URL with a giant amount of text after the # sign is genius. You can have something that looks completely clean for anyone else, then the actual payload if they provided the # data, or even the payload encoded as the # data.

Isn't there a limit on url length?

Holy shit, what about users who have a password manager that autofills that stuff?

It's just a redirect, this isn't an issue. The browser will use the final URL to decide which passwords to look up.

The issue is for clients that don't follow URLs and also manage abuse reputation by domain name. For example, if your webmail client knows that "evilsite.com" is bad because it's frequently reported spam, then you just start using links to "google.com/amp/evilsite.com" and the webmail client's reputation score resets.

How do they protect against websites stealing cookies and executing javascript on google.com origin? This was a stupid idea altogether. They have the googleusercontent.com domain for thus very reason. Why didn't they host amp on per-remote-origin origins?

https://_https.www.remote-website.com.amp.googleusercontent....

They've done exactly this with https://example-com.translate.goog

Yeah. Though they have a potential bug with domains that end in a dot.

For example, my website translated with their service:

https://splet-4a-si.translate.goog/?_x_tr_sch=http&_x_tr_sl=...

Clicking on the link "version control" leads to the page

https://ni-xn----ijanec--9jb-eu-.translate.goog/?_x_tr_sch=h...

(note the second label ending with -) and this page can't be reached according to google, but on the real site (http://splet.4a.si), the link is valid: https://ni.xn--ijanec-9jb.eu/

Another pretty bad aspect of their domain handling (replacing dot with -) is that they can't support really long domains that exceed the length of a label. Secondly, this breaks punycode parsers and instead of "šijanec" as a label you get some garbled unreadable punycode.

Label length problem:

Website http://splet.sijanec.sijanec.sijanec.sijanec.sijanec.sijanec... cannot be unambiguously page-translated with their service. -- they remove the first s in the hostname, yielding:

https://plet-sijanec-sijanec-sijanec-sijanec-sijanec-sijanec...

EDIT: they seem to add a get parameter _x_tr_hp=s, so this is probably how they work around the limitation. Nice!

They could've done www.website.example.translate.goog, but that would add issues with TLS, since a wildcard subject alternative name only matches one label. But by getting a CA signed cert, limited to translate.goog (which is possible), they could just issue certs on the fly.

The amp version gets around the length by hashing the hostname if it's too long:

https://amp.dev/documentation/guides-and-tutorials/learn/amp...

Interesting, but that means they have to store the hostname somewhere.

It's repeated in the URL path, not just the hostname.

Ah, I see!

I thought that AMP was dead?

It has ceased development and Google no longer tries to push it, but unfortunately many large and slow-moving publications already hitched themselves to the wagon.

I was about to point at The Guardian as an example, but it looks like they managed to migrate off. Good riddance.

Thanks, kind of makes sense, they found an even more evil way to try and control the web.

On the web, nothing ever dies. It only gets shoved aside and forgotten about.

In the modern centralized web things die all the time.

Google is probably the prime example of this...

Predicted [0] three years ago by user A4ET8a8uTh0 and myself (I've also written similar comments for the past six years).

[0] https://news.ycombinator.com/item?id=23324576

Stop playing cat vs mouse and start using a physical hardware token as a 2fa. This makes it impossible to phish people because anything but the right domain gets a wrong key.

except that there's tens of them and each implementation requires a specific one.

They pretty much all support u2fa

Would the setting in Brave protect against this?

https://support.brave.com/hc/en-us/articles/8611298579981

Wouldn't a easy solution for coop networks be to automatically redirect amp-urls to non-amp-urls?

Reply on news.ycombinator.com