Need help pen testing a web app? Ask the client!

 Wait! Isn’t the client paying you to test the app? Should you really be asking them for help?

Absolutely! Clients want the best value for their money.  If you don’t talk to them about their web app you’re testing, I’d hazard to say you’re cheating them.

One of my recent engagements has been performing penetration tests on a large web application with multiple servers.  When it boils down to it, it is really multiple web applications that interact with the same back-end database.   The penetration test is supposed to be a white-box test, and we have the web application source code to review for obvious coding errors (though this isn’t strictly a code review type of test).  We are testing the application before it goes into production, so initially there was no data on the system.

As I started looking at the application, I realized how complicated it is.  There are literally hundreds of forms and some of their purposes aren’t immediately clear.  Further, the relationship between the forms definitely isn’t obvious.  The hacker in me wants to figure it all out, but I have to put my inner-hacker on hold to get the best value for the client.  I called up to get some training from the client on the system.

Training? I don’t need no stinking training!

Um, yes you do.  Unless you know how all the forms and data are supposed to interact, you absolutely need training.  A good tool like Burp Suite can help you find all sorts of web site flaws, but it won’t check for constraints set by the developer. For instance, in a recent web application we tested loan officer supervisors could only view applications explicitly assigned to them by someone in an auditor role.  In an application we reviewed last year, everyone in the supervisor role could review all records. If I hadn’t have had training on the specifics of this application, we would have missed a fairly critical logic flaw.

Valid user accounts

When performing a penetration test, I like to make sure I have two sets of valid user credentials and one set of admin credentials.  The logic here is that I want to be able to test the ability to migrate from one authorized user account to the other without supplying the second user’s password.  This is a common flaw.  Another common security issue found is the ability to add administrator (or other) permissions to an already authorized session.  Sure, it’s possible that you could brute force your way into these systems, but what if that fails? You’ll have failed to test for a common security flaw.  Just asking the client for these accounts up front ensures they get maximum coverage for their money.

Parting thoughts

Clearly, there’s a lot more to web app penetration testing than this.  I haven’t even touched on the hard stuff yet (like finding XSS, CSRF, or SQLi), but before you can find that effectively, you need access to the entire website under test.  You’ll also need to understand how the web application works (or is supposed to).  Which leads me full circle back to my original statement: when in doubt, just ask the client.

FOR610 + NetWars = Mucho Malware Goodness

NOTE: I'm leaving this post here for posterity's sake, but this post is an archive.  I originally used it to announce the move to a 6 day format for SANS FOR610.  However,I still think it has value in highlighting the rationale behind the CTF format for day 6.

Original post follows:
I wanted to take this time to a make a formal announcement that FOR610 (SANS Malware Reverse Engineering) is moving to a six day format.  Why six days you ask?  Well, most of our other long classes are six days rather than five.  Most of our six day courses have a final day that involves some sort of capture the flag (CTF) challenge.  Who doesn't like a good CTF?  Yeah, that's what I thought...

A kinder, gentler, CTF

If the thought of a DEFCON style CTF immediately turns you off, fear not. That's not (exactly) what we're doing.  We'll encourage proper hygiene at our CTF, we'll keep the lights on, and we'll keep the music below a dull roar.  Now if you want to geek out for ~6 hours on malware and rock the house without so much as a bio break, then we won't complain, just don't disturb your neighboring teams.  There will be prizes just like the DEFCON CTF (well, not an uber badge).  If your team wins the challenge, you'll score a highly coveted Lethal Forensicator coin.

Why do a CTF at all? I want more material!

Technically, this is more material.  It's more hands-on labs to cut your teeth on. But permit me to share a story with you.  Many years ago, I took a SEC709 with Steve Sims (Exploit Development).  I showed up ready for six days of exploit development goodness. Then I got to the class and found that it was five days of learning and a day 6 CTF.  I was seriously miffed.  I even copped a bad attitude about it the first day. I got over it, but when day 6 rolled around I thought about taking the day to explore San Diego instead of doing some 'silly CTF.'  You see, I knew all this stuff and had nothing to prove (and nothing to learn) by doing the CTF.

I was punked into showing up at the CTF by a coworker.  This particular CTF was a solo event. The FOR610 CTF will be a team event, unless you are just an uber reverse engineer who doesn't need a team.  But I didn't need a team, I was going to blow this out of the water before lunch and still have the rest of the day to explore San Diego.

I needed a team....

Here's the magic of a CTF. It forced me to (quickly) come to terms with the fact that I didn't have this stuff quite as nailed as I thought.  I ran through all the labs in record time.  I don't think I cheated on any of the challenges, I didn't usually "read ahead" to the step by step answers in the labs.  In the few cases where I did, I made sure to learn the actual material.  But when the CTF started, I quickly discovered I didn't quite get it.  I swallowed my pride and spent the day hammering through the CTF (even skipping lunch).  By the end of the day, I actually tied for first place in my class of 16.  I was excited to have been a contender, but more importantly I burned more into my brain on day 6 than the first 5 days combined.  CTF forces you to demonstrate that you get it.  I've never analyzed malware that came with a lab guide. Basically, I don't want your first malware reversing experience to be on the job (that's not good for anyone).

What does the CTF look like?

The CTF runs on the popular NetWars scoring platform.  Those who have played NetWars at a SANS conference know how awesome the platform is.  I'd like to offer a plug to Ed Skoudis and Yori Kvitchko for their work on the platform.  They made my job much easier, allowing me to concentrate on the malware and not the scoring server.

We'll have challenges covering the skills we teach in FOR610, including:

• Behavioral analysis 
• Dynamic analysis (OllyDbg)
• Code analysis (IDA/OllyDbg)
• Malicious office documents
• Malicious PDFs
• Malicious Javascript
• Memory Analysis

If you've never played NetWars before (or you want to see it with MOAR MALWARE) you can watch the webcast used to promote the CTF.  Building a CTF for malware RE that uses automated scoring was challenging.  I demoed the types of challenges you can expect to see and even walked through some RE challenges live.  I'll spare all the details of the webcast assuming that if you want to know them, you'll just watch it (I've rambled enough here already).