After I disclosed the arbitrary file upload vulnerability in Blueimp's jQuery File Upload project in early October I decided to investigate similar projects. I found a list of the top 20 jQuery file upload projects that listed both free open source and commercial repositories.
I started to examine the code that didn't require a purchase, and found the majority didn't provide a method to actually upload the file. They simply provided the frontend framework around jQuery. The other projects that did provide some sort of PHP backend allowing files to be written on the disk, checked to see if the file was of image type only, ensuring that any other file type would be rejected while displaying an error.
Since these projects do not have the same popularity of the Blueimp implementation, I thought I'd attempt to contact their authors and have the vulnerability fixed.
This first example is a bit of a grey area. A project listed by Daniel Morales, simply named uploader, the software is vulnerable to arbitrary file uploads but the author makes a note in the code that it should not be used in production and is insecure.
"This is a ***DEMO*** , the backend / PHP provided is very basic. You can use it as a starting point maybe, but ***do not use this on production***. It doesn't perform any server-side validation, checks, authentication, etc."
Figure 1. Comment in upload.php warning users of the code's lack of security.
$ curl -F "email@example.com" "http://example.com/uploader/demo/backend/upload.php"
Figure 2. A proof of concept exploit.
The question here is, will developers take the time to read the comments and remove that file from their project? I'd like to think so. I cannot justify assigning a CVEID if the author has already documented the vulnerability themselves. It still exists and is exploitable but the author has given fair warning.
The second example is vulnerable once installed and set up to allow file uploads. The project is being developed by Ravishanker Kusuma. The software doesn't create the upload directory itself but in order for the code to work properly, the user has to create the upload directory and ensure it's writeable. I've assigned this vulnerability CVE-2018-9207 as it allows the upload and execution of arbitrary code.
$ curl -F "firstname.lastname@example.org" "http://example.com/jquery-upload-file/php/upload.php"
Figure 3. A proof of concept exploit for CVE-2018-9207.
jQuery Picture Cut
The next vulnerable project is called jQuery Picture Cut. It describes itself as, "... a jquery plugin that handles images in a very friendly and simple way, with a beautiful interface based on bootstrap or jquery ui, has great features like ajax upload, drag image from explorer, image crop and others."
By default this project is vulnerable to arbitrary file upload. It allows a user to upload a PHP file and execute commands as the HTTPD server process owner. I've contacted the author about this vulnerability and assigned it CVE-2018-9208.
$ curl -F "inputOfFile=file" -F "request=upload" -F "enableResize=0" -F "minimumWidthToResize=0" -F "minimumHeightToResize=0" -F "folderOnServer=/tmp/" -F "imageNameRandom=1" -F "maximumSize=10000" -F "enableMaximumSize=0" -F "email@example.com" http://example.com/jQuery-Picture-Cut/src/php/upload.php
Figure 4. An exploit for CVE-2018-9208.
PHP Traditional Server
This last project is called, "php traditional server" its description read, "PHP-based server-side example for handling traditional endpoint requests from Fine Uploader" It's the back end example code for the front end project called Fine Uploader.
This project doesn't filter by file type, which is dangerous as it stores the uploaded files in the web root path. I've assigned this vulnerability CVE-2018-9209 as I'm sure the developer using this project doesn't expect it to allow uploads of PHP files into the web servers root directory.
$ curl -F "firstname.lastname@example.org" "http://example.com/php-traditional-server/endpoint.php"
Figure 5. An example that exploits php-traditional-server uploading a PHP shell file. [Source]
The author is no longer interested in maintaining the software and removed the GitHub repository after I reported the vulnerability. However, there are project forks that are still active.
In my previous blog post, I noted that I had reached out to Github asking for assistance in contacting the 7800 forks of the Blueimp jQuery File Upload project. They responded stating they couldn't help with notification, but said they've passed my "request onto the team to consider for future improvements..."
One of the risks associated with application development is the inclusion of external code that may or may not have been screened for basic vulnerabilities. In some cases, the original code was perfectly clean, but changes to various platforms or environments exposed a previously unknown attack surface.
The concept behind Open Source, and collaborative development is a great thing, but making the end user responsible for fixing the vulnerabilities discovered in the code you've created is incredibly damaging - both to the user and the public at large. Perhaps there should be a basic rule that if a developer isn't willing to fix their code, they should document problems and warn those who might use it. The last thing we need is to have Open Source development associated with the pretext of 'code you can't trust' or 'generally unsafe'.
When selecting an Open Source project, when you need to include external code into your own work, it's best to know the track record of the developer you're using code from. Be prepared to have someone on your team maintain the project if that developer decides to abandon it.
Ask yourself a few questions:
If there have been security advisories filed against it did the developer address them?
How did they address them?
Did they offer a fix?
Or did they dismiss the issue rather than fix them?
If the answers to these questions leave you with feelings of doubt or conflict, perhaps it's best to choose another source.