Write down the attack scenario

Attack scenario is essentially a brief summary of who may want to exploit a particular vulnerability, for what gain, and in what way. The goal isn't to simply go over the reproduction steps for the bug itself, but rather, to think about the way the entire exploitation process would play out.

For some vulnerabilities, such as an XSS bug on www.google.com, the attack venues and the risk are pretty clear. But when reporting more esoteric and complex problems, it helps us to have a good analysis of this sort. For example, at some point, we have gotten reports about our implementation of SAML being non-compliant with a particular aspect of the 300-page specification for the protocol; we had to scratch our heads for a longer while to figure out the implications of that report!

Sometimes writing an attack scenario helps you discover that a particular issue has less impact than initially thought, perhaps because the attacker would need to start at the privilege level where nothing new is gained by leveraging the bug. The opposite can also be true: even the most seasoned security researchers sometimes realize that the bug they found is more serious than it seemed as soon as they try to write it all down.

To illustrate, consider the following reproduction steps:

Hi Google!

I found a vulnerability in all Chrome extensions. Steps to reproduce:

1. Install any Chrome extension,
2. Get the ID of the extension from the page at c
3. Go to ~/.config/google-chrome/Default/Extensions/{ID here},
4. Find a JavaScript file containing the code of the extension,
5. Backdoor the extension with the following script: [...]
The extension can now exploit arbitrary pages and e.g. extract your Gmail messages to get your passwords from third-party pages.

Trying to write up an attack scenario quickly reveals a flaw with the report:

Attack scenario

1. Attacker gets the access to the victim's computer, being logged as the targeted user.
2. Attacker runs these commands to gain access to...

Of course, if the attacker is in that starting position, they could just install malware on the machine. Backdooring an extension is also a possibility - but one that is not particularly interesting or unique.

Here are some tips for writing great attack scenarios:

  1. Think about the starting position the attacker is in. What do they already have access to, and what is still beyond their reach?

  2. Articulate the assumptions about the victim. For example, do they need to be particularly gullible? If so, does your attack make them substantially more vulnerable, or are they doomed either way?

  3. Think about any other prerequisites for the attack and their broader ramifications. For example, if the attack depends on outdated software, how does it compare to exploiting known security bugs in the outdated program?

  4. Write down what the attacker and the victim must do, step by step and in the right order. This is particularly important if there are multiple parties or accounts involved.

  5. Always re-read the summary and make sure that it's easy to follow :-)

Finding coding flaws is fun, but being able to think about and clearly articulate complex attack scenarios is what really makes a successful bug hunter - so any time invested in writing down attack scenarios will probably pay off in the long haul. Many of us come from the security research background and can attest to that :-)