[Owasp-modsecurity-core-rule-set] basic questions of apache exploitation & modsecurity.

[Brian Rectanus]

I think that this is deviating from the list topic (core rule set).
Please take it to the mod-security-users list if you want to discuss
ModSecurity itself.  I've CC'd that list, so please reply there.

Some further comments below...

Ivan Ristic wrote:
> Hi David,
> 
> In principle, ModSecurity was not designed to protect Apache itself.
> It may do, but if it can, it's a byproduct of whatever else we are
> trying to accomplish. I never used ModSecurity in that way, although
> others may have. More responses below.
> 
> 
> On Wed, Feb 10, 2010 at 11:56 PM, David Taveras <d3taveras38d3 at gmail.com> wrote:
>> Hello,
>>
>> Iam trying to build a very general panorama on the paths a hack can
>> take place with modsecurity & an apache webserver. So i have some
>> general questions!
>>
>> a.) all possible apache attacks start via a request method, correct ?
>> (DELETE, GET, HEAD, PUT, POST), correct?
> 
> The request method does not matter if there's a vulnerability in the
> code somewhere that can be exploited before Apache evaluates the
> request method. Overall, I don't think Apache cares much about request
> methods.

Some examples:

* SSL processing

* Parsing the request line (required before you can see the method)

* Header parsing, such as the Host header which may determine the Apache
config (and thus the ModSecurity config) used to process the request.

> 
> 
>> b.) Although modsecurity inspects the REQUEST_URI, the focus is
>> actually the QUERY_STRING this is what all the rules end up inspecting
>> right (aside from the body content for data leakage). Right?
> 
> You would inspect response bodies for leakage, but input data can also
> be in the request headers and the request body.

All aspects of the request are used, but generally speaking it is ARGS
that is probably the most common.

Common examples that you seem to have overlooked:

* Cookie values (both incoming and outgoing)

* General HTTP request abnormalities:
  - Known HTTP method
  - Checking for headers that should normally be there (or not there)
  - Using strict parsing for multi-part form posts

* URI based parameters:
  http://my.host.tld/myapp/view/record/record-id-12345

* Auth values (ie check brute forcing and that passwords fall within a
policy guidelines).

> 
> 
>> c.) If I host an apache webserver with vulerabilities within the
>> apache code and this one hosts no scripts or data. Is it possible to
>> exploit those vulerabilities on apache?
> 
> It depends on the configuration and on the vulnerabilities. It might be.

I would say yes.  Take an SSL exploit as an example.  Also a buffer
overflow in processing the request line.  Both of these fall before
ModSecurity sees the request and there is zero chance of ModSecurity
stopping anything it never sees ;)

> 
> 
>> d.) How if a buffer overflow exploited on a webserver hosting images
>> and php scripts?
> 
> Can you please rephrase the question?

Assuming you meant: How *is* a buffer overflow exploited on a webserver
*only* hosting images and php scripts?

While these may seem like they are both "non-executing" ways of
processing (as apposed to the obvious execution of a CGI script), they
are still executing code.

* All request still require HTTP parsing and there could be a buffer
overflow in this parsing code.

* Most images are static, but they can be dynamic (rendered from a
script - such as CAPTCHAs, routes on maps, etc).  So there could be
external code executed.

* PHP is typically handled in two ways.  You can load mod_php and then
the PHP processing is executed within the Apache processing space.
Another (maybe even more common method due to threading issues in php)
is running PHP as a fast-cgi application, which runs the PHP processing
within a separate processing space which Apache then communicates via
IPC.  In either case any buffer overflow in PHP processing may mean that
protections could be bypassed, or worse allow for arbitrary code
execution.  You may think you are protected because the code normally is
running as a non-admin user (www-data, apache, nobody, etc), but if
there is a local exploit on your machine, then this code could be
escalated into running arbitrary code as root.

* And of course there is the possibility of a buffer overflow in the SSL
processing.

* Other exploits could target the caching sub-system (mod_cache), etc.
which would even put static images and pages at risk.


> 
> 
>> e.) What is the point of installing modsecurity aside from certain
>> protection of DoS attacks, or security awareness if I host an apache
>> webserver with only html pages?
> 
> I would say that ModSecurity has little to add in that situation.

You mean only *static*, on disk data, not generated HTML?  Even
seemingly static HTML may be combining headers/footers at runtime.
Also, even static sites generally will have some sort of authentication,
sessions and may even process requests with parameters, but still serve
static data.  But Ivan is correct, ModSecurity really will not help you
as much as it is meant for processing the request/response data.

However, a few exceptions that I can think of:

* Running as a caching reverse-proxy in front of web servers that may be
vulnerable to attacks and cannot be patched/updated for any number of
reasons.

* Aiding in the prevention of path traversal attacks.  That is,
preventing a user from getting to data that the user may not have been
authorized for.

* Aiding in detecting issues with authentication (credentials) and
authorization (sessions).

* Aiding in the detection of site defacement (ie making sure outgoing
data is okay).

* Aiding in the detection of data theft (ie private data leaving the
server, such as confidential documents, etc.)

* Providing a full audit log of requests (all or maybe just for
confidential docs).

* Aiding in the prevention of site scraping.

-B

-- 
Brian Rectanus
Breach Security