PCI Fail, XSS Security Metrics Patched 1.3.8a

Below is the email, site is 1.3.8a, patched and hosted on our servers, which scanned compliant. This is the site http://www.careapparel.com/, along with ALL of the carts 1.3.8a patched as follows....

http://www.lifescomforts.com/
http://www.careactive.com/
http://www.ballastkit.com/
http://www.silverandpewtergifts.com/
and about 8 more, all Security Metrics, all failed for this reported vulnerability.

TCP 80 http LVL7 A cross site scripting vulnerability was found on the server. This vulnerability has been associated
with megaBook guestbook V2.0. Solution: Contact the vendor for a patch. Risk: High

TCP 443 https LVL4 http://en.wikipedia.org/wiki/Cross-site_ scripting Solution: Contact the vendor for a patch or
upgrade. Risk Factor: Medium / CVSS Base Score : 4.3 (CVSS2#AV:N/AC:M/Au:N/C:N/I:P/A:N)
CVE : CVE-2002-1060, CVE-2003-1543, CVE-2005-2453, CVE-2006-1681 BID : 5305, 7344, 7353,
8037, 14473, 17408 Other references : OSVDB:18525, OSVDB:24469, OSVDB:42314, OSVDB:4989,
OSVDB:58976 Risk: High

Synopsis : The remote web server is prone to cross-site scripting attacks.

Description : The remote host is running a web server that fails to adequately sanitize request strings of malicious JavaScript.
By leveraging this issue, an attacker may be able to cause arbitrary HTML and script code to be executed in a user's browser within the security context of the affected site. See also :
http://en.wikipedia.org/wiki/Cross-site_ scripting

Solution: Contact the vendor for a patch or upgrade. Risk Factor: Medium / CVSS Base Score : 4.3 (CVSS2#AV:N/AC:M/Au:N/C:N/I:P/A:N) CVE : CVE-2002-1060, CVE-2003-1543, CVE-2005-2453, CVE-2006-1681 BID : 5305, 7344, 7353,
8037, 14473, 17408 Other references : OSVDB:18525, OSVDB:24469, OSVDB:42314, OSVDB:4989, OSVDB:58976

TCP 80 http 4
Synopsis : The remote web server is prone to cross-site scripting attacks.

Description : The remote host is running a web server that fails to adequately sanitize request strings of malicious JavaScript.
By leveraging this issue, an attacker may be able to cause arbitrary HTML and script code to be executed in a user's browser within the security context of the affected site.

See also : http://en.wikipedia.org/wiki/Cross-site_ scripting

Solution: Contact the vendor for a patch or
upgrade. Risk Factor: Medium / CVSS Base Score : 4.3 (CVSS2#AV:N/AC:M/Au:N/C:N/I:P/A:N) CVE : CVE-2002-1060, CVE-2003-1543, CVE-2005-2453, CVE-2006-1681 BID : 5305, 7344, 7353, 8037, 14473, 17408 Other references : OSVDB:18525, OSVDB:24469, OSVDB:42314, OSVDB:4989,
OSVDB:58976

Concerning the cross-site scripting vulnerabilities that were flagged for https://www.careapparel.com, the reason it was flagged is because the script used by the scanner during the test was returned in the page source.

This is also the reason that 'megaBook' was flagged, not because you have it installed.

Here is an example of what is being
flagged for by the scanner (using the terminal application 'cURL'):

:~$ curl -l
'http://www.careapparel.com/admin.cgi?action=modifypost&entryid="><script>al
ert(document.domain)</script>'
| grep "document.domain"
 % Total    % Received % Xferd  Average Speed   Time    Time     Time
Current
                                Dload  Upload   Total   Spent    Left
Speed
100  1038    0  1038    0     0   1043      0 --:--:-- --:--:--
--:--:--  1043<link rel="canonical"
href="http://www.careapparel.com/admin.cgi?action=modifypost&entryid="><scri
pt>alert(document.domain)</

script>"
/>

> 
> In order to resolve this, you will want to have the web developer make sure that the source being returned by the web server is properly validated and that we're not able to see the injected script returned in the page source.
> 
>     Sincerely,
> 
> 
>     Travis H
>     SecurityMetrics
>     Technical Support
>     Security Support Supervisor
>     (801)705-5700
>     (801)724-9600 Main
>     (801)623-5621 Fax for Questionnaires
>     0207.993.8031 UK
>     <https://www.securitymetrics.com>

Did I mention PCI sucks :censored:

~Melanie

Acunetix Report

Request
GET /index.php/>"><ScRiPt>alert(58139)</ScRiPt> HTTP/1.0
Accept: /
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Host: https://www.careapparel.com
Cookie: zenid=184f7bb5c1756d0b575ce56b31e6971d
Connection: Close
Pragma: no-cache
Acunetix-Product: WVS/6.0 (Acunetix Web Vulnerability Scanner - Free Edition)
Acunetix-Scanning-agreement: Third Party Scanning PROHIBITED
Acunetix-User-agreement: http://www.acunetix.com/wvs/disc.htmResponse
HTTP/1.1 200 OK
Date: Tue, 18 May 2010 04:17:12 GMT
Server: Apache
X-Powered-By: PHP/5.2.10
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Pragma: no-cache
Connection: close
Content-Type: text/html; charset=iso-8859-1
Content-Language: en-US

Vulnerability description
This script is possibly vulnerable to Cross Site Scripting (XSS) attacks.

Cross site scripting (also referred to as XSS) is a vulnerability that allows an attacker to send malicious code (usually in the form of Javascript) to another user. Because a browser cannot know if the script should be trusted or not, it will execute the script in the user context allowing the attacker to access any cookies or session tokens retained by the browser.

This XSS variant usually appears when a PHP script is using one of following variables without filtering them:
PHP_SELF
REQUEST_URI
SCRIPT_URL
SCRIPT_URI

Those variables are set either by Apache or the PHP engine. Apache is automatically ignoring anything in the URI after the .php extension for mapping script filename, but these variables are containing the full URI.
This vulnerability affects /index.php.
The impact of this vulnerability
Malicious users may inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable application to fool a user in order to gather data from them. An attacker can steal the session cookie and take over the account, impersonating the user. It is also possible to modify the content of the page presented to the user.

How to fix this vulnerability
Your script should filter metacharacters from user input.

I know you guys are very busy, but as far as I can see this is real and in all 1.3.8 carts.

Do you intend to release a patch for this? If you do I can report that a patch has been requested and the carts will pass PCI on the exception for software patch in progress.

I will test a 1.3.9 cart today after I apply the latest release, guessing it will pass.... So I would even be willing to merge the functionality from the new release to solve the problem, but I am no programmer.

We have so many customers who just cannot upgrade right now, they have modules and such that are simply not ready. We very much need a patch to hold them over until they can upgrade.

~Melanie

I can't see anything in what you've posted that's actually related to Zen Cart.

The only possible "proof of concept" piece you posted talks about "admin.cgi" ... which is not a Zen Cart component.

If you have an actual detailed proof-of-concept as it relates to a Zen Cart page, then we might be able to look into it.

This is what they are running

    :~$ curl -l
    'http://www.careapparel.com/admin.cgi?action=modifypost&entryid="><script>al
    ert(document.domain)</script>'
    | grep "document.domain"
     % Total    % Received % Xferd  Average Speed   Time    Time     Time
    Current
                                    Dload  Upload   Total   Spent    Left
    Speed
    100  1038    0  1038    0     0   1043      0 --:--:-- --:--:--
    --:--:--  1043<link rel="canonical"
    href="http://www.careapparel.com/admin.cgi?action=modifypost&entryid="><scri
    pt>alert(document.domain)</

    script>"
    />

Which is this reported vulnerability same as megaBook guestbook V2.0.

The issue is that once injected the injected code is seen in the resulting page source. Which is the problem, the overall handling of the injection is fine, as the error produced is 404, but the injection of the hack in to the source (they say) allows for further penetration and the ability to get the injected page to current users.

The Mega book string is just the one they used, but the search forms are vulnerable to other strings as well. None of the sites are using CGI, nor Mega book, it's just the standard string they are using for testing.

I am happy to supply the whole report, but It's a bit too big won't upload here.

~Melanie

Melanie,

Admin.cgi is not part of Zen Cart at all and is part of a some sort of function of the server setup cgi bin.

Disable CGI and delete the cgi bin for the user account and rerun the scan.

This is not a Zen Cart issue.

Qdixon:

Melanie,

Admin.cgi is not part of Zen Cart at all and is part of a some sort of function of the server setup cgi bin.

Disable CGI and delete the cgi bin for the user account and rerun the scan.

This is not a Zen Cart issue.

CGI is fully disabled and no CGI bin exists on the accounts in question. The admin cgi comes from running the cURL hack provided below as the MegaBook vulnerability is part of their standard test.

The scan failed under these conditions.... CGI privileges for the accounts are disabled, no CGI bins exist, MegaBook is not and has never been installed.

The issue is not that MegaBook or CGI exist (as neither do), but rather that running this allows the hack to be injected in to the resulting page source. So this hack or another matters not as the failure is that the resulting page (404) is actually injected.

Because the result is injected, it is a PCI fail as the resulting page cannot show the hack source... no matter what the hack. It must be sanitized.

~Melanie

mprough:

CGI is fully disabled and no CGI bin exists on the accounts in question. The admin cgi comes from running the cURL hack provided below as the MegaBook vulnerability is part of their standard test.

The scan failed under these conditions.... CGI privileges for the accounts are disabled, no CGI bins exist, MegaBook is not and has never been installed.

The issue is not that MegaBook or CGI exist (as neither do), but rather that running this allows the hack to be injected in to the resulting page source. So this hack or another matters not as the failure is that the resulting page (404) is actually injected.

Because the result is injected, it is a PCI fail as the resulting page cannot show the hack source... no matter what the hack. It must be sanitized.

~Melanie
PCI scan failure or not, it appears the problem is with your server.
There's no evidence in this thread so far that points to Zen Cart in any way.

The failed carts are on 5 different servers, only 1 of which is ours. The common thread is that they all failed with Security Metrics. 2 on BlueHost, one on mine, one on NetSol and the rest on HostGator.

I have emailed this guy isaac and asked him to provide the specific details of the vulnerability, and the logic of this issue with the search form.

I will supply this as soon as he responds.

~Melanie

This guy from SM is an a$$, here is what he responded with for my request to supply the logic.

Melanie,

You may not be running Guest Book; however, this vulnerability normally shows up with guest book. If you are not running guest book than you will need to disregard the guest book and pay particular attention to the cross site scripting.

I will include a few examples below. I do not want to include the full test results for security purposes:

Submitted Form State:

• search_in_description: 1
• keyword: 96aa672c4766b343eb136ead882a08cb

Results:
The unencoded attack string was found in the html of the document. Other browsers may be vulnerable to this XSS string.
Tested value: [\xC0][\xBC]script>document.vulnerable=true;[\xC0][\xBC]/script>
The unencoded attack string was found in the html of the document. Other browsers may be vulnerable to this XSS string.
Tested value: <div datafld="b" dataformatas="html" datasrc="#X"></div>

Submitted Form State:

• main_page: advanced_search_result
• search_in_description: 1

Results:
The unencoded attack string was found in the html of the document. Other browsers may be vulnerable to this XSS string.
Tested value: [\xC0][\xBC]script>document.vulnerable=true;[\xC0][\xBC]/script>
The unencoded attack string was found in the html of the document. Other browsers may be vulnerable to this XSS string.
Tested value: <xml id="X"><a><b><script>document.vulnerable=true;</script>;</b></a></xml>

The cross scripting vulnerability revolving around the advanced search was deemed a false positive long ago. Security Metrics seems to ignore this as they are the only ones that have not updated their listings.

I basically told him to put up or shut up, that these were clearly false positives IF he cannot provide the actual vulnerability and here is what he responded..

If the fact still remains that user input is allowed in particular areas of the site you will continue to fail. This is because manipulation of your scripting is possible via user by someone with malicious intent.

Use ControlScan

Qdixon:

The cross scripting vulnerability revolving around the advanced search was deemed a false positive long ago. Security Metrics seems to ignore this as they are the only ones that have not updated their listings.

Can you provide me the correct language to get this properly declared as a false positive and thus tell him to shove it in his a$$

~Melanie

mprough:

Can you provide me the correct language to get this properly declared as a false positive and thus tell him to shove it in his a$$

~Melanie

This is a "Wilt" or "DrByte" question.

Well, SM is a pain...

Any chance I can get the correct language to get the advanced search false positive to them.

They will not listen, the client is going to report them for being forced to use them by the processor, but in the meantime, they paid $$ for these scans and the dim whits will not remove this false positive w/o documentation/proof.

PCI is a damn mess

~Melanie

Melanie,

We're having difficulty finding any way to trigger the problem you describe.
However, we'll be including some changes in the next release to deal with a false positive in the contact-us page. These changes might help stop the situation you're dealing with.

The files in the attached zip are for v1.3.9c.
Backporting to 1.3.8 is not a pleasant experience though :(

https://www.zen-cart.com/download/139c-pci-fixes-beta.zip

Excellent, I will patch it an have the idiots rescan =-)

~Melanie