Tryhackme Write-UP: The Sticker Shop

Intro

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!

Write-Up

After connecting to the THM VPN, and visiting the web page we see a very simple web page with a home screen and a feedback page. Before we dive deeper into page source and network analysis. lets take a look at the feedback page.

As expected we find some user input here. We try popping an alert off the bat, and get nothing which isnt suprising. This will likely be our attack vector. But first lets see whats standing between us and the flag.

Lovely. If we take a look at the response headers. We see that the site is running on a Werkzeug Python server

Werkzeug is a WSGI (Web Server Gateway Interface) test server. It looks like WSGI is a specification that describes how web servers communicate with python web apps. Reading more, it appears to be the next generation of specifications like CGI FastCGI and mod_python, which rings a bell from a past project that used flask for the web server. As I recall, this is what people use Gunicorn for on NGINX servers.

Given that Werkzueg is a test service, I figure this is a fine place to start, so I did a little research on vulnerabilities and found that it’s got a directory traversal vulnerability as well as an RCE. The RCE looks like it might require user with valid creds, so lets see what we can do with directory traversal first.

I tried a few common encoded and escaped directory traversals, but I didnt have any luck. While researching into the vulnerability a bit more I found a werkzueg page on hacktricks. Hacktricks is gold, so I decided to start here.

Right off the bat we see that there’s an interactive python console page if debug is enabled…. Wait a minute… Flask debug console…

That’s right! I remember this debug console now from my work with flask. It was plastered all over the documentation to not ship with this enabled in production. We’re talking Big Bold Red letters. Well sick! lets see if its enabled.

*Sad Trombone* Okay, looks like it isn’t going to be that easy. lets continue on with scrolling through hacktricks. It sppears that we might also be able to trigger some request smuggling. I tried a few combinations though. and still no dice. I could rabbithole here, but we still havnt looked at the only other vector for user input on the site, and all I tried to do previously is pop an alert. Lets try some more injection now that we know what we’re running on.

We know that a basic XSS did nothing, but can we get a blind? Lets roll up a python web server and see…

Well would you look at that! We have a response! Now, lets write a little javascript to see if we can grab the spice.

And behold! We have our flag! Feels good man!

Summary

What did I learn? I learned about a few new vulnerabilities, and was reminded of the WSGI specification and it’s role in web servers. Mostly though I got back into the rhythm of hacking. This one was pretty simple, but hey, its easy. looking forward to more! ^_^