Advanced web application defense with Modsecurity

Daniel Fernandez Bleda

&

Christian Martorella

Who we are? (I)

Christian Martorella:

Security Engineer +6 years experience on the field.

Open Information System Security Group, Barcelona chapter President.

First Improvised Security Testing Conference Organizer

CISSP & OPST

Who we are? (II)

Daniel Fernández Bleda:

Security Engineer +5 years experience on the field.

Institute for Security and Open Methodologies (ISECOM), Member, and OSSTMM promoter.

Open Information System Security Group, Barcelona chapter Member.

CISSP, OPST & OPSA.

Introduce Modsecurity

Show how can you protect your web applications

Show our work in extending the functionalities of this module.

Aim of the Presentation

Web Applications are insecure

Today are the most vulnerable part of company infrastructure.

Everyday the attacks at the application layer are growing:

SQL Injection

XSS

Command Injection

Buffer Overflows

Session manipulation

Etc..

Actual Scenario (I)

The quantity of vulnerabilities is growing

80% of the last 30 exploits posted to Milw0rm target Web Applications: Wordpress, Phpbb, Xml-rpc, etc.

We can find a lot of Firewalls to analyse and filter traffic at the network level, but at the Application level, what are our options? Open and Free, very little..

There are secure networks with insecure applications that jeopardize all security of the company.

Actual Scenario (II)

The web development is chaotic

Lack of web security awareness.

First users requirement, last security (if time allow)

If it works don't touch it (sad but true)

False sense of security:

We have a firewall, we are safe

We use SSL, we are safe

What is the problem? (I)

Firewall

Webserver

Database

Webapps

WebClient

Network firewalls doesn't do anything at this level:

What is the problem (II)

443

80

Intrusion Detection / Prevention for Web Applications

Operate as an Apache Module.

Open Source and GPL

Development by Ivan Ristic

The purpose of ModSecurity is to increase

web application security by protecting them from known and unknown attacks

What is ModSecurity?

Applications you can't modify: legacy applications, protected code like Zend encoder, Phpshield, etc.

New vulnerability discovered, temporal protection until patch is released.

Intrusion Detection .

Prevention.

To protect Web services.

Web applications operated by people other than original software developers.

When can we use it?

Request filtering: incoming requests are analysed as they come in, and before they get handled by the web server or other modules.

Output Filtering: It could analyse the server response. (Error, Critical data Ex. PHP Errors)

Understanding of the HTTP protocol: since the engine understands HTTP, it performs very specific and fine granulated filtering.

Features (I)

Anti-evasion techniques: paths and parameters are normalized before analysis takes place in order to fight evasion techniques.

Remove multiple forward slash characters

Treat backslash and forward slash characters equally

Remove directory self-references

Detect and remove null-bytes (%00)

Decode URL encoded characters

Features (II)

POST payload analysis: the engine will intercept the contents transmitted using the POST method.

HTTPS filtering: since the engine is embedded in the web server, it gets access to request data after decryption takes place.

Features (III)

Features (IV)

Audit logging: full details of every request (including POST) can be logged for later analysis.

For doing an effective forensic investigation, we need at least:

Source IP

Time stamp

HTTP method

URI requested

Full Http Data

URL encoding validation

Unicode encoding validation

Byte range verification [0-255] detect and reject :

- Shellcode

- Cross Request Form Forgerie (CR,LF)

If the language used in our application is English we can limit the byte range to [32-126].

Special built-in checks

Any number of custom rules supported

Rules are formed using regular expressions

Negated rules supported

Analyses:

Headers

Environment variables

Server variables

Individual page variables

POST payload

Script output

Individual cookies

Rules

Reject request with status code [403,500, ..]

Reject request with redirection

Execute external binary on rule match

Log request

Actions (I)

Stop rule processing and let the request through

Rule chaining

Skip next n rules on match

Pauses for a number of milliseconds

Actions (II)

Intercept files being uploaded through the web server

Store uploaded files on disk

Execute an external script to approve or reject files (ClamAV anti-virus)

File upload

Change the identity of the web server

Easy to use internal chroot functionality

Audit log to log complete requests

Debug log

Other

Parse the request.

Perform canonicalization and anti-evasion actions.

Perform special built-in checks.

Execute input rules:

If the request is allowed, then it will reach the handler where it executes.

After the request:

1. Execute output rules.

2. Log the request.

How does it works

A security model is the posture we take at the time of setting rules for our protection systems.

There are two security models:

Positive Model

Negative Model

Security models

We allow what we know is right (safe).

Like Firewall model “Deny All - Allow what we need”.

Pros:

Better performance

Less false positives

Cons:

More time to implement, we need to identify all the scripts in the application, and create rules for them.

Example:

Page log.asp, the field Login could only accept characters [a-zA-Z0-9] and could be 12 char long.

Security models: Positive Model

Deny what is dangerous

Do we know everything that is bad for our applications?

Pros:

Less time to implement

Cons:

More false positives

More processing

Example XSS:

There are a lot of tags and places to look for XSS, we can miss some of them leaving a hole in our application.

Security models: Negative Model (I)

Security Models: Negative Model (II)

<object>...</object>

<embed>...</embed>

<applet>...</applet>

<script>...</script>

<script src="..."></script>

<iframe src="...">

<img src="javascript:...">

<b onMouseOver="...">

&{...};

Per Context configuration:

Main Server

Virtual Host

Directory

Inheritance: Virtual Host and Directory could Inherit the configuration of the Main Server. Same for Directory with Virtual Host.

Configuration

Thoughts...

What about my web server, i don't use Apache

Firewall

Mod_security + Mod_Proxy

WebClient

Apache

Iplanet

IIS

mod_security + mod_proxy = Application Firewall Appliance

Reverse Proxy Model (I)

www.myiis.com

www.myiplanet.com

www.myapache.com

Advantages:	Single point of access

Increased Performance

Network Isolation

Network Topology Hidden from outside

Protect any Web server, IIS, Iplanet, etc.

Disadvantages:	Single point of Failure

Increased Complexity

Reverse Proxy Model (II)

Strip Comments

Cookie signing

Link Signing

Hidden field signing

Web Console to manage logs

Some of these features are present in commercial firewalls, so we thought it will be great if Modsecurity could do the same.

Extending features

Using the Libxml2 we have added an extra functionality, which allows to strip the comments in the html code.

So just adding the directive:

SecStripCodeComment On/Off

Modsecurity will clean all commented code before sending the requested page to the user.

Strip Comments

As an extra options for protecting the applications, we are planning to sign the cookies, to prevent tampering (cookie poisoning)

With directives:

SecSignCookies On/Off

SecEncriptionPassword “password”

We use Cryptlib, to sign the cookies with the AES algorithm.

Still in development.

Cookie Signing

Link Signing (I)

As an extra layer of security we have added the option to sign all links browsables from “Entry points”, so users are able only to follow the “intended flow” of the application.

We use Cryptlib, to sign the links with the AES algorithm.

The directives to control this:

SecSignLinks On/Off

SecEntryPoint “/index.asp” “/images” ... “entry page n”

SecEncriptionPassword “password”

Link Signing (II)

Signing the links we can tackle this threats:

Predictable Resource Location

Forceful Browsing: the attacker "forces" a URL by accessesing it directly instead of following links.

Automated scanners like Nikto, dirb, and others, will be foiled.

Form and Hidden Fields Signing

Another security measure we working in is signing of form hidden fields and signing the forms itself, to prevent the values from being modified in the quantity, names, etc. of the inputs of the form.

Web based Log Console

Facilitate the log analysis task

Snort Acid Style

Some of the listing that it provides:

Top 10 attacks or attackers

Today attacks

Last 15 Attacks

Other characteristics:

Attack details

Search

Delete records

Log console

Log Console (II)

Logs console (III)

Web App Security Consortium (WASC)

This project will use one of the web attacker's most trusted tools against him - the Open Proxy server. Instead of being the target of the attacks, we opt to be used as a conduit of the attack data in order to gather our intelligence. By deploying multiple, specially configured open proxy server (or proxypot), we aim to take a birds-eye look at the types of malicious traffic that traverse these systems.

Open proxy honeypots (I)

The honeypot systems will conduct real-time analysis on the HTTP traffic to categorize the requests into threat classifications outlined by the Web Security Threat Classification and report all logging data to a centralized location.

Open proxy honeypots (II)

Examples

SQL Injection

XSS Scripting

Fine grained checks

Buffer Overflows

Positive Model

File extensions

Output filtering, errors.

Resource location prediction

Strip comment code

Blog/Forums spam protection

Example Scenario

mod_security + mod_proxy

www.secure.com

www.vulnerable.com

client

IIS

Sql Injection

Vulnerable parameter: Login

Test String:

' or 1=1;--

Modsecurity rule:

Secfilter '.+--

Positive way:

SecfilterSelective ARG_login !^[a-zA-Z]+$

XSS Prevention

Vulnerable parameter: pagina

Test String:

<script>alert('Next time I will eat your cookies ');</script>

Hex Encoded:

%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%27%4E%65%78%74%20%74%69%6D%65%20%49%20%77%69%6C%6C%20%65%61%74%20%79%6F%75%72%20%63%6F%6F%6B%69%65%73%20%27%29%3B%3C%2F%73%63%72%69%70%74%3E

Modsecurity rule:

Secfilter “<(.|\n)+>”

Fine Grained (I) Anti-Buffer Overflow

Vulnerable parameter: login

Test String:

TestTestTestTestTestTest

Modsecurity rule:

SecfilterSelective ARG_login .{12,}

Fine Grained (II) Positive Model

Vulnerable parameter: login

Test String:

Test12-

121212

Modsecurity rule:

SecfilterSelective ARG_login !^[a-zA-Z]+$

File extension protection

Vulnerable file extension: *.txt

Requested file: admin/password.txt

Modsecurity rule:

SecfilterSelective SCRIPT_FILENAME .+\.txt$

Positive way: SCRIPT_FILENAME !.+\.asp$

If we use Link Signing we don't need to worry about this rules.

Output errors protection

Vulnerable parameter: password

Test String:

' (single quote)

Modsecurity rule:

SecfilterSelective OUTPUT “Microsoft OLE DB Provider” “redirect:http://www.secure.com/default.asp”

Strip Comment Code

Vulnerable page: help.asp

Commented code:

<!-- remember that admin zone is in /admin/ -->

Modsecurity option:

SecStripCommenCode On

Blog Spam scenario, Wordpress

www.myblog.com

Here Modsecurity is working in the same server that is protecting.

Apache/Wordpress

Web Client

Blog/Forums spam protection

Vulnerable parameter: comments

Spam message:

“Cheap viagra”

“Cheap vLagra”

“Cheap v1agra”

Modsecurity Rule:

Secfilter ARGS “v[iIL1]agra” redirect:http://www.myblog.com/spam.swf

Link Signing activated

mod_security + mod_proxy

www.securesign.com

www.vulnerable.com

client

IIS

Resource Location Prediction

Attack tool: Nikto

Attack options:

nikto -host www.vulnerable.com

nikto -host www.securesign.com

Modsecurity options:

SecSignLinks On

SecEncriptionPassword “our_Pass*Word-$”

Resource Location using Nikto

Resource location using Nikto

XSS with Sign Links enabled

Vulnerable parameter: pagina

Test String:

<script>alert('Next time I will eat your cookies ');</script>

Modsecurity rule:

Secfilter “<(.|\n)+>”

Same for all other type of injection and variable manipulation, that involves a link, or direct access to URL.

File extensions with Sign Links On

Vulnerable file extension: *.txt

Requested file: /admin/password.txt

Modsecurity rule:

SecfilterSelective SCRIPT_FILENAME .+\.txt$

Positive way: SCRIPT_FILENAME !.+\.asp$

We don't need to worry about this rules anymore!

Conclusions

Modsecurity is a great choice for protecting your web applications

Easy to configure

Very effective

Remember that Modsecurity is an extra layer in our protection scheme, we have to secure our applications whenever we can.

There is still much work to do to improve this features, they are an alpha version.

When the first version is available we will announce it in the modsecurity mailing list.

Question, doubts?

Download Modsecurity:

www.modsecurity.org

Mailing List:

mod-security-users@lists.sourceforge.net

Cryptlib:

http://www.cs.auckland.ac.nz/~pgut001/cryptlib/

Libxml2:

http://xmlsoft.org/

References

Thank you!

Coding is no easy

But programmers are patient

Advanced web application defense with Modsecurity

Daniel Fernandez Bleda

dfernandez@isecauditors.com

Christian Martorella

cmartorella@isecauditors.com

2005-07-05T23:10:15