The first time I used Chrome during a web application security review I had a rather unpleasant surprise.  I had audited applications from the same developers before and found countless XSS errors.  This time it looked like they had fixed all those problems!  Little did I know that Chrome was actually performing filtering for reflected XSS attacks, and it wasn’t the developers.  I almost got bitten hard by missing a lot of vulnerabilities and afterwards I just avoided Chrome completely for any type of testing.  I also rely very heavily on a few FireFox plugins: Firebug, Web Developer, and Tamperdata are just a few examples, but in Chrome’s early days there just weren’t a lot of plugins.

There were other plugins missing from Chrome that I don’t use for security testing, but I use for everyday web surfing.  There are a few absolutely necessary plugins for performing any sort of general browsing:  NoScript and Ad Block Plus.  I heavily rely on these in Firefox.

It’s been a few years and I guess it’s time to have another look.

General Settings:

  • The first problem to tackle is the Cross Site Scripting Auditor.  Fortunately there is a command line flag that disables the functionality: –disable-xss-auditor.  Simple enough.
  • The next problem is that Chrome uses the system proxy settings (in both Windows and Mac OS) which can be problematic for me (sometimes I will have several browsers running at the same time–I don’t use the same browser for testing and general surfing, mostly because it can create a lot of noise in an intercepting proxy.)  There is a command line switch for this too: –proxy-server=host:port
These can be used on Windows by modifying a shortcut that executes Chrome with these options set:
C:\Users\<Your UserName Here>\AppData\Local\Google\Chrome\Application\chrome.exe --args --disable-xss-auditor --proxy-server=127.0.0.1:8081
For Example:
On Mac OS I just use a shell script to kill the running browser, and re-execute with my options.  For example . . .

I put together a list of resources for practicing and learning web security assessment techniques.  The list is far from complete, but has a few resources that I have found useful for improving my web app assessment skills.

webseclab
http://www.webseclab.com/

Webseclab is without a doubt the best platform out there for learning recent web attacks; it covers client-side attacks and AJAX: an area many other practice tools miss.  It is designed to be used in an instructor-led environment (Stanford U,) and since you can’t download a professor you will have to figure out what the lesson was on your own—the instructions are pretty sparse.  Here are some of the topics covered: Continue reading »

In my last post I showed how to use Selenium to make complex brute force attacks easier.  I showed a very basic and quick example against my website.  Here is an even shorter post on how to mitigate the attack using the mod_security Apache module.  I won’t cover how to install it or configure it, but just show the rules I am using to detect and respond to a similar brute force attack.  It works reasonably well, although I must admit I haven’t done extensive testing with these rules.

I don’t want to be blocked forever just in case I did something dumb, so I setup the rules to only blacklist a particular IP address for only five minutes.  You can definitely play with the timing and number of failed login attempts required to trigger the filter.  The way it is setup, it will block an IP address from accessing only the login page (the rest of the site is still available) if that IP address fails 15 times in three minutes.  The block lasts for five minutes, and is then reset.

Before showing you the rules a brief explanation is in order.  Mod_security allows rules to work off of persistent storage.  There are a defined number of collections, and within them you can set a variable and a value.  There are a few features that allow you to either deprecate the count of a numeric variable over time, or to expire it completely after a specified timeframe.  Unfortunately, these variables work in an unexpected way.  I initially setup my rules to set a block variable (IP.bf_blocked) in the IP collection once a certain threshold had been reached, and the variable was set to expire in 5 minutes.  Every time I accessed the site after triggering the rule, I was still blocked.  I kept asking why aren’t my modsecurity expirevar values being honored?  Frustrating!

So after furious searching and trying to figure out what was happening, I finally found a post here that explains the problem . . . “The reason for this is how ModSecurity handles expiry timers for variables. Basically, every time a collection is updated, the LAST_UPDATE_TIME timestamp for that collection gets set to the current time. Since we increment the request_count variable for every request, this will monotonically increase.”

Okay, that makes sense.  The examples they provide are pretty good, but there are a couple of errors in the rules that mean they don’t work right.  Anyways, based on that information and some testing here is what I came up with for the wordpress login page: Continue reading »

There is a uptick in brute force attacks as related to web applications.  The Web Hacking Incident Database keeps track of many attacks, and compiles the results; they show that insufficient anti-automation (which includes DoS attacks, but I won’t be covering that today) are the number one cause of web site incidents.

Using brute force methods are an old standby, and many of the attack proxies offer fantastic brute force abilities.  But I always find myself wanting more control, the ability to tweak things, and more intelligent functionality.  Unfortunately most of these apps are pretty rigid in the actions they can perform–if the developer didn’t think of what you want to do you are out of luck.  In these cases it isn’t so uncommon to find myself writing code in PERL, shell, PHP, Javascript, and whatever else I find I need to pull off a specific test case.

Some web apps are really complex, or occasionally someone even develops an application with good session management designed to resist attack.  I recently came across an application that did just this.  The login page invalidated the user’s session, and deleted the cookies each time the page was loaded (assuming a login failure.)  In addition to this, it had CSRF protections in place, so the form had nonce values, which were tied to the session (no reuse.)  If the session and nonce weren’t validated the application threw a security warning and didn’t process the attempted login.  Performing a successful brute force attack against this setup poses a few challenges.  And neither ZAP nor Burpsuite were meeting my needs (still love em though.)

This is where Selenium comes in very useful.  Selenium is a test framework, mostly used by developers and QA test folks.  It has very good potential for pen-testing too.  It is designed so that you can create a customized brute force attack script in just minutes, that would have otherwise taken hours to accomplish.  It runs it through a full featured web browser (usually FireFox, but has other hooks too) so that stuff like tracking application state, nonces, sessions, properly setting referrers and the myriad other crazy dependencies that can arise in a complex web application are handled seamlessly.  Basically it allows you to automate a web browser.

I’ll give a quick demo on BackTrack Linux (Ubuntu based.)  Here is the overview: Continue reading »

Tonight (Thursday) a group of folks that were at Blackhat together are presenting summaries of various presentations and tools that were released at the conference for the Rocky Mountain Cisco Users Group.  I am presenting on the tool that Sensepost released, called reDuh and here are my slides.