Introduction
Recently one of my clients requested, after a critical attack on the server where an application was running, to make sure that the application is secured in all perspectives. We chose McAfee to ensure that the website is 100% hacker proof. After a thorough Application Scan, Network Scan, and PCI Scan, McAfee found out several vulnerabilities in the Website, and I thought some of them exist in most of the websites we make. So here is a brief list and solutions we have found out to make a website 100% McAfee Secured and PCI Compliant.
Before we delve into the technical details, I want to clarify what this article covers and what it does not, better not to create any false expectations. This article is solely based on my experience while solving the vulnerabilities, and I have presented them likewise. As several of the fixes require tweaks in registry, make sure to back the registry up, and change anything at your own risk.
Following are the most important vulnerabilities that were reported by McAfee:
Vulnerability 1
Vulnerability Name: Microsoft .NET Custom Errors Not Set
Description
This is when the custom error page is not set for an application. We generally use the web.config to specify the Error Page. But McAfee requires it to be done both ways.
Solution
In order to fix this vulnerability the error pages must be set from the IIS. The steps are as follows:
- Go to IIS Manager
- Right click on the project name that has to be McAfee Secured
- Click Properties
- In the Properties Box, click on the “Custom Errors” tab and the following window appears:
- Highlight any one of the error types and click on edit properties and a small window appears where the custom error page can be specified.
- Click on OK button in both this and its parent window.
- If even one error page is specified for any one error, McAfee considers this a vulnerability no more.
Vulnerability 2
Vulnerability Name: Allow All Policy in crossdomain.xml
Description
If a website uses several flash videos and content and other websites use them in their websites, the crossdomain.xml comes into play. This XML file sets the policy about who can use the content in their websites in terms of domain name. It has a key called –
<allow-access-from domain="*"/>
According to McAfee, this poses a serious threat of hack attack to the website.
Solution
It is very confusing how McAfee scans the file, because even if the file is removed from the root (wwwroot), and a copy of the file still exists in any place of the whole server, McAfee still finds that and gives an alert. The best solution is to Edit each and every occurrence of that file in the whole server and remove all stars (*) and give specific domain names from which the videos will be accessed. If not required, it is best to completely delete the file.
So the edited file will look like:
<allow-access-from domain="*.yahoo.com"/>
(* denotes anything that prepends the domain name e.g. messenger.yahoo.com in also all protocols: HTTP or HTTPS)
Vulnerability 3
Vulnerability Name: Using SSL v2 in Secure Communications
Description
The remote service appears to encrypt traffic using SSL protocol version 2.
Netscape Communications Corporation introduced SSL 2.0 with the launch of Netscape Navigator 1.0 in 1994 and it contains several well-known weaknesses. For example, SSLv2 doesn't provide any protection against man-in-the-middle attacks during the handshake, and uses the same cryptographic keys for message authentication and for encryption.
In Internet Explorer 7, the default HTTPS protocol settings are changed to disable the weaker SSLv2 protocol and to enable the stronger TLSv1 protocol. By default, Internet Explorer 7 users will only negotiate HTTPS connections using SSLv3 or TLSv1. Mozilla Firefox is expected to drop support for SSLv2 in its upcoming versions.
As almost all modern browsers support SSLv3, disabling support for the weaker SSL method should have minimal impact. The following browsers support SSLv3:
- Internet Explorer 5.5 or higher (PC)
- Internet Explorer 5.0 or higher (Mac)
- Netscape 2.0 (Domestic) or higher (PC/Mac)
- Firefox 0.8 or higher (PC/Mac/Linux)
- Mozilla 1.7 or higher (PC/Mac/Linux)
- Camino 0.8 or higher (Mac)
- Safari 1.0 or higher (Mac)
- Opera 1.7 or higher (PC/Mac)
- Omniweb 3.0 or higher (Mac)
- Konqueror 2.0 or higher (Linux)
According to https://www.pcisecuritystandards.org/pdfs/pcissc_assessors_nl_2008-11.pdf, an Assessor's update report, "...it is imperative that an ASV identify the use of SSL 2.0 to transmit cardholder data as a failure."
Solution
SSL related protocols can run on other service ports as well. Typical ports include: 465, 993, 995, 2078, 2083, 2087, 2096, 8443, etc. Each application will have its own configuration options to handle SSL protocols.
To solve this problem, one needs to open Registry Editor.
Vulnerability 4
Vulnerability Name: Weak Supported SSL Ciphers Suites
Description
The remote host supports the use of SSL ciphers that offer either weak encryption or no encryption at all. This vulnerability is valid for all SSL/TLS sessions that are passing sensitive information.
PCI defines strong cryptography, for secret key based systems, as anything above 80 bit encryption.
Solution
The solution to this is very simple but requires registry tweak again. Following are the steps:
Now the server is secured.
The above mentioned security issues are the major ones that most of the systems have. However other than this, there may be some easy and minor vulnerabilities like:
- Using robots.txt in the pages. (Generally inserted by Web Marketing team to track user hit).
- Directory Scanner: Common directories are revealed. This can be resolved by URL rewriting and setting “Directory Browsing” off.
Note: For the above vulnerabilities, minor registry tweaks will be necessary. So it is strongly recommended to back up the registry before doing anything. By any chance if something gets messed up, just delete the SCHANNEL key and restart the machine, the key will be auto-generated.
History
- 4th March, 2009: Initial post
