If you’re not aware, I joined Dropbox’s security team last September. Since then, I’ve become very involved in the bug bounty community on two fronts: both running a program and as a hacker in my spare time. It’s offered me a unique perspective on many divisive issues and I’ve used my experiences to both improve our program as well as helping to bring a program’s perspective into the conversation with other prominent bug hunters.
Sometime last week I gave back to the bug bounty community by contributing a tip to #bugbountytip on twitter.
Originally, I didn’t expect anyone to pay attention as I’m not as experienced in bug hunting as nnwakelam or yassineaboukir. However, I was pleasantly surprised at the amount of people who thought my tidbit was noteworthy.
Today, I’d like to give back to the community, again, by contributing a few tips to newer hackers in the community. While there are plenty of things your programs would want you to know, I believe these are some of the most impactful tips I could give based on my experience running a program.
Many programs have a feature turned on called Human Augmented Signal, or HAS for short. If you haven’t heard of HAS before, you can read more about it here: https://docs.hackerone.com/programs/human-augmented-signal.html.
In short, HAS flags reports that look like spam or will probably not be accepted. This feature helps reduce the spam and other low quality submissions that programs occasionally receive. While HAS has proven invaluable to our program, I’ve noticed that many (including veteran) hackers don’t understand how it works.
If your report is flagged by HAS, your report won’t enter the new state (https://docs.hackerone.com/hackers/report-states.html) but, instead, will enter a state called pre-submission.
At this time, your report will be reviewed by the HackerOne triage team. Generally, the bug bounty program will not even see, or be alerted to, reports that were put into pre-submission. If the report is valid, then the HackerOne triage team will transition the report to the new state. At this time, the program will then see the submission enter their main queue. However, it’s important to remember that if your report goes from pre-submission to N/A then the program has almost certainly not seen the report at all.
A couple of times now, I’ve seen hackers get frustrated when they observe changes to the asset involved in their report without realizing that the program likely hasn’t even seen their submission. In their frustration they accuse the program of not wanting to pay out to researchers or other shenanigans.
I would advise all (especially newer) hackers on HackerOne to learn a bit more about HAS and what a good report looks like. Writing a better report (being clear, providing examples, showing impact, etc) will help significantly reduce your chance of getting flagged by HAS and will also help the program triage your report quicker.
Sometimes, as a hacker, the way a program is handling a report might appear unfair or irresponsible. If you feel strongly about how a report is transgressing, there are options to help mediate the situation.
Option 1: HackerOne Mediation Request
The first option is use a mediation request. HackerOne offers mediation services if communication between a hacker and the program has begun to break down. They’ll evaluate the report and act like an advocate on your behalf to ensure that everything goes smoothly. However, this feature is a privilege for hackers with 200+ reputation and over 1.0 signal.
Option 2: Email support@hackerone.com
If your account doesn’t have the necessary reputation or signal to use this feature, you can always email support@hackerone.com to get assistance, manually.
One of the most common causes of N/A and informative reports I’ve seen is hackers not recognizing capability-based security when they see it.
In short, capability-based security is a security model in which an unforgeable token (referred to as a capability) is used to convey access rights to some resource. For example: an application may create a capability when generating a download link. After the capability is minted, any party carrying the capability (visiting the link) would have access granted to that particular resource as carried by the capability. An example of what this link may look like: https://example.com/download.php?tkn=4b8368666456c476327dd285a6a21050bea5eeec41c64f5145a561fcb25e9955.
Occasionally, bug hunters may look at this and discover that they don’t have to be authenticated to download the file. Because they’re not logged in, they assume that this must be a vulnerability. However, if we recall, capabilities are also supposed to carry access right information and, therefore, this software is working as intended (and this isn’t a missing access control check).
One issue to check for might be predictable capability generation. If the capabilities are easy to predict then attackers could gain access to some resource by predicting the capability’s value manually. This is similar to IDOR except the vulnerability isn’t missing or insufficient access control logic, but use of insufficiently random values.
Every so often, programs will update their policies to reflect new rules to be mindful of or new assets to hack on. It’s important to both the programs and hackers that participating hackers are up-to-date on the latest policy changes. That way, hackers are both playing by the rules and getting access to the full scope for testing.
Thankfully, HackerOne has a feature to help keep hackers in-the-know with regards to policy updates.
If you plan to keep hacking on a program, make sure to stay aware of recent changes to the policy!
This is probably the most important tip I could offer. Properly understanding and demonstrating impact is one of the most important parts of your report.
I asked well-known bug hunter, europa, “What is the one thing you wish you could go back and tell yourself when you first started bug hunting?”
Demonstrate impact; if you can’t do (any) such thing, then reconsider submitting — europa
Similarly, karimpwnz, had this to say:
There are many so-called “vulnerabilities” that people shouldn’t report, such as logout CSRF, cookie missing secure flag, and content spoofing. A lot of the time, the aforementioned vulnerabilities are not found in a dangerous context; they don’t pose any considerable risk on the users or the website. However, such minor issues can be chained together to create an impactful vulnerability, like with the chaining of logout CSRF, cookie missing secure flag “vulnerability”, and self-XSS; a similar chain was used by Jack Whitton on Uber. Also, who would be friends with a donut? — karimpwnz
Okay, so we’ve established that it’s important to demonstrate impact, but what does that mean? It means that if you think you’ve found a weakness, you have to be able to demonstrate (not just describe) how that weakness would be abused.
Here’s a couple of examples:
XSS on example.com
Don’t just report “XSS on example.com” but describe what an attacker would do with that XSS.
- Could you steal cookies (verify important cookies don’t have HttpOnly set)?
- Could you perform an account takeover by changing the password (There are tricks to get the existing password that don’t require phishing.. but for another time 😄)?
- Could you perform some critical action like purchase items, exfiltrate secrets, etc. etc.
These are the important questions that you should be able to answer. By answering these questions ahead of time, you’ll make the triaging process faster, you’ll be less likely to get flagged by HAS, and you’ll make the program much happier.
Missing X-Content-Type-Options: nosniff on example.com/foo
Very few programs actually ask for “missing best practice” reports. These reports try to pass off a “missing best practice” as a vulnerability. While it may be smart of the program to add these missing security headers or make a particular change to their DNS record, what these reports often don’t do is show how an attacker would be able to exploit these missing security practices. As a result, the value of these reports is severely diminished.
For example, if you found an endpoint that returns JSON without a X-Content-Type-Options: nosniff header but no reflected XSS to demonstrate why having that header is a good idea, then don’t report it. You haven’t found a vulnerability. You found a weakness that could manifest into a vulnerability eventually, but without this reflected XSS you cannot demonstrate impact.
One way to help demonstrate the impact of a report (as well as improve communication) might be to create an easy to use proof of concept (PoC). This is especially helpful if your report contains complicated or specialized knowledge to replicate the attack. As the bug hunter, FileDescriptor, says
Some of my bugs (e.g. OAuth) requires calculate signature and a also a bunch of complicated settings before you can even verify if it’s an issue. Most of my reports are one click no brainier or a script that you can easily execute. — FileDescriptor
Demonstrating impact doesn’t mean pointing to OWASP articles describing why it’s a good idea to accept the report.
Demonstrating impact doesn’t mean citing another HackerOne report where a different program accepted a similar report (this might also get you flagged by HAS, too).
Demonstrating impact doesn’t mean describing what could happen if a vulnerability existed that let you exploit the misconfiguration.
There are some exceptions to this rule, of course. For example, if you find what looks like credentials to an internal system, you should probably report that. However, the general rule of thumb is..
If you can’t exploit it, don’t report it.
tl;dr: PoC||GTFO — europa
I hope that both new and experienced bug hunters learned something interesting. While most of these tips are targeted at new bug hunters, I think there’s room for everyone to grow. I may consider coming up with some more bug bounty related posts in the future, but I’ll likely be focusing on my experiences as a hunter.