ModSecurity Trustwave
This blog has moved! Please update your
bookmarks to

ModSecurity Blog: January 2007

SANS @Risk Web Vulnerabilities List & Mitigation Steps

This is a listing of Web Application Vulnerabilities that were released by SANS in their @RISK newsletter yesterday -

Summary of the vulnerabilities reported this week:
-- Web Application - Cross Site Scripting (8)
07.5.44 - ezDatabase Login.PHP Cross-Site Scripting
07.5.45 - Openads phpAdsNew Admin-Search.PHP Cross-Site Scripting
07.5.46 - 212cafeBoard Multiple Cross-Site Scripting Vulnerabilities
07.5.47 - Bitweaver Articles and Blogs Multiple Cross-Site Scripting Vulnerabilities
07.5.48 - 212Cafe Guestbook Show.PHP Cross-Site Scripting
07.5.49 - Openads for PostgreSQL Unspecified Cross-Site Scripting
07.5.50 - PostNuke Reviews Index.PHP Cross-Site Scripting
07.5.51 - Sabros.US Index.PHP Cross-Site Scripting

-- Web Application - SQL Injection (10)
07.5.52 - Makit Newsposter Script News_Page.ASP SQL Injection
07.5.53 - GPS CMS Print.ASP SQL Injection
07.5.54 - ASP News News_Detail.ASP SQL Injection
07.5.55 - ASP Edge User.ASP SQL Injection
07.5.56 - Drupal Acidfree Module Node Title SQL Injection
07.5.57 - Website Baker Login.PHP SQL Injection
07.5.58 - FishCart Olst Parameter SQL Injection
07.5.59 - Unique Ads Banner.PHP SQL Injection
07.5.60 - PHP-Nuke Multiple SQL Injection Vulnerabilities
07.5.61 - Joomla CMS Multiple SQL Injection Vulnerabilities

-- Web Application (34)
07.5.62 - CGI Rescue WebForm Multiple Input Validation Vulnerabilities
07.5.63 - High5 Review Script Search Field HTML Injection
07.5.64 - Virtual Path PHPBB Module Configure.PHP Remote File Include
07.5.65 - Digitalxero Xero Portal PHPBB_Root_Path Multiple Remote File Include Vulnerabilities
07.5.66 - Drupal Project and Project Issues Tracking Modules Multiple Vulnerabilities
07.5.67 - Community Server Pingback SourceURI Denial of Service and Information Disclosure
07.5.68 - AWFFull Unspecified Multiple Buffer Overflow Vulnerabilities
07.5.69 - Virtual Host Administrator Modules_Dir Remote File Include
07.5.70 - Wordpress Pingback SourceURI Denial of Service and Information Disclosure
07.5.71 - RPW Config.PHP Remote File Include
07.5.72 - phpXD Path Remote File Include
07.5.73 - MyBB Private.PHP HTML Injection
07.5.74 - MaklerPlus Multiple Unspecified Vulnerabilities
07.5.75 - Mini Web Server Unspecified Multiple Buffer Overflow Vulnerabilities
07.5.76 - BBClone Selectlang.PHP Remote File Include
07.5.77 - Yana Framework Guestbook Unspecified Security Bypass
07.5.78 - Vote! Pro Multiple PHP Code Execution Vulnerabilities
07.5.79 - PHP Link Directory Link Submission HTML Injection
07.5.80 - Zomp Index.PHP Local File Include
07.5.81 - PHPIndexPage Config.PHP Remote File Include
07.5.82 - Neon Labs Website NL.PHP Remote File Include
07.5.83 - XMB MemCP.PHP HTML Injection
07.5.84 - PHPSherpa Racine Parameter Remote File Include
07.5.85 - Upload Service Remote File Include
07.5.86 - Mafia Scum Tools Index.PHP Remote File Include
07.5.87 - WebChat Remote File Include
07.5.88 - Bradabra Includes.PHP Remote File Include
07.5.89 - Easebay Resources Paypal Subscription Manager Multiple Input Validation Vulnerabilities
07.5.90 - Easebay Resources Login Manager Multiple Input Validation Vulnerabilities
07.5.91 - SMF Index.PHP HTML Injection
07.5.92 - DocMan Multiple Input Validation Vulnerabilities
07.5.93 - ArsDigita Community System Directory Traversal
07.5.94 - VirtueMart Joomla ECommerce Edition Multiple Unspecified Input Validation Vulnerabilities
07.5.95 - WebGUI Registration Username HTML Injection

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 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. 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 head on over to the site 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.

Top 10 Web Hacks of 2006

Jeremiah Grossman gives an excellent overview of the top Web hacks of 2006. If you haven't been following the events as they unfolded last year this presentation alone will help you catch up.

Key Advantages of the Core Rule Set

Following a question on the core rule set on the ModSecuirty mailing list, I would like to list some of the key properties of the core rule set. The focus of the core rule set is to be a "rule set" rather than a set of rules and the properties below are all derived from that:

Performance - The core rule set is optimized for performance. The amount and content of the rules used predominantly determines the performance impact of ModSecurity, so the performance optimization of the rule set is very important.

Quality - While there will always be false positives, and the core rule set is young, we spend a lot of time trying to make the core rule set better. Some of the things we do are:

  • Regression tests - we have a regression test, so every new version we ship is tested to ensure it does not break anything. Actually every report of a false positive, once solved, gets into the regression test.
  • Real traffic testing - we are continuously converting Giga bytes of cap files to tests and send them through ModSecurity to detect potential false positives. I think you could see the result in version 1.3.2 which includes many fixes based on these tests.

Generic Detection - The core rule set is tuned to detect generic attacks and does not include specific rules for known vulnerabilities. Due to this feature the core rule set has  better performance, is more "plug and play" and requires less updates. If you want to patch known vulnerabilities you may look for rules from gotroot or convert snort rules such as those at bleeding threats, but you must select only the rules that apply to you, otherwise performance may suffer.

Event Information - Each rule in the core rule set has a unique ID and a textual message. In the future we are going to add classification using a new tag action in ModSecurity, as well as longer information regarding each rule using comments in the files themselves.

Plug and Play - We try to make the rule set as plug and play as possible. Since its performance is good and it employs generic detection, and since the number of false positives is getting lower all the time, the core rule set can be installed as is with little twisting and tweaking.

To get deeper into the core rule set you may want to read the presentation I gave about it in a recent OWASP chapter meeting.


November 2010
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30


Atom Feed



Recent Entries