writeups/saschauer/tasteless19.md

   1 # rgb
   2 After browsing through a few challenges i decided to try my luck at this stego challenge.
   3
   4 This was a three part challenge: R, G, and B. So we had to find three flags in one .pcapng file.
   5
   6 The capture contained an http request and an answer that transferred a png image.
   7 I tried analyzing the image with various stego tools, but didn't really get anywhere.
   8
   9 After some time i was getting kind of frustrated, so i decided to move on.
  10
  11 # web-timewarp
  12 The challenge description read:
  13 ```
  14 !!! challenge will shutdown at approx 01:30 UTC !!!
  15
  16 If you haven't solved it until then, we don't think you'll be able to do it.
  17 ```
  18
  19 An important detail to know is that, on the day of the daylight savings time change. This meant that at 03:00 the time changed back to 02:00.
  20
  21 The landing page linked to two endpoints /token and /timewarp:
  22 `go <a href="/token">grab a token</a> and <a href="/timewarp">let's dance</a>!`
  23 Clicking on the first endpoint generates a token, which can then be submitted at the second endpoint.
  24 Unfortunately, if one tries to submit a newly generated token, it's already invalid:
  25 `oh no! too slow! your token is not valid anymore :(`
  26
  27 An token looked like this: `Z2l2ZUZsYWcvRXVyb3BlL0Jlcmxpbg==.U2F0IE9jdCAyNiAxNzoxNDo1NCAyMDE5.lKr4zkB4W0V9VZBnLLyT5ucqp0lCZxMpWEmZRPoZpKlmMHuXcBOg7Aeu6wJClpwYLNJCw_NmzBP6uVDSDyARAw==`
  28 These turned out to be 3 base64 encoded values separated by a `.`
  29 `giveFlag/Europe/Berlin.Sat Oct 26 17:14:54 2019.@x[E}Ug,*IBg\13)XID\19f0{p\13\a\ 2B\18,Bٳ\ 4T4\ 4@`
  30 or more general:
  31 `giveFlag/<server location>.<timestamp>.<some hash>`
  32
  33 If we tried to change location or timestamp, the server responded with:
  34 `oh no! what happened to your integrity?`
  35
  36 It seemed that the challenge was a bout somehow crafting a token, that was valid for long enough to actually be submitted, while still passing the servers integrity checks.
  37
  38 At this point i realized that the challenge description stated, that the challenge would shut down at 01:30 UTC, or 2:30 CET. This made sense, as it would be trivial to solve this challenge right after the time change. Just generate a token before it happens and it is valid for up to almost an hour. This would be way to easy, right?
  39
  40 What followed was a lot of time trying to figure out what kind of hash function could generate a valid token, if changing regions/submitting requests via proxys/etc. would change any parts of the token and could be abused somehow. All in vein.
  41
  42 I had to leave before the time to solve this challenge had come, but in the end we kinda had found the solution quiet at the beginning of our investigations.
  43 We could abuse the time change to generate a token that was valid for long enough.
  44 When thinking about this during the ctf, i kinda ruled out the possibility of this, due to the challenge description stating that the challenge would shut down at 2:30.
  45 In fact i think it did actually shut down around that time, when it came around for the second time that day.
  46 # Retrospective
  47 All in all, i enjoyed the ctf quiet a lot, although i didn't really contribute a lot.
  48 Both challenges were kinda frustrating, but i still had some fun working together on the challenges.
  49
  50
  51