This writeup will detail the steps I took to complete the Vulnlawyers challenge on www.ctfchallenge.co.uk. The following post is for my own notekeeping and I am very much at the start of my Web App Security journey, so buckle up and hopefully you can learn from my many mistakes.
All resources required to complete this challenge are detailed on the website under the VulnBegin and Dojo sections.
For my initial reconnaissance and enumeration I used dnsrecon, Sublist3r, dirfinder, cert.sh and ffuf. I always leave brute-forcing until last as I like to try and find as much information as I can as quietly as possible. I just think it’s best practice to do it that way to avoid detection in the real world. This challenge however had me diving straight into ffuf as I wasn’t able to yield any results from passive recon and I feel like this challenge in-particular relied heavily on brute-force techniques.
Command: dnsrecon -n 18.104.22.168 -d vulnlawyers.co.uk
Command: sublist3r -d vulnlawyers.co.uk
Command: python3 dirfinder.py -cookie=UNIQUE-COOKIE -d vulnlawyers.co.uk
Because the above tools didn’t identify much information, I went into ffuf.
Command: $ffuf -b “ctfchallenge=UNIQUE-COOKIE” -w common.txt -u http://vulnlawyers.co.uk/FUZZ
css [Status: 301, Size: 194, Words: 7, Lines: 8]
denied [Status: 401, Size: 1020, Words: 178, Lines: 30]
images [Status: 301, Size: 194, Words: 7, Lines: 8]
js [Status: 301, Size: 194, Words: 7, Lines: 8]
login [Status: 302, Size: 1119, Words: 197, Lines: 31]
There are two directories above that look interesting, /login and /denied. I know the others won’t be of much use as they’re only 194 bytes in size, and are likely just pages required to host specific web based files. I checked them out anyway found nothing.
Browsing to http://vulnlawyers.co.uk/login instantly redirects to me to http://vulnlawyers.co.uk/denied and gives a message stating that I “Cannot log in from this IP address”, so clearly that’s not going to be much use. There’s bound to be data here somewhere though, so let’s try curling to see if we can identify some kind of invalid forwarding, due to the fact that we’re redirected from /login to /denied.
Command: curl -H “Cookie: UNIQUE-COOKIE” http://vulnlawyers.co.uk/login
Here we find our first flag:
Not only do we get our first flag but we see a href to another login portal:
Visiting http://vulnlawyers.co.uk/lawyers-only gives us another login panel that isn’t blocking us. Let’s try brute forcing the username field to find a valid logon:
Command: ffuf -X POST -w namelist.txt -b “ctfchallenge=UNIQUE-COOKIE” -d “email=FUZZ&password=test” -H ‘Content-Type: application/x-www-form-urlencoded’ -u http://vulnlawyers.co.uk/lawyers-only-login
No luck finding a valid username with fuff, and we’re currently not even sure what the naming convention is so I think we need some more content discovery as I’m not convinced we’ve found everything. There must be some place we can grab some users from.
We’ll try a brute force with dnsrecon:
Command: dnsrecon -d http://vulnlawyers.co.uk -w namelist.txt -t brt
Results: data.vulnlawyers.co.uk: A : 22.214.171.124
Visiting http://data.vulnlawyers.co.uk takes us to an API page, which gives us an API version number and a flag.
So let’s once again fuzz our new domain:
Command: $ffuf -b “ctfchallenge=UNIQUE-COOKIE” -w /home/user/wordlists/common.txt -u http://data.vulnlawyers.co.uk/FUZZ
Results: users [Status: 200]
Visiting http://data.vulnlawyers.co.uk/users gives us a flag a confirmation of naming convention alongside a few usernames we can brute force:
name “Yusef Mcclain”
name “Shayne Cairns”
name “Eisa Evans”
name “Jaskaran Lowe”
name “Marsha Blankenship”
Now we have a valid list of Lawyer logins we can try brute forcing again and hopefully find ourselves a login.
Command: $ffuf -X POST -w 10-million-password-list-top-10000.txt -b “ctfchallenge=UNIQUE-COOKIE” -d “firstname.lastname@example.org&password=FUZZ” -H ‘Content-Type: application/x-www-form-urlencoded’ -u http://vulnlawyers.co.uk/lawyers-only-login -mc all -fc 200
Now we can login to the portal:
Once we’re in we are presented with a flag and the managers profile details:
It says that changes can only be performed by Shayne Cairns, so we need to get his creds. Let’s see if the page is vulnerable to IDOR.
In burp, we can see that when we refresh the page, a GET request goes to:
GET /lawyers-only-profile-details/4 HTTP/1.1
This gives us:
We send that GET request to repeater and change the link to:
GET /lawyers-only-profile-details/1 HTTP/1:
This gives us:
GET /lawyers-only-profile-details/2 HTTP/:
GET /lawyers-only-profile-details/3 HTTP/:
We can see that when we sent our request to profile 2 that we got the managers profile, including his creds and a flag — this is our second from last flag! one more to go.
Let’s now try and log in as the manager, email@example.com.
We see our homepage with a “delete case” button which once clicked gives us the final flag: