When is a hack not a hack?

We all get raises at the same time of year. The buzz is big around the time it happens… whispers of flat 2% or 1% across the board, rumors that “we’re all getting screwed”… you know, standard stuff. They are entered into our payroll software before they’re communicated to us, but we don’t have access, and there’s always a 7-10 day period between the decision and the communication. What, do we have to wait until we get the check to see what it’s going to be?

Well, in fact, no we don’t.

I found what I would like to call a “soft hack”… no injection or script-insertion, no session hijacking or privilege escalation. I didn’t even need a proxy to manipulate the parameters. I just poked around the site that stores our benefits information. See, the benefits information interfaces with the payroll information, which means the numbers I need are already in there. I know that because I’m a manager and I already saw my employees’ increases, but comp numbers are hidden from individuals. So mine is in there somewhere… somewhere.

I look at withholding - if I see how much they’re taking out of the check for taxes of social security, I’m home free. I can do that kind of math. No luck–that’s hidden too. Medical insurance? No luck–it’s a flat rate. Flex spending? Nope–another flat rate.

401(k) contributions? That would do it, right? If I’m withholding 6% and they print the dollar amount, the amount will represent 6% of the new number, right? Of course not–they just print the percentage.

Finally I look at our Life Insurance coverage amounts. My company is awesome–just for working here we get automatic life insurance, gratis, equal to TWO TIMES OUR ANNUAL SALARY.

So, the number listed there–I divide it in half, and there it is, my new salary. Thanks, boss!

Because I’m a software tester first and foremost, I want to verify my methodology: I’m able to look at my benefits “as of” arbitrary dates, so I set the date back a month or so, divided the life insurance in half, and boom… the old salary. We have a soft hack.

And that’s what worries me: even when they don’t give you the information, they give you the information. The thing about this hack, in light of my recent acquisition of the web app penetration testing unit, is that no tool, not AppScan or WebInspect, not burp suite or paros or httprint or nessus or nikto or IEWatch HTTPWatch. What is my AUT trying to tell the world, that I don’t want to tell them? Some little nugget sitting out there in plain site, waiting for the right person to come along and do some second-grade math?

It looks like the best security testing tool you possess is your own mad desire to get the data. Conjuring this motivation is difficult: I’m definitely more interested in my new paycheck numbers than I am in whether some theoretical user can escalate his permissions to perform admin tasks. It’s almost like I need to have a Stanislavski moment before I start this hack-testing: imagine I’m sitting in a dark room somewhere, logged into the target site using “rsmith/password”, and I’m not about to let rsmith’s meager permissions get in my way. I know that information is on that server, and they’ve opened up port 80 for me to get to it. There’s only a thin layer of imperfection sitting between me and the database. It’s only a matter of time.

Should I coin a new term? “Method testing”? Those words are all over these Internets, but they mean something quite different from what I’m spelling out here.

You heard it here first.

Tags: appscan, hacking, pen testing, penetration testing, security testing, web app security, webinspect