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? 😏


HTB Write Up - OSINT - ID Exposed

2020-09-24 - Reading time: 9 minutes

I've been doing a lot of TryHackMe rooms over the last week or two, but this morning I decided to jump over to HackTheBox to take a look at their OSINT challenges.

While I've never done a CTF write-up before, I want to start doing this a bit more often. Especially when I encounter new topics or concepts I've never encountered before.

We are looking for Sara Medson Cruz's last location, where she left a message. We need to find out what this message is! We only have her email: saramedsoncruz@gmail.com

With this bit of content, I spent a lot of time going through my usual routine...

Sherluckin' Out

First, I looked for the username saramedsoncruz using Sherlock. It's a tool written in Python that queries a ton of social media services. (There's websites for this, too.) This pulled up only a couple results:

[*] Checking username saramedsoncruz on:
[+] Pinterest: https://www.pinterest.com/saramedsoncruz/
[+] geocaching: https://www.geocaching.com/p/default.aspx?u=saramedsoncruz

When I saw the Geocaching link, I got excited. We could satisfy all of our requirements.

Her last location? Possibly! A potential message left? Sure! Maybe she took a picture of a message left in a cache. Or had comments about a cache she'd just found.

This seemed to be a lock... but, despite a match on that very specific username, it wound up going nowhere.

Struck out with the Pinterest link, but I had low hopes for that one.

Desperation Sets In...

At this point, I'm trying everything I know. Manually clawing though "Sara Cruz" accounts (and various permutations on the name) on Facebook and other social media sites. One even had a Guy Fawkes mask for an avatar -- I thought to myself "Some dumb hacker shit! Surely, this must be it!"

But, no. Another dead end.

As I'm searching around, I see a link talking about Google IDs and Gmail accounts. It looks interesting, but I put it aside.

I'm about to give up -- which is fine by me. Yeah, I'm always a little disappointed when I throw in the towel, but that's part of the reason I do these CTF challenges: to test what I know, and if it's something I don't know: learn. (From write-ups. Like this. 😏)

...when suddenly!

So I return to the HTB OSINT page, and I take a look at the name of the challenge so I can google a write-up.

"ID Exposed"... hey, waaaait a minute...

I think for a moment as that piece of information zip-zaps across my mind over to the article I'd found earlier: Getting a Grasp on GoogleIDs.

I'd completely overlooked a clue in the title. Turns out this was VERY relevant!

I'll leave the article for you to see the details, but long story short: there's a profile ID number attached to every Google account. There's a couple ways to get this ID outlined in the article.

In my case, I added it to my existing Google Contacts collection and sniffed the data-personid attribute from the modal dialog of the Contacts page when the contact is opened for editing (it may be seen elsewhere, but this is where I got it).

With this in hand, I went over to the People API people.get page, which lets you try executing an API endpoint. In order to execute this endpoint call, you'll need to give permission for your own Google account.

Following the instructions in the article, I plugged in "people/c6412528252752365100" for the resourceName, and "metadata" for the personFields field.

The call, successful, returned this block of JSON:

{
  "resourceName": "people/c6412528252752365100",
  "etag": "%EgMBNy4aBAECBQciDG1IQ1NWS3NJSEc0PQ==",
  "metadata": {
    "sources": [
      {
        "type": "CONTACT",
        "id": "58fde0788976062c",
        "etag": "#mHCSVKsIHG4=",
        "updateTime": "2020-09-24T15:59:18.216Z"
      },
      {
        "type": "PROFILE",
        "id": "117395327982835488254",
        "etag": "#4eZz2/IuMFw=",
        "profileMetadata": {
          "objectType": "PERSON",
          "userTypes": [
            "GOOGLE_USER"
          ]
        }
      }
    ],
    "objectType": "PERSON"
  }
}

Under the metadata -> sources entry with the PROFILE type, there is our GoogleID: 117395327982835488254.

Now That's Brazilliant

From here, we can look for various things (again, check the article for what's possible).

As it turns out, you can take a look at the 'contributions' that a GoogleID has made to Google Maps. This means reviews and photos, for the most part. Certainly the kind of data that would tick the boxes of what this CTF solution asks of us.

So, I tack the GoogleID onto the appropriate URL...

https://www.google.com/maps/contrib/117395327982835488254/

...and sure enough:

"Flag Watcher", huh? 😏

No photos, but they've posted a review for the 'Museu do Futebol' in Brazil, giving it a whopping five stars, and a terse comment of "really nice museum"...

Wait, there's more.

Like, literally 'More'.

Click it.

And there's our flag, buried in a bunch of percent signs to force the comment to collapse. :)

HTB{i_W4S_D_I_S_c_O_v_3_R_3_D}

Conclusion

It's okay to give up, as long as you're willing to learn.

Just be careful that you're not overlooking a clue being given to you. Few things suck more than bashing your head against the wall going down a dead end for an hour when a quick re-read of the CTF details might have prevented it. 😳


Elsewhere...