Archive for the PCI Category

Holes in Your Security Christmas Stockings

Posted in PCI, Penetration Testing, Vulnerability Assessment with tags , , , , , , , , , , on December 31, 2008 by Tim

Over the Holiday season, I tended to my family’s computers for their annual check-up. As usual, I initially checked which Microsoft security updates were not installed. While their computers are configured to download and install Microsoft security updates automatically, several updates usually require manual interaction to install. After the Microsoft security updates were installed, I began the daunting task of installing the non-Microsoft application security updates and upgrades that have accumulated over the course of the year.

Similarly, most organizations have setup Windows Server Update Services (WSUS) or Systems Management Server (SMS) to apply Microsoft security updates. However, most organizations still have not implemented an enterprise-wide solution for applying security patches to non-Microsoft applications. Applications such as Adobe’s Acrobat and Flash or Sun’s Java Runtime Environment are often installed as part of a base laptop image or installed by employees at a later time. While their providers often release security updates, these applications remain at the current patch level as when they were installed. As a result, organizations remain extremely vulnerable from these non-Microsoft applications. For example, on December 5, 2008, US-CERT released an advisory (US-CERT Advisory TA08-340A) concerning security vulnerabilities that could allow an attacker to obtain complete control of systems running vulnerable versions of Sun’s Java Runtime Environment.

I am not recommending organizations abandon non-Microsoft products and would encourage organizations to evaluate the alternatives. The current problem is that non-Microsoft applications are often over-looked and the emphasis in patch management is on Microsoft products.
Several enterprise solutions exist to apply patches to non-Microsoft applications. Similar to Microsoft’s WSUS and SMS, these products are not perfect and have their own flaws. In order to implement an effective solution, the following best-practices practices should be followed:

• Identify the applications that have valid business requirements

• Restrict users from installing other applications

• Implement an enterprise-wide solution that controls applying security patches to non-Microsoft applications

As Microsoft attempts to create more secure products, hackers are crafting malware to specifically exploit non-Microsoft products. For example, a Trojan masquerading as a plugin for Mozilla’s Firefox web browser was recently identified ( – Firefox Trojan). The non-Microsoft application security patches have been overlooked for many years and should become a major initiative of organizations.


The New PCI 6.6

Posted in Application Security, PCI with tags , , , , on November 20, 2008 by Matthew Flick

All Your Public facing Web Apps Are Relevant To Us

I’m going to start off this post with the moral of the story: Good intentions often have bad, unintended consequences. The following is the ‘Testing Procedures’ text of requirement 6.6 from the new PCI DSS v1.2 (source:

For public-facing web applications, ensure that either one of the following methods are in place as follows:

• Verify that public-facing web applications are reviewed (using either manual or automated vulnerability security assessment tools or methods), as follows:

– At least annually
After any changes
By an organization that specializes in application security
That all vulnerabilities are corrected
That the application is re-evaluated after the corrections

Verify that a web-application firewall is in place in front of public-facing web applications to detect and prevent web-based attacks.

    Note that for ease of reading I’m going to shorten “PCI DSS v1.2 Requirement 6.6” to just “PCI 6.6” since nearly everyone already refers to it as such.

    Without further clarification, this requirement now compels an organization that stores, processes, or transmits cardholder data (“CHD”) to apply PCI 6.6 to all of their “web applications” that are publicly accessible, regardless of whether the applications participate in the storage, processing, or transmission of CHD. We must assume also that this requirement will be applicable regardless of other security controls as well, such as network segmentation. Disregarding all other changes to the PCI DSS, this one requirement could significantly increase the level of effort and cost of PCI assessments.

    Before I get into advice for dealing with the new requirement, let’s examine the two options in relation to the change. First option is to have an application security organization perform security testing on the applications, correct identified vulnerabilities, re-test and repeat if necessary. Furthermore, such testing must occur “at least annually”, which should not be a huge problem…and “after any changes”, which could very easily force an organization to simply stop making any changes to its web applications. Unintended consequences.

    The second option seems rather simple, straightforward, and innocuous unless you have actual experience with web application firewalls (“WAFs”). At a high level, WAFs have two basic modes of defense: 1. Blacklisting attack strings, typically pushed down by the vendor like anti-virus signature updates, and 2. Custom rule checking, which requires training the WAF to understand more of the application it is protecting. Both modes can often lead to false positives; the second and more effective mode requires a lot of human interaction throughout the system’s lifecycle. Add to the mix the large price tag for commercial WAFs and the new requirement that requires protection for all public facing web applications, and what you likely end up with is an organization implementing an easily defeated blacklist of your standard attack strings (XSS, SQL injection, etc). Unintended consequences

    I do not want to be accused of PCI hate speech. In fact, I would like to sincerely applaud their efforts in helping to drive application security education and strongly encouraging organizations to address the problems. My concern, though, is that the more stringent the requirements become, the more likely organizations will continue (or begin) to do only the bare minimum in order to “check the box” instead of fixing the root cause of the problem. This is similar to the problem of progressively raising taxes: the higher the tax rate climbs, the more people will invest to identify loopholes, legal or otherwise. Or, in Star Wars terms, “The more you tighten your grip, Tarkin, the more star systems will slip through your fingers.” –Princess Leia

    With this information in mind, we now come to the issue of how to approach PCI 6.6. I’m going to suggest the most pragmatic approach that should work for most or all organizations, or at least those organizations that must endure PCI DSS assessments. In step-by-step format, naturally:

    1. Classify applications – Separate all public facing web applications into a grid by user type (e.g. internal users only, external users only, mixed) and data sensitivity (e.g. CHD, public, internal/corporate, internal/sensitive).
    2. Shorten list – If possible, move all web applications with internal users only to the internal network and provide external access via VPN. This should be an obvious move and something that should have been done well before PCI 6.6, but you might be surprised how often I see this situation.
    3. Create assessment plan – First determine the budget for performing automated runtime vulnerability scans (the “cheap” option) against all remaining public facing web applications. Then the remaining budget—if any—can be reserved to add more effective assessment tasks to the most relevant applications, obviously starting with those that store, process, or transmit CHD.

    As a general rule, I suggest using the results of a vulnerability scan/assessment against one application to identify and remediate potential weaknesses in other applications that either use the same codebase or were developed in similar fashion. This approach should lessen the number of findings in subsequent tests.

    If all the advice in this post seemed familiar or common sense, then congratulations…you’ve been paying attention! The security industry has been evangelizing a risk-based approach for a long time now. Or at least some of us in the industry have been.

    Remediating Common PCI SSL Vulnerabilities with a Simple Windows Registry File

    Posted in PCI, Uncategorized with tags , , , , , on November 12, 2008 by Tim

    Recently I was working with a client who was struggling to remediate two vulnerabilities identified by their quarterly perimeter PCI scans. Specifically, they needed to remediate the following vulnerabilities:

    • SSLv2 Enabled
    • Weak SSL Encryption Ciphers Enabled

    With these vulnerabilities being so common amongst those bound to the PCI DSS, I would have hoped that better remediation information existed beyond Microsoft’s overcomplicated Knowledgebase Article,

    In response to this lack of quality remediation information, I created the following Windows Registry file that aims to simplify the remediation of both vulnerabilities. This file has been tested on IIS 6.0 (Windows 2003) and disables the following weak ciphers, hashing functions, and protocols associated with SSL:

    • Weak Ciphers – DES 56, NULL, RC2 40/128, and RC4 40/56/128
    • Weak Hash Functions – MD5
    • Weak Protocols – PCT 1.0, and SSL 2.0

    You can download the registry file from our website, here.

    The standard “Backup your registry first” and “Test on non-production systems first” rules apply. Happy remediating! (and more importantly…SECURING!!!)