Attacking VulnTraining Part 3

So after a long hiatus of working on side projects, getting frustrated and eventually deciding to take a break, I am once again looking at VulnTraining. Since the last time I was attacking VulnTraining I have reinstalled my OS on my computer, so after getting setup again and installing my tools, I decide to retrace my steps from my previous sessions here and here.

This proves fruitful as I decide to cat the outputs of the found .git directory and find a hidden URL called s3cr3T_d1r3ct0rY which I then find another flag, however it does not return me with a successful capture, so it must be the same as another flag I found earlier, which saddens me, but I save it just in case. I quickly retrace my steps exactly and find it is the directory that I found in the robots.txt file

I am quickly looking through the GitHub repo again when I see there are some SQL database creds removed in a commit, I note them down and also try to use them to login on the server status page but no luck. I then start trying to brute force the login page using ffuf -t 3 -p 0.1 -X "POST" -w ~/ctfs/ctfchallenge/wordlists/usernames.txt -H "Content-Type: application/x-www-form-urlencoded" -u http://vulntraining.co.uk/server/login -d "username=FUZZ&password=[CAPTURED_PASSWORD]" -H $CTF_CHALLENGE_COOKIE -fr "Invalid username/password combination entered".

Unfortunately this takes over 20 minutes, so while I wait for that to complete, I inspect the source for the server login page but there is no flag to be found here. I get the results of the login brute force and unfortunately nothing comes back. I then quickly decide to fuzz for more directories under /server to see if I can bypass the login form. Unfortunately that only returns the URL for the login page.

I then decide to try something that I learnt from the VP of IT and Security at my work described in this blog post, I add the header X-Forwarded-For: 127.0.0.1 and curl the server URL and get flag 4. In this page I can see the HTTP servers version, it is running Nginx, as well as the PHP version. I also see a URL to a phpMyAdmin page, which the developer has changed the route of, but it is still public.

I decide to play with the phpMyAdmin page and try the database credentials from the GitHub repo. It works, if this was a real target I would be disappointed, but this is a CTF so it is a win. Flag 7 is now mine after I find it in a billing_users table. I also find a username and a hashed password. Unfortunately the hash is cut off with ellipsis, so therefore I can not use John The Ripper to brute force the password locally.

I note that phpMyAdmin takes in the db and table using URL parameters mentally, it could be something to explore, I do not know if there is any vulnerabilities with this version of phpMyAdmin. I decide to try and brute force the billing users login in the background while in investigate further.

I open the billing subdomain and quickly notice it returns a different error message if the username exists or not, so I guess I have a lot of fuzzing in the near future. I decide to focus on the username I do know first, so I use ffuf -t 3 -p 0.1 -X "POST" -w ~/ctfs/ctfchallenge/wordlists/passwords.txt -H "Content-Type: application/x-www-form-urlencoded" -u http://billing.vulntraining.co.uk/login -d "username=dominic.bryant&password=FUZZ" -H $CTF_CHALLENGE_COOKIE -fr "Password is invalid" get a password for the discovered user.

I open up the logged in page and there I see flag 7, I only have flag 3 and flags 8 through 11 left. The billing page looks fairly basic, just a table listing a few invoices, which leads me to believe there is another database table I do not have access to yet. Each of the rows in the table have a link to a page showing the full invoice, I try and access invoice 0 and get a page not found response, so I try the latest invoice ID number and add one to it and also get a page not found. The invoices show that there is probably an items table in the database as well. However as I write that, I notice the cost in the table on the home page of billing does not match the accumulative total in the invoices, so I may be wrong here.

I quickly fuzz to see if there are any more invoices, but there are only 4 as far as I can tell. I start fuzzing for more directories in the billing subdomain now that I have an auth token but nothing comes back. I try and see if I can post to an individual invoice endpoint but no luck.

I decide to call it a night after trying to find directories for the random subdomain I found from before but get nothing back.