
Week 10: BSides Augusta Twitter Challenge Writeup
This week I spent a lot of time working on Passloch, my password manager. While I’ve been making lots of progress with Passloch, I took a break this weekend to help out Cleveland GiveCamp. GiveCamp is an event where developers from the local community offer their skills and time to nonprofits. The developers help create websites or applications for these nonprofits that would otherwise be unable to afford a freelancer to do it for them.
Due to the relatively short time period that these developers have to build these sites and the desire to build maintainable sites that the nonprofits can update with minimal technical skill, the developers often use platforms like WordPress or Joomla. WordPress in particular is known for many security problems due to out-of-date plugins, themes, and WordPress itself. This is why I helped out at GiveCamp this week. I wanted to help make sure that these WordPress installations were configured correctly so that after GiveCamp they don’t get compromised.
Most of what we ended up doing was a couple scans with wpscan, nikto, dnsrecon to make sure that domain transfers were disabled, and checking both the SSL configuration with Qualsys SSLLabs and the headers with SecurityHeaders.io. Nothing terribly crazy, unfortunately. I look forward to going back next year as it was a really fun experience getting to help as both a security engineer and developer as well as getting to make new friends.
BSides Augusta Twitter Challenge Writeup
While I am not going to BSides Augusta, I noticed that they posted a challenge on twitter.
Well this certainly got my brain ticking.
The following is an account of what I did to solve the challenge as victor #10.
The first thing I noticed was that this was a hex string. I went to use a converter to see if this hex string would reveal anything when converted to ASCII.

Well this certainly doesn’t look like it means anything. My next thought was to think back to the Malware Analysis class. Perhaps this was XOR encoded? I sought out something to break the XOR encoding. While I was looking on GitHub for an appropriate project to pull down, I had a thought: “What has that many null bytes in a row? It’s almost as if the message is wrapped up in a package or something”.
That’s when it hit me. Could this be a file that I’m looking at? A small file containing a message? Let’s try Googling for magic numbers.

Ahh! GZip! I took the hexadecimal and wrote them into a file.

After extracting the GZip file I found a text file inside called data. Progress! Inside of “data” we had the following message:

Alright, let’s look at the IP address in a web browser to see if there’s a website.

I try a random username and password combination (test/test) to see what happens.

Okay, let’s try with admin/admin.

Usually the next thing I would do is poke around in the sources for the page to see if there are any hints there or obvious soft points.

Wonderful! The first one tells me that I really shouldn’t waste my time trying to brute force the login. The second note tells me that /home.html is probably where I want to go. Let’s go check it out. When I visit the address, it just redirects us to the index page again. I checked burp to see the mechanism for the redirect and to see if any information was leaked there but it’s just a javascript redirect.

I see there’s a call I can make to http://35.184.14.24/register with the appropriate values in the json body. I tried this with burp repeater but got hit with a 401 unauthorized. Okay, so the challenge isn’t to hit the endpoint directly, I need to get authorized somehow..
Let’s look at mechanisms it might use.
The place I first look is in the cookies. Right away I see something interesting.

From working with Base64 long enough, I can recognize eyJ as {" . Upon closer inspection, I can see . in the string. This is normally used as a separator in a JWT (Json Web Token). I look for a JWT parser so I can take a look at the information inside it more easily.

The first arrow points to the algorithm used to create the signature. The second arrow points to part of the payload. It says that our user is "guest" . The last, red arrow points to the secret we’ll use to validate the signature. Obviously, I won’t know the secret value to create a valid signature but if I did, it should validate. In fact, if I was able to figure out the secret value then I would be able to craft any JWT I want.
Welp, that’s what I tried to do.

Let’s download it and create an executable. I make jwtcrack and then run it.

Boom.

Our signature is valid. Let’s change my name to admin.

Let’s change my cookie and try to go to the /home.html page like the javascript file lead us to.

Awesome! (I changed the message to say #10 like when I solved it the first time. It said #11 when I solved it again for this post.)
I imagine that the login probably doesn’t even do anything, after solving this challenge.
Closing Remarks
The one thing I learned is that I should stop trying to figure out what I’m going to do for “next week’s article”. I find so much more enjoyment in the spontaneity of opportunities for me to learn and practice what I know.
See ya next week!
