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.

Arbitrary File Upload From A Different Angle


Today we will discuss about arbitrary file uploads, a less common vulnerability, but one of the most powerful out there.

Less common? Why?

Because any platform with sane developers will validate the content type and the file extension of any file they interact with.
But today I want to introduce you with a new validation attitude that I now advise everyone to use – validate the content itself.
If you are expecting an image to be uploaded – expect the content to be suited as a content of an image. If you are expecting an html file – sanitize it and make sure no script tags exist. There are plenty of libraries and tools to do that.

With that being said, a lot of companies and developers I have came across with said to me: “Why should we make all that effort when we can just host the uploaded files on a CDN (Content Delivery Network)?”.
Well, today’s story is just about that.

Freelancer.com was my first interaction with this new attack vector. They allow images to be uploaded as profile and cover pictures, DOC and DOCX files to be uploaded as resumes and far more.

But they also have a nice feature where users can write articles and publish them for others to read.
This form supports images uploads, and those images, as you can imagine, are being uploaded to a CDN (https://cdn.f-cdn.com/).
f-cdn.com is of course the official CDN of Freelancer INC.

The developers here probably assumed that since images are being uploaded to a CDN, no sanitation and content validation should be done – The form does not support HTML – so XSS cannot be done, and the CDN does not allows php files (or any other like it) to be accessed – just download them.

Well, this attitude allowed me to be able to upload a .exe file to the official CDN of Freelancer INC.

Can you imagine a scenario where a hacker will host malicious viruses on the CDN of an official company? I hope you do.
Far more, there is no size limit – any size of a file can be hosted on the CDN (although it may take time to upload it and the connection may be refused eventually).

So remember – using CDNs is not always the best option. Yes, XSSes will not affect users (because of a different domains) and yes, shells and RCEs will not endanger your server directly. But mis-validating the type of files that your CDN hosts might cause your company to a great lost.
Keep that in mind.