Page 181 - Hands-On Bug Hunting for Penetration Testers

Formatting Your Report Chapter 10

Writing a bounty that will get you the proper restitution for the bug's severity requires that
you can get the security team vetting your submission to reproduce your attack, but
alsobjust as, if not more importantlybyou need to write a compelling attack scenario. To
write a compelling attack scenario, you need a few things:

Specificity: Your attack scenario should have specific varieties of bugs and
exploits in mind and, if at all possible, mention a specific piece that's opposed to
its type (username and not BVUI databunless that is the best description for the
multiple pieces of information you've gathered). Always name an application's
version, include any metadata you have access to, and so on.
Realistic severity: Your vulnerability might not crash every hosting region, or
cripple the company's infrastructure, but it will impose a serious set of risks for
employees, customers, investors, and anyone else caught in the crossfire of an
exploitation. You should be able to define an attack scenario that's realistic (it
can't take crazy resources, or unlimited time), but should lead to unacceptable
data loss, data theft, performance degradation, or a loss in basic functionality, as
these are all clear crises.
Proper terminology: Using the correct jargon (technical terms, acronyms,
applicable metaphors) assures the security team vetting your submission that
your attack scenario is credible because you are credible. You don't want to
bungle a submission reward because you describe what might be a legitimate
find in awkward, confusing, or misleading ways. Being able to leverage common
terms such as Remote Code Execution (RCE)and PoC is essential.
Documentation: This is the report! (Right?) The other sections are related
considerations, but the more you can attach about the scenario itself, the better.
This could mean a screenshot, file, or artifact created as a side effect of the
discovery, or even data along-the-way-but-still-short of an active exploitation
path, proving, for example, that you can print out sensitive cookie information
without actually exfiltrating or abusing the information.

Keeping these principles in mind, let's look at an example of a poorly written
report and contrast it with a stronger attempt, assuming that we're submitting a
report on the same vulnerability we discussed earlierbpersistent XSS, discovered
in the comments section of a popular online forum.

[ 166 ]