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

Polyfill supply chain attack hits 100K+ sites

sansec.io

Post reply on HN
Print view View original

31–40 of 387 posts

Re: Polyfill supply chain attack hits 100K+ sites

#31

Post by rolph »

im3w1l wrote: post #11

So what did the malware actually do ?

The first time a user, who uses a phone, open a website through an ads ( google ads or facebook ) with this link, it will redirect user to a malicious website.

The request send to https://cdn.polyfill.io/v2/polyfill.min.js needs to match the following format:

        Request for the first time from a unique IP, with a unique User-Agent.
        User-Agent match that of a phone, we used an iphone's user agent ( Mozilla/5.0 (iPhone14,2; U; CPU iPhone OS 14_0 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0 Mobile/15E148 Safari/602.1 ).
        Referer from a reputable website that installed polyfill.
        Accept /
        Accept-Encoding gzip, deflate, br, zstd
        Delete all cookies
The request will return the original polyfill code, appended with a piece of malicious code. This code will make a run javascript from https://www.googie-anaiytics.com/ga.js , if the device is not a laptop. You can reproduce this multiple time on the same machine by changing User agent gently, (ex: change Mozilla/5.0 to Mozilla/6.0). Sometimes the server will just timeout or return code without the injection, but it should work most of the time.

The javascript on https://www.googie-anaiytics.com/ga.js will redirect users to a malicious website based on some condition check for a number of conditions before running ( useragent, screen width, ...) to ensure it is a phone, the entry point is at the end:

bdtjfg||cnzfg||wolafg||mattoo||aanaly||ggmana||aplausix||statcct?setTimeout(check_tiaozhuan,-0x4*0x922+0x1ebd+0xd9b):check_tiaozhuan();

The code has some protection built-in, so if it is run on a non-suitable environment, it will attempt to relocate a lot of memory to freeze the current devices. It also re-translate all attribute name access with _0x42bcd7 .

https://github.com/polyfillpolyfill/polyfill-service/issues/...

Re: Polyfill supply chain attack hits 100K+ sites

#32

Post by yesimahuman »

baxtr wrote: post #7

Important context given by the author of polyfill: > If your website uses http://polyfill.io , remove it IMMEDIATELY. I created the polyfill service project but I have never owned the domain name and I have had no influence over its sale. (1) Although I wonder how the GitHub account ownership was transferred. (1) https://x.com/triblondon/status/1761852117579427975

Does this person telling us not to use polyfill.io, and the guy who sold polyfill.io to the chinese company both work at Fastly? If so, that's kind of awkward...

Re: Polyfill supply chain attack hits 100K+ sites

#33

Post by no_wizard »

I can’t believe the Financial Times didn’t secure the domain for the project. They backed it for a long time then dropped support of it.

I wonder if the polyfills themselves are compromised, because you can build your poly fill bundles via npm packages that are published by JakeChampion

Re: Polyfill supply chain attack hits 100K+ sites

#35

Post by jweir »

irrational wrote: post #29
pimterry wrote: post #17

> this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io I've said it before, and I'll say it again: https://httptoolkit.com/blog/public-cdn-risks/ You can reduce issues like this using subresource intergrity (SRI) but there are still tradeoffs (around privacy & reliability - see article above) and there is a better solution: self-host your dependencies behind a CDN servic…

> self-host your dependencies I can kind of understand why people went away from this, but this is how we did it for years/decades and it just worked. Yes, doing this does require more work for you, but that's just part of the job.

Own your process – at best that CDN is spying on your users.

Re: Polyfill supply chain attack hits 100K+ sites

#36

Post by jermaustin1 »

koolba wrote: post #20
davidfischer wrote: post #15

Earlier quoted context omitted.

SRI generally won't work here because the served polyfill JS (and therefore the SRI hash) depends on the user agent/headers sent by the user's browser. If the browser says it's ancient, the resulting polyfill will fill in a bunch of missing JS modules and be a lot of JS. If the browser identifies as modern, it should return nothing at all. Edit: In summary, SRI won't work with a dynamic polyfill which is part of the…

It absolutely would work if the browser validates the SRI hash. The whole point is to know in advance what you expect to receive from the remote site and verify the actual bytes against the known hash. It wouldn’t work for some ancient browser that doesn’t do SRI checks. But it’s no worse for that user than without it.

They are saying that because the content of the script file is dynamic based on useragent and what that useragent currently supports in-browser, the integrity hash would need to also be dynamic which isn't possible to know ahead of time.

Re: Polyfill supply chain attack hits 100K+ sites

#38

Post by koolba »

davidfischer wrote: post #28
koolba wrote: post #20

Earlier quoted context omitted.

It absolutely would work if the browser validates the SRI hash. The whole point is to know in advance what you expect to receive from the remote site and verify the actual bytes against the known hash. It wouldn’t work for some ancient browser that doesn’t do SRI checks. But it’s no worse for that user than without it.

I edited to make my comment more clear but polyfill.io sends dynamic polyfills based on what features the identified browser needs. Since it changes, the SRI hash would need to change so that part won't work.

Ah! I didn’t realize that. My new hot take is that sounds like a terrible idea and is effectively giving full control of the user’s browser to the polyfill site.

Re: Polyfill supply chain attack hits 100K+ sites

#39

Post by hannob »

stusmall wrote: post #6

I'm surprised there is no mention of subresource integrity in the article. It's a low effort, high quality mitigation for almost any JS packages hosted by a CDN. EDIT: Oh, it's because they are selling something. I don't know anything about their offerings, but SRI is made for this and is extremely effective.

In all cases where you can use SRI, there's a better mitigation: Just host a copy of the file yourself.

Re: Polyfill supply chain attack hits 100K+ sites

#40

Post by marcosdumay »

irrational wrote: post #29
pimterry wrote: post #17

> this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io I've said it before, and I'll say it again: https://httptoolkit.com/blog/public-cdn-risks/ You can reduce issues like this using subresource intergrity (SRI) but there are still tradeoffs (around privacy & reliability - see article above) and there is a better solution: self-host your dependencies behind a CDN servic…

> self-host your dependencies I can kind of understand why people went away from this, but this is how we did it for years/decades and it just worked. Yes, doing this does require more work for you, but that's just part of the job.

> and it just worked

Just to add... that is unlike the CDN thing, that will send developers into Stack Overflow looking how to set-up CORS.

Post reply on HN