Failed PCI Compliancy

**Website Failed PCI Complaincy Test!

openSSH X11 Session Hijacking Vulnerability**

OpenSSH is prone to a vulnerability that allows local attackers to hijack forwarded X connections. The system must have both IPv4 and IPv6 enabled at the same time for this to be exploited. Successfully exploiting this issue may allow an attacker run arbitrary shell commands with the privileges of the user running the affected application. This issue is known to affect OpenSSH 4.3p2, though other versions may also be affected. This vulnerability will trigger on any SSH banner version prior to 'openssh-5'. OpenSSH packages shipped with Red Hat Enterprise Linux 4 and 5 are not vulnerable to this issue. However, Red Hat Enterprise Linux 2.1 and 3 are affected.

remediation:

Due to the fact that this vulnerability is detected by analyzing the SSH banner version, an appeal must be submitted after following any remediation step other than upgrading to OpenSSH 5.0. There are several options for removing this issue: 1) Instruct OpenSSH to use only IPv4 or IPv6 by adding either "AddressFamily inet" or "AddressFamily inet6" to sshd_config. 2) Configure the operating system to only use IPv4 or IPv6, but not both. 3) Confirm with your vendor that your version of SSH is patched or CVE-2008-1483. 4) Upgrade to version 5.0 of OpenSSH, or acquire appropriate patches from your vendor. It is strongly recommended that the latest stable version with all of the appropriate patches be installed. 5) Disable X11 forwarding in the sshd_config if it is not needed.

OpenSSH Privilege Separation Monitor Weakness

Based on the version reported reported by OpenSSH running on this host, it is prone to a weakness that, under certain conditions, could allow an attacker to bypass authentication. This issue is due to a design error in the privilege separation monitor that could cause it to authenticate when it should not.

remediation:

This vulnerability was fixed with the release of OpenSSH 4.5, however it is recommended that you upgrade to the latest supported release. Confirm with your vendor that your version of SSH is patched or CVE-2006-5794.

**OpenSSH X11 Cookie Local Authentication Bypass Vulnerability

**OpenSSH is prone to a local authentication-bypass vulnerability because the software fails to properly manage trusted and untrusted X11 cookies. This vulnerability affects local SSH clients with trusted X11 forwarding enabled (enabled via the '-Y' ssh command line argument, or the ssh_config option "ForwardX11Trusted" set to "yes").

Successfully exploiting this issue allows local attackers to potentially launch a forwarded X11 session through SSH in an unauthorized manner. This issue is known to affect OpenSSH starting with version 3.8, and was fixed with the release of version 4.7.remediation:

This issue was fixed with the release of version 4.7 of OpenSSH. However, it is strongly recommended that the latest stable version with all of the appropriate patches be installed.

This issue did not affect the OpenSSH packages as distributed with Red Hat Enterprise Linux 2.1 or 3, as they do not support Trusted X11 forwarding.

OpenSSH < 4.4 Multiple Vulnerability

OpenSSH prior to version 4.4 is affected by multiple vulnerabilities that may allow for a remote attacker to execute arbitrary code on the affected device.
remediation:

This issue was fixed in OpenSSH version 4.4. Upgrade to a recent/stable version

OpenSSH Duplicate Block Denial of Service Vulnerability

A version of OpenSSH prior to 4.4 is running on this host. This version is affected by a Denial of Service vulnerability. However, an attack can only be performed if version 1 of the SSH protocol is enabled.

remediation:

SSH version 1 should be disabled, as it has inherent weaknesses that can be leveraged for man-in-the-middle attacks.

DB Accessibility

There is a port open on this server that is usually used for database connections. Payment industry policy forbids exposing databases containing cardholder data directly to the Internet.

remediation:

You may use the TrustKeeper Appeal process if the database server running on this host is not involved in the storage of cardholder data by your organization, or if you believe that this policy should be waived for any other reason. Please be sure to clearly describe what kind of information is stored in this database if it is associated with an e-commerce application.

MySQL Database Detected

The scanner was able to successfully connect to a MySQL server on this system.

remediation:

Databases should not be accessible from the Internet. Your web site should be re-architected so that the database is protected by a firewall or router access control list. In the short term, consider implementing database access control lists in order to prevent unauthorized IP addresses from connecting to MySQL.

Unsure what part of these i should change something on the site or which part i should contact my host for changes etc.

Any guideance would be great.

been onto my hosts regarding the openSSH and they report the following.

OpenSSH is updated by applying hotpatches rather than upgrading the version. It's fully up to date - you may just need to tell your PCI compliance folks that it's a cPanel server and is patched automatically with their updates.

So why are you posting this here, these vulnerabilities have zero to do with Zen Cart.

You must take this up with your host. This update has nothing to do with updating cpanel either.

Depending on the OS that is running on the machine you will need to update the SSH package to a more recent version. This one is extremely important.

Just to add your host should know better and supply you with a screen shot of the ssh version via the console:

ie/ openssh -v
or openssh version
(depends on what os is running)

I posted this here as i was not 100% sure if it was sofeware or hardware problems. This is why i asked on here. As I was always told, "got a problem? ask and expert"

Also posted this here as its the only private section as you can imagen i wouldn't want to post this on the live forum.

I have sent the full report over to my hosts and they are now saying i need to move to a VPS server to be 100% compliant.

Searched the forums here about zencart hosting and no ware does it say i need VSP server..... how ever i did also search for PCI and found no posts. I can't be the only person having PCI issues surly with this now being a legal requirment.

Its a linux server

No you do not need a VPS server, that is their way of sending you on your way to doing everything yourself. VPS stands for a Virtual Private Server or in other words not a dedicated server but, 1 server is usually divided up into multiple OS installations running in tandem.

If the SSH is the only vulnerability that is holding up your PCI Compliance, simply ask your host to provide you with a screenshot in SSH that shows the version that is running. If it is a updated version showing, submit this to your ASV.

On the other hand, if it shows a vulnerable version and your host will not do anything about updating it, find another host.

DB Accessibility

There is a port open on this server that is usually used for database connections. Payment industry policy forbids exposing databases containing cardholder data directly to the Internet.

remediation:

You may use the TrustKeeper Appeal process if the database server running on this host is not involved in the storage of cardholder data by your organization, or if you believe that this policy should be waived for any other reason. Please be sure to clearly describe what kind of information is stored in this database if it is associated with an e-commerce application.

This is the only other issue, and this is the reason the hosts said i would need a VSP server so that the database would be not accessible. How ever, would i be correct in saying that no credit card details are stored on the database? so this shouldn't apply?

Reply from host regarding DB connection

"It seems to be failing on MySQL connections, we're not able to close this off as customers need to connect remotely. To become fully PCI compliant you would need a VPS server."

The actual PCI Requirement is "any database that holds CARD HOLDER DATA must not be directly accessible."

If you run cpanel, the port is a deny all except for certain ip's in the remote mysql. This does satisfy the requirement.

Another way around this is proving that you do not store cardholder data in the database. You must provide a declaration stating this. It must also be declared in your SAQ as such. Note: this is based on the fact that you are actually not storing anything and I don't know your setup, so be 100% sure.

Otherwise the port must be firewalled and closed to remote access.

As I said before, if your hosting is willing to do nothing find a new one.

just to add to this i finally got all the SSH stuff sorted and my host have been very good to be fair, they supplied me with all the outputs from cpanel and the server show all the server patches and output from the yum list etc etc, basically the PCI people are not rushing.

My setup is all setup with sagepay and the data is collected on my site them passed to sagepay via the SSL server (encripted 248bit) site then recieves info from sagpay to say if successful or not, the card date is not stored on the database just passed from the site to sagepay.

ill look at closing the firewall via IP, what would be the certain ips? my sites static ip? my ip so i can access? my ips of sales team?

checked the firewall and the only IP to have remote access to the database is the static ip of the site.

checked my database and the only CC data stores is the first 4 number and the last 4 numbers filled with xxxxxxxxxxxxx and the expiry date

Sorry to take so long to respond back.

In your case you ARE storing card holder data. Card holder data is defined as any information that contains any digits of a credit card number, cvv or expiry date.

In order to pass PCI Compliance while storing credit card numbers you must have a dedicated database server that is NOT directly accessible. Fully encrypt the data with a minimum of 128 bits of encryption cypher (Blowfish 40 bit is no good and is not compliant) and be audited as such classification.

It is much better to remove the "offline" credit card modules as the risk is way too high and the fines for a breach will bankrupt your company.