Selenium for Web App Pentesting

 Security, Web Security
Jul 232011

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 »

Posted by tag on July 23, 2011

DNSSEC Continued . . . Windows 2008R2 as Primary

 Network Security, Security
Jul 052011

I’ll be honest, I’m not a big fan of the Windows DNS service.  There are cases where an organization might want to use the Windows DNS service as a primary for their Internet facing zones.  I wanted to see how DNSSEC was setup on Windows and if Bind 9 could slave off of it.  Turns out it works fine.  This is the second of two posts on DNSSEC, the first post can be viewed here and dealt with setting up a Bind 9 primary server with DNSSEC.

Most of what I did here is documented in the Microsoft DNSSEC guide.  It’s really long and it took a lot of reading to figure out what really needed to be done. (tl;dr)  It’s a good idea to have this document handy if you are working on this.  Broken down, the process is roughly the same as Bind 9.

  • Build your zone files.
  • Create a KSK, and ZSK.
  • Sign the zone file.
  • Reconfigure DNS server to use the signed file.
  • Slave your other servers.
  • Send DS key to registrar
  • Test.

The Windows DNSSEC implementation has a few differences from Bind, first you can’t sign dynamic DNS zones (Bind can.)  Otherwise it works almost the same, as long as you are willing to hand-edit the zone files (they are pretty much the same format as Bind, so if you know that it is dead simple.)  I am not going to cover the maintenance of DNSSEC zones on Windows, basically the process is edit your source zone, increment the serial number, re-sign, and tell the service to reload the zone configuration.  Easy enough.

Here’s the zone I’ll be working with . . .

First step is to create your Key Signing Key: Continue reading »

Posted by tag on July 5, 2011

The GPU Killed the Password.

 Forensics, Security
Jul 032011

About once a year I take the time to read up on the latest in password cracking techniques, try them out, and decide if anything really warrants a change in my behavior.  Well things have definitely heated up over the last couple of years.

Rainbow tables were the last big thing in password attacks.  It’s a really interesting concept that trades time for storage.  As you would expect, these things get really big, especially when you start talking about eight or more characters.  Add in any level of complexity and you can see astronomical sizes, for example the NTLM tables for characters 1-8 including both upper and lower case, and numbers is 453gb.  That’s almost double the limit for inbound data that Comcast allows in a month for their residential customers.  Not only that, it would probably take about a month to download.

Still, it’s a neat hack, and since searching a rainbow table is super fast it will still be relevant for a long time.  But something else has changed.

Enter the GPU.  Graphics processors are designed in a significantly different fashion than a CPU.  They can do a small set of very specific computational tasks extremely efficiently.  If the task you have CAN be run on a GPU it will probably be significantly faster than if done on a normal CPU.

Let’s take for instance my humble test system.  The CPU isn’t awful, but isn’t very speedy either.  It’s an Intel Quad-core Q8200 2.33ghz which is rated at 37.28 GigaFlops.  It was low-mid range range a few years ago and I recently put one of the lower end graphics cards in it.  When I was shopping for a new card my only real requirement was to have a displayport connector so I could use my iMac as a monitor and not have to run Backtrack in a VM.  I bought the cheapest card I could find with displayport, at the time a Radeon 5570.  Yes, it’s ONLY a $65 graphics card.  But, it’s capable of 520 GigaFLOPS (there are 400 processors on there.)  Continue reading »

Posted by tag on July 3, 2011

DNSSEC on Bind 9.7

 Network Security, Security
Jun 302011

I have been reading about DNSSEC and decided to do some quick testing.

One of the questions I had was, what happens with slave nameservers?  How does DNSSEC work with a slave?  Does it need copies of keys?  If my hosting provider is slaved off of me, and running Bind 9.x what extra steps need to be taken to enable DNSSEC.  Well the answer to that turned out to be really simple.  The slave servers don’t work any different than normal–all of the signing and key management is inside the zone file.

Setting up the signed zones isn’t really as hard as you might expect.  There are a few concepts you have to understand:

  • DNSSEC relies on a chain of trust based on public key cryptography.
  • It uses encryption for validation, not privacy.
  • You will most likely use a couple of public/private keys, one for signing keys, and one for signing zones.
  • The parent zone must have information about your key signing key, this is done with a DS resource record, it’s just a hash of the key signing public key in a DNS record.
  • Why two keys?  By using a key signing key and zone signing key, you can rotate the key used for signing the zone without having to notify your parent zone.

So setting it up goes something like this: Continue reading »

Posted by tag on June 30, 2011

iPad Forensics and Data Theft

 Apple, Forensics, Security
May 042011

I recently had an opportunity to do some testing on the iPad, I wanted to evaluate the methods for performing forensics and the ability for someone to recover data off of the device.  Apple’s security implementation on the iOS platform is pretty abysmal.  In this post I will talk a little about the iOS platform and go over some of the techniques I used to pull data off the device.  I have a few more tricks that aren’t mentioned here, and hopefully I will get a chance to type those up in the near future.

All of this information is available out there somewhere, but I didn’t find a nice complete guide of how to get at the data without permanently jailbreaking the device.  None of this is original research, and I don’t have any association with any of the software developers and hackers that built these tools.

The premise is that when performing forensics you should modify the device as minimally as possible.  This isn’t always possible, but with iOS it is particularly difficult because accessing the data requires a jailbroken kernel and a few *nix utilities.  The most common approach (at least when doing an acquisition in the field) is to use a boot disk, load an operating system into RAM and then perform the data capture.

Before getting into the details, and they are not for someone that is not technically inclined, I want to talk a little about iOS.

Some common misconceptions about iOS (iPhone and iPad):

It isn’t a PC.

  • Well, it sort of isn’t, it’s a Mac, but aside from marketing distinctions it most certainly is a Unix computer–just with a interface that doesn’t allow you to do anything other than what you are told.
  • According to Apple’s sales numbers, people like having a limited user interface and no control over the computer they are using.
  • This leads to a assumption that the device is simple–it is not.
  • It’s Darwin, essentially a trimmed down version of Mac OS X with Springboard instead of Finder.
  • Once you load up some tools, you can do most things that any other Unix system can do.

Data isn’t stored on the device, everything is in the “cloud” or stored elsewhere.

  • No, it has a hard drive (solid state.)
  • Most applications cache everything you view, you have no control over this, once again the decisions have been made for you.
  • It tracks your location (this recently made the news.)
  • It has to keep a log of what you type to make predictive typing work.  Yes, it logs what you type.

It’s encrypted, your data is safe.

  • Technically it is encrypted, but Apple did such a poor job of implementing the key management, the encryption is rendered completely useless.
  • There IS a second layer of encryption that is new in the 4.x releases of iOS, so far it only applies to mail.app.
  • Calendars ARE NOT encrypted–how much email is embedded in calendar requests in a corporate environment?  You might be surprised.
  • Unless you can decrypt the keychain, you can’t get access to these files (in theory this can be done, but who knows if the videos posted to youtube are real.)
  • Only applies if 4.x was installed from scratch. Upgraded your iPad/iPhone from 3.x? Your data is still plaintext.

That said, Apple actually got something right: remote wipe works like a champ.  As long as your device is turned on, and on a network, you might be able to stop someone from stealing information off of it.

Tools I found useful: Continue reading »

Posted by tag on May 4, 2011
 Older Entries  Newer Entries