In the days following the original post concerning my disclosure of the flaw in jQuery-File-Upload (CVE-2018-9206), many people reached to me with a number of questions on various related topics. I think a blog post is the best way to answer many of them, along with explaining ongoing efforts to identify and patch vulnerable jQuery instances in the wild.
First of all, I found this vulnerability while doing some preliminary research on NodeJS npm modules. I generally look for plugins or modules that might perform sensitive system operations, like reading or writing files, creating backups. or possibly executing shell commands.
That means searching the npm project repository for packages that match strings like upload, download, backup, file, etc., and after an hour of searching and examining a couple of projects, I found Blueimp's jQuery-File-Upload. I examined the code and thought to myself, "this needs to be tested".
Disclosure and Additional Research:
This discovery was the basis of the original disclosure, and where much of the news centered on it came from. But additional research yielded more findings. As it turns out, the problem is much larger than a single jQuery project. There were 7,800 forks of Blueimp's code on GitHub.
So far, I have found that the code has been packaged for Debian and Ubuntu. The maintainers of both Linux flavors have already patched the vulnerable code, so any developers using those packages can upgrade them with the package manager.
In addition, a fork of the Blueimp project provides a jQuery-File-Upload docker image. When installing the docker image, it currently pulls the latest code down from Blueimp's GitHub repository. However, if you've got this docker container running, you should rebuild it to grab a patched version of the software.
A fellow researcher Chrissy "5w0rdfish" Morgan pointed out that other software products were built on top of jQuery-file-Upload. I reached out to Responsive FileManager and let them know. Once they confirmed their code was vulnerable, they fixed the vulnerability and issued a patch in less than a day.
This is a tricky situation, because researchers know that testing an exploit against a system you don't own, or have written consent to test against, is a big no no. Therefore we can't be sure of which sites are vulnerable and which sites are not.
Down The Rabbit Hole:
Not only was the jQuery-File-Upload code widespread, but there were many variations of it. In an attempt to identify different vulnerable versions, I downloaded 1,000 forked repositories (the limit imposed by GitHub) from of Blueimp's jQuery-File-Upload and started to compare files via using sha256 hashes:
1000 Total samples
14 variations of index.php
15 variations of UploadHandler.php
13 variations of upload.php
23 variations of upload.class.php
241 instances of UploadHandler.php
104 instances of upload.php
610 instances of upload.class.php
899 instances of index.php
What this is shows, is that there are 15 different versions of Uploadhandler.php, and 23 different variations of upload.class.php. Meaning one could be modified to fix the vulnerability, or only slightly customized to meet the needs of a software developer.
I decided to test the 1,000 forks by moving them all into my lab server's HTTP server root path and develop my exploit to try the different variations I had identified from the sample of 1,000.
Over 970 returned the output of system('id') showing that the shell.php file was uploaded and the id command was executed on the server. A quick test of a handful of others revealed they were indeed exploitable with only a slight tweak to the exploit code. Some authors changed the upload path from files to file or the file variable to filename etc.
Considering the wide reach of jQuery-File-Upload, I thought I would start by notifying the 7,800 forked project owners of the vulnerability. I figured we could devise a way to programmatically notify the repository owners. I reached out to GitHub's support team, and after a few days, they responded to my request for assistance. The conversation is ongoing, but my hope is to work with them and notify the thousands of vulnerable project fork authors, encouraging them to pull the latest update from the Blueimp repository.
As a long time researcher, I try to be sympathetic to developers and vendors of whom I've found security issues with. I've made mistakes in the past, like releasing an exploit for a vulnerability I discovered in some security software a week before Christmas, only to get a phone call from the products manager telling me how he had his entire development team is working on it over the weekend. Oops. So, I've tried to make sure that I don't screw up like that again.
I was very pleased when a friend pointed me at this comment from the jQuery-File-Upload author, Blueimp:
Larry was also super helpful in identifying the underlying issue and very polite in his emails.
Would definitely write another security vulnerability into my code again if I knew that Larry would report it. ;)
I'd settle for someday sitting down and having a coffee together. I'll buy.
I hope the media coverage will help software developer and project owners to check their own code not only for the use of Blueimp's jQuery-File-Upload but also the reliance on .htaccess as a security control. My concern is that there are other software projects out there that are relying on .htaccess to protect them when that security control is no longer the default.