Rating:
# Dotlocker 1
This was the only flag I managed to capture during the CTF itself, and this was definitely interesting enough to warrant a write up for both parts (we figured out Dotlocker 2 after the CTF ended)!
Visiting the main page we're greeted with the DotLocker application. Looks like it's specifically designed to do dotfile storage. Neat!
Generally with web apps you want to capture all the functionality you can, so I generally start off testing through all the workflows I can, so creating a new dotfile, creating one from a skeleton, etc etc.
The first thing to notice is that when you create a new dotfile from a template, it seems to be fetching it directly from the `/etc` directory! Interesting design choice, but also not entirely outside the realm of possibility if you've ever met "enterprise" developers :P.
So let's tinker! We have no idea about the stack at this point, but the standard LFI -> RCE path is to use your LFI to include `/proc/self/environ` and hope to inject code into one of the CGI environment variables passed in. Let's try that:
Hmm, no dice. Testing around for other files (`/var/log/auth.log`, `/var/log/messages`, etc) it's clear that we're likely constrained to `/etc` only :-/. Well, with that, what else can we see? Files like `/etc/shadow` and `/etc/passwd` help us enumerate users on the system (and potentially brute-force their credentials).
Looks like we have an `app` user with uid 1337 :P. How about /etc/shadow?
Interesting! This implies that the webserver isn't actually running as root on the box (the `app` user also helps confirm that) and likely doesn't have permissions to read that.
Anyway, what else can we examine in here that might give us hints?
Looking at the response headers, it looks like there's an nginx server running, let's try to find the config for that?
Hey that works, looks like we have our main nginx config file here and we can read it. Typically this file is more of a general catch-all config, most site configs live in `/etc/nginx/sites-enabled/default` or `/etc/nginx/sites-available/default`, so let's check those for more info.
A hah! That looks promising. With this config we're able to discern:
- There's a `/server` folder on the server, that's holding a `server.py` file
- This application is using gunicorn as it's python server, being proxied to through nginx
- This application has a `/static` directory, aliased to `/server/static`
The `/static` route shares out files using the nginx `alias`, but seems somewhat suspect (there are a few ways to configure these static routes, and alias isn't one I'm familiar with).
Googling "nginx alias vulnerability" lead me to https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/, which describes an issue with this exact config. Apparently not having a trailing `/` on `/static` means we can traverse up a directory and read files we shouldn't be able to, which is *very* relevant to our interests!
Requesting `/static../server.py` and bam! We found our flag - `flag{0ff_by_sl4sh_n0w_1_hav3_y0ur_sourc3}`
