Security leaving you

Original author: Larry Cashdollar
  • Transfer

I attended the Messaging, Malware and Mobile Anti-Abuse Working Group meeting ( in Brooklyn, New York. I expected better weather to wander around the city, enjoy the conference, and a wide selection of food in the area. I was so sure of the clearness of the sky that I didn’t even take anything from the rain with me. And it rained all week. This forced me to stay in my hotel room with free WiFi and my working laptop. I decided to spend this time researching Node.js and their related packages available at .

There are thousands of packages from users available for download and installation into your project. I searched NPM for popular package names such as file, backup, download, or upload. The last search query showed me a project called jQuery file upload from a Blueimp user. His description seemed interesting enough to download and explore it.

File upload widget for jQuery, with support for multiple file selection, drag & drop, progress indicator, validation and preview of images, audio and video. It supports cross-domain requests, a partial and renewable mechanism for downloading files with resize images on the client side. It works in any server platform (PHP, Python, Ruby on Rails, Java, Node.js, Go, etc.), which supports standard file upload via an HTML form.

I started looking at the source of the package and focused my attention on a couple of PHP files in the server / php directory. The files were called upload.php and UploadHandler.php. Upload.php called UploadHandler.php, where the main file upload code was located. I also noticed that the files were uploaded to the files / directory in the root of the web server. I wrote a simple command with curl and a primitive PHP script that confirmed to me that I can upload the file to the server and then use it to execute commands on the server.

$ curl -F "files=@shell.php"

Where the shell.php file contains:

<?php $cmd=$_GET['cmd']; system($cmd);?>

Opening a page in the browser with the cmd = id parameter from the test server returned the id of the user who started the server process to me. I assumed that this vulnerability did not go unnoticed and a quick search on Google confirmed to me that other projects that used this code or its derivatives were vulnerable. There were also some videos showing how to attack similar software packages.

I notified the author of jQuery File Upload and began documenting what I found to assign a CVE number. Soon the next day, the somewhat embarrassed author replied to me, asking for more information, since he could not reproduce the vulnerability in his test environment.

After comparing our test configurations via email, we found that Apache developers have turned off support for .htaccess files since version 2.3.9. It turns out that this was done to improve performance , so that the server would not have to check this file every time it accesses the appropriate directory. Moreover, this change was also made to prevent users from overriding the security settings that were configured on the server.

Thus, Apache had good intentions when disabling .htaccess, but their changes also put some developers and their projects at risk, in particular, if they were counting on the security settings made in .htaccess.

In the case of this library, in order to properly handle this situation and fix the CVE-2018-9206 file loading vulnerability, the developer modified the code so that it only allowed downloading image files.

This problem is more than one project.

It is also worth noting here that due to changes in Apache, some of the 7,800 other projects may be vulnerable to the problem with downloading files.

Most of these forks still carry the original vulnerability in their code. In some cases, the vulnerability remains even after the developer has edited the original Blueimp code to embed it in his project, so the projects are still vulnerable to my example of an attack with minor variations.

This means that if any of these projects is used in production, then it is vulnerable to the vulnerability of downloading a file and its subsequent execution. Discovering opportunities for data theft from applications, malware injection, deface, and other harm.

Unfortunately, there is no way to accurately determine how many projects forked from the original jQuery File Upload are still actively supported and apply changes made in the main project. It is also not possible to determine exactly where forked projects are used in production, if any. Moreover, the old versions of the project were also vulnerable to problems with downloading files, up to 2010.


The Internet relies on a variety of security mechanisms to keep our systems, data, and transactions safe and secure. If one of these mechanisms suddenly disappears, it could jeopardize the safety of users and developers counting on it.

It is a good idea for developers to look at changes in the systems and libraries on which they base their project. In this article, the security mechanism that was removed by Apache affected not only the Blueimp Jquery file upload, but also all its forks and branches. The vulnerability has affected a lot of projects that depend on it, ranging from stand-alone web applications and ending with plug-ins to WordPress and other CMS.

Also popular now: