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:
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 -
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.
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:
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.
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:
Click on the .reg file to enter it into the registry.
Review that the entries have been entered in the registry as follows.
Figure 4: Reviewing the weak cipher registry entries.
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
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
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
Carsten Siemens edited Revision 29. Comment: fixed typo