Hi, here’s a new episode of the Bug Hunter podcast!

You can now listen to it using the widget below or on the following platforms: Apple podcasts/iTunes, Google Podcasts, Podbean, Anchor, Spotify, Breaker, Pocket Casts, Overcast and RadioPublic.

If your favorite podcasting app is missing from this list, please let me know so I can add it.

Also, if you prefer written text, you’ll find the whole transcript below. It’s also helpful for finding any links or commands mentioned in the audio.

Transcript #

Hey hackers! This is the Bug Hunter podcast by Pentesterland. The podcast for pentesters & bug bounty hunters.
We tackle technical questions & inspirational topics to help you develop both a hacker skillset & mindset.

Introduction #

Welcome to episode 4! I’m you host, Mariem. And the title of this episode is: “Bypassing email filters & Thinking out of the box”.

Today, I have two segments called:

1. Favorite hacks: on how to think out of the box
2. Q&A: on bypassing email filters with round brackets

I’m very excited about this one. I reached out to several hackers and many of them responded with awesome advice. I can’t wait to tell you all about it!

Before we start, the transcript for this episode is on pentester.land/categories/podcast/. Under episode n°4, you’ll find this show’s transcript, including any links or tools I mention.

Favorite hacks #

I’m always advocating for using a personal knowledge base and pentest checklists. But the truth is any checklist has its limits. It’s only one part of the puzzle. Another big part is out of the box thinking. The ability to come up with new ideas you haven’t seen anywhere before which may be unique to the specific environment you are testing at the moment.

But how to develop out of the box thinking? Is it a talent some people are born with and others are not? Is it something we can work on using specific steps and tools?

These are the questions that I wanted to explore in this podcast. A couple of weeks ago, I was traveling by train, without my laptop, and brainstorming this topic in my head. Then it hit me, wouldn’t it be great to ask other hackers and bug hunters what they thought? And then to give you a compilation of their tips and advice?

So, because I was traveling, and knew I wouldn’t have much time to think about the questions, I just wrote in my phone the first 3 questions that came to my mind, which are:

• 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?

I sent them to some of the best bug hunters I follow on Twitter. To be honest, I didn’t expect to get as many answers. Or that they would be so detailed.

Except 2 of them, I hadn’t spoken to them before. They didn’t know me nor Pentester Land. So I’m very very grateful to those who responded who are: @zseano, Nicolas Grégoire @Agarri_FR, Somdev Sangwan @s0md3v, Ed @EdOverflow, Gwendal Le Coguic @gwendallecoguic, and Eray Mitrani @ErayMitrani.

These guys are awesome and so generous with their knowledge! Their answers were so amazing and detailed, that summarizing them in this short podcast wouldn’t do them justice. So what I’m going to do in this episode is a summary of their tips on how to think out of the box. Then I’m also going to share their full answers as blog posts on Pentester.land in the next few weeks. This way, you’ll have all the information. And I will be able to add any additional advice I get from other hackers who wanted to participate but weren’t available until then.

So… that was a unusually long introduction! Without further ado, here are some ideas on how to think differently and differentiate yourself as a bug hunter.

The first question is…

How to find bugs that are not duplicates? #

Some tips to get better at find new valid bugs are:

• Instead of looking for obvious bugs like XSS in a front-page search bar (which everyone does), choose a goal, a kind of bug you want to find and focus on it That’s what Nicolas Grégoire (@Agarri_FR) did, he chose Yahoo YQL, read the docs, experimented… This allowed him to find 5 XXEs on Yahoo and earn $5950. He applied this same idea to 5 targets in total, and made 50K in 20 days.
• If you find a duplicate, don’t get discouraged. Instead, ask yourself: Does this behaviour exist elsewhere? Are these parameters used somewhere else? For example, does this file disclosure exist on the dev or staging environment?
• Try and think of as many different angles as possible, mobile, different browsers, different countries
• Follow either a lateral approach or a vertical approach. Lateral is when you focus on a single technology or vulnerability across the whole scope. Vertical is when you focus on a single app or business functionality and try to find as many bugs as possible.
• Focus on details
• If the target has an API, read it’s documentation
• Learn programming and automate the boring tasks like subdomains enumeration, directory bruteforce, or checking for outdated JS libraries being used
• Automation also helps spend less time looking for low hanging fruits. For example @EdOverflow wrote a script that can automatically find open redirect by collecting URLs with interesting parameters from the Wayback Machine, using waybackurls
• Don’t use a checklist. It’s OK to maintain a cheatsheet, wiki or knowledge base. But don’t go through a checklist of things to test for blindly without understanding the app or product you are testing
• Also don’t just use existing tools. Improve open source tools to fit your needs and learn how to script small tasks on the fly while hunting.
• Chain bugs. Don’t report low hanging fruits until you can chain them with something else to escalate their severity.
• Install the mobile app, visit their website and click everywhere while monitoring what’s going on. Make sure to start & configure Burp before opening the app. This allowed @zseano to find stored XSS on a public program that’s been tested for years and everyone missed them
• Do what other people don’t do because they didn’t think about it or because they were lazy. For example Gwendal Le Coguic found a .git directory. Instead of immediately reporting an information disclosure, the lazy approach, he studied the code and found an RCE.
• He also says: “root is a state of mind”. Hunting is like every sport, 50% about skills, 50% about spirit and 10% of luck"… mmh, that’s 110% in toal, but, okay, we get the point!

The second question is:

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

• To find logic flaws, you need creativity and knowing your target really well. You need to understand what the company does, their different products… and understand the app you are testing, its purpose, business features, technologies, use cases… Spend time on the app as a user, keep a record of what each part of it does, play around with all features to understand how the system was meant to be used. Then look for ways to break it.
• Also follow @inti, apparently he is a master of logic bugs. So that EdOverflow coined them after him Inti-bugs…
• Apart from knowing the product you’re testing, you also need to know the technology in and out. For example, @ErayMitrani recommends reading the OAuth RFC. Doesn’t seem like a fun or easy read! But that’s what allowed him to find a logic flaw on a GraphQL implementation on Shopify.

The third and last question is:

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

Many bug hunters call themselves security researchers. But it’s different. Research involves more in-depth knowledge of a specific topic and exploring new questions to find new kinds of bugs, not just new bug instances of known vulnerability types. To do research, you need to:

• Pick a subject. Learn as much as you can about it: read whitepapers, watch conference talks, read writeups…
• And try to really understand how the technologies work. @S0md3v gives great advice on this: If you read a writeup on an SSRF bypass, don’t just add the payload to your list of bypasses without understanding why it worked. To really understand SSRF, read about exploiting backend parsers by Orange Tsai. If you want to learn about DOM XSS, you need to understand how the DOM, JavaScript and browsers work.
• Read a lot, also outside of your expertise area
• Also, hack a lot and be curious. The more you hack, the more you start trying random things to see what it does.
• Don’t be afraid of failure. Research doesn’t always yield results.
• Also get to know different technologies that vendors use today. This includes tech stacks, apps, frameworks, features, libraries, etc. It will help you envision where issues might arise and maybe find a new type of bugs on a multitude on bug bounty programs.
• Finally, to really understand a technology, read specifications and build your own app using it.

Woah! That was a lot of information. There are so many gems in these pieces of advice! I can’t thank the hackers who helped me with this enough!

But remember that if you want to really benefit from this, you need to apply these tips. Pick one that you like and think is missing from what you are doing and start with it.

Also if you’re visual like me, check out this podcast’s transcript on the blog. And keep an eye for the AMAs I’ll publish in the next few weeks. They will have more details and give you more time to digest all this information.

Q&A #

Today’s question comes from Neel, who sent us an email saying:

Hi, I was reading your Tip of the week of @intigriti, it says we can use round brackets to inject xss/sqli/rce payloads. I understand what they are trying to say but don’t know how to use it practically. Can you please help me to understand how to use it in real time to find bugs using this technique. Thank You

First of all, thank you Neel for your question and really sorry for taking so much time to respond. I hope to make up for it now.

For anyone who is listening and doesn’t know what this is about… it’s a tip by @securinti I mentioned in The 5 Hacking NewsLetter n°34. You will find the link in the show’s transcript. If you can’t check it out because you’re driving or something, no problem, I will explain everything.

This tip is a technique for bypassing email fiters. It’s useful when you are testing any app whether it’s a Web app or mobile app, where you have an email field.

Let’s say you have a form with many fields: full name, username, password, email, address… And you want to test this form against injection vulnerabilities like XSS, SQL injection, HTML injection, SSTI, etc.

You enter your payloads with special characters like ' ",[, <… And you put these payloads in all the fields, but the app tells you: “No! This is not a valid email”. Because it’s expecting emails in a particular format, probably checking what you give it against a regex. And the email you entered was something like: jane'"><@gmail.com. Special characters are not allowed in the email field.

So what do you do in this case? The first thing to check is whether this is a client-side or server-side validation.

If you copy/paste your payloads into the form and get an error even before submitting the form, it means that client-side validation is in place. It’s a good security measure but you can easily bypass it.

Enable Burp proxy or ZAP proxy, fill up the form with valid data and submit it. For the email field, put something that looks like a real email, like [email protected]. It doesn’t need to exist.

Then once the request is intercepted by Burp, modify it to replace all values with your payloads. In the email parameter, replace [email protected] with your payload containing special characters. Then send the request.

By doing this, intercepting the request with Burp and modifying it on the fly, you bypass any client-side validation, any JS code that checks that you filled up the form with valid data.

And if the app isn’t well secured, this might be enough to put whatever you want into the email field and test for injection attacks.

But if the server still responds with an error saying that the email isn’t valid, it means that validation is done server-side. The server only accepts emails that are valid, with no special characters.

And here comes the ingenious trick by Inti: Even if the server checks the format of the email and only allows valid ones, it is still possible to inject special characters!

To do that, write a valid email like: [email protected]. Then between jane and at, add round brackets and put whatever payload with special characters you want inside them.

So the email will look like: jane('"><script>alert(2)</script>)@gmail.com.

Basically, put your payload between round brackets. It tricks the server into thinking it’s a valid email while you can still inject any special characters to test for injection attacks.

This trick is easily the best thing I’ve learned this whole year. It’s so simple and useful, and opens up the attack surface.
I’d love to know how Inti came up with it, because this kind of tricks is how you find bugs that everyone else is missing!

Bonus #

I don’t have a joke this time, but one term that I’ve only discovered recently: It’s Beg bounty, a contraption of the verb “beg” as in asking for money, and “bug bounty”. It’s when someone tests a network or site without permission, then asks to be paid for it. So it’s like begging.

I think it’s fun having a term for that. It’s very specific.

But please, don’t do this. Testing apps without permission is always risky, and it’s providing a service the company didn’t even ask for. You’d have more chance to get threats than money, and it’s not cool. Critical bug are much cooler!

Conclusion #

That’s it for today guys!

Thanks for listening to The Bug Hunter podcast by PentesterLand. If you like what you just heard, please share with your friends and colleagues, like, subscribe and comment.

Also, send your questions and suggestions by DM on Twitter at twitter.com/pentesterland or send us an email to [email protected].

See you next time! Keep on hacking!

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