Hacking in Bets

craftsmanship

Sep 9

Written By kuzushi

Security of an application/system isn’t a perfect information game. You are always playing with out a full picture of all the factors affecting the ‘security posture’ of any given system. If you were to factor in runtimes, shared libraries, server issues, human issues, code integrity, misconfigurations, design issues— there just isn’t a realistic way to identify every problem that might exist. It becomes pretty clear that the question of ‘is it secure?’ keeps many infosec professionals up at night.

As an industry we’ve accepted this is a really hard problem and try to address it by defining better more measurable activities for engagements. These tests typically look like:

Outcomes based: We want you to steal/do X
Standards based: <compliance group> says do it this way…
Adversarial based: Do what the bad guys do!
Scenario based: Build testable hypothesis and see if they are true!

These tests each have pros and cons, and while they are far more of provable in terms of activities— they don’t actually move the needle for you as a pentester. You are still time gapped and results fall on your shoulders.

When I was younger I played the game of pentesting like chess. I truly believed in perfect play strategy, where I’d model what a website was doing and plan an attack strategy that would guarantee results. I studied web architecture like it was an opening move that I could build responses to. And I practiced, a lot. This type of approach works really well for me— but it can be slow and it doesn’t always pay out right away.

Because time is the great equalizer, how you spend it has the biggest impact on results. Even with the above approach, I’ find myself questioning the momentum I was getting or if my playbook was the right one. The further you get into an engagement the harder it is to make big changes. Especially as time progresses and you don’t have the findings you want— it can be terrifying. As Annie Duke puts it in her book “Thinking in Bets” life isn’t like chess— and good decisions aren’t all that goes into winning. Probability matters. Life is more like poker and, whether you like it or not, you are betting with your time on engagements.

So how do you increase your odds?

As it turns out, time management has been one the best thing I have ever learned as a pentester. Having a great workflow lets you place more bets in an engagement. The quicker you can move through 'whatever your process is’ you can place bigger bets. And you will feel more comfortable doing so too. We can get into OODA loops and agile testing methods later— but lets face it, you more likely to take bigger risks with time when you already have some strong findings in the beginning.

Perhaps just as important as time management, you have to prioritize. If you investigate bug bounty programs as a source of data, I pulled 319 of the most recent (rated) submissions and found a near 50/50 split between low and medium risk findings against high and critical risk ones. There were almost as many low risk findings as there were critical ones. Now, this data isn’t statistically significant nor doesn’t hold up for a variety of reasons as there is a lot of data unavailable in terms of risk rating, it doesn’t account for submissions that are rejected, people are highly motivated/compensated for higher risk findings, etc.… but it is interesting.

Have you ever considered that maybe the frequency of what you find is based on what you are good at? If the above is any indication of reality, you have almost the same chance of finding higher risk issues just as much as you do lower risk ones. So why aren’t you? IME this is where understanding technology really helps. If you waste half an engagement getting a graphql query to work, that only hurts you. I mean, at the very least, isn’t that also an argument for leveraging tooling/automation that you trust to take care of lower risk findings for you so you don’t take up much of your precious time? If you give each vulnerability the same amount of time during a test, it is you who suffers.

Finally, regardless of risk rating, not all findings provide YOU the same amount of utility. If you prioritize things that make the remainder of an engagement easier, you start to stack the game in your favor. Finding SQL injection is a whole lot easier if you have source code. It is far easier to find a vulnerable upload if you already have a privileged account. Each of those exploits makes you far more likely to find both more issues and perhaps even more critical ones. You might not know what would come next in a draw, but that doesn’t mean the ability to see your opponent’s cards wouldn’t make the game much easier.

Hacking in Bets

Nothing will work unless you do

Professional Rule Breaking