Cat Pictures 2
Now with more Cat Pictures! - by gamercat
Recon
Scanning our target with Nmap we can discover five open ports, of which three are running a web server and two are an ssh server.
We have a web server on ports 80, 8080, and 3000. On Port 22 and 222 an SSH server.
On the web server on port 80 a photo management application called Lychee is running.
The application running on the web server on port 3000 is the software development platform Gitea, recognizable by the set cookie i_like_gitea.
Visiting the web servers, we are able to see, that on port 80 a Lychee instance is running with version 3.1.1.
On 8080 just nginx.
On Port 3000 as mentioned Gitea with version 1.17.3, and there is also already a user present, samarium.
Flag 1 - Metadata and Repositories
For the first flag, we are inspecting the contents of the web server on port 80. Here are some cat pictures in an album.
In the album itself, there are seven cute pictures of different cats. Each picture has some basic information.
But the first picture has a description that states "note to self; strip metadata". So maybe we can find some hints or information about the first flag in the metadata of this picture or the other ones.
Downloading the image and running Exiftool on that to retrieve the metadata of it does not reveal anything of interest.
Just by running Strings on the picture to print any printable characters in the file and looking at the first elements, we are able to receive the first hint.
On the webserver on port 8080 is a cryptic named text file hidden.
There we see a note from the dev himself, putting a password there to not forget it. In his perception of security, it is probably enough to have valuable things like user credentials that are hard to find. Besides the credentials, there is a second hint: that there is an Ansible runner - olivetin - running on port 1337.
With the found credentials we log in to the Gitea application.
From there, we are able to see a repository called Ansible in which the first flag is viewable.
Looking a the source of flag1 we are able to read it.
Flag 2 - Ansible and Playbooks
In the Ansible repository, a playbook.yaml is present. Which runs the whoami command as the user bismuth. As we remember, there is an Ansible runner present on port 1337.
Visiting the runner on port 1337 with a browser, we are able to run Ansible Playbooks.
And see the results in the logs.
Hitting the panel Run Ansible Playbook the playbook in the repository gets executed, and in the logs, we can see the results of whoami
Knowing this, we are able to execute OS commands by editing the playbook, running the playbook, and viewing the results in the logs.
To retrieve the second flag, we use the commands ls -lah to check where we are. And see, we might be in the home directory of the user bismuth with the flag2.txt being there.
Editing the playbook to be able to retrieve the second flag.
And we are able to retrieve the second flag.
Flag 3 - The Obvious and the Easy
While browsing the home directory using Ansible, we could see that there was also a .ssh directory there. Using Ansible we look into it and find a private SSH key id_rsa of the user bismuth. Via cat we get the key and edit it with the help of Cyberchef to restore it.
Get the private key of user bismuth.
Edit the key via Cyberchef, removing ",, and the spaces.
Next, add the correct permissions to the key and use it to log in as the user bismuthusing SSH.
From there, we are able to enumerate the machine. Neither are we able to run any commands as sudo without providing a password, nor are there any suid binaries to escalate privileges. Via SCP we get our tools like Linpeas and pspy to the target and make them executable.
Running Linpeas, we see that the PATH variable is set to a writeable location and stated as a 95% PE vector by Linpeas. A bin folder and .local/bin folder in the home directory of the user bismuth. That was my rabbit hole, which I want to briefly explain at the end. But there is also the version of the tool sudo marked.
Looking for an exploit, we directly get a hit. CVE-2021-3156 a Heap-Based Buffer Overflow in Sudo (Baron Samedit).
Next, we need an exploit that gives us a root shell to abuse this vulnerability. CptGibbon has a PoC exactly doing it.
For the exploit we have to get the files from his repository to the victim machine and compile the exploit via make, resulting in the exploit. Running it gives us a root shell, and we are able to retrieve the third flag.
Via SCP we transfer the source files from CptGibbon to the target machine.
There, we compile the result via make.
Running the exploit, we are able to get a root shell and retrieve the third flag.
My rabbit hole
From the Linpeas output with the 95% PE vector, I was highly distracted, didn't keep in mind possible other vulnerabilities, and just wanted to find a way to exploit the writable path.
So I thought that maybe placing a script at /home/bismuth/bin containing a reverse shell gets somehow called by the root user, by using a binary without an absolute path and the root user shares the same path variable - why not?
Checking cronjobs and running processes via pspy64 nothing was found. Then I had the idea, that executing the playbook might have some interactions with the root users. And it had. But it was not abuseable. Maybe this can be used in another CTF.
So keep this in mind; don't just get distracted by the most flashy and obvious things.
Last updated
