1

Barracuda has found multiple instances of OS Command Injection vulnerabilities in a static website. In each instance, the vulnerable URL was the jQuery plugin itself (version 2.1.1).

Barracuda rates each Severity as Critical, and the Confidence as Certain.

An OS command injection attack occurs when an attacker attempts to execute system level commands through a vulnerable application. Applications are considered vulnerable to the OS command injection attack if they utilize user input in a system level command.

CVSS

Score: 7.5

Vector: AV:N/AC:L/Au:N/C:P/I:P/A:P

Remedation Background

Minimize use of OS commands in web applications, as they are always a security risk. When it is necessary to use an OS command that includes user input, comprehensively scrub all user input for malicious characters prior to running the command.

The issue details are "The field v was submitted with the value /bin/cat /etc/passwd. The marker root:" followed by a huge chunk of minified jQuery (6 pages), and ends with "fa+";expires=Thu, 01 Jan 1970 00:00:00 was found in the response, suggesting that the injected command was executed, and therefore that OS command injection is possible.".

There were also High Severity in the same jQuery plugin for Directory Traversal:

Directory Traversal, also known as Path Traversal, "dot-dot-slash" and "backtracking", is when a misconfigured server or code error allows an attacker access to files outside the web root folder. These files may contain source code, configuration, and critical system files, including password files.

CVSS Score: 6.8

Vector: AV:N/AC:M/Au:N/C:P/I:P/A:P

Remedation Background

Do not use user input that is not properly sanitized as any part of a path component. It is even more advisable to never use user input in a path component at all.

Again, the details were "The v parameter was submitted with the value /etc/passwd, and the response contained the value root:" followed by 6 pages of minified jQuery.

I'm going through all of the forms to verify that the inputs are, in fact, properly sanitized, but the report seems to be identifying the vulnerabilities in jQuery 2.1.1 itself.

That strikes me as unlikely, but I'd like to be able to know for sure if these are, in fact, false positives. I will be updating to a more recent version of jQuery, just to be safe. What steps should I take beyond investigating the form inputs and updating jQuery?

1
  • Seems unlikely. If the URL was of the form example.com/jquery.js?v=ABC, it be likely to be loading jQuery itself, having replaced the cachebusting variable with /bin/cat /etc/passwd. Six pages would be a fairly long passwd file for a webserver - they're more commonly something between 20 and 50 lines long, in my experience!
    – Matthew
    May 27, 2016 at 13:00

2 Answers 2

6

It's a false positive.

In both cases, the scanner only searched for "root:", assuming it is part of a passwd file. The line that is found is:

root:function(a){return a===o}

This is obviously not from a passwd file. It is also very unlikely that any server-side vulnerability exists in a request for a jQuery file, generally they are static files that are served as-is.

That the scanner reports "certain" is a bit surprising, as "root:" is way too general of a keyword for such a high confidence rating.

When getting a report such as this, you need to verify the result. In these cases, you should:

  • search for the keyword the scanner gives you - "root:" in this case - and see if it actually is what the scanner thinks it is.
  • adapt the payload and see what happens. In the case of the command injection, you could try other commands and see if they are executed, in the case of the file inclusion you should try to include other files.
4

No, JQuery is a client-side technology, which is really a wrapper for JavaScript for use within a web-browser only

JavaScript doesn't have the capability to run OS commands when invoked by a browser, unless security settings are lowered within Internet Explorer.

And JQuery cannot provide any additional functionality that circumvents this.

This appears to be a false positive due to the minified JQuery being returned and mistaken by the vulnerability scanner as returning a sensitive, server-side system file.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .