Skip to content

Latest commit

 

History

History
65 lines (34 loc) · 4.7 KB

redirector.md

File metadata and controls

65 lines (34 loc) · 4.7 KB

Redirector

200 points, 76 solves

You’re attempting to find sensitive information on a villain organization’s website, however, you are not having much luck. You notice that the site uses a lot of redirects, with some information on those redirect pages. However, you cannot inspect that information quick enough before you are redirected.

Link

Requirements

  • Burp Suite Community/Professional
  • FoxyProxy (optional for easy toggling between proxies). Set up link
  • Patience

Approach

This challenge had something to do with redirection, as the challenge title suggests. The first thing I did was to open up the page in a web browser. However, seems like this leads to another page saying it is not being redirected properly. We can see the initial url has a "/i" appended to it... Interesting...

img

I decided to use burp proxy to capture and analyse the traffic sent to the web server, as well as the headers. (Remember to turn Intercept On).

Removing the argument and reloading the page thereafter, we get a Intercept prompt, we get a change after the GET method--j... hmm this is suspicious and yet reminds me of a challenge I've done in the past in class.

img

img

img

Forwarding the traffic once more we get a c - wow! I was starting to think we got the flag since the format was jctf{xxx}. After forwarding the traffic a couple more times, we hit the end? After further inspection of the HTTP History tab, we see this and are able to roughly decipher the flag--j... c... t... f... {... y... 0... u... %7B... l... 1... k... E... m... Y... -... R... e... d... i.... Since url encoding is used, %7B can be decoded as underscore (_). So what we have now is jctf{y0u_l1kEmY-Redi... is this the flag? hmm not quite...

img

Tried to enter this but sadly got rejected. I thought maybe I mistyped something and went back to triple check. Then I asked for tech support thinking that there was some typo lol!

So the support guy gave me some clues that unexpectedly helped me figure out what to use (but he never heard of it himself apparently!)

img

After he said The last part is cut off! Perhaps, you need to extend the your redirects. I got an idea--to use burp repeater. So for every response given, I edited the letter behind the GET /. Take note that you will want to have a notepad at this point to document all the characters output as they will not be shown in the HTTP History tab.

We will first send any one of the responses with a character to the Repeater Tab (when you right click all of the content will be sent).

img

We then hit Go to send the request manually, since the web browser way didn't work... well it didn't fully (till the entire flag was printed).

img

Ok now we have some response with another character - r. Now what we need to do is replace i, which was our initial request, with r (the next request). i.e. the previous response will become the next request... you get the idea

img

img

After we reach the end of the flag format (character }), we will want to stop since we already get the entire format out. This finally lead to the flag (we can now stop here!): jctf{y0u_l1kEmY-Redir3CTs}.

img

If the characters were say url encoded (say in a new challenge), we could simply use the same method by url encode the ending character (i.e } to %7D), using the same logic to stop when we get the entire valid string.

Reflection

This was a rather meaningful challenge which reinforced my understanding of redirects and the use of burp repeater and burp as a whole, an invaluable tool for web-app pentesting.