0x00SEC CTF - Exercise #4

This weekend I took a dive into 0x00Sec's new bi-monthly CTF.

Note::: NO, I won't be posting the found flag{}, but I will be posting the methods I used.

• CTF Name: Exercise #4
• Resource: 0x00SEC
• Difficulty: Easy
• Number of Flags: 1

Flag1

• Hint:

  1. A developer has slipped up after moving from dev to prod. Capitalize!
  2. Note in the Source Code of <!-- TODO: --> <!-- * Restrict debug log access -->

• Acquired By:
  
  -Warning:::I did go down a rabbit hole around step 8 soooo yeah. Just a heads up.
  
  -First thing to do is to just to look at the source code. This shows nothing specific except the hint. All scripts are bootstrap that are being used and nothing looks custom.
  
  -Step 2 is to check what happens when I attempt to log in. This tells me that my Password is Incorrect in an error message... ??? This is odd as usually you want error messages to be more generic and not specify any hints that might let an attacker guess someones password or login credentials.
  
  -Step 3 I notice that there is a PHPSESSID when the page loads that hold "1b3c80528eb53dcb23dfc61cd0cf174d" but it doesn't currently appear to be any of the usual encodings BUT I will check back.
  
  -Step 4 is to check the debug log. What is this? Where is this? I want to see if there is a /debug page first and this "Not Found" but it tells me that the server is "Apache/2.4.38 (Debian)".
  
  -Step 5 is to Google a bit and try to find some information on Apache debug logs. This lead me to try "https://exercise-4.0x00sec.dev/debug.log" which products quite a log.
  
  -Step 6 is to look through the log. First thing I notice is in the response for the page is an "ETag" and I need to look into this But first I'm going to simply search the file for some key words. I notice there are a few PHOSESSID's. And by a few I mean a lot. This file is huge. First thing I want to do is just try changing one of the PHPSESSIDs on the site and see what happens. This sadly did not produce anything so I am going to download the file in case I need it.
  
  -Step 7 is to look into the ETag but that is not helpful as "The ETag HTTP response header is an identifier for a specific version of a resource. It lets caches be more efficient and save bandwidth, as a web server does not need to resend a full response if the content has not changed."
  
  -Step 8 is to now see if there are other logs because I am wondering if this is not the correct log...
  
  
  access.log is not found.
  
  error.log is not found.
  
  referer.log is not found.
  
  Ok. So the debug.log is the thing to stick with but it is pretty big. There doesn't seem to be much that stands out to me except the cookies. I wonder if they are "random" until someone signs in but then it persists for too long so I might be able to use it. This would take to long to try each one by hand so I threw them into a Note++ file and stripped out everything except the cookie hash and now I am going to pop it into ZAP to fuzz the site with them and see that happens.
  
  Sadly that didn't produce anything useful..
  
  -Step 9: Now I want to look closer at the log and see what if there is anything odd about it or the cookies. I think it is the cookie still BUT I need a shorter list or maybe something specific. If you look at the log you will notice that a few are repeating, a few have "x-" headers, and a few don't have cookies. If we go to the very bottom of the list we can see that the time stamp is the oldest. This is probably the first log since it was moved to production and this is the cookie we want.
  
  If we take this cookie and replace the browsers cookie with it, on refresh we are not logged in and have the flag.

Thoughts

I messed up a lot on this one and went down a rabbit hole for a while. This is part of the process of learning and I wanted to show that with this post. No, it might not help anyone BUT it was my process nonetheless.

Learned

Cookies are interesting things that when left open to the world can lead to account takeover or information disclosure issues (and more I'm sure).
It's important to make sure that cookies have time limits so that attacks like this cannot happen and that when moving things to production things are ready and nothing important like this devs account cookie/log are still there.

Happy Hacking

Resources

1. https://ctf.0x00sec.org/
2. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag

Please Note that I am still learning. If something that I have stated is incorrect please let me know. I would love to learn more about what I may not understand fully.