Using Google Chrome for Security Testing

 Security, Web Security
Nov 012011

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 . . .
Posted by tag on November 1, 2011

Firewire Attacks Against Mac OS Lion FileVault 2 Encryption

 Apple, Forensics, Security
Sep 182011

There is some question about the extent to which Lion and FileVault is vulnerable to Firewire DMA attacks.  I performed some research (full paper is available below) and can present the following results:

Retrieving plain text passwords from RAM on Mac OS Lion (10.7) can be done under most circumstances where the system is using the default configuration.  But, I want to point out that this definitely isn’t a fatal flaw in FileVault 2′s design and that it is quite easy to mitigate against these attacks.  Unfortunately, Lion is not “secure by default”.

Here is a quick summary of what states are susceptible to the attack:


For a more-depth discussion of why, please see the paper (at the bottom of this post.)

Stopping the Attack

Protecting against the attack is pretty simple (assuming that FV2 is turned on,) requiring three configuration settings to be modified (Fast User Switching, and a couple of sleep options.) This will protect the system as long as it isn’t running and unlocked (in which case it is insecure anyway,) and if you haven’t logged out and left the system running (I don’t have any suggestions on that one.)  Here is how . . .

Continue reading »

Posted by tag on September 18, 2011

Cracking Mac OS Lion Passwords

 Apple, Forensics, Security
Sep 052011

Update Nov. 4, 2011: John’s jumbo version now has support for cracking these hashes too.  (Thanks solardiz for pointing this out!)

Update Sept. 7, 2011: There is a better way to get at the hashes, have a look at the “davegrohl” tool (here is a locally mirrored copy of version 1.0).  I’ll leave this post up since the explanation of how this works is still relevant.

With the latest release of MacOS version 10.7, there are a lot of changes and the way that password hashes are stored are no exception.  Dave Dribin provided a fantastic evaluation of how passwords were stored in previous versions of the OS, and I won’t duplicate his work.  With Lion, Apple decided to switch to using 4-byte salted SHA2 hashes with 512 bits.  It’s a significant upgrade to how the hashes are stored, but still quite a ways short of the Linux implementation in crypt(3).  More about that later.

Apple doesn’t make grabbing the hashes an intuitive process (I won’t say it isn’t easy, because it IS repeatable, and computers make repeatable processes easy.)  So how are they stored?

In the “/var/db/dslocal/nodes/Default/users/” directory, which is only available to the root user, there are a number of “plist” files.  That’s where the hashes are stored.  But it isn’t so simple.  Extracting the hashes requires a bit of massaging.  Let’s go through the process for an example user, with the login name of “test”.

If you weren’t already aware, there are several different valid plist file formats.  The two we are concerned with are binary and xml.  The plist file holding our hashes is in binary format and needs to be converted:

bash-3.2# file /var/db/dslocal/nodes/Default/users/test.plist
 /var/db/dslocal/nodes/Default/users/test.plist: Apple binary property list
 bash-3.2# cp /var/db/dslocal/nodes/Default/users/test.plist .
 bash-3.2# plutil -convert xml1 test.plist

Inside of that file, there is a key called ShadowHashData, which contains a text string. For example: Continue reading »

Posted by tag on September 5, 2011

Resources for Learning Web Application Security

 Security, Web Security
Aug 092011

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 »

Posted by tag on August 9, 2011

Stopping Brute-force Logins Against WordPress

 Security, Web Security
Jul 292011

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 »

Posted by tag on July 29, 2011
 Older Entries