Subscribe to our Threatpost Today newsletter

Join thousands of people who receive the latest breaking cybersecurity news every day.

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

*

*

I agree to my personal data being stored and used to receive the newsletter

*

I agree to accept information and occasional commercial offers from Threatpost partners

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

Thousands of Applications Vulnerable to RCE via jQuery File Upload

The flaw has existed for eight years thanks to a security change in Apache.

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.

Discussion

You really shouldn't rely on a sole source like this, as you have repeated some serious factually inaccurate claims made by your source. We are security researchers and we were well aware of implementation issues that can cause security issues when using this plugin. We are not alone it that, here is a report from 2014 related to that. More importantly, .htaccess files are still normally usable in newer versions of Apache HTTP Server, contrary to what Mr. Cashdollar is claiming. If they were not then, for example, many WordPress websites would not be functioning properly. We discussed the problems with the original claims you are repeating in more detail [here].

Thanks for your note! To clarify: He was not saying that security researchers (and adversaries) are unaware of the issue -- I noted the YouTube videos showing exploits for it -- only that it hasn't gotten that much publicity (I amended a sentence in the story to be more clear) and that both he and the jQuery File Upload author were unaware of the problem.
As for .htaccess files in Apache, my understanding (and what I said) is that they are no longer enabled by default -- which is laid out in Apache's documentation. I didn't say that they're unusable in newer versions of Apache -- it still is possible to turn them on. But they're no longer automatically enabled. I added a sentence in the story to make that more clear.
I've also reached out to Cashdollar for a response and will post it when he gets back to me.

Hi again! Here is the response that Larry Cashdollar gave me:
"It’s not a sole source. The author of Blueimp and I verified it.
Yes, .htaccess are indeed usable in any version of Apache. If you configure it on versions after 2.3.9. No one ever said they weren’t.
Gianni Angelozzi didn’t dig into the problem and determine which script was being included, nor did he contact that script author (Blueimp) to have it fixed. He claimed the issue was with wordpress plugin sexy-contact-form, including a script, there is no mention of the Blueimp source. Or any research into the script that was included. Gianni Angelozzi missed the real issue in Blueimp’s software.
.htaccess can still be utilized on Apache. It’s just no longer the default. I myself doubled-checked by enabling it and testing again in my lab.
Thanks, Larry"

Authors

Threatpost

InfoSec Insider Post

InfoSec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Sponsored

Sponsored Post

Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.