OzSec2020 CTF | 1<3W!r35h4rk Challenge

Recently (it’s still going as I write this post), I’ve been able to participate in the OzSec2020 Capture-The-Flag competition. There were a couple challenges that were pretty interesting, and the Wireshark one was something I didn’t know existed/hadn’t touched before, so I just wanted to post a short write-up covering it. As of right now, it’s 20 minutes until the CTF ends and my team is sitting at 2nd place, so we ended up doing pretty decently!

But let’s go ahead and jump into it. If you want to follow along, feel free to download the .pcap file from here. Here is the challenge itself:

So, opening up the .pcap file we see a bunch of packets falling under the label 802.11, and this challenge mentions that we need to decipher the .pcap, and investigate it using a tool (or tools) on Kali (we’ll be using Wireshark).

First, to decipher the .pcap, we can go ahead and throw it at aircrack-ng. To read more on cracking 802.11 WEP using aircrack, click here. In short though, aircrack-ng is able to recover the WEP key once enough encrypted packets have been captured, and this .pcap has loads of them.

A key has been successfully found! Sweet! Now we just have to go over into Wireshark to decipher the packets, and find the correct request. For more in-depth step-by-step guide on the ins and outs of decrypting 802.11 in Wireshark, click here.

Now we actually have to find the password itself. All of our packets are decrypted, and the entirety of the .pcap file is looking a lot more readable. But it’s a large file, and we don’t want to go chasing down random rabbit-holes attempting to find the password. The question we have to ask ourselves is:

  • What type of request would a web-based admin panel have for completing a password change?

And our answer to that is: an http POST request. This isn’t a sure fire way to find it, and if we hadn’t found it this way there is another thing we could try, but for now let’s focus on the POST request. It’s just a very common way to handle passwords, and along with that, this is an admin panel in a browser we’re talking about, so we need to remember to include http in our filter.

Nice! Only one packet, let’s open it up:

And there you can see the password. It is besides the “PassPhrase=” section. This is the quick and easy way to solve it. If we hadn’t been able to find it using that filter, we probably would have ended up dumping the http.data through tshark and grep’ing for stuff like “pass”, “flag”, “phrase”, etc. It can definitely vary between CTFs, but a good addition would be to grep for their designated layout for flags as well. So if I was doing a MetaCTF challenge, and had a dump of data, I might look for “MetaCTF{” because that’s how most of their flags start.

Looks like we ended up officially taking second place as well!

Thanks for giving this a read, and if you have any recommendations, criticisms, or questions, feel free to reach out.