110
Introduction to Web Application Firewalls From Rich Helton’s October 2010 Web Application Firewall classes

Web Application Firewall intro

Embed Size (px)

Citation preview

Page 1: Web Application Firewall intro

Introduction to Web Application Firewalls

From Rich Helton’s October 2010 Web Application Firewall classes

Page 2: Web Application Firewall intro

WAF ( A quick fix)

Instead of rewriting code, some potentially quicker methods is to put an application to intercept the HTTP traffic ahead of the HTTP server known as a Web Application Firewall (WAF).

The WAF takes configurations like a normal firewall on what traffic to pass and reject. The difference is that it is responding specifically to an HTTP server like Apache or IIS.

For Apache, the most popular approach is to use its Open Source plugin called mod_security. http://www.modsecurity.org/

For IIS, WebKnight from AQTronix, http://aqtronix.com/?PageID=99 is the most popular Open Source solution.

Not everything can be covered by a WAF, especially session hijacking flaws, but XSS and SQL Injection can be mitigated. http://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls

Page 3: Web Application Firewall intro

WAF ( Not just a server fix)

WAFs are filters that sit in front of the Web Application. Depending on their configuration, they will deny, or log,

validated information from the Internet into the Application.

They are a good source in auditing the information that is hitting the Web site and the scans that are constantly taking place.

Page 4: Web Application Firewall intro

Pro’s and Con’s

Pro’s: Installing a WAF is quicker, in most cases, than changing

code and re-deploying a Web Application. WAF’s may find issues, by using its rule sets, that the code

may not be prepared to find. This is because WAFs have thousands of rules generated by industry experts.

Con’s:WAFs are limited by the rules that are installed in them. Therefore, if the rule is not there, it cannot protect against it. Validation is a better protection, because form level validation will use white-listing on what input is allowed, versus black-listing on the input that is denied.

Page 5: Web Application Firewall intro

ModSecurity/ApacheLabs

Page 6: Web Application Firewall intro

Lab1(Applying Tomcat)

Page 7: Web Application Firewall intro

Tomcat will need Apache

Starting Apache:

If there is an error, run the “StartApache.bat” in the lab and observe the error. Likely Apache may already be started.

Check Apache by IE http://localhost/ and it returns:

Page 8: Web Application Firewall intro

Tomcat will need Apache

To link Tomcat and Apache, the mod_jk module will need to be installed, see http://tomcat.apache.org/connectors-doc/ . Also known as the Tomcat Connector.

Note: Tomcat can also use Microsoft’s IIS, instead of Apache, utilizing the Microsoft ISAPI plugin. The easiest way to install the mod_jk connector is to have

Tomcat generate “conf/auto/mod_jk.conf” from its Container and have Apache reference it from its “conf/httpd.conf” file: LoadModule jk_module modules/mod_jk.so

Include C:/Apache2/apache-tomcat-6.0.28/conf/auto/mod_jk.conf

See http://www.johnturner.com/howto/apache2-tomcat4129-jk-winxp-howto.html

Page 9: Web Application Firewall intro

Tomcat will need Apache

Page 10: Web Application Firewall intro

Tomcat will need Apache

Start in “C:\Labs\Lab_Mod_JK”. Run the “TestApacheConfig.bat”

The Apache directory is pre-installed in “C:\Apache2”. Tomcat will be pre-installed in “C:\Apache2\apache-

tomcat-6.0.28”

Page 11: Web Application Firewall intro

Tomcat will need Apache

You might receive the following screen from the generated mod_jk.conf:

The mod_jk.conf is generated from Tomcat and is running an old version of Tomcat. This file can be edited and copied to a new location and referenced, such as “C:\Apache2\apache-tomcat-6.0.28\conf” .

Page 12: Web Application Firewall intro

Installing mod_jk

mod_jk is the module that Tomcat and Apache will use to communicate. The C:\Apache2\apache-tomcat-6.0.28\conf\auto\mod_jk.conf file is generated from Tomcat at startup to tell Apache which files are available.

The Apache httpd.conf is configured to find the mod_jk.so module and configuration files by adding the following lines:

This is both in the Lab1 directory and already modified.

Page 13: Web Application Firewall intro

Installing mod_jk

Notice that the mod_jk.log will log the communications from Apache to Tomcat.

A workers.properties also has to be created in the $tomcat/conf to describe the ajp13 (mod_jk protocol) threads across port 8009.

Tomcat’s server.xml also has to be modified to listen with the mod_jk.so file:

Page 14: Web Application Firewall intro

Starting Tomcat/Apache

After a successful Start in Apache, and running C:\Apache2\apache-tomcat-6.0.28\bin\startup.bat . You can see it is successful by looking at the logs for an exceptions (look for the keyword exception in the files) and a successful start:

Page 15: Web Application Firewall intro

Port 8009

Port 8009 was used in the configuration workers.properties and server.xml to communicate between Apache and Tomcat. Using a product like fport.exe from Foundstone, the port should appear to be open and listening from java starting it, notice port 8009:

Page 16: Web Application Firewall intro

Now Try a Struts XSS Sample

Calling http://localhost/mandiant-struts-form-vulnerable/index.jsp

Page 17: Web Application Firewall intro

Now Try a Struts XSS Sample

Typing in the XSS “<script>alert(123)</script>”, XSS appears:

Page 18: Web Application Firewall intro

Lab2(Adding ModSecurity)

Page 19: Web Application Firewall intro

Apache mod_security

The mod_security module information can be found at http://www.modsecurity.org/

Load the mod_security and unique id modules (this example is XP) in conf/httpd.conf: LoadModule security2_module modules/mod_security2.so

LoadModule unique_id_module modules/mod_unique_id.so

Add the base configuration and some of the base rules: Include conf/mod_security.conf

Include conf/base_rules/modsecurity_crs_41_xss_attacks.conf

Include conf/base_rules/modsecurity_crs_23_request_limits.conf

Include conf/base_rules/modsecurity_crs_35_bad_robots.conf

Include conf/base_rules/modsecurity_crs_40_generic_attacks.conf

Include conf/base_rules/modsecurity_crs_41_sql_injection_attacks.conf

Page 20: Web Application Firewall intro

Apache mod_unique_id

The modules/mod_unique_id.so has to be installed for mod_security to work.

To check to see which modules are currently being used by Apache, run httpd –t –D DUMP_MODULES from the Apache2/bin directory:

Page 21: Web Application Firewall intro

Apache mod_unique_id

Ensuring that the field is set in Apache2/httpd.conf :

Now run httpd –t –D DUMP_MODULES from the Apache2/bin directory:

Page 22: Web Application Firewall intro

Apache mod_security2

Copying the libxml2.dll, mod_security2.so, and pcre.dll to Apache2/modules, and adding the following to httpd.conf :

Now run httpd –t –D DUMP_MODULES from the

Apache2/bin directory to see security2_module:

Page 23: Web Application Firewall intro

mod_security2 minimal configuration

Changing the modsecurity.conf-minimal to modsecurity.conf, the httpd.conf needs to call it:

Setting the rules to “500 Internal Server Error”, the XSS

now returns an error code of 500:

Page 24: Web Application Firewall intro

Testing which rules may apply

http://www.modsecurity.org/demo/phpids has a smoketest to verify which rules may apply

Page 25: Web Application Firewall intro

ModSecurity Template for Building Rules

Page 26: Web Application Firewall intro

Lab3(Manipulating Rules)

Page 27: Web Application Firewall intro

Apache mod_security logs

The mod_security logs show what the mod_security blocked. If the minimal configuration was used with mod_security, it

will send which rule that it blocked on to the “Apache2/logs/mod_audit.log.”

The log will match a rule that will define, usually through a Regex expression, the blocking sequence.

To log, the location of the logs need to be defined, as well as their level of logging.

SecAuditEngine On Enables audit logging for all transactions.

SecAuditEngine RelevantOnly Enables audit logging only for transactions that match a rule, or that have a status code that matches the regular expression configured via SecAuditLo- gRelevantStatus.

SecAuditEngine Off Disables audit logging.

Page 28: Web Application Firewall intro

Defining logging (modsecurity.conf)

Page 29: Web Application Firewall intro

What do the mod_audit log say?

It blocked the mandiant page for the following reasons:

Page 30: Web Application Firewall intro

What do the mod_audit log say?

Looking closer,

It appears that the phids filter identified “<scri” as XSS.

Page 31: Web Application Firewall intro

What do the mod_audit log say?

Looking closer,

It appears that the phids filter identified “<scri” as XSS.

Page 32: Web Application Firewall intro

A simple test

Let’s see what happens when we remove the 41_phids_filters.conf

I am going to leave Tomcat running, it is not processing the rules, only Apache.

I am going to stop Apache, delete the 41_phids_filters.conf file, test the configuration, and start Apache.

The Apache configuration tested good, always test with changes…

Page 33: Web Application Firewall intro

This time it didn’t block,but triggered an audit rule

In the modsecurity_crs_41_xss_attacks.conf, it says pass and audit:

Page 34: Web Application Firewall intro

Conclusion

Adding the file 41_phids_filters.conf back in will start the process to block again.

Another alternative is to set the xss_attacks.conf rule to block by changing the rule from changing “pass” to “deny”.

There are many, many rules, and more than likely, they overlap in some manner.

This exercise was to show how to manipulate the rules just in case some of them block normal business activities.

Page 35: Web Application Firewall intro

Lab4(Logging Only)

Page 36: Web Application Firewall intro

Startup

Ensure that Apache is set to block XSS with phids rules as before.

In this exercise, we will simply log and not block. By default, modsecurity only logs, so we need to simply

commit out the deny statement in the httpd.conf, after stopping Apache, check the config, and restart Apache.

Page 37: Web Application Firewall intro

XSS passes through

This time XSS passes through

Page 38: Web Application Firewall intro

The XSS alerts are logged

In the audit log we see the phpids alerts for XSS, along with the other rules as well. This is because it was not blocked by the phpids alert and kept going:

Page 39: Web Application Firewall intro

Lets test some tools(scanning with Netsparker)

Page 40: Web Application Firewall intro

It found XSS(scanning with Netsparker)

Page 41: Web Application Firewall intro

ModSecurity audit logs

When Netsparker scanned the site, the audit logs went from 32 KB to 732 KB. This is because it was capturing the NetSparker attacks.

Page 42: Web Application Firewall intro

Turning on “deny” again(XSS went away)

Page 43: Web Application Firewall intro

Conclusions

The most interesting part of this exercise is that we have the ability to capture an audit log , without blocking anything, and understand what attacks are hitting the web site.

Page 44: Web Application Firewall intro

Lab5(FingerPrinting)

Page 45: Web Application Firewall intro

Startup

Ensure that Apache is set to block XSS with phids rules as before.

By knowing the Web Server type, and patches, it provides hackers a roadmap of what attacks to perform.

ModSecurity can fake the signature. Changing the httpd.conf:

Page 46: Web Application Firewall intro

HttpPrint scans our type (Apache)

Page 47: Web Application Firewall intro

Let’s pretend to be an IIS machine

Changing the httpd.conf:

And the mod_security.conf:

Page 48: Web Application Firewall intro

Now we are Apache appearing as IIS 5.0

Page 49: Web Application Firewall intro

WebKnight/IISLabs

Page 50: Web Application Firewall intro

Lab1(Starting IIS/Hacme Bank)

Page 51: Web Application Firewall intro

WebKnight

WebKnight is an Open Source Web Application Firewall from AQTronix, http://aqtronix.com/?PageID=99

IIS 5.1 and SQL Server 2008 be installed from (Need ISO/Disk for XP while Installing) Web Platform Installer http://www.microsoft.com/web/downloads/platform.aspx

What also will prove useful is the Web Visual Studio 2010 Express, http://www.microsoft.com/web/downloads/platform.aspx

The version of HacmeBank is an updated version of HacmeBank to work on the modern .NET frameworks, it may work with versions 2.0 – 4.0. It was updated from the older versions found at http://www.owasp.org/index.php/OWASP_O2_Platform/WIKI/Using_O2_on:_HacmeBank

Page 52: Web Application Firewall intro

Ensure IIS is started and HacmeBank installed (Control Panel-> Administrative

Tools->Internet Information Services)

Page 53: Web Application Firewall intro

Webknight

HacmeBank has 3 main pieces: The Hacme_Bank_V2_WS – Hacme Bank Web Service

that will provide the Login web service to the Database, has .asmx files.

The Hacme_Bank_V2_Website – provides the asp files for the pages and forms.

The FoundStone_Bank Database will have to be installed.

Page 54: Web Application Firewall intro

FoundStone_Bank DB(SQL Server Management Studio)

Page 55: Web Application Firewall intro

Installing FoundStone_Bank DB

With the newer source code, there is a both a sql script and installer for the Database:

Page 56: Web Application Firewall intro

Visual Studio Web Express

Most of the management can be done by Visual Studio:

Page 57: Web Application Firewall intro

.NET Version

Be very aware of which .NET version is set for the Web Site, it will change many things.

Page 58: Web Application Firewall intro

Test the Hacme Web Service

http://localhost/HacmeBank_v2_WS/WebServices/UserManagement.asmx

Page 59: Web Application Firewall intro

Test the Hacme Web Service

Login Service, user “jv”, password “jv789”.

Page 60: Web Application Firewall intro

Test the Hacme Web Service

Return of “0001” means that it found it in the database.

Page 61: Web Application Firewall intro

Test the Hacme Web Site

http://localhost/HacmeBank_v2_Website/aspx/Login.aspx, UserName “jv”, Password “jv789”.

Page 62: Web Application Firewall intro

Test the Hacme Web Site

Joe Vilella will Login OK.

Page 63: Web Application Firewall intro

Lab2(SQL Injection Test)

Page 64: Web Application Firewall intro

Intro to SQL Injection…

Many web pages communicate directly to a backend database for processing.

For example, a username and password is asked for on the Web page and the web page will pass it to the database to validate the information.

Some applications will not validate the field adequately before passing it to the database, and the database will process whatever it will receive.

Hackers will pass SQL commands directly to the database, and in some cases tables like “passwords” are returned because the SQL commands are not being filtered adequately.

SQL may return errors in the web page that even lists the correct tables to query so that the hacker may make more accurate attempts to get data.

Page 65: Web Application Firewall intro

SQL Injection

SQL Injection is the ability to inject malicious SQL commands into the backend code.

For example:

SELECT * FROM users WHERE username = ‘USRTEXT ' AND password = ‘PASSTEXT’

Passing ' OR 1=1-- in the USRTEXT field generates:

SELECT * FROM users WHERE username = ‘’ OR 1=1 -- '

AND password = ‘PASSTEXT’ The OR 1=1 returns true and the rest is commented

out

Page 66: Web Application Firewall intro

Common attack strings

‘ or 27(hex) – delineates SQL string values.“ or 22 (hex) – also delineates SQL string values.; or 3B (hex) - terminates statements.# or 23(hex) - also terminates a statement. (Access DB)/* or 2F2A (hex) - comment delimiter.-- or 2D2D (hex) – also comment delimiter.( or 28 (hex) or ) or 29 (hex) – logical sub clauses.{ or 7B (hex) or } or 7D (hex) – terminates a question.exec – used to call MS-SQL stored procedures.

union – a SQL command very common to SQL injection.

Page 67: Web Application Firewall intro

SQL Injection

http://localhost/HacmeBank_v2_Website/aspx/Login.aspx, use “' OR 1=1–” as the UserName and “Submit”.

Page 68: Web Application Firewall intro

SQL Injection

Joe Vilella will Login OK without a Username and Password.

Page 69: Web Application Firewall intro

Common Code fixes to SQL Injection…

Validate the form field to only accept specific input for the fields. For example, for login name use ^[0-9a-zA-Z]*$, which is

Regular expressions for an alpha-numerical field.

For Apache Struts, use the org.apache.struts.validator.ValidatorPlugin, http://www.owasp.org/index.php/Data_Validation_(Code_Review) .

For JSPs/Servlets, validate in the Servlet using the with the “java.utile.regex” framework in a similar manner.

Don’t use SQL Use Prepared Statements, or Hibernate, to call the database.

http://www.owasp.org/index.php/Preventing_SQL_Injection_in_Java

Page 70: Web Application Firewall intro

Lab3(XSS)

Page 71: Web Application Firewall intro

XSS in a form

http://localhost/HacmeBank_v2_Website/aspx/main.aspx?function=PostMessageForm

, type “<script>alert(document.cookie);</script>”

Page 72: Web Application Firewall intro

XSS

The cookie script will execute

Page 73: Web Application Firewall intro

Lab4(Install WebKnight)

Page 74: Web Application Firewall intro

WebKnight

A copy will be in MyDocuments:

Page 75: Web Application Firewall intro

WebKnight

The WebKnight page is http://aqtronix.com/?PageID=99 How to install can be found at

http://aqtronix.com/?PageID=99#Install The WebKnight FAQ can be found at

http://aqtronix.com/?PageID=114 and troubleshooting http://aqtronix.com/?PageID=114#trouble

Page 76: Web Application Firewall intro

WebKnight

Starting the Install:

Page 77: Web Application Firewall intro

WebKnight

Hit Typical:

Page 78: Web Application Firewall intro

WebKnight

Already done:

Page 79: Web Application Firewall intro

SQL Injection

http://localhost/HacmeBank_v2_Website/aspx/Login.aspx, use “' OR 1=1–” as the UserName and “Submit”.

Page 80: Web Application Firewall intro

SQL Injection

Out of the Box, it blocked SQL Injection.

Page 81: Web Application Firewall intro

Lab5(WebKnight)

Page 82: Web Application Firewall intro

WebKnight

The Webknight product has a Loaded .xml that shows what is currently loaded, a WebKnight.xml on what needs to be loaded next and a Robots.xml dedicated to Bots.

If you ever get into trouble, you can delete the WebKnight.XML and the default will be created.

WebKnight has preview settings to look at online http://www.aqtronix.com/WebKnight/Manual/WebKnight.xml

Make sure you edit the file WebKnight.xml and NOT Loaded.xml (this last one is for debugging and to see what is loaded in memory).

Once every minute, the Loaded.xml will replace itself with the WebKnight.xml.

Page 83: Web Application Firewall intro

WebKnight

The Webknight product has editors for looking at the logs and xml:

That are read from the AQTRONIX directory in Program Files:

Page 84: Web Application Firewall intro

WebKnight

You can even edit the WebKnight.XML directly if desired:

Page 85: Web Application Firewall intro

WebKnight

We don’t really know what was blocked. Looking at Log Anaylsis, part of the block was a shadow file:

Page 86: Web Application Firewall intro

WebKnight Loaded XML

WebKnight has several sections to configure sections of the configuration file.

Page 87: Web Application Firewall intro

WebKnight

By default, file uploads, Frontpage Extensions, WebDAV, ASP.NET and many protocols are turned off…..

Page 88: Web Application Firewall intro

WebKnight Logging

What to log can be specified

Page 89: Web Application Firewall intro

WebKnight Authentication

We can deny blank passwords, Admin passwords, common passwords , etc.

Page 90: Web Application Firewall intro

WebKnight Robots

We can deny Bots of various kinds.

Page 91: Web Application Firewall intro

WebKnight Robots.xml

Webknight aggressively attacks Bots, http://www.aqtronix.com/?PageID=114

Page 92: Web Application Firewall intro

WebKnight Robots.xml

Webknight has a Robots.xml just to configure for this effort:

Page 93: Web Application Firewall intro

Lab6(Config WebKnight)

Page 94: Web Application Firewall intro

Configuring WebKnight

Configuring WebKnight is mostly a combination of going between testing the site for desired results, looking at WebKnight’s Log Analysis to validate if the desired results match perceived results,a and using the WebKnight Configuration tool to change the results until they meet the desired outcome.

Always stop/start IIS after the changes.

WebKnight has preview settings to look at online http://www.aqtronix.com/WebKnight/Manual/WebKnight.xml

Make sure you edit the file WebKnight.xml and NOT Loaded.xml (this last one is for debugging and to see what is loaded in memory).

Page 95: Web Application Firewall intro

WebKnight

Looking back at WebKnight, the shadow.txtbox.gif appears as a shadow file and was blocked.

Page 96: Web Application Firewall intro

WebKnight

We set WebKnight to temporarily allow all files as test and Soap calls. Wait a minute for it to load as a Loaded.XML.

Page 97: Web Application Firewall intro

WebKnight

Now we can log in.

Page 98: Web Application Firewall intro

WebKnight

And SQL Injection is blocked.

Page 99: Web Application Firewall intro

WebKnight

Logging Only, instead of blocking, set the Incident Response section to “Response Log Only”.

Page 100: Web Application Firewall intro

SQL Injection

Joe Vilella will Login OK without a Username and Password.

Page 101: Web Application Firewall intro

SQL Injection

Joe Vilella will Login OK without a Username and Password.

Page 102: Web Application Firewall intro

Lab7(NetSparker)

Page 103: Web Application Firewall intro

Configuring WebKnight

Ensure that WebKnight is in Logging Only mode from the last exercise.

Ensure that Netsparker is installed, if not install it from the “My Documents” directory. It will require the .NET 3.5 framework.

Page 104: Web Application Firewall intro

Start scanning with Netsparker

Page 105: Web Application Firewall intro

If you are in Logging Only mode

If in Logging Only Mode, Netsparker will report many issues with the Hacme site.

The WebKnight logs will have many alerts in it from NetSparker attacking IIS.

Page 106: Web Application Firewall intro

Turn off the Logging Only mode

Double check by both checking the Loaded.xml and test the site for SQLInjection.

Page 107: Web Application Firewall intro

Rescan with the Logging Only mode off

Page 108: Web Application Firewall intro

The scan is cleaner

If there is time, we can go through the WebKnight.xml, change some settings, test, and continue to reconfigure WebKnight to get the optimal results.

Page 109: Web Application Firewall intro

Final Thoughts

Page 110: Web Application Firewall intro

Final Thoughts

Are there any Questions? Feel free to contact me at [email protected] Also, always only try these tools with your own

test site or with permission of the system owner.