> For the complete documentation index, see [llms.txt](https://0xb0b.gitbook.io/writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xb0b.gitbook.io/writeups/tryhackme/2023/cat-pictures-2.md). # Cat Pictures 2 {% embed url="" %} ## 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 `bismuth`using 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. {% embed url="" %} 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.

Run the exploit and getting the thrid 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.