PCI Compliance scan

The results of a PCI compliance scan of our store by "Trust Keeper" threw up the following four failures. I realise that some are to do with the server (though I've included them for completeness). The third - "Cross-Site Scripting" - would appear to be a Zen Cart issue.

I'm using 1.3.9d though I think that at the time of the scan I was still on 1.3.9c

Linux nfs-utils Overflow

Severity: High

PCI: The detection of this vulnerability results in PCI Non-Compliance.

CVSSv2:: AV:N/AC:L/Au:N/C:C/I:C/A:C

Base Score: 10

Description: The rpc.mountd service was detected on this server. This is a remote procedure call (RPC) based service that is known to have an overflow vulnerability which can give root-level access to an attacker. Note that this service may have been activated by default when you installed your operating system.

Remediation: Block access to this service using a firewall rule or router access control lists (best practice rules only allow the minimally required service connections to the public). Also, consider disabling this and other RPC services that are not actually being used in your normal operations.

Unix/Linux RPC Service Accessibility

Severity: High

PCI: The detection of this vulnerability results in PCI Non-Compliance.

Description: Ports associated with Unix/Linux remote procedure calls are accessible from the Internet. This generally reflects a lack of adequate firewalling or other network-level access control.

Cross-Site Scripting (XSS)

Severity: Medium

PCI: The detection of this vulnerability results in PCI Non-Compliance.

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

Base Score: 4.3

Description: Cross-site scripting is a term used to describe problems which arise when maliciously crafted user data causes a web application to re-direct an unsuspecting web browser to an undesired site. It was possible to send strings with special HTML characters ( < > " ' ) to your web application, and see them rendered in the response. Since these characters were not encoded by the web application, it may be possible to inject HTML scripting code into the rendered page. The injections can occur in your HTML body, Title, Scripting, or even commented out portions of the document. Note: Due to the potential negative impact on this web server's resources that could result from attacking a large number of cross-site scripting attack vectors, TrustKeeper abandons this test after it has found at least three instances where user input is not being properly sanitized. Therefore, it is possible that the reported findings associated with this vulnerability are only a subset of all possible attack vectors.
Note: All Cross-Site Scripting vulnerabilities are considered non-compliant by PCI.

Remediation: This is a generic warning based on a test that indicates that your web application may not validate user-provided input, such as that provided by a form. Review your web application to ensure that user data is checked on the server side of the application (NOT in the web browser) for proper length and character content. It is recommended that a white-list of acceptable characters be used, with all other characters being HTML encoded prior to being sent in response to the client. Review the "Cross-Site Scripting", "Data Validation", and "Review Code for Cross-site scripting" pages on OWASP.org (see the reference links in this finding).

SSLv2 Supported

Severity: Medium

PCI: The detection of this vulnerability results in PCI Non-Compliance.

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

Base Score: 5

Description: This SSL service supports SSLv2 connections. SSLv2 has known cryptographic weaknesses that can lead to the compromise of data encrypted during the SSL session. Secure web applications should only enable SSLv3, TLSv1, or newer. SSLv3 was released in 1996 with numerous security enhancements over SSLv2. TLSv1 was introduced in 1999 as an enhancement to the security features of SSLv3. All modern browsers have support for both SSLv3 and TLSv1, and often disable support for SSLv2 in the interests of security. The PCI ASV Operational Requirements requires that if SSLv2 is used in the transmission of cardholder data, this must result in a failure. This was clarified in the PCI "Assessor Update: November 2008" (see the reference link in this finding).

Remediation: If this service is used for the transmission of cardholder data, then SSLv2 should be disabled, and SSLv3, TLSv1, and/or newer should be implemented. For Apache and mod_ssl, the "SSLProtocol" configuration option is commonly used to limit the protocol versions for web servers which use OpenSSL: SSLProtocol -ALL +SSLv3 +TLSv1. (See the reference link to apache.org for more information). For Microsoft IIS server, refer to the Microsoft Knowledge Base article kb187498 to remove SSLv2 support. (See the reference link to support.microsoft.com for more information). For information on disabling SSLv2 in other HTTP web servers or other services, contact the service vendor for support information.

The cross scripting one is a false positive.

All the rest of them are server related.

Thanks for the confirmation. The server-related ones are in hand with our service provider.

Any guidance as to how I should appeal the false positive with the compliance people?

Regards

Nick

Just submit the false positive to them. You could say their scanner does not scan deep enough to see sanitation. It seems like a general message.

What is stated from them can not be the full information, it does not include vulnerability number, concept and solution. Under PCI rules in order to be above a # 2 it must come with a concept and solution.

Thanks for the follow-up.

I should, perhaps, mention that I'm using Ceon Manual Card as a payment module. I realise you don't support this directly, but is it likely to be exposing this vulnerability? If so, I can take it up with Conor.

Regards

Nick

No it doesn't relate to that in particular. The information provided by the scanning company should show what they did to come to that conclusion...that is what is missing. Without that there is no way to know.

There are a lot of security sites out there that have vulnerability and bugtrack... all the cross scripting vulnerabilites noted have solutions pointing back to this forum for earlier versions of ZC. 1.3.9d is ok as of the date of this post.

I appealed this with TrustKeeper but the appeal was denied on the basis that:

"We have denied this appeal based on the lack of information provided regarding the vulnerability itself. Please re-appeal this vulnerability and confirm that user data is sanitized on the server side of the application, assuming that it is."

I have re-appealed it with a simple statement that "I can confirm that user data is sanitized on the server side of the application" but it would be handy to have some more detailed information in reserve in case that's not enough for them.

Regards

Nick

Definitely keep re-appealing. THEY are the ones at fault here.

Sorry for the CAPS following ... I don't mean to SHOUT, but I do mean to emphatically make a point ...

THERE IS NO WAY TO CONFIRM OR DENY, LET ALONE TEST, AN ALLEGED VULNERABILITY IF NO SPECIFIC DETAILS ARE SUPPLIED.
Since they've given you ABSOLUTELY no real details, tell them there's no way they can legitimately fail you, let alone deny an appeal.
It is THEY who have done the "lack of information provided regarding the vulnerability itself".

Demand your money back. And/or ask to speak to the president of the company to address the incompetence of their staff and services.

Geez ... these scanning companies are just raping people for cash-grabs and flaunting their facade of power.

As of September 1st all ASV's are mandated to report the same findings with the same vulnerability ratings as per a new requirement from the PCI Security Council.

BTW, TrustKeeper is actually Trust Wave. DrByte kinda said it all.

An ASV can not make a level 3,4 or 5 without showing concept, solution and output. (This is in the ASV Guidebook)

This is a copy and paste of the relevant section of the full report of the scan. Does it shed any more light?

Cross-Site Scripting (XSS)

Cross-site scripting is a term used to describe problems which arise when maliciously crafted user data causes a web application to redirect an unsuspecting web browser to an undesired site. It was possible to send strings with special HTML characters ( < > " ' ) to your web application, and see them rendered in the response. Since these characters were not encoded by the web application, it may be possible to inject HTML scripting code into the rendered page. The injections can occur in your HTML body, Title, Scripting, or even commented out portions of the document. Note: Due to the potential negative impact on this web server's resources that could result from attacking a large number of cross-site scripting attack vectors, TrustKeeper abandons this test after it has found at least three instances where user input is not being properly sanitized. Therefore, it is possible that the reported findings associated with this vulnerability are only a subset of all possible attack vectors.

Note: All Cross-Site Scripting vulnerabilities are considered noncompliant by PCI.

Service: (80) Apache
Evidence:
• Virtual Host: https://www.donallnagealai.ie
• Date: 2010-06-13 01:49:39.075
• Vulnerable Page: http://83.170.124.30:80/
shop/index.php?main_page=contact_us&
action=send&zenid=c9678045c8081a83624f6b102659d049
• HTTP Request Mode: post
• HTTP Status Code: 200
• Test Input String: %3CScRipT%20%3Ealert%28%27test
%27%29%3B%3C%2FScRipT%20%3E
• Search Pattern: <ScRipT >alert('test');</ScRipT >
• Pattern Match: <ScRipT >alert('test');</ScRipT >
• Referrer Page: http://www.donallnagealai.ie/
shop/index.php?main_page=contac
t_us&zenid=c9678045c8081a83624f6b102659d049
• Vulnerable Parameter: contactname
• Vulnerable Parameter: email

Service: (80) Apache
Evidence:
• Virtual Host: https://www.donallnagealai.ie
• Date: 2010-06-13 01:49:40.476
• Vulnerable Page: http://83.170.124.30:80/
shop/index.php?main_page=contact_us&
action=send&zenid=c9678045c8081a83624f6b102659d049
• HTTP Request Mode: post
• HTTP Status Code: 200
• Test Input String: %22%3E%27%3E%3CIfRaME%3E
• Search Pattern: (?i)(?<!")>'><IfRaME>
• Pattern Match: >'><IfRaME>
• Referrer Page: http://www.donallnagealai.ie/
shop/index.php?main_page=contac
t_us&zenid=c9678045c8081a83624f6b102659d049
• Vulnerable Parameter: contactname
• Vulnerable Parameter: email

Reference: http://www.cert.org/advisories/CA-2000-02.htmlReference:
http://www.owasp.org/index.php/Cross-site_scriptingReference:
http://www.owasp.org/index.php/Data_ValidationReference: http://
https://www.owasp.org/index.php/Review_Code_for_Cross-site_sc ripting

CVSSv2: AV:N/AC:M/Au:N/C:N/I:P/A:N (Base Score:4.30)

Remediation Action

This is a generic warning based on a test that indicates that your web application may not validate user-provided input, such as that provided by a form. Review your web application to ensure that user data is checked on the server side of the application (NOT in the web browser) for proper length and character content. It is recommended that a white-list of acceptable characters be used, with all other characters being HTML encoded prior to being sent in response to the client. Review the "Cross-Site Scripting", "Data Validation", and "Review Code for Cross-site scripting" pages on OWASP.org (see the reference
links in this finding).

1. I can't recreate either of those problems on a v1.3.9d site.
2. When testing them on your site, I can't, because there's no "submit" button because your ReCaptcha addon is broken, making your contact-us page non-functional.

Yup - just spotted the broken recaptcha thing. Had overwritten a header.php file during the last upgrade.

Now fixed - try again, if you don't mind.

Okay, using just a browser, I can't replicate either of those problems using the details posted.

I suggest you ask them to prove there's a real vulnerability with human interaction, not just some false-positive happening because of an automated testing robot.

Or maybe whatever problem you had earlier was causing what they were complaining about.

k,

I created the script below.

<?php
@ini_set('display_errors', 'on');
error_reporting(E_ALL);

define('POSTURL', 'http://www.donallnagealai.ie/shop/index.php?main_page=contact_us&action=send');
define('POSTVARS', 'contactname=%3CScRipT%20%3Ealert%28%27XSS%27%29%3B%3C%2FScRipT%20%3E'); 
$ch = curl_init(POSTURL);
curl_setopt($ch, CURLOPT_POST,1);
curl_setopt($ch, CURLOPT_POSTFIELDS,POSTVARS);
curl_setopt($ch, CURLOPT_HEADER ,0);  
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
$data = curl_exec($ch);
echo $data;
curl_close($ch);

running that script, basically recreates one of the tests mentioned

however if you look at the output, it shows the contactname being sanitized to

_ScRipT alert('XSS');/ScRipT _

... which of course poses no risk, and you can see that it doesn't match the "Search Pattern" or "Pattern Match" ideas reported by the scanner (there are no < or > symbols, thus there is no match, and also no problem.

I got the email resulting from it.

What I don't understand here is this: surely the worst that can result from misuse of this form is me receiving an email full of gobbledegook. It's not as though (AFAIAA) this actually interfaces with the customer module in the SQL database.

Regards

Nick

What they're testing for is the idea of causing an error message with one field, but with the other field cause some javascript or other rogue action that starts some unknown behavior on the webpage, perhaps even loading data from your database or stealing information from your site/cookies via a rogue script they're summoning hidden from another site. All that can only happen if they can trigger an error that causes the data they input to be drawn back again on the screen (as part of the error message and/or just to re-populate the fields that were filled in, using the data they input) and executed by the browser to pull/run the scripts from those other sites.
While it's not a "frequent" type of attack because the payload is minimal vs the effort required to produce it, it does happen.
The current version of Zen Cart is not vulnerable to the attack they described.

Thanks for all of your help. I'll keep you posted on the appeal status.