New Vulnerability Alert by SecureState Now Available!

SecureState Vulnerability Alert for March 2011

Each month, SecureState will release a Vulnerability Alert, which provides an analysis of the most commonly identified vulnerabilities found during assessments that SecureState performs on more than 350 clients.

This release provides the security community with a description and threat of the most common and dangerous vulnerabilities that are occurring today, in addition to the traditional severity, description, threat, and CVSS base score, if applicable. The CVSS base score is the Common Vulnerability Scoring System, which was designed to provide a standard for rating software vulnerabilities. This scoring system is based on a range of 1-10.

SecureState will highlight one vulnerability each month with an analysis on what the vulnerability means and what can be done to prevent it.

 

There are several reasons to perform a Vulnerability Assessment:

  1. It is a good practice because it is valuable to see how your external presence looks.
  2. There may be regulations that require Vulnerability Assessments on all of your systems.
  3. The Payment Card Industry (PCI) requires quarterly scans on systems that handle credit card information. According to the Payment Card Industry Data Security Standard (PCI DSS), a vulnerability that causes a non-compliant report is any vulnerability that has a CVSS Base score of 4.0 and above. The table of vulnerabilities you see below is a list of the Top 5 Vulnerabilities SecureState saw that causes our clients to fail their PCI scan.

 

 

SSL version 2: Why it is bad, and how can it be prevented.

SSL is a necessity in organizations today, and it is odd that vulnerabilities related to SSL implementation are even found. Let’s take a look at the “SSL Server has SSLv2 Enabled Vulnerability” from the SecureState Vulnerability Alert. This vulnerability commonly appears because there are configurations that have not been set on either a server or network device.

There are a number of flaws inherent with SSLv2. SSLv2 has weak message integrity for export ciphers. Cryptographic keys in SSLv2 are used for both message authentication and encryption. This means if a weak encryption scheme is negotiated, for example 40-bit keys, the message authentication code uses the same weak key, which is unnecessary. There is also a cipher suite rollback attack where the attacker would edit the list of cipher suite preferences to use a weaker form of encryption. SSLv2 does not have any protection for the handshake that occurs, meaning a man-in-the-middle downgrade attack can go undetected. With SSLv2, message integrity can be compromised. The SSLv2 message authentication uses the MD5 hashing function, and is insecure. Finally, a truncation attack can be performed. SSLv2 relies on TCP FIN to close the session, so the attacker can forge a TCP FIN, and the peer will not be able to tell if it was a legitimate end of data or not.

There are also many other SSL vulnerabilities that can cause a non-compliant scan for PCI. For more information on this SSL vulnerability, as well as others, please go http://securestate.blogspot.com/2010/01/happy-ssl-vulnerability-day.html

This, as well as other vulnerabilities, can be prevented by developing Minimum Security Baselines (MSB). MSBs are one thing that can be done to help you get that compliant PCI scan. MSBs are benchmarks developed at the operating system, database, and application level to assure that specific security configurations are implemented according to industry leading practices and risk acceptance criteria that management has defined. Once the MSB has been developed and implemented, it is very important that policies are created to ensure that the MSBs are updated periodically. Knowing these baselines have been developed, implemented, and updated correctly, you can ensure that vulnerabilities such as SSLv2 enabled would not appear on a PCI scan.

 

Leave a Comment...

Your email address will not be published. Required fields are marked *


*