Sunday, November 27, 2011

I Need a Project...

[Note: This post is just a brainstorm session. I apologize for the run-on sentences and possibly confusing flow, but I wanted to just pour out my ideas in the exact manner in which I think.]

I'm back from Fall break and getting ready to dive back into classes here at RIT for the Winter. I'll be taking classes in Wireless Networking, Databases, Computer Crime, and Sociology. I'm looking forward to a great quarter, but at the same time, I need a project. Not something for school, just a regular personal project. I'm still continuing to learn a lot about web application firewalls, and I'm thinking something along those lines, but maybe from a different approach. Brainstorming now:

I've been working on a number of Perl scripts for competition-based hack and defend scenarios. Scripts that lock users out, watch for un-authorized users to a system, etc. I can keep doing that, but I need a more detailed project.


I need to improve my PHP skills. I'm thinking about a vulnerable web app that teaches exploitation. That way it will help me, since I need to code the site and purposefully add vulnerabilities, and then I can secure it with a WAF when I'm done. But Damn Vulnerable Web App already exists. But it's not that detailed, only a few pages and very basic exploits. I'm thinking of something that can be more of a learning experience, something with step-by-step walkthroughs and demos of exploitable security flaws. It should also show the code/techniques necessary to protect against that vulnerability as well. I like this idea. 

I'm trying to think of other ideas, but I keep coming back to a vulnerable web app / tutorial / teaching guide. There really needs to be a good, solid guide to web application vulnerabilities that lets the user see exactly what is happening. I think I'm going to run with this. To the drawing board!

Wednesday, November 9, 2011

Mod Security Presentation

I will be giving a presentation on Friday at SPARSA (RIT's Computer Security Club). I will be talking about my experiences so far using ModSecurity and how it can be used to secure web applications. For a preview of my presentation, check out the Google Doc Presentation below:

 


Tuesday, November 1, 2011

Working with Web Vulnerabilities and Web Application Firewalls [Part 5 - Mod Security]

[Note: this is part five of a multi-part series of posts detailing my experiences with securing web applications, creating test environments for practicing and installing and operating a web application firewall. Web security is an extremely important part of IT security since almost every major organization has a "web face." I will be exploring XSS, mySQL injection, and the use of web application firewalls to protect against these attacks.]

When we last left off in the series, I was demonstrating that Damn Vulnerable Web App is actually... vulnerable. But now it's time to move on and actually detect (and stop) hacking attacks through the use of a web application firewall known as Mod Security.

Intro to Mod Security
Mod Security is essentially a firewall module that can be added to an Apache web server to help detect, filter, and even block web attacks. It uses a complex set of rules based on signatures and regular expressions to determine whether or not a particular input is malicious. Unlike a traditional firewall, which merely analyzes source/destination addresses and perhaps port numbers or services, Mod Security is able to analyze the HTTP traffic that is passing over port 80 to the web server and determine the exact payload. This is extremely important because it enables us to block attacks that are entirely web-based.

Installation
Before installing mod_security, make sure you stop your server by running:
service httpd stop

Mod Security can be downloaded from http://modsecurity.org/download however, the simplest method is to issue:

 yum install mod_security

Mod Security has a default set of rules and pattern matching techniques that it uses to detect attacks. For right now, we will be using the default rules. Hopefully in a future addition to this series I will delve more into the intricate settings to create a custom-tailored firewall. For now, I'll demonstrate Mod Security's features out-of-the-box.

Testing
Restart your Apache server:

service httpd start

And now, return to your DVWA homepage and login. For this demo, I will be attempting the same SQL injection attack that was performed in part four of this series. Watch what happens this time...

Remember from before that the attack had succeeded, returning a list of every user account in the system. From a security standpoint, it's pretty obvious that the page you see above is a much-preferred response to an attack.

The Logs
Mod Security is extremely useful because, as shown above, it blocked the attack from occurring. However, it's also great to have logs of which events were blocked. Luckily, Mod Security does that as well.

The logs are stored in /var/log/httpd/modsec_audit.log. Looking at the logs immediately after attempting our OR '1' = '1 attack, the following log is shown:


This log message reveals why our attack was stopped. The attack matched a pattern that was outlined in the mySQL injection ruleset. The log entry also details the response that Mod Security took - in this case, displaying a 403 access denied error.

More to Come!
This example only scratches the surface (and barely, at that) of what Mod Security can do. The configuration and rules can be changed and modified as needed to fit the needs of any web application. I hope to explore a lot more of the functionality behind Mod Security and perhaps write some custom rules. Stay tuned!