Category Archives: penetration testing

Cheat Sheet: Virtual Web Application Patching

cloud, pci dss, penetration testing, security, ,

IMG_0794-smallDo you operate public-facing web applications in your card data environment? Here’s a pointer to a great source of information from the Open Web Application Security Project (OWASP) on the subject of virtual patching.

What is virtual patching? Within the context of web vulnerabilities, this refers to the practice of applying a defensive layer to intercept potentially malicious traffic destined for your web applications. Of course, the very best defence against these attacks is to write secure code to begin with, however there are a number of circumstances in which this isn’t achievable.

For example, where you’re running a 3rd party web application, or if you simply don’t have the resources available to make the code changes.

Highly recommended reading for all developers and development managers.

Read it here.

PCI DSS Cloud Computing Guidelines

cloud, pci dss, penetration testing, ,

A new guidance document from the PCI SSC provides useful information about the use of Cloud Service Providers (CSPs) and how this may affect PCI compliance.

Although cloud computing feels like a new thing, the issues about responsibility for cardholder data are certainly not new. Related issues, such as nebulous (pun intended) statements about PCI compliance from a CSP need to be qualified, and mutual responsibilities clearly established.

Actually, this new document echoes some guidance that we’ve been publishing for a while now. Have a look at PCI Compliance Claims: 3 Questions You Must Ask for example. More recently, we published a 10 minute video entitled Penetration Testing & The Cloud, which is an ideal management introduction to the subject, even if PCI DSS isn’t on your radar.

The SSC document is available here.

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/

PCI DSS Vulnerability & Penetration Testing

penetration testing, , ,

As a standard that pays a lot of attention to practical activities, the PCI DSS mandates a range of testing activities. We frequently see confusion about what needs to be tested, how and when. At the end of this post is a link to our short guide to all PCI DSS testing requirements.

Some key messages for you:

  • Each testing requirement is distinct (i.e. conducting one type of test does not necessarily satisfy another test requirement)
  • Watch out for the scope – most tests must be conducted internally and externally
  • Tests must be carried out according to the frequency specified in the DSS, and after significant change to the card data environment
  • Quarterly ASV scans must be carried out by an ASV company
  • Expect your QSA to require evidence that each applicable test has been conducted, plus evidence that significant findings have been addressed

Yes, there’s a lot of testing – but bear in mind that these tests provide you with vital assurance that your PCI controls are functioning correctly and that your organisation is not exposed to high risk vulnerabilities. If there’s something wrong, you need to know sooner rather than later.

Download our free guide covering the PCI DSS Security Testing Requirements