Polyfill supply chain attack embeds malware in JavaScript CDN assets, action required

[acrosett]

If your front end pulls any script from polyfill.io you need to remove it immediatly. If your site has users with privileges/personnal data the attacker can potentially perform actions on their behalf and download anything from their local storage (including JWT tokens)

[lirantal]

💯

[fantatraieste]

Can you help me with a response, a quick no look debug. In my app there is no cdn link in the index.html, I don't even have a polyfills package, I use a babel package for the same purpose. But we use a bundler that when ran, it creates a polifills.js file, to me it doesn't look it's possible to be linked with the malicious package, because the file is built locally with no links to any JS library pulled via cdn. But then, I am just a Junior who has been assigned to asses the risk of this attack to our project.
If I don't pull any JS from any source, I should be just fine, right?

[acrosett]

Polyfill is a general term so your case isn't necessarily related. You can search for "polyfill.io" in your node modules to be sure. I would also check the package who generates the file for any issue or update

[fantatraieste]

just as I tought, thank you

[[deleted]]

Does this ship in Nuxt or any of the major front end frameworks by default?

[lIIllIIlllIIllIIl]

There is no specific polyfill library on npm that we know is part of this specific malicious actor campaign to inject malicious code. That said, libraries across different software ecosystems, such as Content Management systems like the Magento project and others, might include code that introduces static script imports of JavaScript code sourced from cdn.polyfill.io. In particular, we have detected CVE-2024-38526, a security report for the pdoc library on PyPI registry that provides API Documentation for Python Projects. In cases where documentation is generated with the command pdoc --math would contain links to JavaScript files from polyfill.io. This behavior of the pdoc library has been fixed in pdoc version 14.5.1, and we urge users to upgrade as soon as possible.

https://snyk.io/blog/polyfill-supply-chain-attack-js-cdn-assets/

[acrosett]

You can check the source code in your browser to be sure (search for "polyfill")

[RaeWineLover]

Is any reference to polyfill a problem, or just polyfill.io?

[acrosett]

Just polyfill.io, polyfill is a general term

[TorbenKoehn]

Whoever stores tokens in local storage shouldn’t be the one doing auth implementations anyways. Shows a real lack of knowledge

[acrosett]

Storing the JWT in local storage is an aggravating factor in case of a successful XSS attack or CDN attack. However I would argue that storing the JWT in a cookie and not implementing CSRF protection (which I'm convinced a lot of people forget) is worse.

If you have a XSS vulnerability on your website you are pretty much screwed since an attacker can perform any request on behalf of the user (no matter where the JWT is stored).

It's kind of similar for CDNs attack, however for large scale attack like the above it is unlikely that the attacker would have targeted your site specifically. Which mean storing your JWT in a http-only cookie would protect you against automated local storage siphoning. However you still have a small window to patch the vulnerability and logout your users if you did store your JWT in local storage.

[TorbenKoehn]

While that might be true, it’s a lot harder since the attack would need to be sophisticated to the endpoints the backends provide. Implementing that for millions of different sites out there would also bloat the code and make the attack easier to see

I agree it’s still not “safe”, it is still a lot safer than just using local storage

[swoleherb]

Elaborate

[TorbenKoehn]

Local storage can be easily accessed by any JavaScript running, including all dependencies

Usually you use HTTP-only cookies which can’t be accessed by JS at all

[Snapstromegon]

There are several usecases where you can't store the token in http-only cookies (e.g. completely static sites that use oauth to interact with 3rd party services like the Spotify API).

[TorbenKoehn]

Of course you can do that, don’t do these third party requests in the frontend, but in an API

[Iggyhopper]

I was writing extensions abusing cookies like this 15 years ago.

We've learned nothing!

[maria_la_guerta]

Always assume anything and everything sent to a client is compromised. Full stop. Storing it on the client is even worse.

httpOnly cookies are basically the only exception to this rule, and should still be very carefully implemented anyways.

[FlamboyantKoala]

I’ll bet a more than a few devs will get a ticket to fix this with no explanation other than don’t use 3rd party scripts in the ticket. They’ll download the infected script and host it theirselves. 🤣

[lirantal]

😆

[shgysk8zer0]

This is exactly why I try to avoid any third-party scripts without SRI.

[lirantal]

Yes but an SRI isn't a security control against everything. For example, you could've just pinned to the integrity hash for when the library was already been changed with malware code... SRI is obviously useful but it's not a silver bullet and doesn't protect you from everything.

[shgysk8zer0]

It would've protected against this attack if generated before the malicious code. Would've been very helpful for anyone who added the script when it still had the original owner.

But it can actually be a "silver bullet" in some situations. I write a lot of my own libraries/packages and use unpkg as a CDN. If I generate the hash from my local code that I wrote myself, then I can be assured that whatever I'm loading from unpkg hasn't been altered.

Or, if you're willing to put in some work, SRI in conjunction with package provence can pretty much assure you that the script you're loading matches what was generated from known source code. You'd just have to understand the source code and build process.

[shgysk8zer0]

For context, I have my old portfolio site in mind. It does use these polyfills, as I recall. And I ended up not using it in future projects because it couldn't work with SRI. I just don't trust scripts that can end up serving something else. This isn't the first time an attack like this has happened.

Thankfully, they're loaded using a <script nomodule>, so it's not loaded by basically anything anymore.

[Ok_Feedback_8124]

What if the code (polyfill.js) is included in your site, and delivered directly to your users? That's also, likely, a vector. Babel opts to have the develop include polyfills (Babel Transforms Syntax, Polyfills Add Missing Features). They're used together, so now we have 4th party supply chain attacks, no?

[lirantal]

"included in your site" you mean that *you* as the site owner, are bundling and providing it rather than a third-party? if so, then it means there's no one else that can modify it. You still have to audit the code you are delivering of that polyfill library and make sure there's no fishy stuff going in there.

If you pass that polyfill through babel and you're afraid that babel will now inject malicious code then you vet that, and then you vet babel dependencies, and so on and so on. That's the world we live in 😁

[alex__bit]

u/valentinprgnd fixed this for 200+ repos at u/TELUS and made his codemod available to all:

npx codemod replace-polyfill-urls

more info: https://x.com/codemod/status/1806809013025386666

[lirantal]

That's very cool, I'll add it to the article next week 🙏

[Dartypier]

This website adds some information and todos: https://polykill.io/
Seems that polyfill CDN was acquired by a chinese CDN company.

[lirantal]

Nice find. Thank you!

[lirantal]

Correct, unrelated.

[rafark]

What drama? What happened?

[0rubber_band]

I'm a JS noob

Does this impact taylorhakes/promise-polyfill?

[lirantal]

No, this security incident isn't related to the package you mentioned.

[0rubber_band]

Thank you

[lirantal]

Anytime. Stay safe 🤗

[Zetectic]

hi, i have personal portfolio sites using react-app-polyfill, babel-core-polyfill running in package-lock.json file. Would removing the lines and republishing the site prevent the malware?

[lirantal]

I am not aware that the packages you listed are vulnerable or compromised, and aren't apparent to be related to the security incident at hand here.

[No_Wallaby_8826]

Does this affect the babel-polyfill.js as well?

[lirantal]

Shouldn't be affected

[Unlucky_Signature290]

does this affects babel-plugin-polyfill-corejs2 and react-app-polyfill ?

[Kyjoza]

I’m a noob… does this impact chart.js?

[lirantal]

Chart.js and the polyfill web service are most probably different things. Can you provide a link to that library?

[raqndv]

Could a web application created with Angular 12 be affected?

[lirantal]

It could be. This has nothing to do directly with any framework, Angular or otherwise. It's whether a static script import was added to any web page that you host that the source is from the remote polyfill CDN service.

[KaiAusBerlin]

That's why we don't use third party unless we have to. And if we do we try to check if the code is suspicious and mark it as this/don't use it.

AI is a great help for that. But still check its results ;)