Format
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 3000 10.129.86.64
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-14 03:41 EDT
Nmap scan report for 10.129.86.64
Host is up (0.16s latency).
Not shown: 65532 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
3000/tcp open pppWe have to add app.microblog.htb and microblog.htb to our /etc/hosts file to view port 80.
Microblog -> Blog Creation
Port 80 reveals a blogging service called Microblog:
At the bottom, it appears that the website creates new blogs by using new subdomains.
By clicking on Contrubute Here, we are redirected to port 3000 that hosts a Gitea instance with some source code:
Before going there, let's take a look at the rest of the website. After registering a user, it seems that we can 'create' a subdomain:
After creating one, we can edit it.
Going to the edit page reveals that we can use h1 or txt.
This would send a POST request to /edit/index.php:
Sunny Code Review -> LFI
When checking the application, it seems that we have a sunny subdomain.
Witin the sunny directory, it seems that there is an edit function. The PHP code for this is pretty long, so let's break it down:
This is standard session stuff, and it seems to use a bulletproof.php, which is an image uploader plugin.
The next part of the code seems to verify the users that owns a 'blog' and also checks if we are a Pro user. At the bottom of the code, there's a function that checks whether ourt user is 'Pro':
The Pro user is the target here, as it looks like command injection is possible. The last chunk of code has to do with the upload functions. Most of the functions are somewhat identical to each other, taking 2 POST parameters, with one being called id.
In this case, it seems that the id parameter is directly passed into fopen, meaning this could be vulnerable to LFI. Earlier, we created a new blog which created a new subdomain, so let's test our vulnerability there and confirm that it works.
This means that the code for new blogs are all the same. This means that the 'Pro' user portion is also present on our test blog. Also, it is worth noting that after a few minutes, our new blog and user is deleted from the browser as part of the cleanup script.
App Code Review -> Find Path
Let's take a look at the main site that is creating new subdomains.
It seems that when the new site is created, it is writeable for a while. Not sure what to do with this though.
After looking through all the code, the 'Pro' user method seems to be the correct way. The ProUser method would allow us to use bulletproof.php to upload files, of which we can probably upload some kind of PHP reverse shell and execute it. Now, we need to find out how to manipulate the Redis database to make ourselves Pro.
Redis Manipulation -> RCE
While researching possible exploits, I found that it was possible to use SSRF to manipulate the Redis database.
It is possible to set our session using SSRF using the HSET command on Redis. We can test this out by using this:
Afterwards, if we create a website, we notice that we can upload Images:
Great! We are a Pro User and can upload files now. Since we are Pro, this chunk of code would be executed:
This creates an /uploads directory and makes it writeable. This means that we can actually use the LFI to write a file. The reason this works is because of the code below:
The header parameter would have the contents of the PHP webshell, while the id parameter would have the full path of the file to be written since both are not sanitised. I used this HTTP request:
Afterwards, we can confirm we have RCE:
And then we can get a reverse shell:
Privilege Escalation
Pspy -> Cooper Creds
Within the machine, if we run pspy64, we would eventually see this:
We can use these credentials to access the user via ssh.
Format String -> Root Creds
When we check sudo privileges, we can see the user can run a Python script:
The script seems to do some stuff with Redis. First it checks whether the user is root, and some flags can be used. It does some string concatenation at the start too.
Afterwards, it connects to the Redis database and uses a secret password to do so:
The provision function is the longest, and it does quite a few things.
It seems to take a username parameter and then it checks if the user exists. Afterwards, it seems to create a license key for the user. This uses the {license.license} string to do so.
The format() string function is vulnerable to a few attacks, and the name of the box means that this is the intended method for PrivEsc. This gives rise to Format String Vulnerabilities:
Perhaps we can use this to dump the secret variable that is used. Maybe that's a hash for the root user. First, we can create a new user called user123 on the website and login to Redis on the machine to view it (use the socket file!):
Afterwards, when we run the license program, we get the License Key:
I first tried to use HSET to insert a user of our own choosing:
We can see that this is making an error occur within the script. We can see that the format() function uses license=l, so we can use that to dump the script's global context out:
Within this entire string is the root password of :unCR4ckaBL3Pa$$w0rd. We can then su to root.
Rooted!
Last updated