4 Overall, ASIS CTF was quite an enjoyable experience for me.
5 The challenges were interesting and required a lot of team effort to be solved, which I really liked.
6 That is why when I refer to "we" in the writeup, I mean me and the other studets that took part in the challenges and the Mattermost discussions.
8 For this CTF, I decided that I wanted to play only web challenges and that is why all of the challenges
9 in this writeup are web-based.
11 ## Attempted Challenges
12 ### Protected Area (Web) - SOLVED
15 The challenge was interesting, because it was not the typical web challenge that I was used to.
17 #### Gathering information
18 The website consisted of a plain HTML page with no inputs, no styling and no login forms. This could exclude XSS and SQL injection, but I was not quite sure yet.
20 The first thing I did is to study the page: I found a JS script that made requests to an endpoint and returned the content of remote files.
21 I also found out what functions are included and that the following requests were being made on page load:
23 http://66.172.33.148:8008/check_perm/readable/?file=public.txt
24 http://66.172.33.148:8008/read_file/?file=public.txt
27 Starting from there, I found out that the backend is written in Python (the `/check_perm` endpoint returns `True` for boolean -
28 doesn't necessarily mean it was Python, but it was worth a shot) that opens only `*.txt` files on the server.
30 That is when I was convinced that the intended exploit was some sort of path traversal.
33 Being the script kiddie I am, I tried scanning the page with [dirbuster](https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project) and got rate limited :).
35 While being rate limited, I researched for any vulnerabilities in the nginx and jquery versions,
36 but both of them were quite recent and nothing of worth was found.
38 When I got unbanned, I thought it was a good idea to try to inject python code (to use environment variables such as `$HOME`)
39 but this was not successful, because the code got converted to string.
41 When code injection was not possible, I tried doing path traversal to find out that `../` and `./` are ignored, even when URI-encoded.
43 We found out that the `/read_file` endpoint always returns `security` if the request does not end in `.txt`.
44 We used that and added a parameter that ends with `.txt` and we were able to read other files.
46 Knowing that the application was written in Python, we managed to read `app.py` and find a
47 file called `api.py` which showed us the URL of the protected area.
49 Apart from the protected area, `api.py` also showed us that the files `config.py` and `functions.py` existed.
50 In `config.py`, we found the admin password and a secret which would later on be used to login to the protected area.
51 In `functions.py`, we found out how the login gets checked.
52 We used that and the credentials we had found previously to get the flag.
54 ### Protected Area 2 (Web)
57 The challenge was sort of similar to Protected Area, but we didn't manage to solve it.
59 #### Gathering information
60 At first glance, the page looks more or less the same: same HTML page and `public.txt` contains the same content as before.
62 The JavaScript code was a little different, though, and mentioned `private.txt`,
63 which contained a link to a docker repository (https://github.com/tiangolo/uwsgi-nginx-flask-docker), possibly used for the challenge.
65 As expected, the trick with reading the files from the previous challenge didn't work.
67 Part of the information gathering was starting a container with the image
68 from above localyy, so that I could gather a better overview of the file structure.
71 The first thing I did was to try and find out if there are `docker-compose` files available -
72 no success as the `/check_perm/readable` endpoint, which I used to determine if certain files existed and were readable, didn't find anything.
74 After that I tried scanning the docker image from above for vulnerabilities with [Clair](https://github.com/quay/clair),
75 but nothing of interest was found.
77 Using the endpoint from above and path traversal (`../` was not escaped here),
78 I found out that we have the permission to read the nginx configuration and `app.py`.
80 We then found that we could read files by making requests like the following one:
82 curl -v http://66.172.33.148:5008/check_perm/read/?file=../app/main.py
85 Using the request from above, I found out that there is a `config.py` file in `/opt/py/app` which had inside where the flag is.
87 The flag was surely a file, but it was not readable.
89 I tried playing with the different endpoints but I didn't manage to open the file and the time for the CTF ran out.
94 The last challenge was marked as web, but it should have been marked as binary instead.
96 I started the ShareL as a way to distract myself from the protected areas,
97 but I hit so many problems in the information gathering phase that I decided to ditch it and continue with the other challenges.
99 #### Gathering information
100 The application consisted of a single `apk` file, which apparently was a link-sharing system.
102 I started an Android VM to test the app, but after installing it, the app only returned an error and nothing more.
103 I tried launching different architectures and using physicall devices that I had lying around, but nothing worked.
105 I then decompiled the binary using [apktool](https://ibotpeaches.github.io/Apktool/) to see what I could find.
106 I found the directory `smali/com/asisctf/ShareL` which contained different `smali` files but they weren't useful to me
107 as I don't know anything how to read them.
109 After hours spent on pointless browsing through the decompiled files and trying different ways to install the application, I gave
110 up and returned to the protected areas.