Hello,
As a newbie with THE worst rating, I am at a loss on how to get things going.
I have seen tons of resources and could have easily looked over something. Let me set the scene:
I have downloaded a mobile app from a bug bounty I am looking at. I ran some analysis and found some issues. This gave way to the questions:
How do I find out if these issues I found have been reported before? I wish to avoid embarrassing myself by submitting previously submitted issues.
As I am not a programmmer, what is a good way to look at the code and then research how to resolve the issue. Assuming that mitigation is part of the reporting process yes?
Thanks for your help,
Dave
2 Likes
Hi @TheArcher!
Welcome to Bug Bounties and to Bugcrowd!
To your question, part of the challenge as a researcher is that you’re operating with very limited information about what else has been reported. Most of the time you have very little, if any, so you’ve just got to do your best 
Finding a “duplicate”, as we refer to them, isn’t a bad thing. It just means someone got there before you.
You actually don’t have to include mitigation or patching information. You could if you want to, but it’s not required. The main information you’ll want to include are reproduction steps, screenshots/video, any sort of repro information (Browser used, Browser Version, etc), and you should clearly state what the bug is and the potential impact of the bug. You’ve sort of have to “sell” it, meaning you need to help someone understand why they should care about this bug you’ve found.
For more on writing submissions, check out this blog post:
You might also like this blog post:
3 Likes
Hello Sam,
And thank you for the welcome.
Yes, doing bug bounties can be likened, in a weird sort of way, to playing poker. Poker is a game of incomplete information. Your response makes it sound like bounty hunting can be as well. To a lesser degree, I’ll grant you.
I will read the links and use them as a template. I have done a bit of tech writing, so I am not totally afraid to submit something. I just need to make sure it is in a format that helps the program leads take notice. In a good way!
Thanks and expect more questions as time goes by!
Sincerely,
Dave
Yeah, duplicates are long going to be a battle in the bug bounty industry. But we’ve had some ideas on the topic, including a feature that I think could make a positive impact. It’s a feature that is opt-in for programs, so the rollout of this will be a bit slow, as bounty programs decide they’re OK with sharing this information. But it’s a feature available to all customers:
1 Like
Ok that makes complete sense.
And it will be really slow to be adopted and loved by companies. Too cynical?
As it would make the researchers job SO much easier if I find something and then check and oops! It was already found. I can then move on from that to something else to look at.
I hope it gets traction soon!
Hey Sam,
After reading about how to do a report, I used a scanning tool that gave many issues for both potential vulnerabilities and information issues.
Any pointers on how to best submit that? Or just clean up the xml version of the report and paste it in to the Write up box?
I can put the bigger issues in there, then the other findgings in the box below it.
Thanks,
Dave
Hi @TheArcher,
I will recommend you not to run a scanner. Usually, brings little value to the program and little value to you. Also, in the policy of most programs this is directly prohibited.
If you still want to do it (which is not something wrong in my opinion as long as the program doesn’t ask you to stop doing it), at least take the time to write the report to make clear the issue and not just copy & paste the report from the scanner.
A few weeks ago I ran a Burp Scanner to see if it was really worth it, and after a few hundred requests it found an issue which I hadn’t noticed which was pretty straightforward. I stopped the scanner and I haven’t used it since then. I got a bounty for that report. With this I want to make clear that from what I observe, a scanner is not useless, and probably there are bug bounty participants that use it.
Best.
Hello @stefanofinding,
Thank you for your reply. And I completely agree that just copy/paste of a scanner report does not, nor should it, endear a bounty hunter to the program. That is lazy. Or in the words of Daffy Duck to Porky Pig, “You are a slovely housekeeper”.
As to your suggestion about not using a scanner, if I am not a developer, nor have ever been, would you mind offering some guidance? In my current job as a level 2 tech support guy, I have had access to the code of some products. And when I see errors pointing to lines in a file of code, I can find them, and understand what went wrong. I am not able to write the code to change it and fix the error. It was suggested to write a sample app to then learn how to analyze and break them for fun and profit. Would you agree with that line of thought?
Any suggestions are greatly appreciated!
Thanks,
Dave
Hi @TheArcher,
I’m glad you got my point about scanners. It’s not something bad, but it’s not something helpful. And if you care about a career in security or something like that, I don’t see how “running Burp scanner since 2018” in your CV is going to help (maybe it does!) 
I usually recommend people to learn programming, at least something basic like doing the Javascript course on codecademy.com or other similar website. However, from what I observe and read from others, it’s not necessary at all. I make an okay income from bug bounties, but I know people that are killing it and they don’t even know how to code or understand reading code. You don’t need to know how to code to find a CSRF or other very critical bugs. The other thing is that you don’t need to read code in most bug bounty programs (maybe there are exceptions like open source projects) other than Javascript in the client-side if you want to do it. And if you do read server-side code, better report that critical bug!
You can get a better idea about what I’m talking about after reading many reports and write-ups. Notice how many times they mention or quote something about a programming language.
The best you can do, is to start with what you know. Make time to read everything about vulnerabilities (reports, write-ups, papers, etc), and at the same time try to find bugs. When I started, one thing that helped me (and I think I still do it), is that I tried to find the same bug I read in a write-up or test that endpoint mentioned in a report or things like that. I found my first bug after reading a write-up from Jack Whitton and testing the same Facebook feature he mentioned in it. What I found was not as critical as his, but it was enough to get a 1000 bounty.
So, it’s important that you don’t wait to start looking for bugs, because that way you are going to learn or at least realize what you need to learn. I knew some Javascript before starting, but after spending so much time looking for XSS (I don’t recommend to spend time looking for XSS only) I ended up knowing more about Javascript. Also, I didn’t even know how to use Burp and I didn’t even understand a raw HTTP request/response.
I hope you find some guidance there. Maybe it works for you, maybe it doesn’t.
Best.
Hello Stefano,
Thank you for your reply. As a newbie, relying on tools seems the easy way to go. Your points are well taken that they are just that: a tool.
The real bugs are found by looking for them. So if I may ask some questions:
So learning JavaScript, if you HAD to pin down a language, would the best place to start? Based on the JS you are seeing in web pages/applications? Are you hunting web or mobile bugs?
And reading the writeup’s here would be advisable? So as to see what was found and where? This sounds like some advice I got where using Metasploit against Metasploitable and then looking at the code in Metasploit to see how the exploit was crafted. Sounds like you are saying the same. And not having to be a coder as well. Yes?
I am in awe of a bug hunter admitting they don’t understand raw HTTP data. I thought I would have to be a wizard at that. Would you mind sharing some of your thoughts on what you do where you don’t need that knowledge?
Take care,
Dave
Hi Dave, sorry for the delay.
It really depends on what you need. For example, if you want to understand web applications in the client side, then Javascript would be the best place to start. But, in my opinion, understanding how to code is useful even if you don’t use it. If I were a top 10 bug hunter I would say that for sure, but I’m not, so be careful taking my advice on this.
I do hunting on web applications. If you choose mobile applications you are going to be in high demand, because the majority focus on web applications from what I’ve seen.
Yes, reading writeups is the most useful way to learn in my experience. And trying to find the same bug or looking at the same endpoint/location where the bug was found is also useful.
I never used Metasploit, but it seems useful what you mention because you can understand how the vulnerability is exploited. And as you said, you don’t have to be a coder to do that, you can learn “on demand” (using google when you don’t understand something that you read).
I do understand the HTTP messages now 
, but when I started I didn’t. Many vulnerabilities do not require you to understand what is going on in a HTTP message. For me it’s more comfortable to read the HTTP message now, but when I started I just used the tab in Burp that shows the parameters in a table and played with that. You don’t have to understand a HTTP message to find a CSRF or XSS vulnerability, you don’t even need Burp or similar tool.
Best.
Hello Stefano,
Thank you again for taking time to respond to my queries.
I am going to do some reading of Android bug reports. Then try and see if I can find the same thing. Or if it is fixed.
That should help.
I do appreciate your insights. Maybe some day, I can make a few bucks at bounties 
Muchos Gracias!
Dave
Hi Dave.
You are welcome.
That’s great! Looking forward to hear about your findings!
I hope you can achieve that goal. Worst case scenario, you learn a lot and get experience, which may be helpful in pursuing a career in security if that’s what you want.
¡De nada!
Even I am also confronting with the same sort of consequences.I have one more query to add on regarding my Arlo Q what are the possible ways to make me know that my security camera is being hacked.I have checked the following details in arlo security review.Are there anything else needed to be added on?
