PCI Requirement 6.6 Is About Remediation

There have been many heated debates in web security circles around the wording of the PCI 1.1 Requirement 6.6 section and it all centers around the semantics of the word "either". The Requirement 6.6 states the following:

"6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:

• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
  
• Installing an application layer firewall in front of web-facing applications.

Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement."

The word either in this context indirectly implies that these two option are functionally equivalent and therefore the user could choose either one and receive the same level of security benefit. Well, as you might guess, this sparked a vast amount of debate from webappsec folks as to the amount of security protection that is gained from a source code review vs. using a web application firewall. To make the waters even murkier, you even had web vulnerability scanner/service vendors asking the PCI counsel if users could run these tools vs. conducting an actual source code review. So now users who were attempting to become compliance with PCI section 6.6 weren't sure what they needed to do or what tool or process was the "best" approach...

I believe that an important issue that is being forgotten when people think of "source code review" is that the actual review is only one portion of the overall process. Most people do not factor in the remediation portion of the process. I could probably be convinced that a manual source code review vs. review with a source code analysis tool vs. running web vuln scanner could yield roughly similar results - they identify what the problems are. What about fixing them?

This is the core issue in 6.6 - to implement some sort of remediation to prevent successful web attacks. Why do I believe this? Well, if you refer to the PCI DSS Security Audit Procedures document it outlines how a PCI auditor will evalute each requirement to confirm whether or not the organization is in compliance. Section 6.6 - Testing Procedures - states the following:

"6.6 For web-based applications, ensure that one of the following methods are in place as follows:

• Verify that custom application code is periodically reviewed by an organization that specializes in application security; that all coding vulnerabilities were corrected; and that the application was re-evaluated after the corrections"

As you can see, the goal of this section is to show that not only were vulnerabilities identified but that they were also fixed. So whether or not the vulnerabilities were identified by source code review or a scanner does not seem to be the main issue from PCI but rather was the vulnerability actually fixed??? It is the process of actually remediating the vulnerabilities that is taking entirely too long for organizations, if it happens at all. I mean, how many times does an Authorized Scanning Vendor (ASV) find the exact same vulns showing up in scan after scan? They are quickly showing the customer what/where the problems are but they just can't fix them for a variety of reasons:

• Regression Testing Time; Any source code changes require extensive regression testing in numerous environments which may delay deployment in production by many weeks or even months.
  
• Fixing Custom Code is Cost Prohibitive; In-house web assessment identifies vulnerabilities in your custom coded web application, however it is too expensive to recode the application.
  
• Legacy Code/Breaking Functionality; Due to support or business requirements, legacy application code can not be patched as prior installs broke functionality. There may even be licensing issues where the vendor will not allow for changes in the code.
  
• Outsourced Code; Outsourced applications that would require a new project to fix.
  
• Certification and Accredidation is a Pain; For government organizations, the C&A process is very time consuming and any changes to the source code would require a new one.

Whatever the reason, current SDLC processes for quickly fixing vulnerabilities found in production are lacking. This brings us to the web application firewall. If you look at the 2nd party of the 6.6 testing procedures, it states this for WAFs –

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

Notice that the WAF has to be in block mode! This again, supports the idea of remediation. So, just because an organization deploys a WAF is not enough to comply with requirement 6.6. You need to be blocking attacks (mainly SQL Injection and XSS as they are the only 2 that are considered HIGH severity). It is for these reasons that I believe that the "intent" of 6.6 is geared towards remediation efforts and not just identification tasks.

Virtual Patching During Incident Response: United Nations Defacement

Virtual Patching is a policy for a web application firewall (in this case ModSecurity) that is able to identify attempts to exploit a specific Website vulnerability. ModSecurity analyzes transactions and intercepts attacks in transit, so malicious traffic never reaches the target Website. The end result is that even if a vulnerability still exists within the application’s source code, the virtual patch will protect against clients attempting to exploit it.

Virtual Patching is an extremely valuable technique that can be used to provide immediate protection against identified vulnerabilities. The trick here, however, is that you first must identify them! You can’t really create a patch if you don’t know what the problem is. There are six main processes that may yield vulnerability information that you can then take action on by virtually patching them:

• Vendor contact (e.g. pre-warning)
• Public disclosure
• Bug report to the development team
• Vulnerability assessment (internal or external)
• Code review
• Security incident

All of these scenarios are somewhat similar in that they all provide vulnerability information in reports of some sort. The only exception is that last one, a Security Incident. This is a unique situation in that there are no ifs, ands or buts involved in the discussions as to whether or not you need to respond to this issue. Any sort of lead time that you may have been counting on for a normal patching process, source code fix or system outage is suddenly thrown out the windows as proper Incident Response steps require you to act immediately. This is where Virtual Patching can prove to be invaluable.

Want a real life example?

In case you missed it, the United Nations (UN) website was recently defaced by a defacement trio known as "KEREM125 M0STED AND GSY." They defaced the site by adding html text to the speeches page. An archived screen shot is located here - notice the text under the "Latest speeches" window. And then here on the specific speech page.

While the details of the specific attack vector can not be 100% confirmed, it is suspected that the attackers used an SQL Injection vulnerability. A software developer named Giorgio Maone chronicled this incident on his Blog site. Maone partly deduced that SQL Injection was the likely attack vector by the missing apostrophe/single-quote in the word "dont" in the defacement text. Single-quotes are normally a key component of creating proper SQL query syntax and it is assumed that attempting to include it in the text would have complicated the SQL Injection attack. Maone also showed that the "statID" parameter for the statments_full.asp page is the most likely candidate for the attack as this URL – "http://www.un.org/apps/news/infocus/sgspeeches/statments_full.asp?statID=105'" – reveals the following DB error message:

ADODB.Recordset.1 error '80004005'
SQLState: 37000
Native Error Code: 8180
SQLState: 37000
Native Error Code: 105
[MERANT][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the character string ''.
[MERANT][ODBC SQL Server Driver][SQL Server]Statement(s) could not be prepared.

/apps/news/infocus/sgspeeches/statments_full.asp, line 26 

UN Incident Response Issues

Once the defacement was identified, the main UN site was taken offline and the following message was presented to clients:

This site will be temporarily unavailable due to scheduled maintenance.

After a number of hours, the site came back online. Unfortunately, vulnerability had not been patched as the same error message could be generated. It seemed that there was some sort of basic filter in place that attempted to filter out the single-quote character, however this is not a sufficient fix as there are SQL Injection queries that do not rely on this character. There is also the possibility of bypassing this filter by using the char() function. A short time later, the entire site was offline and presented clients with this message:

The UN website is undergoing urgent maintenance and is currently unavailable. Please check back in a short while.

When the site did come back online the Speeches section was not available and the same old vulnerability was still present...

What was happening?

We can only speculate at this point as to what was happening behind closed doors in the UN Incident Response team meetings, however they obviously had difficulty with addressing the standard "Eradication Phase" of the issue. When the choice is either being totally offline while waiting for the source code to be fixed vs. putting the site back online and monitoring the logs more closely for issues, the latter will always win out.

How a Virtual Patch could have helped

Looking at the URL again, we can narrow down the issue to the statments_full.asp application and specifically to the statID parameter. Looking at the normal, expected values associated with the statID parameter you can see that the data should only be digits. The following ModSecurity Virtual Patch could have been used to fix this issue by implementing a positive security ruleset:

<Location /apps/news/infocus/sgspeeches/statments_full.asp>
SecRule &ARGS "!@eq 1"
SecRule ARGS_NAMES "!^statid$"
SecRule ARGS:statID "!^\d{1,3}$"
</Location>

This rule uses the normal Apache Location directive as a container for the ModSecurity rules. Inside this location, we are enforcing the following three rules:

• The statments_full.asp page will only accept 1 argument
• The name of the argument must be statID (note that the rule uses all lowercase as there is certain transformation functions being applied to normalize traffic)
• The value of statID can only be 1 to 3 numeric digits

If this rule were in place, the example URL provided above would have been denied with this alert message:

[Wed Jun 13 01:06:37 2007] [error] [client 192.168.15.1] ModSecurity: Access denied with code 403 (phase 2). Match of "rx ^\\\\d{1,3}$" against "ARGS:statID" required. [file "/usr/local/apache/conf/rules/modsecurity_crs_15_customrules.conf"] [line "4"] [hostname "www.un.org"] [uri "/apps/news/infocus/sgspeeches/statments_full.asp?statID=105'"] [unique_id "lCFILsCoD4QAABWcDp4AAAAD"]

This Virtual Patch would have provided instant protection against this issue until the actual source code could have been update or fixed.