« Patching and Hooking Students (Part 2) | Main | Crypto AppSec Issues »

Patching and Hooking Students (Part 1)

The semester has to start off with a bang. Students need to know why they are there, what they are going to learn, and be pumped about it. Somewhere in between I need to sneak in some ideas that will grow over the course of the semester.

Taking inspiration from recently released details about the Heartland data breach, I decided to simulate a fairly sophisticated attack against a public facing website and introduce them to threat modeling while I was at it.

Introducing, our target, Beta Two Labs, an uberl33t haxxor space located in Brooklyn Heights.

It's always more interesting when you have a fun target :-).

The scenario:

Beta Two Labs is using their website to organize an upcoming party at their hackerspace. You have been hired to disrupt the planning of this party and to infiltrate their organization. What do you do?

The attack surface here is extremely wide and you can accomplish your goals with a variety of techniques physical, client-side, or server-side. I let them think it out for a few minutes, and then I presented my own view of this challenge.

Step 1: Fingerprint and enumerate their web presence

Like most "hackerspaces", Beta Two Labs is running Wordpress which is absolutely riddled with bugs. It's also well known that Wordpress leaks its version information in "generator" meta tags hidden through its pages. This is too easy, so I hid the generator tag with wp-security-scan. There are lots of better ways to detect the version, like comparing diffs of different published versions for modified functionality or files. To make things simple, I left the readme.html file in the webroot:

I wasn't counting on anyone in the class dropping WP 0day, so I assumed this would be a dead end for them. Auditing the Wordpress codebase is a pain in the ass anyway, I kept an easier route open.

Wordpress plugins are installed at a predictable URI path. If we poll for a few of the top plugins, we should be able to identify which ones they have installed. Even simpler, if we're smart, we can figure out they have wp-security-scan installed from the lack of a generator tag. Code quality in plugins is probably going to be much less than in wp-core.

It turns out that wp-security-scan is a fairly complicated plugin and the potential for some good bugs is there. Again, I made things easy and injected a remote file include vulnerability into it, so that we could assume we would find a bug eventually and to demonstrate that security technologies themselves can generate huge exposures if you're not careful (which should be a recurring theme in this course).

To be continued in Part 2...

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.