How to think out of the box with @s0md3v
Posted in Articles on April 11, 2019
Posted in Articles on March 28, 2019
Hey hackers! This is the second AMA around the topic of: How to think out of the box?
As a reminder, it’s part of a series started when I was preparing the Bug Hunter podcast Ep. 4 on this same topic. I wanted to include advice from different bug hunters. So I asked several hackers these 3 specific questions:
@EdOverflow was one of the generous hackers who responded. Here is his advice:
The dreaded duplicate. Even the best bug bounty hunters encounter duplicates every now and then. A significant portion of duplicates are caused by bug bounty programs taking too long to resolve a reported issue. Since this question is targeted towards bug bounty hunters and not programs, let me cover some small points that can decrease the likelihood that one might end up with a duplicate report.
When approaching a target, try leaving your mental checklist behind. We all have the OWASP Top 10 practically memorised at this point and can easily find low-hanging fruit. Do you really think Frans Rosén has a printed-out version of the OWASP Top 10 by his side at all time while he is hunting?
Focus on more application-specific issues and get to know the product you are testing. Sometimes you might get lucky and find something straight away, other times you will need to invest time and effort in order to find a bug. That’s what makes bug bounty hunting fun.
Don’t waste your time going out of your way to manually find low-hanging fruit and performing repetitive tasks. The time you spend searching for low-hanging fruit could be used to actually find something more impactful. In addition, being able to script small tasks on the fly while I am hunting is essential to my bug bounty hunting approach. Just to give you an idea of what I mean by “scripting on the fly”, take this case during H1-202 where I quickly wrote a JavaScript Wayback Machine file fetcher and differ specifically made for Mapbox.
Since your recent podcast covered the Wayback Machine, let me give you an example where TomNomNom’s waybackurls
can come in handy for quickly grabbing some low-hanging fruit. Whenever I need an open redirect, I can either refer to my previous notes (always keep track of small things as you go along :P), or just generate a list of archived URLs, grep for parameters that are commonly vulnerable to open redirects, and then automatically determine if they are vulnerable or not. Is this a bullet-proof solution? No, I didn’t invest much time into this script. Does it work for me? Yep, it does the job in most cases and saves me a lot of time and trouble.
#!/bin/bash
sigma=$(grep -i "url=" "$1");
lol=$(echo "$sigma" | cut -c1-60 | sort -u);
while read -r hehe; do
url=$(echo "$sigma" | grep -m 1 -i "$hehe" | sed -e 's#url=[^\&]*#url=https://google.com#gI');
if curl -LIs "$url" | grep -Ei 'location: (https?:)?[/\\]{2,}google.com' > /dev/null; then
echo "$url";
fi
done <<< "$lol"
So remember, automate the boring tasks.
The reason why I might need to grab an open redirect is to chain with other issues in order to escalate the severity of the issue. Don’t waste your time reporting low-hanging fruit and spend more time working on chaining issues and getting those impressive bounty amounts. If all you do is report every single minor issue you stumble across, then of course you are going to get hit by a wave of duplicate reports.
For me at least this is similar to how an artist might come up with an interesting concept or an author starts writing a new book. Be creative and open-minded. Don’t let people tell you what you are about to do is a waste of time and don’t be afraid of failure. If research always yielded perfect results, we would all be researchers (although some might argue we all kind of use that “security researcher” badge at this point 😅).
I have encountered two common cases that push me down a path leading to a new research topic: accidentally stumbling across something and hypothesizing about a potential area of interest. The former can happen while I am hunting or sometimes in my sleep. Yes, I have had cases where I suddenly came up with an idea in my sleep. Suffice to say, I didn’t get much sleep that night.
When it comes to hypothesizing, what I really mean is get to know various areas of technology and keep an eye out for particular tech stacks, applications, frameworks, features, etc. that vendors use today. Familiarizing yourself with these projects and building blocks has definitely helped me envision where issues might arise. Read specifications and maybe even go as far as building your own application with these components.
Learn to build it, then break it.
Logic bugs are one of my favourite types of bugs. I admire bug bounty hunters who find logic flaws in applications such as Inti De Ceukelaire. In fact, Inti is so creative and good at finding logic flaws, I have started naming them after him: Inti-bugs.
The “secret” to finding logic flaws is a combination of creativity and knowing your target really well. I would really struggle to find logic flaws without being able to think out of the box and knowing the ins and outs of the target application.
The first step is to spend time on the platform as a user. Play around with the target application and try to get to grip with the various features the platform provides. Once you feel comfortable, start questioning things and view things from the perspective of the developers of the application. “Why would they have added this here?”, “What if they forgot about this?”, “What is this feature’s main purpose?”, etc. are just some of the questions that go through my mind as I am staring at the bug bounty program’s product. Often times, logic flaws arise from a foundational design flaw whereby the developers and engineers had a specific purpose in mind but hadn’t accounted for how this feature could be abused. I like to picture logic flaws as “bending the rules” or just “bending features so that they point in another direction from where they were designed to point in the first place”. You could picture the feature as a pair of binoculars directed towards a beautiful field, only for a hacker to come along and spin the binoculars around the “wrong way”.
In other words, it really boils down to understanding the intention of how a system was meant to be used and how that process flow could be broken. For instance, if you are testing a travel site that has a fixed amount per flight — what happens if somebody works within those confines and books a series of smaller flights with first class to reach an expensive destination they shouldn’t be able to book at that rate? That loophole is within the confines of the system, but the system was also designed to limit the amount each employee can book, so it’s not a bug that breaks the technical aspect of the application, but the underlying logic of the system.
If you enjoyed reading this, please consider sharing it, leaving a comment, suggestions, questions…