Most crawlers and brute force subdomain scanners use some lists for checking the existence of files, respectively subdomains that otherwise are not linked or cannot be found by examining the existing visible data.
But you have websites that are focused on a particular area (financial, social, administrative etc). And a word like “game” is less likely to be a subfolder or subdomain of a banking application. A more likely subdomain or directory in this case is “payment”.
In the same time you might need to test a website that primarily uses a non-English language and if you use an English wordlist you might not be so successful. For example “geschaeftskunden.telekom.de” would probably not be found by such a list.
Of course, in any application you might have “likely” words like “admin”,”api”. But this is another category which is dependent on the platform and not on the content.
So I suggest using a wordcounter to help creating a list of reasonable words from the content of the root website for example.
Here is the list of words I quickly got from pasting http://www.paypal.com into http://www.wordcounter.net/ :
Some of the usual conversation words might appear, but mostly it’s very relevant. And the website has almost all these words, at least as a subdomain or a subfolder.
Of course, lists that are based on other criteria like CMS or other open source applications that might be used (“/misc/drupal.js” or “wp-admin” or “jira” etc) are something different. You need to check those too.
Because you cannot test a very high number you need to optimize based on context .And the content of the application is a very important variable. The content can be (one example ) reduced to keyword density (maybe filter the junk a little). And this keyword density can be used as a wordlist.
I think I found the best way to utilize the exploratory testing in security bug bounties. Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. Bug hunting has no rule in finding bugs (there are the rules of conduct, reporting, rewarding – but no one tells you how you need to find the vulnerability).
First you learn about what is a bug bounty program, you learn what companies offer these bug bounty programs, what areas are covered, you learn some technical things specifically to security etc. Then you create your own steps to find the issues. You visualize possible vulnerabilities by just “looking around” and design future actions. You then execute what you have designed (mentally or what you have written down) in your own way. Sometimes you just try manually some things, you might use scanners, you might use complex actions.
One of my favorite approaches is to reduce the messy BB(bug bounty) world (numerous vulnerability programs, areas, bug type) into simple puzzles that I have to solve.
Sometimes you get a little bit bored, like with everything, and that’s why you need to switch to other ways to find issues, learn new stuff to keep motivation.
Overall I thank all the companies that started these vulnerability reward programs. Some are better than others depending how you measure it and what is your personal experience with it. Its a great opportunity for many out there to test themselves, earn some cash, use a broad level of skills that in a normal job maybe you can’t and just have a little fun.
I did a trip to LA, San Francisco, San Jose, Las Vegas and New York. Too much to mention, but overall I loved it a lot. Nice cities, nice people everywhere.
Highlights of my trip were the visit to Paypal in San Jose, Defcon and the skydiving session in Vegas.
Just sharing some photos, hard to do massive upload of high quality photos..
You may want to start testing for bug bounty programs, you have a couple of hours, but not that many ideas in the beginning.
One tip that I recommend is to decide what BB you wanna approach and then get a list of bugs that you know were rewarded in the past. Then try to find similarities between these bugs and write it down. It’s good to take two bb programs so you can de-focus, get different perspectives. Also it will reduce the frustration when you don’t find any bug if you focus only in one area/BB.
So for what I described above I do for example:
1) Get a list of 10 bugs (as recent as possible) rewarded by Paypal (make sure these bugs are in scope too, because changes in the rules are often). In this particular case I sent often bugs to Paypal therefore I will use bugs from my own submissions
2)Get a list of 10 bugs from Google. Although I was rewarded a couple of times by Google is not my most comfortable BB program. So here I just Google it or look in other people’s blogs
Only these simple steps will help because:
I see many examples of rewarded bugs with final POC, or some description on a tool or some article on how someone found a bug etc, but not discussions about approaches in security bug bounties.
Like WHERE do you start from in looking for a vulnerability, WHEN do you try certain stuff and other stuff, WHAT do you look in a certain area, WHY do you do a specific action?
The final POC might be enough for the submission report, but it doesn’t tell that much on how you find it. You can get some ideas, but vague ones.
I don’t think it’s only that all bug hunters want to keep all their secrets. I believe they wanna share, but don’t know how. Also they don’t care about that much about the approach or identify it as a vital part. And even if you wanna keep some stuff, which is normal in any field, you still have a need to discuss with others about something you are not so sure about.
Here are some topics I would propose to look at:
And there would be more topics, but the examples given hopefully should give an idea on what I wanna say.