HTB Write Up - Misc - misDIRection

2020-09-30 - Reading time: 10 minutes

Another Hack the Box write-up. This one is pretty short (EDIT: is it?), but it illustrates an unintended, but important gotcha that hit me.

But first...

I found out last time that a seemingly unwritten HTB convention* is that you only post write-ups for challenges that are retired (accessible to the paid VIP folks).

* Honestly, I only saw it mentioned while digging into the forums, and was
told about it later when I posted the previous one on Reddit.

While I didn't see an official explanation for this behavior, I suspect this is keep people from simply Googling for the flag. If that IS the case, I disagree with that idea: any good CTF'er will know to exclude the flag identifier -HTB or the CTF name (-"Hack the Box") when looking for information to help them legitimately solve the problem.

If someone is going to be a rotten rat and cheat their way through the challenges, well, that's kind of the risk you take when it's open to the public. Hiding the answers just means they'll squirrel them away out of sight for the rats to find. (Boy there's a lot of animals in this paragraph.)

And, of course, if it's simply to give value to VIP members, well, I have no interest in helping a business maintain a poor model. But I don't expect that to be the motive here. 😉

Suffice it to say, considering this one hasn't been retired since 2018, I won't be sharing it anywhere outside my own blog, apparently. And maybe Twitter. (Hi, Twitter!)

The Case Against Windows

I did this challenge, initially, using Windows. Mostly because this seemed like a pretty easy challenge, and I didn't think that would be a problem.

The challenge provides you with a zip file, appropriately named misDIRection.zip.

Unzipping the file produces a .secret/ directory, and inside a series of directories labelled 0-9a-zA-Z. Some of these are empty. But some have 0-byte files named after integers. There were no duplicates among them.

Archive:  ../misDIRection.zip
   creating: .secret/
   creating: .secret/S/
 extracting: .secret/S/1
   creating: .secret/V/
 extracting: .secret/V/35
   creating: .secret/F/
 extracting: .secret/F/2
 extracting: .secret/F/19
 extracting: .secret/F/27
   creating: .secret/o/
   creating: .secret/H/
   creating: .secret/A/
   creating: .secret/r/
   creating: .secret/m/
   creating: .secret/B/
 extracting: .secret/B/23

...etc...

I thought about this one for a bit, and considered how a message could be encoded.

Then I had an idea: what if the numbers map to a position in an output. Like, where file "1" is, that's in the S directory.  "2" is in F, etc.

So I started charting this out in Notepad, but I got about 4 letters deep and realized -- wait, I should be doing this in a programmatic way. There are tools for this. Work smarter.

So I pull up the WSL bash prompt and throw down: find . -type f | sort -k 1.13 -n

This finds all the file-type entries under the current directory and pipes the result into sort. The -k argument basically says to sort on the 13th column, and -n specifies a numeric sort.

This gave a pretty clear arrangement: SFrce0rjUjNjdeX5XzFUX1BSNdFUX1NPN2V9. NICE!

Not So Fast, Son

While this wasn't the flag, of course, it seemed like a solid lead into a second phase.

So I pull up CyberChef and start messing around with it. I go through the usual transformations I try, and Base64 immediately catches my eye: HZÜ{JãR3cuåù_1T_PR5ÑT_SO7e}.

It's so painfully close to what I'm looking for. You can SEE the skeleton of a legit Hack the Box flag: HTB{xxx_xxx_xxx_xxx}. You can see the curly braces, and the underscores, and even the opening "H". Presumably some of the other letters are correct as well, but you can't know that yet, of course.

So I went down some weird rabbit holes. The hashid tool thought it was BigCrypt:

Analyzing 'SFrce0rjUjNjdeX5XzFUX1BSNdFUX1NPN2V9'
[+] BigCrypt

And The Towel Was Thrown In

Everything I tried wound up being big time wasters.

So I gave up and looked for a write-up. Inside that write-up, the guy did everything I did:

WHAT?

I do a search for SFrce0rjUjNjdeX5XzFUX1BSNdFUX1NPN2V9 -- and sure enough, there it is.

Am I going crazy? It's just a basic Base64 decoding. Why is mine different?

Just to verify, I pipe it through the same base64 tool on my end. Nope. Still different.

What am I doing differently here?!

Then it dawns on me: I'm using Windows.

I'd gotten used to doing some formerly Unix-style command line stuff in Windows, thanks to WSL letting me bounce between the two worlds. And that was my mistake.

A Return to Relative Sanity

Let's take a look:

  • Some characters showed up fine.
  • The same string gave two different decodings.
  • How could that be?

Well, unzipping a file that creates an alphabet... both upper AND lowercase letters... oh shit.

Right: unzipping in Windows means ".secret/s" is the same directory as ".secret/S".

Which one you get depends on which one unzipped first. So I had a jumble of upper and lowercase directories that Windows went all YOLO on. And when I jumped over to WSL to do my find command, the damage was already done.

I needed to unzip the file from Unix.

So I nuked the entire directory and unpacked all of this from a proper Linux bash shell in my lab VM. And sure enough, I have a lot more directories.

I run my find command, and I get a slightly different version of my string: SFRCe0RJUjNjdEx5XzFuX1BsNDFuX1NpN2V9.

Note the case differences:

Wrong: SFrce0rjUjNjdeX5XzFUX1BSNdFUX1NPN2V9
Right: SFRCe0RJUjNjdEx5XzFuX1BsNDFuX1NpN2V9

So I pump that through base64 -d, and we get the CORRECT flag this time: HTB{DIR3ctLy_1n_Pl41n_Si7e}.

The Takeaway

This was frustrating, but still quite educational: in the future I might encounter an issue similar to this, and hopefully I'll remember this experience. I mean, I didn't look closely enough at my string, and searching for it in the write-up made me think it was 1:1 exactly the same. All because search tools are, by default, case insensitive. And Windows is case insensitive.

But I'm very sensitive. 😢

Seriously, though don't get too comfortable with Windows, man. It'll stab you when you're not looking!

I don't for a moment think the author of this challenge intended for this outcome. (I sure didn't.) But hey: thank goodness SOMEONE wrote a write-up on a non-retired Hack the Box challenge, huh? 😏

Elsewhere...