|
With 2012 here, and PCI compliance now on its 8th year, we are beginning to see more and more merchants becoming PCI compliant. A big reason to this is that banks and merchant account providers (MAPs) are now forcing their merchants to be PCI compliant. I think its great that they're doing this! And if you're not PCI compliant they hit you with an extra service fee. And we all know how much banks love their services fees. These fees can be anywhere from $20 per month to $100 per month or up to $1200 per year per merchant account. So if you have 2 websites, with two different merchant accounts, times that fee by two!
Many MAPs provide their own scanning service for you (possiby as part of an additional fee they are charging), or have a preferred vendor they work with, in addition to letting you use your own if you have one. The problem here is the bank or MAP generally has the final say if your compliant or not. This is especially unfair for Linux users, or even any web site hosted on a Linux server. The reason being, is that with Linux, its common to back port packages based on the CVE information. However a scanner typically just looks at the version in the header, and doesn't know whether its been patched or now.
In the past, with the reputable scanners, they understand this, and they have methods to handle such false positives. Such as requesting documentation as to what OS your running, what kernel, which patches you've applied. And in my clients case, he also had the output from Metasploit showing the exploit failed. And then they may manually test it as well, to ensure its not vulnerable. However, now with the banks in charge of the scanning you are at their mercy. One particular client of mine, had his explanation of a patched version of exim, rejected by his bank. The PCI department, which was not located in North America, at the U.S. owned bank, were utterly unhelpful and incompetent. One technician there admitted he had never heard of Linux.
Several weeks had gone by with no help from countless techs, depite promises that a higher level tech would get back to him in a unspecified time. On the final call, after mentioning the existing case number, the representative said, I see here there is a technical problem with your server causing you to fail the scan. After this it was clear the bank's PCI help department didn't have the knowledge, training and/or willingness to assist with the problem. And in their eyes, if my clients server showing up as vulnerable on a PCI scan, then it must be vulnerable. And it would be my clients responsibility to fix what ever it is on his end, and resubmit the scan.
This unwillingness by the bank doesn't surprise me. Considering they have up to 1200 reasons to not help someone pass a scan. If its a smaller bank or MAP and they have just few Linux hosted sites running a back ported package, then it may be very unlikely the bank will assist you. Its much easier for them to just say your uncompliant and charge you the extra fee.
So what are your options here? You can bite the bullet and uninstall (or overwrite) the old package to make the bank's scanner happy. However if you've done a lot of customizations, this may not be possible or practical, especially since many vulnerabiltes are fixed by changing a single line, or a few lines of code. Another option is to change the package header to a version that meets the scan requirement. You can also remove the version number totally, however the scanner may give an error, saying it could not determine the version and that the package may be vulnerable, which would cause the scan to fail.
Now the second option, should only be done as a last resort, and also only if you are 100% sure you are not vulnerable. You should also run this by your PCI consultant to ensure he approves it, as well as put this in your security documentation. You also want to carefully watch for any new exploits, as they may still apply to your base version.
Lets get to the howto. For example if you are running a cPanel server, they currently use (in their stable versions) a back ported version of Exim 4.69, which will show up as vulnerable on a PCI scan, even though its been patched to prevent those vulnerabilities. To get around this for scanners that are looking at the exim header, first check the change log:
rpm -q --changelog exim
This will give a list of the version changes, as well as CVE information. Figure out up to which version's patches have been applied. Or if its a package supplied by a third party, contact that 3rd party and ask them. A good idea to find up to which version it contains vulnerability patches for is by referencing it with http://www.cvedetails.com/. Note that you do not have to have every single vulnerability listed there patched for PCI compliance as some are minor/informational, or only apply to specific distros or architectures.
It would be a good idea to penetration test your server to help ensure its not vulnerable. We won't get into any specifics on how to do that here. However if you visit the CVE details site mentioned earlier, it will list available Metasploit Modules, if one exists for a particular vulnerability. If it is not vulnerable Metasploit will return something similar to:
Exploit exception: Something went wrong, perhaps this host is patched?
Workspace:default Progress:2/2 (100%) Complete (0 sessions opened) exploit/unix/smtp/exim4_string_format
Using Exim as our example, after you've found what version you have the secure equivelent of, edit the following file:
/etc/exim.conf
The line your looking for is as follow:
smtp_banner = "${primary_hostname} ESMTP Exim ${version_number} \
\#${compile_number} ${tod_full} \n\
We do not authorize the use of this system to transport unsolicited, \n\
and/or bulk e-mail."
Replace ${version_number} with the version you have patched up to. It is also a good idea to add a second line here stating you have patched up to that version. For example, before "We do not..." add:
\n\ Previous version installed patched for vulernabilities up to the version indicated
If you find yourself in a situation with a ruthless bank or MAP who is refusing to look at your information, and demanding you pay a fine, then keep the above in mind. It will work for a lot of packages, but not necessarily all of them, and some will be easier to change than others.
|
