Forem: security.txt

The poor man’s bug bounty monitoring setup

EdOverflow 🐸 — Sun, 15 Jul 2018 00:00:00 +0000

Fishing station on the shores of the Black Sea by Jules Laurens

I must confess, I have been holding on to a small trick that could allow anybody — even those of you that are not into developing and maintaining software — to set up a monitoring system in mere minutes. The reason why I call it the poor man’s monitoring setup is simply to indicate that this setup is not extremely sophisticated, but it does its job beautifully.

When bug bounty hunters monitor targets, they want to receive indications that something new has appeared or that there is a new instance. This is done so that one can immediately jump onto interesting targets and components, which is particularly useful on competitive bug bounty programmes.

The main part of this setup relies on Git. We want to be able to store results from our reconnaissance tools — such as subdomain-bruteforcing scripts — and be able to quickly see changes. We also need a place to store the output remotely. For this particular example, I will be using private GitHub repositories. Students can get free private repositories on GitHub if you apply here: https://education.github.com/pack. Please keep in mind, that there are plenty of alternatives out there, I am just sticking to GitHub for this write-up.

Once you have your private repository set up, make sure to store all output from your tools that you want to monitor inside of the local Git folder. When done running your tools, your monitoring script should attempt to git commit the output. The clever thing here is that Git will not commit unmodified files, meaning you will only be able to git commit files that include newly discovered endpoints. git push your files to the private GitHub and include a nice commit message, because this will become useful later.

Now that everything is being pushed to GitHub, we want to have a way to be notified about new commits. It turns out, GitHub has a nifty little feature which allows you to send emails to an address whenever there is a new commit on the master branch.

1) Navigate to https://github.com/YOUR\_USERNAME/REPO/settings/installations;

2) Under the “Add service” dropdown, look for “email”;

3) Add your email address in the “Address” field.

Finally, run the your tools with the Git commit process as a cron job. I wrote the whole thing in a few lines of Bash.

$ crontab -l
# Edit this file to introduce tasks to be run by cron.
...

0 * * * * /usr/local/bin/scan example.com

You are now ready to go. Sit back and relax. GitHub will now notify you whenever any changes were made via email with a nice diff of the files. So you can be sat in a Caffè somewhere and know straight away when a new endpoint was discovered on your favourite bug bounty target.

On a side note, I just want to add, please do not perform over-the-top type of scanning when monitoring. Keep things light-weight and prioritise targets.

A lightweight reconnaissance setup for bug bounty hunters

EdOverflow 🐸 — Sun, 29 Oct 2017 00:00:00 +0000

The following is a lightweight reconnaissance setup that should help you quickly gather information on a given target. We will run through the basic installation steps and then take a look at how to use this setup while hunting.

Please keep in mind that there are hundreds of tools out there and there is no way they could all be included in this write-up. This write-up is targeted towards people getting started or for those that want a simple setup. The author assumes that the reader already has a basic understanding of how to use a terminal. If not, the reader may want to start with https://linuxjourney.com/ before reading on.

Sublist3r

📀 Installation

$ git clone https://github.com/aboul3la/Sublist3r.git
$ cd Sublist3r
$ sudo pip install -r requirements.txt

💬 Aliases

alias sublist3r='python /path/to/Sublist3r/sublist3r.py -d '


alias sublist3r-one=". <(cat domains | awk '{print \"sublist3r \"$1 \" -o \" $1 \".txt\"}')"

dirsearch

📀 Installation

$ git clone https://github.com/maurosoria/dirsearch.git
$ cd dirsearch/db
$ wget https://gist.githubusercontent.com/EdOverflow/c4d6d8c43b315546892aa5dab67fdd6c/raw/7dc210b17d7742b46de340b824a0caa0f25cf3cc/open_redirect_wordlist.txt

💬 Aliases

alias dirsearch='python3 /path/to/dirsearch/dirsearch.py -u '


alias dirsearch-one=". <(cat domains | awk '{print \"dirsearch \"\$1 \" -e *\"}')"


alias openredirect=". <(cat domains | awk '{print \"dirsearch \"\$1 \" -w /path/to/dirsearch/db/open_redirect_wordlist.txt -e *\"}')"

webscreenshot

📀 Installation

Make sure to install PhantomJS too.

$ git clone https://github.com/maaaaz/webscreenshot.git

Steps to take when approaching a target

1) Verify target’s scope (*.example.com);

2) Run Sublist3r on example.com and output all findings to a file called output:

$ sublist3r example.com -o output
...
$ cat output
foo.example.com
bar.example.com
admin.example.com
dev.example.com
www.example.com
git.example.com

3) Check which domains resolve:

$ while read domain; do if host "$domain" > /dev/null; then echo $domain; fi; done < output >> domains

4) Run webscreenshot on the domains file:

$ python webscreenshot.py -i domains output example
...
$ eog example

💡 Tip: Look for 404 pages, login panels, directory listings and old-looking pages when reviewing the screenshots.

5) Run dirsearch on the domains file:

$ dirsearch-one

6) Check for open redirects using dirsearch on the domains file:

$ openredirect

📝 Exercises

The following tasks are left as exercises for the reader:

1) Write a shell script that performs the entire process when supplied with a single domain (example.com).

2) Practice going through the process by picking a couple bug bounty programs on HackerOne and Bugcrowd.

Conclusion

The author would like to acknowledge the help provided by @TomNomNom. The cover image is by João Silas.

Broken Link Hijacking - How expired links can be exploited.

EdOverflow 🐸 — Sun, 03 Sep 2017 00:00:00 +0000

Broken Link Hijacking (BLH) exists whenever a target links to an expired domain or page. Broken Link Hijacking comes in two forms, reflected and stored. This issue has been exploited in the wild numerous times, but surprisingly few researchers actively look for broken links in bug bounty programs.

This post aims to give you a basic overview of the different issues that could possibly arise if a target links to an expired endpoint.

Stored Broken Link Hijacking

Impersonation

When a company deletes their social media account they might forget to remove the link from their website. An attacker can create an account on the social media platform with that username and impersonate the company.

External JS File Hijacking

If a target has an external JS file and that domain/page is expired, you can claim it and then you essentially have stored XSS.

Say for instance example.edu has an external JS file hosted on example.com and example.com has expired.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>Broken Link Hijacking</title>
</head>
<body>
  <script src="//example.com/script.js"></script>
</body>
</html>

Now you can takeover example.com and can control the JS file on example.edu.

Information Leakage

Hijacking broken links which are missing the rel="noopener noreferrer" attribute could leak information to the attacker-controlled page. [1]

Also sometimes companies still link to expired analytics pages. If the attacker can hijack that expired page, they can monitor traffic and possibly gather valuable information about the target’s users. Someone actually once found one of these on Gratipay’s program: https://hackerone.com/reports/111078.

Content Hijacking

An attacker can hijack the content of a page by taking over the expired domain/page. A good example of this can be seen in @MisterCh0c’s blog post “How I hijacked top celebrities tweets including Katy Perry, Shakira…”.

Reflected Broken Link Hijacking

You know that feeling when you think you have reflected XSS, but cannot break out of the href or src attributes?

If the link is a CDN or a file hosting service, you can construct a malicious link and host that file on the service. Admittedly, these are very rare, but definitely something to keep in mind in case you come across this issue in the future.

Example Scenario

http://example.edu/?version=1.0.0 returns a specific version of the JS file being hosted on cdn.example.

<!-- http://example.edu/?version=1.0.0 -->
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>Broken Link Hijacking</title>
</head>
<body>
  <script src="//cdn.example/1.0.0/script.js"></script>
</body>
</html>

cdn.example allows us to add our project and host a malicious JS file.

<!-- http://example.edu/?link=maliciouspath -->
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>Broken Link Hijacking</title>
</head>
<body>
  <script src="//cdn.example/maliciouspath/script.js"></script>
</body>
</html>

Tools

broken-link-checker

broken-link-checker will crawl a target and look for broken links. Whenever I use this tool I like to run:

$ blc -rof --filter-level 3 https://example.com/

After a while I often find myself adapting it to something like this in order to prevent false positives:

$ blc -rfoi --exclude linkedin.com --exclude youtube.com --filter-level 3 https://example.com/

Link: https://github.com/stevenvachon/broken-link-checker

twitterBFTD

misterch0c released a little script that finds expired domains in tweets.

Link: https://github.com/misterch0c/twitterBFTD

References

[1] GitHub. (2017). cure53/HTTPLeaks. [online] Available at: https://github.com/cure53/HTTPLeaks [Accessed 3 Sep. 2017].

GitHub for Bug Bounty Hunters

EdOverflow 🐸 — Tue, 08 Aug 2017 00:00:00 +0000

GitHub repositories can disclose all sorts of potentially valuable information for bug bounty hunters. The targets do not always have to be open source for there to be issues. Organization members and their open source projects can sometimes accidentally expose information that could be used against the target company. in this article I will give you a brief overview that should help you get started targeting GitHub repositories for vulnerabilities and for general recon.

Mass Cloning

You can just do your research on github.com, but I would suggest cloning all the target’s repositories so that you can run your tests locally. I would highly recommend @mazen160’s GitHubCloner. Just run the script and you should be good to go.

$ python githubcloner.py --org organization -o /tmp/output

Static Analysis

When it comes to static analysis it is very important to start by actually understanding the project you are targeting. Run the project and use the main features. I call this the “Jobert step”, because I have heard that Jobert spends the first 30 minutes of every hunt using the project and understanding the target before finding vulnerabilities.

Manual analysis

This is where the “learn to make it, then break it” mentality comes into play. If you can familiarize yourself with a programming language, you should know the ins and outs of what to do and what not to do in terms of security.

Once you understand the target and its architecture, you can start grepping! Search for keywords that you are interested in, understand best or know that developers tend to mess up. Here is a basic list of some of the keywords I will look for during a general first assessment:

API and key. (Get some more endpoints and find API keys.)
token
secret
TODO
password
vulnerable 😜
http:// & https://

Then I will focus on terms that make me smile when developers mess things up:

CSRF
random
hash
MD5, SHA-1, SHA-2, etc.
HMAC

When you get used to certain vulnerability types, you will start knowing exactly what to look for in a specific language. So for instance, when I want to find a timing leak in Java, I know that Arrays.equals() and HMAC combined causes that issue.

Another vital step is to look through the commit history. You will be amazed at the amount of information you can gather from commits. Sometimes I see contributors thinking they have removed credentials, when they stay in the commit history. I have come across old endpoints that still work thanks to the git history. Aside from current issues, you might discover past issues that could potentially be bypassed thanks to old commits.

Tools

Sometimes automating the boring tasks can help give you a basic overview of what to look for. It is important to note, that you should never copy and paste findings from scanners into your reports. You will get a lot of false positives, therefore you must always look into the possible issue manually to ensure exploitability.

When I target Python projects, the main tool that I use is Bandit. Bandit will find common issues, but will often return low hanging fruit or false positives. So be careful when using it. It should definitely not be relied on.

$ bandit -r path/to/your/code -ll

If you want to find outdated Python modules in a project, paste the contents of the requirements.txt in https://pyup.io/tools/requirements-checker/. This will show you if there were any security issues in the specified version of the module.

Snyk.io is a wonderful tool for checking dependencies. The platform supports a wide variety of languages.

For recon, many researchers suggest using Gitrob. This tool will look for sensitive information in public GitHub repositories.

$ gitrob analyze acme,johndoe,janedoe

For finding high entropy strings (API keys, tokens, passswords, etc.), you can use truffleHog.

$ truffleHog https://github.com/dxa4481/truffleHog.git

If you are looking for an all-in-one secrets finder, git-all-secrets by @anshuman_bh is the tool for you. This tool combines multiple open source secrets finders into one big tool.

For Ruby on Rails apps, I recommend Brakeman. Brakeman is a static analysis security scanner that can find a ton of various security issues in code.

Use LinkFinder by Gerben Javado to find endpoints in the JS files of the repository.

$ python linkfinder.py -i 'path/to/your/code/*.js' -r ^/api/ -o cli

Social Engineering

OK, seriously do not social engineer the project owners.

Reporting your Findings

As always when it comes to bug bounty hunting, read the program’s policy thoroughly. Very rarely does a program accept reports through GitHub. Contact the security team or if possible use a bug bounty platform such as HackerOne or Bugcrowd.

On a side note, a cool thing about white-box testing is that since you have access to the code it can be easier to suggest a fix or submit a patch. 😉