Hey hackers! This is another AMA on the topic of: How to think out of the box?

The previous ones were with @zseano, @EdOverflow and @ErayMitrani.

The podcast episode that started this whole series is The Bug Hunter Podcast 4: Bypassing email filters & Thinking out of the box.
While preparing it, I wanted to include advice from different bug hunters. So I asked several hackers these 3 specific questions:

• How to find bugs that are not duplicates?
• How to find new areas of research (like in @securinti’s last blog post or what James Kettle does)?
• How to find logic bugs or bugs that don’t fall under any category, can’t be found with tools or require real thinking?

@s0md3v was one of these hackers, and he was kind enough to respond with this awesome advice:

Hello there, I am not a bug hunter but I would love to contribute to the podcast as it addresses a topic that is important but isn’t often talked about.

How to find bugs that are not duplicates? #

Low hanging fruits such as an XSS vulnerable search box or easily automatize flaws such as subdomain takeovers are pwned within first few hours when a program is made public. There’s high probability of getting duplicates if you report such bugs and you will also be left behind in the race for bugs that aren’t this easy to find.
Looking for such bugs in multiple programs is called farming which is a term used for preferring quantity over quality. Obviously not a great thing to do when your intention is to find quality bugs, forcing yourself to learn news things and get much bigger bounties.
However, easy to find bugs are great because, well…they are easy to find. You can learn to code and automate these boring parts to find such issues faster than anyone else.
Knowledge of programming is amazing skill to have. If you are into web application security, I suggest you to learn Python for automation and HTML, JS and PHP as starters to get a better understanding of how web applications work.

How to find new areas of research (like in @securinti’s last blog post or what James Kettle does)? #

The thing that prevents people from doing something new and creative is their lack of knowledge. Researchers that find new attack vectors or flaws have a very good understanding of the subject.
For example, Orange Tsai didn’t accidentally exploited popular URL parsing implementations. I believe he read URI specification or more precisely, RFC for URIs. Well, RFCs are official documentations of protocols, specifications etc. They aren’t very fun to read because of the formal language and the immense amount of information but they are excellent resources for learning about standards in detail. It’s quite simple, If you want know about something, read it’s documentation. It works for everything ranging from an API implementation to an internet protocol or a software library.
So yeah, there is no “tip” or “trick” to find something new but a general idea is to understand how things work and constantly ask yourself what can be done. Watch presentations from DefCon and other conferences and you will get to see good examples of creativity.

Since I have mentioned the concept of learning how things work, I must include how to do that. I think the best way to do learn things in detail is to read white papers and RFCs. White papers are written after deep research on a subject and hence are good resources if you want the details of a particular subject. The easiest way to search for white papers is to use the ’ext’ search filter of google e.g. ‘DOM XSS ext:pdf’.

Something that I would like to address is people reading bug bounty write-ups for their dose of knowledge. It’s good for learning real world applications of an attack and variations observed in the wild but they do not tell anything about the underlying cause of the vulnerability and hence the reader fails to achieve something new with the information. Yes, he might be able to find bugs by doing what author did or by using a variation of it but it won’t help in a new finding.
So if you are into security research, try to read the boring stuff too.

So what should people do to really understand and benefit from write-ups? Take more time to dissect them and research what they don’t understand? Or learn about the technology exploited in the write-up? Or something else? #

About the bug bounty write-ups, as I said earlier, they are very good resources for learning real world applications of an attack but they often lack details.
For example, if you are reading a write-up where someone was able to bypass SSRF protection, instead of just adding the final payload to your “list of bypasses”, try to learn why that happened.

How to find logic bugs or bugs that don’t fall under any category, can’t be found with tools or require real thinking? #

I suggest you to spend more time learning about what they do as a company, what their different products are and how they interact with clients.
Spend a good amount of time mapping their web application, how different parts of it interact with each other. Get all the subdomains and endpoints in your sight. If they have an API, read it’s documentation.
Put yourself in the shoes of the user/client, think what you would do as a user of the web application and use the previously collected information to abuse the functionality or find business flaws. Try to chain minor mis-configuration for a higher impact.
Information gathering (both passive and active) is a very important phase and pretty much determines what you will get with your testing.
Also, it’s okay to have a bad day. Get proper sleep, drink a glass of water to make your brain work about 10% more efficiently, go out, listen to music. You might be a workaholic but hey, if rest refreshes your mind and makes you work more efficiently, it’s a good deal right?

Thank you so much @s0md3v for taking the time to share your knowledge and experience with us. Very grateful! #

If you enjoyed reading this, please consider sharing it, leaving a comment, suggestions, questions…