Adjustments for PCI-DSS Scan
Adjustments Needed for a Small Business Server to Pass a PCI-DSS Scan
The Payment Card Industry requires certain standards to be in place in order to process credit cards. This article has not been prepared to advise you on the security of your Small Business Server, rather merely to advise you what is needed if your vendor should require you or your client to have their Small Business Server scanned by an external PCI scan. This document should not be seen as evidence that a Small Business Server is PCI compliant.
I would strongly recommend that small businesses not store credit cards on any personal computer or server on their local network. It is wiser to outsource the credit card processing to a secure processor than to attempt to store the credit card numbers on the server. You will need to review the PCI guidance at http://www.pcisecuritystandards.org/ and obtain the appropriate advice and counsel from your bank, IT provider or other consultant. This document is merely guidance for those items typically cited by Small Business Server owners when an external PCI scan is performed. It may not include all of the issues your PCI scan vendor lists. You should contact your PCI scan vendor for recommendations for remedial action as needed.
General recommendations for Microsoft products can be found in this white paper: http://www.microsoft.com/downloads/details.aspx?FamilyID=D8320DF1-D0D0-469F-A6FC-B53987BD74C2&displaylang=en.
1. Outlook Web Access on SBS 2003:
Typically the scan results will refer to a URL that is no longer valid - http://exploitlabs.com/files/advisories/EXPL-A-2005-001-owa.txt and then detail the following vulnerability:
Synopsis : The remote web server is affected by a URL injection vulnerability. Description : The remote host is running Microsoft Outlook Web Access 2003. Due to a lack of sanitization of the user input, the remote version of this software is vulnerable to URL injection that can be exploited to redirect a user to a different, unauthorized web server after authenticating to OWA. This unauthorized site could be used to capture sensitive information by appearing to be part of the web application.
Searching on the web you can find old references to it as well a link to a page that actually details out an adjustment that can be made to the server so that it can pass the PCI scan process - http://archives.neohapsis.com/archives/fulldisclosure/2005-07/0504.html
The specific resolution for the OWA on SBS 2003 vulnerability is courtesy of Darryl J. Roberts (1)
You can test for this vulnerability (from the information exploitlabs.com) by taking your OWA login and appending it by url=https://website.
https://owa.domain.com/exchweb/bin/auth/owalogon.asp?url=https://google.com
Where owa.domain.com is your Outlook Web Access URL. Before the fix, log on to OWA and you will be redirected to Google.com. After the fix, log on to OWA and the URL parameter will be ignored.
The fix for this is as follows:
Find the logon.asp file on the server and hardcode the url for OWA so that it won't respond to user input. The file in question is located at C:\Program Files\Exchsrvr\exchweb\bin\auth\language>\logon.asp (or wherever your Exchange has been installed) which uses user inputs without verification. There are two lines in code that should be edited:
*redirectPath = Request.QueryString("url")
redirectPath = Server.HTMLEncode(redirectPath)*
If you set "url" string statically in this code, then user inputs are ignored for "url" parameter. Or simply comment out these two lines; it redirects you default server page without looking user input "url".
Figure1: Find the logon.asp underneath the auth languange folder.
Figure 2: The "url" string to edit or rem out
You can merely type in a ' to rem out the two lines as shown in the Figure below:
Figure 3: Remarking out the lines in the logon.asp file
You may wish to rename and keep a copy of the original login.asp page in case you need it.
The remainder of the issues will impact both SBS 2003 and SBS 2008:
2. Port 3389 - The remote version of the Remote Desktop Protocol Server (Terminal Service) is vulnerable to a man in the middle (MiTM) attack.
When you leave Remote Desktop (port 3389) open for external access a PCI scan will identify it as vulnerable to a man in the middle attack. Even updating the RDP to version 7 will not make the server pass the scan. Thus I'd recommend that you chose one of two options:
a. Limit port 3389 to be access by your static IP only. Limiting access of the port to your IP will ensure that the server passes an external scan as it will not be open to wide access.
b. Leave port 3389 closed on your firewall and only access the server via VPN. This will keep the server closed to external scans as well. You do not need port 3389 open to be able to provide Remote Web Workplace.
3. Port 443 - The remote service supports the use of medium strength SSL ciphers and the remote service supports the use of weak SSL ciphers.
The guidance for items 3, 4 and 5 is contained in http://support.microsoft.com/default.aspx?scid=kb;en-us;245030 but various sites refer to the fixes as well. One of the better blog sites to recap the registry entries needed is http://blog.zenone.org/2009/03/pci-compliance-disable-sslv2-and-weak.html. To block the use of medium strength SSL ciphers and weak ciphers copy the following section to notepad and save it as a .reg file or download the reg file from here: http://msmvps.com/media/p/1764367.aspx
Click on the .reg file to enter it into the registry.
*** --Copy from here---***
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128]
"Enabled"=dword:00000000
--Copy to here---
Review that the entries have been entered in the registry as follows.
Figure 4: Reviewing the weak cipher registry entries.
4. Port 443 - The remote service encrypts traffic using a protocol with known weaknesses. The remote service accepts connections encrypted using SSL 2.0.
To adjust the server to ensure that it does not accept SSL connections with 2.0 or lower copy the following section to notepad and save it as a .reg file or download it from here: http://msmvps.com/media/p/1764366.aspx.. Click on the .reg file to enter it into the registry. More information on these settings can be found at http://support.microsoft.com/kb/187498.
---Copy from here---
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000
---Copy to here---
And confirm that the entries have been entered in the registry as follows and reboot the server.
Figure 5: Reviewing SSL v2 registry entries.
These adjustments should make your server now pass a PCI external scan.
(1) Thanks to Darryl J. Roberts, MCSE, MCP+I, CompTIA CTT+, IT Professional Service www.itprofessionalservices.net* for the guidance as posted to* www.patchmanagement.org*
*
5. Server flagged as failing IIS BEAST vulnerability
Solution courtesy of Bob Groger
Client used Trustwave for their PCI DSS scans and they kept failing for BEAST vulnerability. I did all the registry edits, rearranged cipher orders, rescanned for hours. It either failed, or RWW didn't work. Finally I found the tool at
https://www.nartac.com/Products/IISCrypto/Default.aspx and followed the instructions at http://www.amixa.com/blog/2012/12/22/how-to-get-iis-7-5-web-server-to-pass-the-beast-pci-vulnerability-compliance-scans/