[checked] Blind SQL Injection Vulnerability - Virtuemart 2.0.8e

[masters1333]

I need help fixing this problem for PCI compliance. Here is the summary from the PCI scan...

Host: www.mydomain.com
Path: /component

THREAT REFERENCE

Summary:
Blind SQL injection vulnerability in task parameter to /.../.../view/productdetails/virtuemart_product_id/16/virtuemart_category_id/2/tmpl/component

Risk: High (3)
Port: 80
Protocol: TCP
Threat ID: web_prog_sql_blind

Details: When a web application uses user-supplied input parameters
within SQL queries without first checking them for unexpected
characters, it becomes possible for an attacker to
manipulate the query. This type of attack is known as a
SQL injection attack.

For example, suppose a web program passes the following
query to the database application:


SELECT * FROM USERS WHERE USERNAME='$user' AND PASSWORD='$pass'


where $user and $pass are variables supplied by the user through a web form.
So if the user were to enter the name "admin" and the password "abc", the query would become:


SELECT * FROM USERS WHERE USERNAME='admin' AND PASSWORD='abc'


and the database would return any existing record where the username is "admin" and the password is "abc", thus authenticating
the user if the password "abc" is correct. Now suppose an attacker were to enter a malformed password such as the following:


' OR 'a'='a


Inserting the malformed password into the query exactly as
it appears above would cause the query to become:


SELECT * FROM USERS WHERE USERNAME='admin' AND PASSWORD='' OR 'a'='a'


The resulting query would return the records where the username
is "admin" and the password is null OR the string 'a' equals 'a', which is always true.
Thus, by manipulating the SQL query, all records are returned from the table
without having known the correct password.

This is just one example of an attack which is possible
using SQL injection. Other forms of attacks could allow
the attacker to gain unauthorized read, write, or delete
access to the database, or to retrieve passwords.

There are also security bypass vulnerabilities which allow for the
bypass of anti-sql-injection filters in the software.

Information From Target:
Service: 80:TCP
MySQL-style database, SQL SET / WHERE
Response time:
0 seconds normal response
7 seconds executing injected delay
Sent:
POST /.../.../view/productdetails/virtuemart_product_id/16/virtuemart_category_id/2/tmpl/component HTTP/1.0
Host: www.mydomain.com
User-Agent: Mozilla/5.0
Content-length: 255
Content-Type: application/x-www-form-urlencoded
Connection: Keep-Alive
Cookie: 9a20e8046610daa344301df5a4a33171=a0ca65319375c3e92fb04cca4860ad92

name=123&email=123&comment=123&submit_ask=Send&counter=0&virtuemart_product_id=16&tmpl=component&view=productdetails&option=com_virtuemart&virtuemart_category_id=2&task=x'%20and%20benchmark(100000000,HEX(999999))%20--%20&af5ce61785c5a0ff49084b71638c389a=1
Received: HTTP/1.1 200 OK

************************************************************

[jjk]

Just curious - which PCI scan does come up with this? (Because afaik you are the first and only one who reports something like this and at a first glance the tool's conclusion appears to be nonsense - but I'm no vulnerability expert). Did you actually test what your tool thinks would be possible?
However, you should consider to update to a newer version. 2.0.8 is pretty old.

[Milbo]

I rechecked this now. Every JRequest is casted to int, filtered by str_replace or by getString of joomla. We are in contact with the guys who do the scanner and it seems it is a false alert.