If security means every maintainer of every OSS package you use has to be scrupulous, tireless, and not screw up for life, not sure what to say when this kind of thing happens other than "isn't that the only possible outcome given the system and incentives on a long enough timeline?"
Kind of like the "why is my favorite company monetizing now and using dark patterns?" Well, on an infinite timeline did you think service would remain high quality, free, well supported, and run by tireless, unselfish, unambitious benevolent dictators for the rest of your life? Or was it a foregone question that was only a matter of "when" not "if"?
> 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.
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 service you control (just bunny/cloudflare/akamai/whatever is fine and cheap).
In a tiny prototyping project, a public CDN is convenient to get started fast, sure, but if you're deploying major websites I would really strong recommend not using public CDNs, never ever ever ever (the World Economic Forum website is affected here, for example! Absolutely ridiculous).
https://blog.cloudflare.com/polyfill-io-now-available-on-cdn...
app.launchdarkly.com
cdn.brandmetrics.com
chrt.fm
clientstream.launchdarkly.com
events.launchdarkly.com
fastlane.rubiconproject.com
fonts.gstatic.com
g.3gl.net
grid.bidswitch.net
hbopenbid.pubmatic.com
htlb.casalemedia.com
ib.adnxs.com
metrics.zeustechnology.com
pixel.adsafeprotected.com
podcast.washpostpodcasts.com
podtrac.com
redirect.washpostpodcasts.com
rtb.openx.net
scripts.webcontentassessor.com
s.go-mpulse.net
tlx.3lift.com
wapo.zeustechnology.com
www.google.com
www.gstatic.com
Fox News home page external content: 3p-geo.yahoo.com
acdn.adnxs.com
ads.pubmatic.com
amp.akamaized.net
api.foxweather.com
bat.bing.com
bidder.criteo.com
c2shb.pubgw.yahoo.com
cdn.segment.com
cdn.taboola.com
configs.knotch.com
contributor.google.com
dpm.demdex.net
eb2.3lift.com
eus.rubiconproject.com
fastlane.rubiconproject.com
foxnewsplayer-a.akamaihd.net
frontdoor.knotch.it
fundingchoicesmessages.google.com
global.ketchcdn.com
grid.bidswitch.net
hbopenbid.pubmatic.com
htlb.casalemedia.com
ib.adnxs.com
js.appboycdn.com
js-sec.indexww.com
link.h-cdn.com
pagead2.googlesyndication.com
perr.h-cdn.com
pix.pub
player.h-cdn.com
prod.fennec.atp.fox
prod.idgraph.dt.fox
prod.pyxis.atp.fox
rtb.openx.net
secure-us.imrworldwide.com
static.chartbeat.com
static.criteo.net
s.yimg.com
sync.springserve.com
tlx.3lift.com
u.openx.net
webcontentassessor.global.ssl.fastly.net
www.foxbusiness.com
www.googletagmanager.com
www.knotch-cdn.com
zagent20.h-cdn.com
So there's your target list for attacking voters.I think a lot of people conflate criticism of JS with criticism of the way it's been used for the past number of years, putting a nuanced topic into a black-and-white "for or against" sort of discussion. I've done a number of projects heavily using JS-- vanilla, with modern frameworks, server-side and in the browser-- and aside from some fundamental annoyances with it's approach to a few things, it's been a great tool. There's nothing fundamental about JS itself that makes applications vulnerable to this like a buffer overflow would, but the way it is used right now seems to make it a lot easier for inexperienced, under-resourced, or even just distracted developers to open up big holes using generally accepted techniques.
But I've never been a full-time front-end-web or node dev, so maybe I'm mistaken? Compared to the server-side stuff I've worked with, there's definitely a concerning wild west vibe moving into modern JS environments. I think there was a casual "well, it's all in client-side userspace" attitude about the way it was used before which effectively shifted most of the security concerns to the browser. We should probably push a little harder to shake that. Think about how much JS your bank uses in their website? I'll bet they didn't write all of their own interaction libraries.
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.
The follow up of "you know that the random packages you're including could have malware" is even more hopeless.
Meanwhile most libraries seem to have 80 trillion dependencies written by random github accounts called “xihonghua” or something with no other projects on their account.
However, theguardian.com is using it from its own domain, which is safe. But most of the other 5000 websites don't.
||polyfill.io^
Any other practical steps that mobile users can take?
https://addons.mozilla.org/en-US/firefox/addon/noscript/
You can’t expect to remain secure on the modern web while running arbitrary javascript from anyone and everyone.
I wonder if the polyfills themselves are compromised, because you can build your poly fill bundles via npm packages that are published by JakeChampion
Sure, in a true supply chain attack, you wouldn’t be able to trust npm or github or whatever, but atleast you wouldn’t be compromised immediately.
And even outside of security concerns, why would you ever allow someone else to deploy code to your site without testing it first?
<script src="https://polyfill.io/v3/polyfill.min.js?features=es6"></script>
<script id="MathJax-script" async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"></script>
Therefore, if you ever used MathJax, by possibly copying the above and forgetting, make sure to patch it out.[1] https://www.mathjax.org/#gettingstarted
EDIT: To clarify, patch out just the polyfill (the first line in the snippet). You can of course keep using MathJax, and the second line alone should be enough. (Though still better host a copy by yourself, just in case).
- remove it fully (as per original author). It is no more needed - use alternate cdns (from fastly or cloudflare)
Also as a good practice, use SRI (though it wouldn’t have helped in this attack)
I posted a note here: https://cpn.jjude.com/@jjude/statuses/01J195H28FZWJTN7EKT9JW...
Please add any actions that devs and non-devs can take to mitigate this attack.
1. Developer allows some organization to inject arbitrary code in the developer's system
2. Organization injects malicious code
3. Developer acts all surprised and calls it an "attack"
Maybe don't trust 3rd parties so much? There's technical means to avoid it.
Calling this situation a supply chain attack is like saying you were victim of a "ethanol consumption attack" when you get drunk from drinking too many beers.
https://medium.com/@wrongsahil/protecting-yourself-from-poly...
Are people actually calling Tweets "Xeets" now?
;; QUESTION SECTION:
;cdn.polyfill.io. IN A
;; ANSWER SECTION:
cdn.polyfill.io. 553 IN CNAME cdn.polyfill.io.cdn.cloudflare.net.
cdn.polyfill.io.cdn.cloudflare.net. 253 IN A 172.67.209.56
cdn.polyfill.io.cdn.cloudflare.net. 253 IN A 104.21.23.55
Or is Cloudflare warning about this and hosting the attack site?Github accounts of open source software are now for sale?
Content-Security-Policy: default-src 'self';
then add narrow, individually justified exceptions.Quite the CDN, eh? :/
But I use a lot of dependencies; it's just that I've written most of them.
What has been annoying AF, is the inevitable sneer, when I mention that I like to avoid dependencies.
They usually mumble something like "Yeah, but DRY...", or "That's a SOLVED problem!" etc. I don't usually hang around to hear it.
This needs to be mitigated client side, not rely on the good will of the administrators.
We need a much more decentralized alternative, that lets static files be served based on content hashes. For now browser extensions are the only way. It’s sad but the Web doesn’t protect clients from servers. Only servers from clients.
Had it not been for the greed of Fastly's employee, this whole thing could've been avoided.
The company known as "Funnull" appears to be based in the Philippines. The phone number associated with their WhatsApp and WeChat accounts has country code +63. Also they appear to be based at 30th Street, 14th Floor, Net Cube Center, E-Square Zone, Metro Manila, Taguig, Philippines at least if the information on this page [1], purportedly from the founder of the company that was acquired and renamed Funnull, is to be trusted (Click "View Source," then run it through Google Translate)
Claude translation:
===
> Announcement
> I am the former owner of the original Philippine company Anjie CDN. After my incident, the company was managed by my family. Due to their isolation and lack of support, they were persuaded by unscrupulous individuals to sell the company. Subsequently, the company was acquired and renamed as Fangneng CDN, which later developed into the ACB Group.
> This is precisely what I need to clarify: Fangneng CDN company and the ACB Group have no connection with me or my family. Recently, many companies have contacted my family and threatened them, believing that Fangneng CDN company has stolen important information such as member data and financial transactions through client domain names using infiltration and mirroring techniques, and has stolen customer programs through server rental services. This matter is unrelated to me and my family. Please contact Fangneng CDN company to resolve these issues.
> I reiterate: As my family has long since closed Anjie CDN company, any events that occurred afterwards are unrelated to me and my family!
> Note: Due to my personal issues, this statement is being released on my behalf by my family.
> Fangneng CDN's actual office location: 30th Street 14TH Floor, Net Cube Center, E-Square Zone, Metro Manila, Taguig, Philippines.
> Due to the release of this statement, the Anjie domain name has been reactivated by Fangneng CDN company. Currently, Anjie and Fangneng are one company, so I once again declare that any conflicts and disputes arising from Anjie CDN and Fangneng CDN companies are not related to me or my family in any way!
> First publication date of the announcement: May 18, 2022
> Announcement update date: May 18, 2024
[1] Original URL: https://cc.bingj.com/cache.aspx?q=%E5%AE%89%E6%8D%B7%E8%BF%9...
Archive.today version: https://archive.is/uDNoV