A Little Background On Me
While it is no secret that I like to spend my time working on perfecting the dark arts what might a secret is that I often times struggle with exactly when (and what) to report. If you also find yourself on the fence about if you should, or should not, file a report to your favorite program on sites like HackerOne and BugCrowd then hopefully this report will give you some useful advice.
Before officially moving over into cyber security I spent many years in my professional life as a software developer. While I tend to feel like coming from a development background can be incredibly helpful hunting for security issues I feel like it can also make it hard to see the security impact versus just seeing a bug.
Impactful or Just Impacted
When evaluating something that I have found, the single most important thing I try to consider is what kind of impact I believe that it could realistically have on the organization. This is where things can really start to get fuzzy for me, and at times even frustrating. To make matters more stressful when dealing with programs like HackerOne every submission can feel a little bit like a game of russian roulette with your signal and reputation being on the line. Add on top of that only the first to submit the bug ends up with the bounty and you have a recipe for internal (and external) conflict.
Thirsty For That Bug Juice
As someone who has tasted the sweet nectar of a Triaged security issue let me tell you … that bug juice is addictive. Once you have tasted it you will find yourself chasing that dragon for hours on end trying to get that next bug. At times I can even find myself wanting a bug that I have found to be valid so badly that it can be easy to start slipping into the false belief that it impacts security in some meaningful way. It is critical to stop and ask yourself if what you have found has an actual impact on security or if it is just a regular old bug that does not decrease the security posture of the organization you are hacking on. Sometimes a JSON parse error is just a JSON parse error … although sometimes it’s not ;)
Play On The Edge (Case) And You Might Just Fall
I am absolutely the kind of person who loves to live on the very edge case of a finding, but those edges can dangerous too. One example of playing with an edge case, at least for me, is dealing with limited information disclosure that does not have an immediate security impact but still provides information to an attacker about internal resources, etc. Should that be reported or not? What does the scope of the program say, ah yes, like most of the time it lists information disclosure as out of scope unless it can lead to actual exploitation and not a theoretical attack. Does gaining limited information about something count as theoretical or not? Would an attacker simply disregard that information and not file it away in their notes when doing reconnaissance on an organization?
Unfortunately this, like most edge cases, just ends up being a judgement call. Worse yet it’s a judgement call that that could land you in a spot where you take a hit on your signal and reputation too. So how can you limit the risk while still going for a reward? One thing that I will always do is search the programs previous disclosures and see if they have a report that is in the same spirit of the issue I have found and if so how they resolved it (or didn’t resolve it). Additionally as you work with individual programs, and their triagers, you will start to get a feel for what they value or don’t value.
Another example of an edge case that I struggle with is what to do about security issues sitting behind an administrative login? Requiring someone to already have administrative access to an application certainly lowers the impact in my opinion, but should it completely remove that impact?. Worse yet should a security issue in a third party library only used behind an administrative login still be considered valid? My feeling on that is that yes, just because it requires elevated access to get to does not mean it still does not pose some level of risk. However, how much risk and if that risk is in scope is another question all together :/
At the end of the day I still feel like the only way to succeed is to try. I have also accepted the fact that, at times, my signal and reputation will end up being the victim of a report when I feel like it is the right thing to do. If it is something (security related) that I would want to know about as a developer on that product than I am probably going to take the risk and let them know, but sweet mercy that internal struggle is real.
This entire article is the result of my latest week long internal turmoil, and incessant texting to Paul, over an edge case security issue that I found. Eventually I decided to just go ahead and submit and see what happens. As of now it has been moved to Triaged … so I guess only time will tell.
One final note before we move on, this is not my blessing to spam a program with every little thing that you find hoping it’ll get triaged. Quite the opposite, this entire article is about providing value when you are not sure if the recipient will truly understand the very real value that you firmly believe you are providing by submitting that report.
Limiting Your Risk While Showing Them Theirs
Ok, now that I have covered the crux of my dilemma how can we still submit the highest quality bug report possible when we do decide that we are going to submit that bug report …
Realism or Abstract
When it comes to explaining your bug in your report, and it’s impact to the organization, which of the following two paintings would you say that your issue more closely resembles:
| Edward Hopper’s painting Nighthawks | Jackson Pollock’s Autumn Rhythm (Number 30) |
|---|---|
 |
 |
If your answer is Autumn Rhythm (Number 30) then it might worth holding off on your submission until you can clearly explain your bug to a rubber duck in such a way that it feels more like Nighthawks.
My experience thus far has been that almost all of my submissions that have had a very clear realistic and demonstrated impact have had a much higher chance of going to Triaged instead of Informational or the dreaded N/A.
PoC || GTFO
If a picture is worth a thousand words than a Proof of Concept should be worth a thousand dollars. While not every finding will necessitate fully functioning exploit code I can assure you having it will not hurt you either. Sometimes the best proof of impact is simply to provide a python script that they can run and actually see with their own eyes. There really is something magical about running a script and watching the exploitation take place automagically. Although understand that having a PoC guarantees nothing, I have also had reports marked Informational with fully functional python code automating the entire process. But hey, if nothing else you are getting better at coding right? :)
Life’s Not Fair … The Fair Comes In September
If you decide that you are going to go down the road of bug bounties, and security research in general, you need to remember that not every organization is the same. The risk that those organizations are willing to accept is also not the same. Just because another organization Triaged the same type of report that you submitted to your favorite organization does not guarantee you anything. Additionally risk levels, and risk acceptance, can change over time as well. Today’s Informational might just end up becoming tomorrow’s Triaged.
Risky Business
At the end of the day it is ultimately not our risk to accept, it is theirs. I have certainly been on the other side of reports marked Informational when I absolutely felt like the issue was real and should be addressed. However, that program disagreed, and so the choice is simply to continue hacking on them or move on. I elected to continue hacking on them as at the end of the day I still enjoy working on that program and enjoy helping to make it more secure.
In Conclusion
Good luck and happy bug hunting!
