Hi. I am running three zen cart v1.5.7 sites. shopmedstore.dukestores.duke.edu, shopnasher.dukestores.duke.edu, and shopdivinity.dukestores.duke.edu.

We have been running zen cart for many years and it has been great. For PCI compliance we have regular scans. Usually we pass or need to install an Apache or PHP update. No big deal. This week we failed our scan due to SQL Injection Vulnerabilities listed for zen cart software for all three sites. They are all running the latest version 1.5.7

I pasted their explanation of the vulnerability below. It does appear that when they pass 8=8 (true) the output from zen cart contains form-data; name="y" and when they pass 8=6 (false) the output does not include that data.

Can this behavior be changed in zen cart? It is a problem?

CVE Number Vulnerability CVSS

Score Severity Compliance
Status Details
1 SQL Injection Vulnerability 7.5 High Fail
URL: https://shopdivinity.dukestores.duke.edu/index.php?main_page=%27+or+8%3D6+--+-&products_id=88&action=add_product

Port: tcp/443
A SQL injection vulnerability (SQLi) was identified in this web
application. SQL injection is when modified SQL syntax is supplied to a
user defined parameter to have it query the SQL database directly,
which is not the desired intent of the web application. A simple proof
of concept example of this would be for a user to supply "' or SELECT
DATABASES;--" to a user defined parameter and then upon submission,
a list of databases on the system would be supplied for the user
because the SQL query was interpreted directly on the SQL server
instance. SQL injection can be found in many different forms and
combinations so the full request and response that was used
demonstrate this vulnerability has been provided below as evidence.
All SQL Injection vulnerabilities are considered non-compliant by PCI.
CVSSv2: AV:N/AC:L/Au:N/C:P/I:P/A:P
Service: https
Reference:
https://www.owasp.org/index.php/Guide_to_SQL_Injection
https://www.owasp.org/index.php/SQL_Injection
Evidence:
DetectionDetails: Boolean based SQL vulnerability found
POST -
https://shopdivinity.dukestores.duke.edu/index.php?main_page=%27+or+8%3D6+--+-&products_id=88&action=add_product - main_page
False Injection: ' or 8=6 -- -
True Injection: ' or 8=8 -- -
True and false injections produced different responses

True Request: POST
https://shopdivinity.dukestores.duke.edu/index.php?main_page=%27+or+8%3D8+--+-&products_id=88&action=add_product
HTTP/1.1
Origin: https://shopdivinity.dukestores.duke.edu
Upgrade-Insecure-Requests: 1
Referer:
https://shopdivinity.dukestores.duke.edu/index.php?main_page=product_info&products_id=88
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
Sec-Fetch-User: ?1
Content-Type: multipart/form-data; boundary=----
WebKitFormBoundary7nBlQaZGTt8Q9Zta
------WebKitFormBoundary7nBlQaZGTt8Q9Zta
Content-Disposition: form-data; name="securityToken"
b9c1e0c45095d895b9e1ff2fdedb2cd9
------WebKitFormBoundary7nBlQaZGTt8Q9Zta
Content-Disposition: form-data; name="cart_quantity"
1
------WebKitFormBoundary7nBlQaZGTt8Q9Zta
Content-Disposition: form-data; name="products_id"
88
------WebKitFormBoundary7nBlQaZGTt8Q9Zta
Content-Disposition: form-data; name="x"
0
------WebKitFormBoundary7nBlQaZGTt8Q9Zta
Content-Disposition: form-data; name="y"
0
------WebKitFormBoundary7nBlQaZGTt8Q9Zta--

False Request: POST
https://shopdivinity.dukestores.duke.edu/index.php?main_page=%27+or+8%3D6+--+-&products_id=88&action=add_product
HTTP/1.1
Origin: https://shopdivinity.dukestores.duke.edu
Upgrade-Insecure-Requests: 1
Referer:
https://shopdivinity.dukestores.duke.edu/index.php?main_page=product_info&products_id=88
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
Sec-Fetch-User: ?1
Content-Type: multipart/form-data; boundary=----
WebKitFormBoundary7nBlQaZGTt8Q9Zta
------WebKitFormBoundary7nBlQaZGTt8Q9Zta
Content-Disposition: form-data; name="securityToken"
b9c1e0c45095d895b9e1ff2fdedb2cd9
------WebKitFormBoundary7nBlQaZGTt8Q9Zta
Content-Disposition: form-data; name="cart_quantity"
1
------WebKitFormBoundary7nBlQaZGTt8Q9Zta
Content-Disposition: form-data; name="products_id"
88
------WebKitFormBoundary7nBlQaZGTt8Q9Zta
Content-Disposition: form-data; name="x"
0
------WebKitFormBoundary7nBlQaZGTt8Q9Zta

-end of message-

To understand some context, can you outline in what ways have your stores been changed from original Zen Cart code?

Hi,

The only change from the stock install is we are using a CyberSource payment module. I don't understand all the details of the vulnerability SecureTrust is alleging but it looks like if they append 8=8 or 8=6 to their POST reques the zen cart database is returning different responses, possibly meaning those values are being passed directly to the SQL request and not being filtered out. Thanks for any insight. -Scott

At first glance, this has nothing to do with any POST variables,
The parameter being manipulated is the GET main_page variable, which is never used in any sql to add a product.

The question then becomes, why do the 2 different main_page settings produce a different html output.

I think this is a false positive, but still need to understand why.

Having trouble replicating anything that is actually a security issue.

What Zen Cart version did you upgrade from? (eg: you indicated you've been having scans for 3 years, so presumably this only "started" with the first scan on 1.5.7?)

Can you zip up your /includes/ directory and subdirectories (from your server) and email it to me at [email protected] (you can leave out your db credentials in the configure.php file: I don't need/want those!) (a fresh install of 1.5.7 contains around 10 MB, which zips down to under 4 MB ... most email programs allow 7-10 MB file attachments) (You could email a Dropbox link or Google Drive download link, instead, too.)
I'd like to use it to compare against a fresh ZC install to identify how things have been customized, just in case something unexpected is in your files.

Also, does your relationship with them let you ask for the actual HTML output they got for the good/bad requests? It's possible that in this case they're actually causing an add-to-cart, which puts "one" item in the cart, and then the next request (since we can tell they're not isolating tests from each other, evidenced by the fact that they're using the same security token) puts "another" item in the cart, thus there are 2, not 1, which means the output is "different" (and that "different" is what flags them to think there's a vulnerability).
The actual HTML from both the true/false tests would be extremely helpful.

Thanks for your help wilt and Dr Byte. I'm sorry I didn't have instant email notifications enabled in my settings, I do now so will be much more responsive.

What Zen Cart version did you upgrade from? (eg: you indicated you've been having scans for 3 years, so presumably this only "started" with the first scan on 1.5.7?)

When we first failed the scan a few weeks ago we were running 1.5.6, so I figured lets upgrade to the current version and see if that fixes things. And then we failed the scan again with 1.5.7. Although they scan us regularly I believe this new fuzzy SQL Injection vulnerability testing is brand new, it has never been part of their testing suite before. So it entirely possible it could be a false positive but they're going to ask me for supporting evidence if that's the case, unfortunately.

DrByte I will gladly send you my files but would it be easier for you to troubleshoot this if I ask them to scan one of your vanilla 1.5.7 sites if you have one up? In that case you could be sure that I didn't make any modifications to the code and you've have better access to the httpd logs. Just let me know, I'll be glad to compress and send you the files if that's what you would prefer.

Given that the problem existed before the upgrade, it's hard to isolate it to one ZC version.

It would be helpful if they'd give you the actual response differences their bot received, in order to ascertain the actual reason for the difference.

Remember, Zen Cart randomly displays different sidebar and banner content on every page load. If their algorithm is flagging these normal randomizing content changes as being an SQLi issue, then it's definitely a false-positive.

A manual comparison of the actual generated HTML produced by both the true and false "tests" their bot did, would be revealing.

Secondarily I'd be happy to review a zip of your site files as an added precaution.

Good news! I asked our compliance office to have our scanning company provide the additional details that you had requested. This is what they said -

"Trustwave is now passing the SQL injection finding. This had to be a false positive; the same issue recently occurred with another website."

So we're good now, I really appreciate the quick feedback and help you provided with this!