Writing Vuln Submissions that Maximize Your Payouts - presentation given at Nullcon 2016 by Bugcrowd's Kymberlee Price. Learn more about Bugcrowd here: https://bugcrowd.com/join-the-crowd

1. Crowdsourced Cybersecurity
Writing Vuln Submissions that Maximize Your Payouts
Kymberlee Price
Senior Director of Researcher Operations

2. 2
whoami
• Senior Director of a Red Team
• PSIRT Case Manager
• Data Analyst
• Internet Crime Investigator
• Behavioral Psychologist
• Lawful Good
@kym_possible

3. 3
Out of Scope earns no $$
Step 1: Read The Bounty Brief
h"ps://blog.bugcrowd.com/pro2p-­‐read-­‐the-­‐bounty-­‐brief/
h"ps://blog.bugcrowd.com/public-­‐disclosure-­‐policy-­‐2016
h"ps://forum.bugcrowd.com/t/in-­‐scope-­‐and-­‐public-­‐disclosure/933

4. 4
Step 2: Understand the Impact
Knowing what kind of vulnerability
you’ve found is important.
Communicating the Impact of that
Vulnerability in your submission is even
more important.
Impact is what drives severity and
prioritization decisions.
Severity is what determines how much
you get paid out.
STRIDE Model
Spoofing
Tampering
Repudiation
Information Disclosure
DoS
Elevation of Privilege
h"ps://forum.bugcrowd.com/t/wri2ng-­‐a-­‐bug-­‐report-­‐a"ack-­‐scenario-­‐and-­‐impact-­‐are-­‐key/640

5. 5
Example: Why Impact > Vuln Type
Submission:
Create a $APPLICATION account.
go to dashboard and click on $FUNCTIONALITY
Enter all the details.
There is a parameter called $NAME at the end of $FUNCTIONALITY
Enter the javascript payload and you can see the popup.
This is a valid XSS vulnerability that results in elevation of privilege, but is very low
priority to fix. Why?
The attacker has to social engineer the victim to install code, this requires significant
victim interaction and is not remotely exploitable.
Once the cookie is stolen the attacker can only exploit that one victim; the attacker
has to exploit each victim individually. The vulnerability does not affect multiple
users or the system integrity.

6. 6
Step 3: POC|GTFO
Getting a scan result isn’t enough
Finding an out of date library with known CVEs isn’t enough
You have to validate that the application is actually exploitable. BUT BE CAREFUL
– don’t take down an app or pivot to compromise data. If you ever question “should
I try to exploit this” submit the bug without POC and ask.
Share POC videos and code samples SECURELY. (i.e. Don’t Use YouTube)
Explain the Attack Scenario:
• Attacker does X
• Victim does Y (where Y may be “nothing”)
• Attacker can now do Z

7. 7
Scenario 1: The reproduction steps and attack scenario are incomplete and unclear.
Mistakes I’ve Seen
Submitted:
An attacker creates a fake account and changes his e-mail. The e-mail
confirmation link can now be used to login someone into the fake account and
then then monitor actions performed by the victim or even interact with him.
Let's break down why that is going to get rejected as invalid:
o An attacker creates a fake account <-- what kind of account? user? do they
need to be an admin to do this?
o and changes his e-mail. <-- changes it to what? the victim's email?
o The e-mail confirmation link can now be used <-- by whom?
o to login someone <-- the victim?
o into the fake account <-- why would the victim do this?
o and then then monitor actions performed by the victim or even interact with
him. <-- so they can view the victim's actions? can they access the victim's
account settings without victim interaction?

8. 8
Scenario 2: The submission requires another vulnerability to be exploited first
Mistakes I’ve Seen
If a submission starts with
"Suppose I am an attacker and (the user's browser is compromised/I got access
to the recovery email option of your $APPLICATION account)”
Everything that comes next is not exploitable on its own and requires a second
theoretical vulnerability in the application. While in some cases the report may
recommend a legitimate security best practice, in most cases those are
unrewardable in bounty programs.

9. 9
Scenario 3: the exploit impact is unclear.
Mistakes I’ve Seen
Submitted:
An attacker is just required to send an email confirmation link to the victim & he'll
be automatically logged into his (attacker's) account. I can then monitor his
actions & interact
Ok, this means that the attacker has just compromised themselves by giving the
"victim" access to the attacker's account. The victim account is not in any way
compromised, unless the attacker manages to elaborately social engineer the victim
to give up their credentials to the attacker once logged into the attacker account.
But if I can get you to click an email link, that isn't a web application vulnerability the
customer can patch.

10. 10
Scenario 4: not a vulnerability
Mistakes I’ve Seen
Submission:
Application Allows it users to change their USERNAME, and there is big issue is
no prevention of account name takeover.
let's explain:-
1. suppose "Kymberlee" is change their username to Kymberlee1 ok but
interesting bug is your application not blacklisting old username and anyone can
takeover old username. and there is also no limit of username change.
security risk:-
i'm sure every researcher posting own cobalt,hackerone,bugcrowd links on social
sites and other accounts for showing own rank.
but what if after 6th month of posting. user changed their username to another
name? old link is stil not blacklisted any other fake core researcher can takeover
old name .
The ability to change usernames is intended functionality. Now if the attacker can
change my username without my involvement, then THAT is a vulnerability to be
rewarded and fixed!

11. 11
TL;DR
• Read the Bounty Brief so you focus on rewardable vulnerabilities
• Communicate Impact – STRIDE model
• Verify findings and provide POC & Attack Scenario
h"ps://forum.bugcrowd.com/t/wri2ng-­‐a-­‐bug-­‐report-­‐a"ack-­‐scenario-­‐and-­‐impact-­‐are-­‐key/640

12. Crowdsourced Cybersecurity
Kymberlee Price
Senior Director of Researcher Operations
support@bugcrowd.com
@kym_possible