A widely used plugin by Blueimp called jQuery File Upload contains a years-old vulnerability that potentially places 7,800 different software applications at risk for compromise and remote code-execution (RCE).
jQuery File Upload is a is a user-contributed open-source package for software developers that describes itself as a “file upload widget with multiple file selection, drag-and-drop support, progress bars, validation and preview images, and audio and video for jQuery.” It works with any server-side platform that supports standard HTML-form file uploads, such as PHP, Python, Ruby on Rails, Java and Node.js.
Akamai Security Intelligence Response Team (SIRT) researcher Larry Cashdollar took a closer look at two PHP files in the package – Upload.php and UploadHandler.php – under the directory server/php path within the code, and found a glaring vulnerability.
“The Upload.php file calls the main file UploadHandler.php where all of the file upload code resides,” he explained in a posting last week. “I also saw that all files were uploaded to the files/directory in the web server’s root path. I wrote a quick command line test with curl, and a simple PHP shell file confirmed that I could upload a web shell and run commands on the server.”
Cashdollar told Threatpost that the issue is not only that the files are uploaded to the web server’s path, but also, the attacker doesn’t need any form of authentication to upload files.
“Those files aren’t checked to see if they can be executed on the server,” he told us. “Once the attacker uploads a PHP or other file that can be executed by the server, they can run commands on that server with the privileges of the web server — usually ‘www-data’. This opens up a whole array of attacks.”
For instance, an attacker could upload a PHP shell, giving him or her access to the system, in order to install malware, exfiltrate data from the website, use the shell to pivot into other parts of the network (depending on where the server is hosted), deface the site, use the site as a command-and-control (C2) server for a botnet, and so on.
After he notified jQuery File Upload author Sebastian Tschan of the issue, it emerged that the flaw (CVE-2018-9206) was introduced when Apache, Blueimp’s web server, disabled a default security control that the widget used for file access control for its root directory. Default support for .htaccess files was eliminated starting with Apache 2.3.9 (though users can choose to enable it), leaving unprotected any code that used the feature to impose restrictions on folder access – including jQuery File Upload.
“Blueimp’s code relied on the .htaccess control to keep malicious files from being uploaded and executed on the server,” Cashdollar told us. “This control was removed by default in versions of Apache 2.3.9. So .htaccess files were ignored, leaving the software open to exploitation without that security control in place. The author (Blueimp) wasn’t aware of this change in Apache’s default configuration (me either).”
Apache 2.3.9 was first introduced in 2010 – meaning that the flaw has been around for the better part of a decade. Adversaries have copped on to this, too, with numerous videos on YouTube showing how to exploit the problem. Somehow, however, the flaw has not gotten that much publicity.
The larger issue is that jQuery File Upload code forks and variations used in production packages – some 7,800 of them, according to Cashdollar – are also vulnerable to file upload and code execution. This in turn opens the applications up to data exfiltration or malware.
“The majority of these code forks carry the original vulnerability over into their code,” Cashdollar said. “In some cases, the vulnerability persists even after the project author changed the original Blueimp code to suit their own project, with each project exploitable by a slight variation of my proof-of-concept example.”
Blueimp has corrected the problem in the latest version of its software, by only allowing image-file uploads by default, such as file types GIF, JPG, JPEG and PNG. Projects that use the Blueimp code base will however have to issue their own fix.
“They, too, are vulnerable unless the authors of those projects made changes to fix the code or not rely on .htaccess for security,” Cashdollar said.
