Verifying that your 3rd party script sources are reputable is important. But that alone may not be enough.
That’s what the world learned in 2021, when a massive vulnerability in Cloudlfare’s cdnjs was flagged. Here’s the rundown of what, and how, it happened.
Cdnjs is one of the most commonly used JavaScript Content Delivery Networks (CDNs) of today. Over 12% of all websites on the internet inject at least one script through cdnjs. A researcher with the screen name ‘RyotaK’ shared a supply chain vulnerability in cdnjs, allowing anyone on the internet to commit changes to cdnjs libraries when following a sequence of specific steps. Here are his full findings.
The vulnerability existed within the cdnjs library update server. This specific module aids developers in safely integrating popular packages into their sites.
The vulnerability in some detail
By publishing a .tgz file to the npm registry with a crafted filename designed to exploit this path traversal flaw, an attacker could trigger the cdnjs library update server to process the malicious file. This would overwrite a regularly executed script file, leading to arbitrary command execution on Cloudflare's servers.
To prove the exploitability, a demonstration was planned. It involved creating a .tgz file that, upon processing by the cdnjs update mechanism, would overwrite an innocuous script with malicious code. However, before executing this plan, the researcher discovered another potent attack vector through Git repository updates, involving symlinks that could potentially read arbitrary files from the update server.
An unintended mistake in the demonstration process led to a significant revelation. A symbolic link intended to point to a harmless file was mistakenly directed to /proc/self/environ, exposing sensitive environment variables, including GITHUB_REPO_API_KEY and WORKERS_KV_API_TOKEN. This mistake unveiled how an attacker could gain access to most of the cdnjs infrastructure, posing a massive security risk.
The potential issues
This could have resulted in remote code execution on Cloudflare's servers and the potential to run malicious code on the scripts, which are used by all end users. This bypasses Web Application Firewalls (WAFs) and any other filtering mechanisms since it runs directly on the browser itself.
As previously mentioned, this would’ve exposed more than 12% of websites and all their visitors to immediate danger if exploited (once caches were expired).
Cloudflare was quick to respond and took appropriate action before anyone was able to leverage the exploit. They are known for their detailed and very transparent post-mortums and incident disclosures. The full details of which can be read here.
The better way to do it
All of this goes to show that you can not just trust sources.
Even the best in the world are prone to mistakes. A safer and more secure way is to verify what those sources deliver.
Which is why c/side exists. We offer a tiny script to add to a webpage, which does 2 things:
- Rewrite sources of scripts to proxy them through c/side. Making c/side sit in the flow of the request between the user and the 3rd party script, allowing full insight into the scripts served. We don’t just whitelist sources, but dive deep into every script, 100% of the sessions. In some cases, optimizations can even be made through caching static scripts.
- Perform some browser-side behavior checks.
c/side also monitors over 60 attributes and uses AI to flag any indicators of malicious intent in real-time. Our solution takes into account historical context meaning changes over time get taken into account making it easier to spot hijacks. On top of that, c/side uses AI to parse through the code of the 3rd party script. The combination of our ever-evolving detection mechanisms means we can spot the attempt in milliseconds and can shut it down before any malicious operations and or alert if dangerous behavior arises.