Category Archives: ASV

Approved Scanning Vendor

ASV Scan Interference

Just a reminder of a regular observation we make when conducting ASV scans. It’s the issue of interference from an IDS or IPS system. Whilst such systems are useful in normal production situations, they must not interfere in any way with the ASV scan. If interference is detected by the ASV scan – we have no choice but to issue a failing scan report.

This mandatory requirement is documented in the ASV Program Guide v1.0 on page 14 in the section entitled “Perform a Scan without Interference from IDS/IPS” as follows:

In order to ensure that reliable scans can be conducted, the ASV scan solution must be allowed to perform scanning without interference from intrusion detection systems (IDSs) or intrusion prevention systems (IPSs). Such active protection systems may react differently to an automated scanning solution than they would react to a targeted hacker attack, which could cause inaccuracies in the scan report.

This is part of the defense-in-depth approach of PCI DSS. If the scan cannot detect vulnerabilities on Internet-facing systems because the scan is blocked by an IDS/IPS, those vulnerabilities will remain uncorrected and may be exploited if the IDS/IPS changes or fails. If an ASV detects that an IDS/IPS has blocked or filtered a scan, then the ASV is required to fail the scan as inconclusive. All ASV scans must be validated by the ASV to ensure they have not been blocked or filtered by an IDS/IPS.

The upshot is that if you have an IDS/IPS system in place, you are required to grant full access for the ASV scanner.

The full ASV program guide is available here.

Taming The BEAST

ASV, penetration testing, risk, security

This is a follow-up post to our previous article on the subject.

Here we offer technical assistance to those of you trying to fix the BEAST vulnerability, and offer some mitigation practices.

The problem revolves around a vulnerability identified years ago in TLSv1 and SSLv3 protocol CBC mode ciphers (the stronger ciphers). This issue was fixed in TLSv1.1 (2006) and TLSv1.2, however, adoption of these versions has been slow due to lack of any real incentive. Up until now the attack was considered unfeasible, but recent developments have made it viable and it is now a real threat. Please see the whitepaper at http://blog.tempest.com.br/static/attachments/marco-carnut/driblando-ataque-beast-com-pasme-rc4/ssl_jun21.pdf for a deatiled technical analysis of the issue.

The following articles are very useful in understanding and taming the BEAST:

https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls
http://blog.zoller.lu/2011/09/beast-summary-tls-cbc-countermeasures.html
http://vnhacker.blogspot.co.uk/2011/09/beast.html
https://blog.torproject.org/blog/tor-and-beast-ssl-attack
https://blogs.akamai.com/2012/05/what-you-need-to-know-about-beast.html

The current simplest way to mitigate the risk associated with this vulnerability in a secure manner and maintain compatibility between servers and clients is to prioritise TLSv1.1/TLSv1.2 CBC mode ciphers and then TLSv1.0/SSLv3 RC4 ciphers over the deprecated TLSv1.0/SSLv3 CBC mode ciphers. This should catch the majority of sessions before the minority of clients fall back to the vulnerable ciphers, thereby decreasing the likelihood of a successful attack.

The following remediation notes and references may be of use:

Apache
(taken from https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls)

SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

Windows (not including 2003 or XP)
Prioritising Schannel cipher suites is possible, please see:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx

Windows (Older Flavours)
See the following to control which ciphers are supported:
http://support.microsoft.com/kb/245030

Windows (Recent Versions)
A patch is available:
http://technet.microsoft.com/en-us/security/bulletin/ms12-006
However, problems have arisen from this so the prioritising method may be preferred. See:
http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspx

OpenSSL
OpenSSL has addressed the issue, however, as the feature was found to cause problems with some SSL implementations it is disabled by default. It is also known that Tomcat, Apache mod_ssl and Exim disable the feature by default. The fix is also claimed not to work by some. (https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls). Again, prioritising ciphers therefore seems to be the only workable route.

Other Systems
Please check for vendor specific patches. Failing that, and if the prioritisation of ciphers is not an existing function, then disabling unwanted ciphers may be the only option in the short term. For a complete list of ciphers and other details, please see: http://www.openssl.org/docs/apps/ciphers.html

Utilities
For an effective way of determining supported SSL ciphers, see the following:

The online Qualys SSL test application:
https://www.ssllabs.com/ssltest

sslscan, a useful tool, can be downloaded from:
http://sourceforge.net/projects/sslscan/

ASV Reports: The BEAST Inside

ASV, pci dss, security,

Many of our ASV customers are seeing scan reports making reference to a “BEAST” attack susceptibility. But what is it, and more importantly, how can you fix it?

The bad news is that our ASV scan report is informing you that the strong encryption on your “secure” web server could be rendered useless and your customers accounts could therefore be compromised. That should be enough to give any of you sleepless nights, but the good news is that a configuration change is probably all that is needed to mitigate this particular attack.

I’ll post a more technical follow-up which includes technical fix information. In the meantime, here’s the background story for those of you who are interested.

About a year ago, two researchers discovered weaknesses in the encryption used on the majority of web sites. Further to their research, they released a tool that claimed to be capable of forcibly decrypting the confidential communication between a user and a web site. As an example, they showed how the tool could be used to break into a connection with PayPal, exposing information that was previously thought to be securely transmitted. As you can imagine, it caused a bit of a stir in the information security community.

The researchers were Thai Duong and Juliano Rizzo, and their tool was “Browser Exploit Against SSL/TLS” – BEAST for short.

Using the BEAST tool to actually break in to secure connections is somewhat tricky, and requires a number of supporting factors to be in play (the web server needs to be configured in a certain way, the attacker needs to be able to access the network traffic emanating from the user, and the vulnerable user needs to be tricked into loading the BEAST tool via a web link of some kind)

However, these factors are in no way insurmountable if the attacker is sufficiently motivated and equipped. Given the fact that there are still many web sites that are configured in a way that would enable a BEAST attack on the user, we should assume that BEAST remains at least potentially viable for the foreseeable future.

Reference: http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/

ASV Scanning: Roles & Responsibilities

ASV, security

Since we moved to the new ASV Program Guide v1.0 procedure last year, we’ve answered numerous questions from customers about the new reports and associated procedures as mandated by the Program Guide. For the most part, “Why are you doing this?” is the most commonly asked question!

Rather than insisting that you read the entire ASV Program Guide from cover to cover (which of course you can, if you want to), we’ve extracted one relevant part of the Guide for you. Specifically, part that details the roles and responsibilities that apply to all ASV companies and their scan customers.

http://www.ambersail.com/articles/ASV_roles.php