writing vuln reports that maximize payouts - nullcon 2016
TRANSCRIPT
Crowdsourced Cybersecurity
Writing Vuln Submissions that Maximize Your Payouts
Kymberlee Price Senior Director of Researcher Operations
2
whoami
• Senior Director of a Red Team • PSIRT Case Manager • Data Analyst • Internet Crime Investigator • Behavioral Psychologist • Lawful Good
@kym_possible
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
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
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
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
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
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
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
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
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
Crowdsourced Cybersecurity
Kymberlee Price
Senior Director of Researcher Operations [email protected]
@kym_possible