EC2 Micro Instance Limitations

EC2 offers a lot of advantages over many web site hosting options.  I am a bit of a control freak and like having full control over my web server.  This has advantages and disadvantages of course, meaning more work but more flexibility.  Running a WordPress blog on a micro instance can be a serious challenge.  I have fought with getting my site to have a minimum level of stability, and here are some of my notes on what helped.  Amazon offers a free EC2 micro instance for a year to new users, so it is a very attractive option for hosting a web site.

The EC2 micro instance is pretty cheap compared to the other system options that Amazon offers, but there are some caveats that may shock you after using it for a while.  There are a couple of major problems with using this option for hosting a website:

• CPU Usage restrictions: If you use 100% CPU for more than a few minutes, Amazon will “steal” CPU time from the instance, meaning that they throttle your instance.  This can last (from my observations) as long as five minutes, and then you get a few seconds of 100% again, then the restrictions are back.  This will cripple your website, making it slow, and even timing-out requests.
• Limited Memory: The instance is limited to 613MB of RAM, and does not have a swap partition.  If you run out of memory the system will panic and reboot.

If you have more than 1000 visitors or so a day, a micro instance probably isn’t worth your time.  But for many small sites (like mine) it does make sense.  I wasn’t aware of these limitations before setting up my site, and I very quickly ran into site reliability issues.  Here are a few of the things that I did to make my site more stable.

You can save a lot of money by purchasing a reserved instance for a year, but my advice is to run for a few months before making the leap.  If you find that your micro instance doesn’t cut it, you have just thrown away a chunk of cash.

So, let’s look at a few of the things you can do to make a WordPress site run reasonably well on a Micro Instance:

• Configuration:

• Tune Apache to run the correct number of threads.
• Use the minimum required memory for MySQL.
• Pre-cache your web pages.
• Use a content distribution network (CDN) such as CloudFront.
• Setup a swap partition.

• Configure alerting for CPU usage and network traffic.
• Be ready to rent a larger instance if you get a big traffic spike.

• Use a 32 bit operating system.

Continue reading »

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

C:\Users\<Your UserName Here>\AppData\Local\Google\Chrome\Application\chrome.exe --args --disable-xss-auditor --proxy-server=127.0.0.1:8081

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 »

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 »

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
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 »