Skip to content

Instantly share code, notes, and snippets.

View EdOverflow's full-sized avatar
I swear there was an XSS somewhere around here...

EdOverflow EdOverflow

I swear there was an XSS somewhere around here...
View GitHub Profile
@EdOverflow
EdOverflow / github_onplatform.md
Last active August 27, 2020 10:22
My basic workflow when using GitHub for recon purposes.

On-platform GitHub Reconnaissance

Note: Please keep in mind, that all of this does not work if you are not signed in to GitHub.

When searching for issues related to a target I often like to quickly look up their GitHub organization on Google.

So let's say Gratipay says nothing about being open source. A quick Google "Gratipay GitHub" should return Gratipay's org page on GitHub.

Then from there I am going to check what repos actually belong to the org and which are forked. You can do this by selecting the Type: dropdown on the right hand side of the page.

How to store all the bug bounty assets like domains, ip addresses, etc. in file and automatically check for the any 0day vuln that comes into the market?

Here is a simple approach that might work for you. Perform reconnaissance as you would typically do and collect hosts and targets. Next, find an application running the target software or setup a local instance. Gather strings that would easily allow you to discern the piece of software from other applications (e.g. with GitLab this may be _gitlab_session). With that small list of keywords in hand, fingerprint all hosts by requesting the index page using a tool such as meg by @TomNomNom and then grepping for the strings. Make sure to then store your findings in a structured fashion that allows you to query applications running that software in future. I primarily use text files in folders for this purpose but I know of others who prefer to store everything in a database.

@EdOverflow
EdOverflow / rmoulette.sh
Last active August 3, 2020 11:56
russian rmoulette
#!/bin/bash
su -
rm "-$(cat /dev/urandom | tr -dc 'a-z' | fold -w ${RANDOM:0:1} | head -n 1)" "$(ls | sort -R | head -1)"

Logical bugs require that you understand the app workflow as much as u can and that can take days and even weeks how do you stay motivated during that time and keep going even though you're not finding bugs?

It is true logic flaws require a comprehensive understanding of the target application and service. Part of the reason why I can deal with the concern of not finding bugs is rooted in my mentality and approach to bug bounty hunting in general.

Anyone who has worked closely with me will be able to attest that I have a tendency to come and go when it comes to bug bounty hunting. One week I am hunting and then I am on „holiday“ for a few months. This is to ensure I do not burn out and it gives me the freedom to ponder on issues rather than get all wrapped up in a program.

Someone once referred to my approach as the „Veni, vidi, vici“ of bug bounty. Although I am no Julius Caesar (and I hope on you

@EdOverflow
EdOverflow / googlegroups.sh
Created April 5, 2018 14:06
Find a public Google group for a particular host. Some of these groups contain sensitive information. The tool runs against a list of hosts and returns all public groups.
#!/bin/bash
# Find a public Google group for a particular host.
# Some of these groups contain sensitive information.
# The tool runs against a list of hosts and returns all public groups.
while read domain; do
if curl -LIs "https://groups.google.com/a/$domain" | grep "overview" > /dev/null; then
echo "[+] https://groups.google.com/a/$domain/forum/#!overview"
fi

How much average time do you spend studying in a week? Because I feel the time I spend studying is still lacking.

I am not sure how much time I spend studying on average. One thing is clear: I am continuously reading documentation on the fly as I am targeting an application.

When I first started, I used to spend my train journeys heading home from school reading documentation and write-ups. During my school breaks, you would often see me rushing into the library to print out documentation for the ride home. The reason being is I had no cellular reception on the train and therefore used this opportunity to force myself to read even the most boring of documentation. I credit a lot of my current knowledge to my school commutes.

Thank you, Switzerland, for the fantastic public transport. :P

What’s the best report you’ve seen and what makes a really good report?

My favourite reports are those that demonstrate the hacker understands the application and has an interest in collaborating with the company. It is that extra bit of effort that is noticeable in a report and makes triaging fun. An excellent example of this is with Frans Rosén’s reports. It is quite apparent Frans has a comprehensive understanding of the target and the team could consult him whenever necessary.

Do you collaborate a lot with others? And who do you collaborate with the most?

Back in 2017 during H1-702 in Las Vegas, NahamSec gave me some profound advice. It was something along the lines of “collaboration is key in the bug bounty industry”. Ben was right. Looking back since, collaborating with others has been instrumental. Some of my most successful bug bounty hunting sessions were while working with others.

For the past year, I have been running a collaboration program primarily with students from ETH Zürich. The goal of this program is to foster diversity and bring new brains to this industry. I help the members improve their bug bounty skills, and in return, I get to bounce ideas off them. It is a very symbiotic process that has resulted in some surprising findings. Most notably, last year, one of the members found a critical vulnerability on Google.

Many times I find myself removing ~98% LOC from JS assets due to them being bundled dependencies. Analyzing them from Chrome's debugger works but doesn't seem to be the best approach to me. What's your approach when hunting on JS-heavy apps?

Initially, I start by praying that the target has Webpack source map enabled. If that fails, know the type of JavaScript application you are targeting. This means I like to know what JavaScript framework a target is running and familiarise myself with the target‘s coding practices. This is where my motto “Learn to build it then break it” comes from. I set up a very bare-bones application locally using my JavaScript framework of choice and familiarise myself with the technology. While this won’t necessarily always result in more findings, it helps in getting past that initial first step of feeling lost when faced with a wall of code.

I also recommend searching for keywords that are more likely to be application-specific such as “auth”.

Another sneaky trick is to look