supply chain security is an interesting topic of security research. The reason being, a lot of people don't pay a lot of attention to it. You kind of just trust where your software comes from and run it without a ton of issue. But the problem with this is that supply chain vulnerabilities are so widespread that when an attack happens, they typically affect the entire internet like hundreds of thousands of places because of how widespread the software that we all use is. In this video, we're talking about a supply chain attack that affected over 100,000 websites and is still actively being worked out right now. The attack is called polyfill or now referred to as poly kill. And in this video, we'll go into kind of the nature of what polyfill was, the way that supply chain attacks typically work out, how this supply chain attack in particular worked out, and how browser exploits happen. Now, I've been in the offensive security, the security research Community for over 10 years, and this is hands down one of the craziest exploits that I've seen. Now, if you're

new here. Hi, my name is Ed. This is a learning channel where I make videos about software security, cyber security, and a bunch of other stuff. So if you like that or just want to hang out, hit that sub button. I really appreciate it. Now all of the supply chain issue boils down to this Library called polyfill, and it was hosted at one point on this website called polyfill.io. Now, if you don't know what polyfilling is, I didn't until recently. I'm not a web guy. Polyfilling is a way that back in the day we were able to use modern JavaScript on old browsers, right? So there were browsers like IE7 and older versions of Firefox that really didn't have a lot of support for modern JavaScript features, and there is this Library called polyfill that you're able to use to effectively inject the features into the browser so that the browsers were all at the same level. Now, as my buddy Theo indicated, I didn't realize this when Chrome came about. Chrome kind of set the bar for the Baseline JavaScript.

requirements for browser so polyfill is really no longer required, but a lot of websites still depend on it. And like any website, typically when you write JavaScript, you don't write the JavaScript yourself. You don't write all the code. You depend on these things called CDNs or content delivery networks. And what they do is they host the code for you so you can just go pull them down when you go to the website. And even right now when I go to MDN web docs, if I go to my network tab and hit refresh, you'll probably see that I'm downloading a ton of other JavaScript files that are used to run this website, right? So it's not entirely uncommon that this happens. Now the issue is that recently, and but recently it was actually about a month ago, there is an issue where somebody posted a potential vulnerability in the polyfill library, and it was immediately deleted off of GitHub. Very suspicious. So people are trying to figure out, okay, why was this deleted? It turns out that the polyfill.io domain that was not

originally owned or maintained by the Pol library maintainer was acquired by a Chinese company. Now, what they did is extremely interesting. So again, just like any other JavaScript website, what you'll do is, if you want to depend on the poly full Library, you will just literally put a remote script Source link into your code to pull out this JavaScript, right? So the compromise URL is this Library here, and actually, I think name sheep, the owner of the polyfill.io domain, does not serve this IP address right now. So you'll see the CDN doesn't work. But so what happens is that you go and pull down this library, and that code gets put into your browser and gives you the features of polyfill, which again is just meant to make sure that you and all the other browsers are on the same Baseline of functionality so that all in JavaScript works well. What's pretty insane is again company bought this. No inherent issue with that, but when you go and check out or checked out before they pulled this all down the version of

polyfill that this website was serving versus other CDN like cloudflare for example a bunch of obfuscated code was put into the library there were all of these obfuscated functions with random prototypes and and variables that effectively would go out and reach out to not Google analytics Googy analytics and they would pull down G a .js which if this were actually Google analytics it would look like the JavaScript page that a lot of sites depend on to do tracking of users when they're going to websites you want to see how long the browse time was what their clickthrough rate was on certain elements all that stuff all this can be done through Google analytics so if you look at this quick enough you're like what those aren't L's those are I's so Googy analytics gets injected into the polyfill.io polyfill CDN. So eventually what happens is they have all this obfuscated code someone did the work of kind of reverse engineering what this actually does when poly. min.js gets put

into your browser. On certain devices, polyfill.io will load up Google Analytics ga.js. They've pulled down this piece of JavaScript, but what it actually ended up being was this PasteBin here, which is another heavily obfuscated piece of JavaScript code. Very interesting. So the question is, what does this piece of JavaScript code do? What is happening here? This is where I think a lot of speculation is still around. There hasn't been a ton of reverse engineering work. I'm actively working on taking this apart right now to figure out what it actually is, but I have a couple inclinations just on my experience in the security world and reading articles about browser exploitation, right? So the question kind of becomes, why is it bad if an arbitrary user runs JavaScript in your browser, right? Like, who cares? There's nothing inherently wrong with that. The idea being that the JavaScript engine, the V8 sandbox, is a sandbox. Now, if you don't know what V8 is, V8 is the open-source high-performance JavaScript and WebAssembly engine that

is written C++ so what what are we actually getting at here. What this thing actually does is if you've ever like used JavaScript right in the browser, there has to be somewhere that interprets the code and runs the JavaScript on the CPU. That is called your JavaScript engine, right? So for example, if I put ver x equals 0, whatever, all of this is being interpreted via an engine that is written in C++, which is known as V8, right? And that's how the Chrome backend works. I'm pretty sure that Firefox uses V8 again. I don't know the ins and outs of all the browsers, but I know that Node.js and Chrome do use V8. Now, again, this is written in C++, which means that it can have any number of memory corruption vulnerabilities that you will find in any other application. This is where the world of browser exploitation comes in, where you are able to Via JavaScript write exploits that take advantage of known vulnerabilities or potentially zero days in V8's interpretation of C++ and use that to

escape the V8 sandbox and get code execution on the remote host computer. So wrapping this all up, polyfill.io like I said before is ran on hundreds of thousands of websites. So what does this mean? This means that if you visit a website that is using polyfill and is depending on the polyfill.io CDN, or at least prior to the CDN being taken down, that you were going to the website, the Google the Google Analytics JavaScript page, and then from there was potentially serving you JavaScript that was being used to exploit your browser. Now again, we are in pretty much in speculation mode right now, but what this looks like to me is a JavaScript exploit that has been obfuscated so that you can't reverse engineer it that is doing some kind of memory corruption to gain execution in the browser, right? Kind of a crazy thing. And from a malicious actor perspective, while this is so advantageous is that they don't have to do any work like provided that this exploit is written well and has enough

functionality in it. What they can literally do is push a malicious update to their CDN, and then every user that goes to these websites and loads their version of JavaScript is served this exploit and is used. And that JavaScript can be used to potentially escape the v8m get code execution on your computer, and then from there they have a mass exploitation campaign. So truly insane. Now what are people saying on Twitter? What are people saying? What is the company that bought polyfill saying on Twitter? Well, well, well, well, the company that acquired this, again, the polyfill.io domain, was not actually run by the person who maintained polyfill. Right, here's one of the reasons that I believe it is truly a malicious campaign and not like a Oopsy Daisy like someone got hacked, you know what I mean, like it's very intentional. And the reason being the number of times that polyfill IO tried to cover their tracks. So let's go through this. So article here bleeping computer cloudflare, we never

authorized polyfill.io to use our name now so cloudflare. If you don't know, is a huge cloud provider that does a bunch of stuff for a majority of the internet. You can host Services there, you can have your domain names hosted there, you can do web application filters there, you can do load balancers there, a whole bunch of stuff. One of the things that cloud flare is known for is it is a large content delivery Network, which means that instead of going to polyfill.io to Serve Yourself poly. JS, there's also a copy hosted on cloudflare. So if you went to the polyfill IO a couple days ago before this whole thing went down, you would see that there's a little lock sign, which means that it's secure obviously, and cloudflare security protection is enabled. And then you go and you look at this and you're seeing that polyfill.io is actually the URL and it's not the cloudflare CDN. So either polyfill.io is a cname, you know, a name lookup on a DNS record for a cloudflare domain or poly

is trying to say that our code is backed by the Cloudflare CDN. They're a third party, so you can trust us, 'cause we're cool, right? And so what Cloudflare effectively says in this article is that Cloudflare never recommended to polyfill.io that they were allowed to use our name on their website. We asked them to remove the false statement, and they have so far ignored our requests. And because Nam sheep is now not serving the polyfill.io domain name, you can't really confirm or deny this, but it's in the pictures. And so even further, Poil has doubled down on Twitter and said, I have had enough of Cloud Flare's repeated baseless and malicious definition. I don't know, man. First of all, not really baseless. This is like you actively gaslighting the entire internet. Moving forward, I'll be fully dedicated to developing a global CDM product that surpasses Cloudflare, showcasing the true power of capital. I don't know what that means. Again, that bought by a Chinese company serving malicious.

JavaScript. This reads to me like somebody who wrote a very flowery paragraph in Mandarin and put it into Google translate, but I digest. I have already secured 50 million startup funding. The product, okay, so effectively, what he says. And note that he put this giant image in the Twitter. Polyfill.io is going to attempt to be their own CDN because they're mad at Cloudflare for telling them to stop hosting malicious JavaScript. Pretty crazy situation. And if you can go to their account, you can tell it's fairly new because they have like 40 followers. Again, like if you want to follow them, I guess fine, but no, this is likely a malicious CDN account. And literally all their posts are about them getting slander on the internet for, I will repeat myself, posting malware on the internet. Yeah, so kind of a wild place to be in now. If any of this interests you, if you want to go learn about the world of browser exploitation, like how to find or write exploits that attack a browser, just know how they.

actually work reban 01 who is someone that I follow on Twitter. I recommend that you go follow them as well. Posted a really really cool write up from a CTF capture the flag called exploiting V8 at open ecsc. Basically, there was a capture the flag challenge that they were supposed to exploit a Chrome CBE. One of them was in an implementation of array. exor in JavaScript. And here's the code diff. And again, like I said before, the V8 engine is just C++ that you run that interprets JavaScript, right? So this whole write up is their adventure of finding out how to AR ray. xor produce a memory corruption vulnerability and then using that to pop bsh and get a shell on the computer that is running Chrome. So really great right up. But yeah, supply chain security is completely crazy. It is a world that I'm really nervous that people are not thinking enough about. Between the SolarWinds attack, I think in 2020, where a security product got attacked, I think by

the Russians. And then you have the XZ back door, where this widely used compression Library gets attacked. And now JavaScript CDNs are being purchased up by other countries and having code injected into them. It begs a really interesting question about the future of not only open source, but just code that people use that they didn't write themselves, right? So anyway, if you thought this video was interesting, do me a favor, hit that like button, hit subscribe, and then go check out this other video. This other video about the XC back door, which was really cool. It's kind of the same thing, only it has to do with a much smaller but much more widely used library that almost had the same fate as this. We'll see you there.

malicious javascript injected into 100,000 websites

Teaching you 🧠 about the lowest level
