My colleagues and I must deal with what appears to be “shifting sand” every time we prepare to run the quarterly PCI vulnerability scans for our clients.
I have not reported a PCI FAIL for quite some time. Last month a scan was run as scheduled on 3 March 2012 to determine how much more effort was needed (if any) to ensure compliance. At the time the reports for our clients did not show a vulnerability for ASP.NET. Having completed all of the scheduled work by the revised deadline of 3 April 2012, the reports were run again and this time I found that 2 clients failed PCI compliance with a number of servers showing an ASP.NET vulnerability:
90780 - Microsoft ASP.NETValidateRequest Filters Bypass Cross-Site Scripting VulnerabilityCVE-2008-3842,CVE-2008-3843
No fix is available at this time; please consider implementingmitigating controls (firewalls, traffic filtering, etc.) to address theseissues. For
specific information on how to remediate these issues pleaseconsult the technical report below.
As I was due to report to the acquiring bank by 11 April 2012 and as the Easter break (peak trading for those clients) fell just 2 days after the scans, there was little opportunity to investigate the problems other than to try to determine what had changed in the infrastructure in both companies to cause this problem to occur. The answer to that was ultimately nothing but with the amount of change that had been taking place in the last 3 months this took a good deal of effort to satisfy me that the changes that we had implemented had not caused the problem to arise.
Further investigation of the alerts that I receive via subscription from Qualys (the ASV for both clients) identified a change in the status of the ASP.NET vulnerability that was announced in the weekly bulletin received on 19 March 2012. The bulletin is presented in list form and a quick glance at that list could result in something being missed (as on this occasion). The attachment is not much better as it needs to be reformatted in order to view all of the information before a search can begin.
This vulnerability has been in existence since 2008. Why has it suddenly been upgraded ? Without warning ? Why did it not appear simply as awarning on previous reports ? What impact has this had on other retailers? Are my clients alone in reporting this issue ?
As you can imagine there is a great deal of frustration at the moment about this failure especially as it was outside of our control, was not immediately obvious, and will probably result in a great deal of time and effort to investigate, possibly mitigate and may have a potential impact upon the operating companies’ plans for PCI Audit.
I have written to Jeremy King at the PCI SSC and to the acquiring banks to ask about this vulnerability and the process for notification to ASVs to see if there is a better way of delivering the information to all retailers without the need for the retailer having to subscribe to a mailing list to receive the notification, search through lists of vulnerabilities, decide if the listed vulnerabilities are applicable to its environment and determine what action has to be taken to prevent a PCI failure if at all possible. We already subscribe to the Qualys mailing list and have implemented a process forscanning the “PCI” devices on a monthly basis for our clients and still I find myself in the position of having to report a PCI failure. I have not yet received a reply to my email to Jeremy.
I will appreciate any advice and help that anyone can give to try to improve the situation and to make it easier for retailers to identify and mitigate potential problems whilst striving to achieve and maintain compliance and to prevent a repeat occurence.
We completely understand your comments and the difficulty this issue has caused you. We also completely sympathize with the timing aspect of this issue, as related to PCI compliance.
This QID was added on 3/14 in response to an urgent request from a large Acquiring Bank. Although we do understand the difficulty from a timing perspective, in this case the potential for real world risk required that this item be included immediately.
This QID is reported when we detect the vulnerable framework (v1, v2 or v3) in the Results Section of the Scan Data. Upgrading to a non-vulnerble framework would be the typical solution, howerver we understand that may be a very difficult solution path.
As an ASV, when customers request an item as a False Positive Request, we assess the true risk of the issue, and so if we can validate that the Vulnerability is not Exploitable, we can issue a Pass for this item for PCI Compliance. If a Merchant can provide proof that XSS is not Exploitable on a target, then the issue can essentially be approved as a False Positive for PCI. Examples of possible proof could include a Web Application Scan, Penetration Test, Code Review, Audit, etc...
Additionaly, in regards to the timing aspect, you could also reach out to your Acquirer when submiting your Quarterly PCI Report and let them know that this item was just recently reported, and that you are working on investigating and remediating, howerver need more time. Acquirers do commonly accept exception requests such as these, and would thereby accept the report, and look to see that the issue is resolved by your next Quarterly Report.
Lastly, we are currently working on a comprehensive solution to help ensure that timing issues like this are better managed in the future, from a Notification, Timing and Reporting aspect. We are in the final stages of finalizing this solution and should have it rolled out to Production in the very near future.
If you have any further questions, or would like to discuss any of the above items in greater detail, please feel free to contact Qualys Support and ask for one of our PCI Subject Matter Experts, as we would be happy to discuss and assist howerver possible. We could also discuss some Compliance Workflow optimizations which many of our customers have found vey helpful, in regards to more easily managing their Quarterly Compliance Deadlines.
Thank you for your feedback.
Which acquiring bank provided you with the request ? I am in discussion with my client's acquiring bank who has taken this up with the PCI SSC and it would be useful for them to have this detail.
Why do you take direction from acquiring banks and not the PCI SSC ? I would have expected this type of upgrade to have been discussed and approved by the PCI SSC. What role do they play in the categorisation of vulnerabilities ? Can you provide details of the process and your plans for the "comprehensive solution" that you mention please ?
I too failed PCI due to the above reclassification. I am curious though as my webservers are behind a load balancer, but I am only failing on 1 site. Why is only 1 site failing, better yet why are the other sites passing. Any ideas would be greatly appreciated.
Thanks in advance,
It sounds like a networking or configuration issue may be resonsible for similar systems reporting different results. You might want to submit this request to email@example.com along with the scan results so that we can investigate further.
Also, if you have a QualysGuard Internal Scanner Appliance, you can try scanning all the systems from the Internal perspective, thereby bypassing your Load Balancer. This should help give you a more accurate understanding if all of the systems are vulnerable or not, and also help to determine if it is a Networking Issue with the Load Balancer, or a Configuration Issue on the Servers.
In this case the Large Acquiring Institution was also a Customer, and so per our standard process we will review and potentially add additional vulnerabilities to QualysGuard per Customer request. We are not able to release the name of the Customer.
We take vulnerability feeds from Industry Souces, Internal Research, Customer/Partner Feedback, etc... The PCI Council provides rules and guidelines around PCI Scoring, but does not directly review vulnerabilities or approve vulnerabilities.
The comprehensive solution will be focused on an improved process for releasing these types of issues in the future, so that hopefully customers will be better prepared/notified/informed when new items like this are included as part of PCI. We should have a release statement for this in the very near future which will outline this solution.
Does this mean that Qualys is the only ASV that will generate a PCI FAIL for this vulnerability on a scheduled PCI scan ? If not how do you communicate this change of status with other ASVs ?
As this is a PCI Failing Vulnerability, all ASV's that detect and report this should be marking it as a PCI Fail, per the PCI Councils Scoring Guidelines.
As for communication to ASV's, do you work for an ASV? If so could you contact me directly at firstname.lastname@example.org so that we can discuss this in greater detail?
1. I can't find any documentation that shows that any versions beyond 1.1 and 2.0 are vulnerable to this bypass. ValidateRequest persists into versions 3-4 in .NET, but there is nothing showing that they are in fact, vulnerable. Is there any documents supporting this?
2. Since this vulnerability doesn't actually check to see if ValidateRequest is in use at all, just the versions of.NET framework running on the server, would it be possible to move this into the "Potential" category? Logically, this makes more sense.
Ok, add me to the list of failures.... And to top it all off, there is NO resolution that works, I have (2) servers that are on my DMZ that just started failing, so I'm waiting for Qualys support to give me some direction I've unstalled all versions of .net and installed 4.0, stil fails....
Come on Qualys, I've alsways told other admins and customers that your process is great; been using qualys for (5) years now, don't make me regret it...
It is my understanding that a full clean install of v.4 should no longer report "X-AspNet-Version: 2.0.50727" in your Results. If this is still being reported it may be that the versions weren't properly updated during the upgrade/install? Feel free to call into our support line 1-866-801-6161 for further assistance. You can ask to speak to me directly and I will be glad to help you resolve this situation asap.
Also, a quick and easy way to address this from a Compliance Standpoint would be to provide 'proof' that the target host is not vulnerable/exploitable. A completed Web App Scan, or Pen Test, or Code Review, or Audit, etc... could provide this proof, and allow us to approve this as a False Positive Exception.
I hope that helps, and please do call in if you would like to discuss further, as we are dedicated to helping our customers as much as possible. Many of us here at Qualys, including myself, are former customers as well, so we completely understand the difficulty associated with new PCI Failing Vulnerabilities, especially ones like this that are fairly difficult to remediate.
I have a seen Q90780 report on a server with a full and clean install of 4.0. I suspect the issue is reporting because even though 4.0 is installed, there is software running on the asset that has been compiled and is running on an earlier version.
Even with the install of 4.0, the previous version remain present on the server to support legacy applications.
The qualys scanner is picking up on the ASP.NET version the http runtime web header. In speaking with several web application security professionals, the overall opinion I am hearing is that if an organization has a good web application, pentest and internal vulnerability management program in place, the best bet is to update the web.config to supress disclosure to the ASP.NET version. Basically, best practice is not to disclose version/release information in your web headers. Ultimately, it is up to your organization to evalulate the risk posed by its http runtime header code management standard/policy.
Add this line to the web.config = clean scan
<httpRuntime enableVersionHeader="false"/> </system.web>
You are correct that the vendor documentation currently shows version 1.1 & 2.0 as vulnerable. Qualys has performed additional investigation, including exploiting this issue in our own Lab, to verify that a fully patch v.3 is also vulnerable (the vulnerable component of v.2 is also used by default in v.3). We have confirmed that v.4 does not use the vulnerable component, and is not exploitable.
This vulnerability is based upon the detection of the vulnerable framework being installed & running. The framework itself is vulnerable, with or without the ValidateRequest Filter. If the ValidateRequest Filter is used, it can be bypassed, to exploit the framework. If the ValiateRequest Filter is not used, the framework can also be exploited, as no filtering would be present. For this reason, we feel the framework itself is vulnerable, and so the detection of this framework being installed is reported as a confirmed vulnerability.
Qualys Support has published a FAQ about QID 90780 covering the key aspects of this vuln based on this thread and conversations Qualys Support has had with other customers. I've marked this as the correct answer to this thread, so that people can easily find this FAQ.