The CDNjs’ Remote Control Execution

This article is originally posted by our partner, Reflectiz. Click here to view their original article.

On July 16th, 2021, a security researcher, Ryotak, published an article about an RCE (remote code execution) vulnerability that he found on April 7th on CloudFlare’s CDNjs. To put it plainly: he found a way to take control of CDNjs infrastructure, which will allow them to modify scripts served by CDNjs, thus completely overtaking it and every library on it.

RCE is always exciting to find, as it’s practically the ‘game-over’ for every service out there. However, this specific ‘game-over’ was unique as it possibly indicates a huge backdoor to millions of sites worldwide. The possibilities of this particular backdoor were endless.

First, let’s start with clearing up the essential terms: 

1. Content Delivery Network – a geographically distributed network of proxy servers and their data centers. The function is to provide high availability and performance by distributing the service spatially relative to end-users. Think of storage of different digital applications (repositories, scripts, code, tags, etc.) constantly updated and linked to dynamic websites worldwide.
2. Cloudflare’s CDNjs – a free and open-source CDN service trusted by millions of websites around the world. By the time this article was published, it was already the biggest open-source CDN service in the world. Our records show that 1 out of 10 dynamic sites uses this CDN to serve their open-source code. According to Cloudflare, they claim to make over 200 billion requests each month.
3. Remote Code Execution – an attacker can execute arbitrary commands or code on a target machine or in a target process. This is where the attack progresses to the next level. Reaching RCE is the hardest thing to do, as you need to understand your target and its infrastructure. ere endless.

I’ll summarize plainly: if you get RCE, especially when we’re talking about one of the most common CDN around the world, you hit the jackpot.

This article will elaborate on the vulnerability Ryotak found on CloudFlare’s open-source CDNjs library, the given situation that enabled it, and the possible outcomes had threat actors found and exploited it first.

Now that we have established the basics, let’s dig in deeper.

CDN for JavaScript

Why do we need a CDN for J.S.? Simple, the modern website is composed of dozens of digital applications. Digital applications can be third-party code, tags, and many JavaScript open-source repositories that control every website aspect. With the growing usage of client-side developing frameworks, it’s become widespread.

But there are so many open sources and even more versions of them. How would you solve it? By storing them in vital global services that can serve them in a quick time while guaranteeing that you’re getting the version that you need. That’s why Cloudflare built its CDNjs services.

Different departments in your organization probably use dozens of OS repositories stored in CDNs. They use it because it enables an accelerated enterprise scaling up without spending valuable time and resources developing these functions in-house. However, as you probably already know, this dependency has its downsides.

The challenge with centralized networks

From a user perspective, centralized information networks are good as you’d want all of the relevant information gathered for you in an organized and accessible manner. But that is also the challenge raised by the centralization of information, as the centralized aspect makes these centers an attractive target for threat actors.

Let’s take web-skimming as an example. What makes web-skimming so potent isn’t its efficiency at infiltrating a single target; it’s the fact that it uses a central source of information as a trap to collect a large amount of sensitive data from its users.

The CDNjs Remote Code Execution

The vulnerability that Ryotek revealed, which enabled him to take control over the largest CDN in the world, was a compromised auto-update bot that let him inject code into any repository in the CDNjs without any security validation.

The threat actor then would have been able to do an LFI as it was loaded to the repository by the threat actor to do anything he wanted. In this case, the entire environment variables list, which is all the needed tokens for access.  It means that he could have inserted malicious code into millions of sites that rely on any 3rd-party scripts stored in the infected CDN.

If threat actors would’ve exploited this particular vulnerability– E.G., if they had found the CDNjs backdoor– you wouldn’t be able to stop it. You probably wouldn’t even be aware of it in the first place. It’s crucial to emphasize that what we describe affects some of the world’s largest commercial websites, including eBay, Udemy, Fiverr, and many more. I think you can do the math and realize what’s at stake.

The possibilities of the attackers

Because this vulnerability was found in the largest open-source CDN, he technically got control over a large chunk of the internet. Imagine what threat actors could do once they infiltrated a network of scripts used by most of the internet, and the victims wouldn’t even know it.

This kind of cyber attack would allow any threat actors to:

• Access to sensitive information inside any affected site
• Web-Skimming or any other sensitive form-jacking.
• Phishing attack
• Ransomware

And much more if they’re creative enough.

What can we do about it?

Although this particular event ended without any damage, I can’t stress out the fact that what we’re talking about is taking over the world at the push of a button. Maybe this time, an ethical security researcher found the breach, but a new security threat will raise its head at one point or another, and whoever finds it first won’t necessarily have good intentions.

However, there are a few steps we can take to protect ourselves from this kind of attack:

1. Avoid using external scripts in sensitive pages such as checkout pages.
2. Enforce standards of third-party code implementation procedure.
3. Localize necessary scripts so they can’t be modified externally.
4. Monitor your third-party code and analyze its behavior continuously.

Website owners, c-suite leaders, and particularly CISOs, need to remember that threat actors won’t stop until they find the next vulnerability to exploit. There is no magic solution, but you can prepare your security measurements by establishing a defensive baseline that helps you analyze your digital applications to detect suspicious behavior.

Referred Solution

Get Free Website Risk Detection!

Learn how to control your third-party apps and avoid the next website supply-chain attack