This blog is not a writeup for a bug but instead is something that all hackers should know when they are reporting a bug. All platform like HackerOne and Bugcrowd have different ways each reports are handled: won’t fix, duplicate,Not Applicable, Informative etc. Each of these will reflect on points you get for example in HackerOne your Signal is average of your reputation, so the more N/A & Informative the less your signal gets. This also impacts your reputation. There is a chain reaction for this because once all of them go down, algorithms designed to automatically invite hackers to private programs will not invite hackers with low signals and reputation. So how can you hack more, learn more, earn more and get invited more? Here are few tips:

How to approach a target?

Bug bounty all comes down to understanding your target. Usually you do not have source code of the app so you cannot just pin point a vulnerability. You will have to understand how the app works, what kind of services it has and what are the permissions in the app. To better answer this question, I will provide a “completely” theoretical app to you:

There is a web app called awesomecompany.com and they recently launched a bug bounty. They allow you to buy bitcoins after you are a verified user.

So how will you approach this:

First make sure you understand the application. This means actually use the application. Do not think as a hacker just yet. Note every endpoint you use. Try to understand what they do for example: 1) Identity verification, 2) Buying and selling bitcoins, 3) Account 2FA for protection, 4) Profile updates, 5) messages you can send when buying or selling bitcoins to other users. These are couple of vulnerabilities I can think top of my head.

Targeting the app:

Now once you have the idea of what you can find, let your recon tools find other vulnerabilities like subdomain takeover, aws buckets, api keys and credentials, hardcoded auths etc. .

Next, use your prior knowledge to strategically test part of applications that are critical for example what if you can get access to someone else’s identity verification file? Can you do a bXSS out of the identity verification process? How does the 2FA security check work? Can you update someone else’s profile with IDOR and change their email for account takeover? Can you XSS someone with a message you send to them when transferring bitcoin?

In general, make sure you use the app at least for about 30 Minutes to 1 hour. Do not start reporting right away, make sure you check for impacts and all other conditions before reporting.

How to report a bug?

Now this is something that comes up a lot. The main question here is: What is important? Quantity or Quality? In many cases Quality is extremely important for the bug to be triaged. If you just write something like this:

Hi, I found a CSRF on your site. You can change profile information in example.com/profile/account and do account takeover. Here is picture of the request that is sent. Thanks! @yourname

Ok..so you told them that the endpoint at /profile/account is vulnerable to CSRF. In the triage side, now the company has to reproduce this. They have to go to their account, use Burp to generate CSRF poc and reproduce this. This might not take much but compare that above report to this:

Hi,

# Summary During the testing of the endpoint, `/profile/update` it was noticed that a POST request is sent. The request looks like this: {Picture} In that, we see no CSRF protection which allows attacker to modify information of another user.

# Reproduction To reproduce, simply download the HTML file or copy paste this code

{code} and run it locally.

# Impact In that page, we can change our email without any authentication, so an attacker can change the email of their victim -\> reset the account password with new email. This will lead to automatic account takeover

# Fix A proper authentication of the form with randomized CSRF token will be good. Along with that, I personally recommend that you force user to put their current password when changing critical information like email.

Which one is better? For triage the second report gives 1) the PoC exploit, 2) Gives impact scenario and 3) Gives a potential fix to the team.

What to do after reporting a bug?

Most platforms have a metric for each program. The metric explains certain facts like: Average response time, average bounty, highest bounty, average bounty period. If a program has average response time of 15 days and you start asking updates from the 2nd or 3rd day is that a good behavior?

Once the report gets triaged, be patience. If it takes more than 1 month then its one thing to ask for update. But asking for update within 5 days for a small CSRF is not a good habit. However, for example if you report a RCE, the case of the report being resolved is different. Whenever a hacker finds a RCE, companies do not close reports as resolved right after the fix. They have to run a forensics check to make sure it was not exploited before.

What bugs should you refrain from reporting?

There are couple of bugs that you should make sure you never report. Main thing to remember: “See Something, Say Something” does not mean you report any weird issues you see. Never report bugs like these:

1. Content spoofing in 404 pages or anywhere. Unless you can get a HTML injection or make it a XSS content spoofing is not really a big deal.
2. SPF/DMARC/DKIM weakness/missing & email spoofing: These all are linked, email spoofing is result of how a email vendor sees the SPF record of the domain. Email spoofing is more a phishing attack and most of them usually land on the spam box. If one mail service takes it Inbox does not mean all will do the same. Do not report these bugs.
3. Logout CSRF: Ok you can logout a user. But what is the issue with that? Can you exploit it make it dangerous, if not do not report it.
4. Email spamming or as some call it “Email Bombing”: A company has a reset password function, that you can use to send a lot of emails to user. It will annoy a user but how is that a security issue? That is a UI bug more than a security issue. If companies start paying for UI bug then I would make millions.
5. Banner grabbing: lets say you find that someone is using a certain version of wordpress, or certain version of apache2/nginx. Do not report it unless you can use some kind of vulnerability it has to exploit something. If a public announcement says that certain version of wordpress of RCE, do not report it unless you can prove that the site is also vulnerable to RCE i.e. test it and see if it is vulnerable or not.*
6. Never ever report a bug and just leave a reference to another report thinking that will explain the vulnerability. Each companies has its own policy and its system on how different app works. Referring something from totally different company does not make sense.

That is all for today. If I think of other things to not report (there are more than 6 for sure, I will add them here).

How to be a good hacker

If you submit a bug that was a false positive and it gets closed as N/A, never reply with a message saying “Hi, can you please close this as Informative, it hurts my reputation?”. These kind of texts leave a bad impact for the company. They want to help hackers (trust me when I say this) but at the same time, they do not want to close all reports as Informative. Companies grow along with hackers, they learn from each report that is sent to them. Hackers learn from companies based on how companies handle each bugs. Some companies like Gratipay are really good at transparency. When a code is fixed, they put it out so users can see where the vulnerability was. As a hacker, you should always be willing to learn. If your bug gets closed as N/A and unless you are absolutely sure that it should not be closed as such, do not argue. If you believe that you missed something on the report for example you did not realize they had other authentications besides CSRF, ask them, be enthusiastic.

Bug bounty is not just to earn money but it is to learn and grow. No one is perfect, we learn each day with each bugs we find.

How to grow as a hacker?

Researching and knowing about different vulnerability is what helps a hacker succeed. Constantly check for new bugs that are disclosed. I personally recommend following: https://hackerone.com/hacktivity and seeing disclosed reports. Make sure you understand how each bugs were found and what impact of them were. Never and I repeat NEVER copy paste a publicly disclosed report and send it to multiple programs because programs can easily detect spams. Secondly, try to practice the vulnerable. Create a vulnerable application that will match the disclosed vulnerability and see if you can break it.

If you feel stuck ask questions but when you do be polite and patience. Everyone in the community wants to help you but keep asking them the same question and not following their advice will make them block you instead of responding.

In the end, always have patience. When you start out in the security world you won’t find RCE right away on top programs. Start learning and growing. Never take shortcuts. Here is my favorite quote: “Fake it till you make it does not work in security”.

Cheers!