AppSec Blog

Weekly Roundup of @Risk Web Application Vulnerabilities


@RISK: The Consensus Security Vulnerability Alert

October 21st, 2010 Vol. 9. Week 43


Web Application - Cross Site Scripting
Web Application - SQL Injection
Web Application


Want to learn how to virtually patch these web application vulnerabilities? Come to the SANS@Night talk at the upcoming Cyber Defense Initiative (CDI) conference entitled:

Virtually Patching the SANS @Risk Web Vulnerabilities

- Ryan Barnett
- Tuesday, December 14, 2010 - 7pm to 8pm

What is your Time-to-Fix metric for remediating identified web application vulnerabilities? Is is measured in hours, days or months? Let's face the facts, there are many real world business scenarios where it is not possible to update web application code in either a timely manner or at all. This is where the tactical use-case of implementing a virtual patch to address identified issues proves its worth. This talk assumes that all attendees already understand the rationale and business justification of virtual patches and will instead focus on some real-world examples of web application vulnerabilities taken from the weekly SANS @Risk newsletter. We will walk through the steps of identifying the critical attack details, creating and testing a virtual patch using the open source ModSecurity web application firewall.


Mitigation Steps:
It is important to note that if you are running any of these web applications, you should do the following:

1) Check on the reference links for each vulnerability (SecurityFocus site, etc...) and verify if a patch is available. If one is, then proceed with implementing the patch ASAP.

2) Run a few tests to see if the example expoit code might be already captured by the current OWASP ModSecurity Core Rules files. There are already many different XSS/SQL Injection rules that probably would block the vast majority of these 2 categories of issues. If the Core Rules do not block these issues, then proceed to #3 (Virtual Patching).

3) Whether a patch is available or not, you should attempt to implement a ModSecurity "Virtual Patch" for the vulnerability. You can go about this in one of two ways -

First, the vulnerability information on SecurityFocus usually include an "exploit" tab for each vulnerability where exploit details/proof of concept code is often provided. For example, with the AdaptWeb vuln listed above, there is example exploit data (including attack vector locations) listed here. You can take the example exploit code and then create a corresponding patch. The patch can either be a negative filter that blocks the underlying vulnerability vector. You can also, optionally, create a positive filter that will only allow acceptable character sets/lengths, etc...

Second, you can optionally review other public IDS rule sets such as Emerging Threats to see if they have released an IDS signatures for these vulnerabilities. If they have, you can then take the content/uricontent/pcre portions of the sigs and translate them into analagous ModSecurity rules.

Post a Comment


* Indicates a required field.