User Flag
We start by doing the usual nmap scans:
For now, in the nmap scan we can notice some interesting things: there is a ghost 5.58 and a /ghost dir. Let’s move on.
Two ports open: ssh and http. Starting with port 80 we do our typical vhost and dir scans on it.
There is a dev vhost, so let’s add it to the /etc/hosts file, and do a dir scan on it:
We collected a lot of useful information with theses scans. Let’s use it.
Checking the http://linkvortext.htb/ghost we are sent to a login panel:
In the site map file we can find a possible name of a user admin:
The dev host is not particularly interesting:
But in our scans we saw that there was a .git dir so let’s dump the repo:
We receive a repo with a lot of files:
Time to do some searching. One of the very first things to check when interacting with a git repo is to check its status:
Two files have been changed. Let’s look at them:
In the Dockerfile we can see that there is a config file copied to the container.
In the js file we can find many passwords, maybe one of these is the password for the login portal we saw before. So now we only need an email.
Let’s look at the .git to see if we can find one:
And we found one. It seems that the email format is [username]@linkvortex.htb
So let’s try with admin:
And immediately the first password works:
Looking around the application we can’t find nothing that interesting, so let’s google to see if can find an exploit. Googling for “ghost 5.58”, the first result gives us a list of vulnerabilities. One of those stands out:
First this vulnerability seems to have been fixed exactly on the next version of the one we are interacting with. Secondly, is an arbitrary File read. Maybe we can read the file we found that is being copied to the container?
Searching for the cve we find something very interesting:
This is some cheeky analysis, but you may notice that the owner to the github repo has the same name of the creator of the box:
So it seems that we are in the right track!
Looking at the exploit script, it seems we are able to upload symbolic links, disguised them as pictures and the backend doesn’t do any check for this. So the script creates a symbolic link to a file renames it as a .png, zips it and uploads it. Finally it curls the image and we should get the content of the file the symbolic link was point to.
Then we call the script:
Now let’s ask for a file:
And it seems to be working. Now for the file we saw being copied to the docker container /var/lib/ghost/config.production.json:
Right at the end of this file we conveniently get a username and a passwords.
Let’s see if we can ssh with this credential:
And we are in. Let’s ssh and get the user flag:
Root Flag
One of the first things to check is to see if we can run anything as sudo:
And sure enough we can. Let’s look at the script:
Looking at the script it seems to be doing something similar as the previous exploit. Expecting a symbolic link as .png and then moving it to quarantine and printing its content if the $CHECK_CONTENT var is True.
Now, if we pay attention we can see that the script only sets the var CHECK_CONTENT if this var is not zero. So we can do something like:
And when we run the script, when it gets to the final if $CHECK_CONTENT its going to run ‘/bin/cat /root/root.txt’ as root and print the flag:
