Independence Is Not a Dirty Word

Follow us @

Happy new year! This is the first post for year 2017.
I hope you guys weren’t too hangovered like I did. Seriously.

As promised in the last case-study, today we are going to see a very interesting case-study, with an interesting twist.

Everyone seems to love jQuery. This awesome Javascript library is everywhere I look — dozens of thousands of companies use it in their website applications, and it is super convenient — especially when it comes to AJAX requests — importing jQuery makes our lives a whole lot easier.

A library of libraries

jQuery is not alone. Google and Microsoft (and sometimes Mozilla and Apple, Facebook and Twitter as well) release new JS libraries all the time, and advice developers to use them and to import them to their products. For example, if you want to play a QuickTime video, you should import Apple’s QuickTime JS library, and if you want that neat jQuery DatePicker, you should import that library from Google, jQuery or any other mirror.

Count the times I used the word ‘import’ in the last paragraph. Done? 4 times.
Whenever we want to use a certain public JS library, which belongs to a certain company or service, we directly import it from that company.
To be more clear, we simply place a <script> tag on our website, with a ‘src’ property pointing to the JS file address:

<script src=”http/s://trustworthydomain.com/path/to/js/file.js></script>

Did you get it? We are loading a script from another website — a 3rd party website — to our website’s context. We are violating the number one rule of web security — we trust other website!

Now, this might sound a little stupid

Why shouldn’t I be able to import a script from a trustworthy company like jQuery, Microsoft or Google? And you are right. Kind of.

When you are importing a script from a trustworthy company, in 90% of the time you will be importing it from the company’s CDN.
CDNs stands for Content Delivery Network, and it is (quoted:) “a system of distributed servers (network) that deliver webpages and other Web content to a user based on the geographic locations of the user, the origin of the webpage and a content delivery server.”

Its an hosting service which provides storage services to the company’s clients based on their location and a few other factors. The JS file you are importing is not being kept on the company’s official server (again- most of the times).

In this case-study we’ll see how a very popular company has fell for this

This company (which, of course, we cannot reveal) has developed a popular JS library and hosted it on a 3rd party CDN they purchased. That CDN was “smart” and redirected users to the closest server according to the user’s location:

When a request arrived to the main server, the server determined the location of the request’s IP and then routed the request to the nearest server according to the determined location.

Dozens of websites have planted a <script src> tag in their source code, pointing to that company’s main server CDN, and it has provided their users with the necessary JS library.

An (un)pleasent surprise

After doing some research on the Apache server that was installed on Server C (Copy C in the image), we have concluded that it’s version was really out of date, and that it was vulnerable to an Arbitrary File Upload attack, which allowed us to upload a file to the CDN (but not to execute code).
Not that serious, at first glance.

But! When we examined the way the file was being uploaded, unauthorisedly of course, we saw that it is possible to use a Directory Traversal on the file path. We simply changed the filename to ../../../<company’s domain>/<product name>/<version>/<jsfilename>.js And we were able to replace the company’s legitimate JS file with a malicious one.

Basically, we had an XSS on dozens of websites and companies, without even conducting one minute of research against them. The funny thing was that this attack affected only users who got directed to the vulnerable server (Server C).

What can we learn from this (TL;DR)

Never trust 3rd party websites and services to do your job! I told you that millions of times already. Be independent. Be a big boy that can stay alone in the house.

The safest solution will be to manually download the JS libraries files you use and keep them on your server.

But what happens when the JS libraries I’m using get updated?

Clearly, with the suggested method there is no easy way to keep track of it, besides using a Package Manager like Bower. All you’ll have to do is to synchronise your libraries every once in a while.

Before Javascript Package Managers were popular, I’ve advised a friend of mine to simply write a cronjob or a python script that will check the latest version of the JS library available on the company’s server and then compare it to the local one. If the versions does not equal — the script sends an email to the tech team.
Big JS libraries don’t get updated that often.

So, after the horror movie you just watched, The next thing you are going to do, besides coffee, is to download your 3rd party libraries to your server.

Cheers.

Comments are closed.