# 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!
![image](https://user-images.githubusercontent.com/1072598/97641961-7a676380-1a1a-11eb-9840-985bf26e771b.png)
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. 
![image](https://user-images.githubusercontent.com/1072598/97642025-9a972280-1a1a-11eb-87b0-b3a5cbf2437a.png)
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. 
![image](https://user-images.githubusercontent.com/1072598/97642129-d0d4a200-1a1a-11eb-9d42-42d74f69780b.png)
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:
![image](https://user-images.githubusercontent.com/1072598/97642320-3c1e7400-1a1b-11eb-927d-5766fed17d1b.png)
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).
![image](https://user-images.githubusercontent.com/1072598/97642456-915a8580-1a1b-11eb-988e-e996dbdefdb8.png)
Looks like we have an `app` user with uid 1337 :P. How about /etc/shadow?
![image](https://user-images.githubusercontent.com/1072598/97642489-a9caa000-1a1b-11eb-9621-12457163dc71.png)
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? 
![image](https://user-images.githubusercontent.com/1072598/97642533-d2529a00-1a1b-11eb-9e15-cc09ddde14a2.png)
Looking at the response headers, it looks like there's an nginx server running, let's try to find the config for that?
![image](https://user-images.githubusercontent.com/1072598/97642568-e8f8f100-1a1b-11eb-9e1e-2cf3985d3fdb.png)
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.
![image](https://user-images.githubusercontent.com/1072598/97642640-15147200-1a1c-11eb-97df-62c2cc66c95e.png)
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!
![image](https://user-images.githubusercontent.com/1072598/97642928-c61b0c80-1a1c-11eb-907b-6cac076664ee.png)
Requesting `/static../server.py` and bam! We found our flag - `flag{0ff_by_sl4sh_n0w_1_hav3_y0ur_sourc3}`