# Frosteau Busy with Vim {% embed url="" %} All banner and comic images are courtesy of TryHackMe -

The following post by 0xb0b is licensed under [CC BY 4.0

](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1) ## Getting to SQ3 - The QR Code The QR Code to Side Quest 2 can be found in the Challenge `Task 17 [Day 11] **Active Directory** Jingle Bells, Shadow Spells` We are already in the Evil-WinRM session with the hash from VanSprinkels. On the administrator's desktop, we find a folder `chatlog_files`.

In addition to the flag and the folder on the desktop, we also find a HTML file. This contains the chat between the Yeti and McGreedy.

The files can be easily transferred to our machine via Evil-WinRM.

McGreedy has accidentally shared a screenshot containing the key to the next challenge, but has deleted it. As a solution, he cropped the image with Snip & Sketch and shared it again. This clearly indicates that we will probably have to restore the image to get the key.

Snip & Sketch appears to be the Windows Snipping Tool. {% embed url="" %} After searching for Snip & Sketch and crop recovery, we find the current `aCropolypse` vulnerability. This is a vulnerability related to `CVE 2023-21036`, about the tool Markup, a snipping tool on Google Pixel smartphones. Following aCropalypse's discovery there were more zero days found, affecting Snip & Sketch for Windows 10 and Snipping Tool for Windows 11. See: {% embed url="" %} In the folder, we not only find the cropped image, but also a screenshot of the desktop without the key. However, this gives us an important indication of the size of the image.

Here is the cropped image:

There are some tools to make use of this vulnerability. The following works in this case: {% embed url="" %} We download the project, install the requirements and start the tool directly.

We select restoring tool. Select our image to be restored, choose Windows 11 Snipping Tool and set the size to `2560x1080`.

## Frosteau's Laptop OK, let's start with side quest number 3 and see what we have in front of us. ### Recon We run a nmap scan and find 6 open ports, including two known ssh on 22 and HTTP on port 80, as well as 4 unknown ports. 8065, 8075, 8085 and 8095.

We run a second nmap scan on the found ports with a service and script scan. You can see here a shortened scan result, because the results and banner grabs are hard to read and would just blow up the snippet. They do not lead to any sufficient results except for port 8075 running FTP and the others running Telnet. ```bash ┌──(0xb0b㉿kali)-[~/Documents/tryhackme/sidequest/quest3] └─$ nmap -sT -sC -sV -p22,80,8065,8075,8085,8095 10.10.53.8 Starting Nmap 7.94SVN ( https://nmap.org ) at 2023-12-18 10:02 EST Nmap scan report for localhost (10.10.53.8) Host is up (0.039s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.9 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 3072 8f:5e:47:aa:e9:26:ac:cc:ea:64:a9:b5:65:1b:7d:72 (RSA) | 256 37:da:40:e4:61:1a:61:4c:1a:6f:ba:31:24:01:4c:12 (ECDSA) |_ 256 f3:7c:9e:92:e4:fd:d8:a1:78:4a:73:63:4a:6d:e9:ed (ED25519) 80/tcp open http WebSockify Python/3.8.10 |_http-server-header: WebSockify Python/3.8.10 |_http-title: Error response | fingerprint-strings: | GetRequest: | HTTP/1.1 405 Method Not Allowed | [...] | HTTPOptions: | HTTP/1.1 501 Unsupported method ('OPTIONS') |_ [...] 8065/tcp open telnet BusyBox telnetd 1.14.0 or later | fingerprint-strings: | GenericLines, GetRequest, Help, NCP, NULL, RPCCheck, SIPOptions, tn3270: |_ Ubuntu 22.04.3 LTS 8075/tcp open ftp BusyBox ftpd (D-Link DCS-932L IP-Cam camera) | ftp-anon: Anonymous FTP login allowed (FTP code 230) |_Can't get directory listing: PASV IP 172.18.0.2 is not the same as 10.10.53.8 | ftp-syst: | STAT: | Server status: | TYPE: BINARY |_Ok |_ftp-bounce: bounce working! 8085/tcp open telnet | fingerprint-strings: | NULL: | Ubuntu 22.04.3 LTS | [...] |_ 8095/tcp open telnet | fingerprint-strings: | GenericLines: | Ubuntu 22.04.3 LTS | [...] |_ Nmap done: 1 IP address (1 host up) scanned in 87.18 seconds ``` Ok, let's connect via Telnet to ports 8065, 8085 and 8095. When connecting with 8065 we only get the info `Ubuntu 22.04.3 LTS`, after that the connection closes directly.

When connecting to port 8085, we are greeted with the Vim banner. Nice, we have a Vim instance, as already announced in the room description and title. This could be interesting. Vim can be used to spawn shells or to browse the file system using a convenient explorer.

When connecting to port 8095, we see that we are confronted with the text editor Nano. This can also be interesting. Nano can at least be used to browse the file system using a convenient explorer. ### What is the value of the first flag? Let's first look at the FTP, we connect with FTP and can log in with the user `anonymous`, as the Nmap scan suggests. Here we find some files and pictures, and also the first two flags, apparently.

We download and inspect the file `flag-1-of-4.txt` and find the first flag.

### What is the value of the second flag? The second fold is not directly revealed in the file. But we have a shell script here that outputs the environment variable `$FLAG2`.

We can execute simple commands in Vim, let's try that. Maybe the shell script is just a hint to take a closer look at the environment variable on the target. Let's connect to 8085 the target Vim instance.

First we try to spawn a shell directly via `:shell`, unfortunately this does not work. More on this later. Instead, we can use `:echo` to display the second flag.

After we have executed `:echo $FLAG2` we get the second flag, nice.

### What is the value of the third flag? So far, so good. As already mentioned, we could not spawn a shell via `:shell`. Also, setting a new shell target via `:set shell` to the usual locations of a bash or sh binary did not work. So let's take a look at the file system first, maybe we have overlooked a binary. Via `:Ex`, we can use the Explorer functionality in Vim to browse the file system via Vim.

Using Ex: A little hint that I was confronted with. Here, my arrow keys for navigation did not work as expected and threw this error.

If you get that message using the arrow keys, you can try the following: Enter `:q` or terminate, reconnect and run `:Ex` again. Then use the following keys to navigate. **h, j, k, l:** * **`h`**: Move left. * **`j`**: Move down. * **`k`**: Move up. * **`l`**: Move right. We have the folder `/ftp` in `/tmp`, i.e. where our files are located in `ftp`. The executable files `nano` and `vim`, which may be used within the Telnet sessions.

Next, let's take a look at the environment variable of the current process in `/proc/self/environ`. Here we find the second flag again, the busybox is set both in `/etc/busybox` as a variable and `/etc/file/busybox`. The hostname is busybusybox. There is a strange protector script in `/usr/special/protector.sh`, we find the ftpd banner and a SHELL variable in `/tmp/sh`, although there is none there. OK, that's a lot of clues. Everything seems to revolve around the `busybox`. As a very brief digression: BusyBox is a software suite that provides a set of Unix utilities in a single executable file. It is designed to be lightweight and efficient, making it well-suited for embedded systems and resource-constrained environments. BusyBox combines several common command-line utilities, such as ls, cp, mv, and others, into a single binary. This is easier to interpret now that the box has been solved than it actually was, but with `/tmp/sh` it seems to be a hint to crafter your own shell and in particular to use the busybox as we will see in a moment.

We can actually find the busybox in `/etc/file`.

If we look in `/usr/bin` there are no binaries, even if we get a shell later, we can't do anything with it. Here it becomes clear that we have to make use of busybox since we are quite constrained. We do not have the usual binaries available.

Strangely enough, we find a shell binary in `/usr/frosty/sh`.

But it is empty, another hint to get it on the system yourself.

We look at the protector script, but it seems to be just a decoy.

Ok, we have ftp access to get files onto the system and vim to get them to where we need them. So the idea is to upload a static binary bash (like ) to the system via ftp and then write it to `/usr/frosty/sh` via vim, for example, to be able to spawn a shell in Vim. {% hint style="info" %} Before the patch /etc/file/busybox was executable by the user running the telnet / vim connection. So all that have to be done was to upload a static bash to the ftp, open that in vim, writes that content to /usr/frosty/sh set shell to /usr/frosty/sh, run shell, see you can’t run anything. Use /etc/file/busybox to run commands like whoami or ps aux to enumerate the machine further. This is not possible anymore, now we have to place our own busybox onto the machine. {% endhint %} Given that we have no other binaries on the system, we'll use the static binary busybox. Since busybox is not accessible, we need to create our own copy of it. Please upload it via FTP and write its content to `/tmp/nano`. Subsequently, rename `/tmp/nano` to `/tmp/busybox` to recognize its applets. {% embed url="" %} Upload busybox:

You don’t need `:Ex` here, but it is a very comfortable way to navigate. To open files use the following: `:e! path/to/your/file.txt` To write its contents to another file: `:w! path/to/your/file.txt` Open the uploaded busybox. `:e! /tmp/ftp/busybox`

Write `/tmp/ftp/busybox` contents to `/usr/frost/sh` `:w! /usr/frosty/sh`

Set the shell to `/usr/frosty/sh` in via `:set shell`.

After getting a shell, we see, we cant run any commands, even the found `/etc/file/busybox` doesnt work. (This worked pre patch)

Exit the shell via CTRL+D and open the busybox in `/tmp/ftp` again. `:e! /tmp/ftp/busybox`

Now write its content to `/tmp/nano`. `:w! /tmp/nano`

After that you might have to set shell again, run the shell and see that it did not work just replacing the contents of nano.

Exit the shell via CTRL+D again Now we make use of the Explorer in Vim again via `:Ex` Navigate to `/tmp/nano` and press capitalized `R` to rename `/tmp/nano` to `/tmp/busybox`

After successfully renaming `/tmp/nano` to `/tmp/busybox`…

...We run our shell again, now we are able to use if to its fully potential.

When enumerating the acutely running processes via `ps aux`, we find that the script `/usr/frosty/sh` is executed with root rights on `8065`. Great, we had our root in front of us the whole time, but didn't see it. Fortunately, we have already filled this file with the content of the busybox.

We connect via telnet with 8065 and have a shell session as root. Nice. Now we can either use our own `busybox` `/tmp/busybox` or the `/etc/file/busybox` already on the system to continue. We change the directory to `/root` and can use `ls` and `cat` via `busybox`. We find the third flag.

### What is the value of the fourth flag? When enumerating with the Vim explorer, `/dev/root` has already been noticed, but has not yet been mentioned because of the overview. As the room with its graphics suggests, it also seems to be about a docker escape. Looking around the system, we see that we are in a Docker container. `/dev/root` seems to be a mount point to the root directory of the host. It strongly reminds of the exploit with lxd/lxc right where you create a misconfigured container with a root mount to the host. But here it just seems to be there already. You can find more about this on hacktricks and in my dreaming writeup section `The Unintended (Bonus)` . {% embed url="" %} {% embed url="" %}

Ok, let's mount to `/dev/root` and see what happens. We are able to reach the root directory of the host. Damn, that was almost too easy.

From our mount directory, we reach to the home directory of the host's root. Here we find the fourth flag and the yeti key.

### What is the value of the third Yetikey that has been placed in the root directory to verify the compromise? And in the same folder, we find the `yetikey3.txt`.

## Credits To My Team {% embed url="" %} For working together on this challenge {% endembed %} Check out Sumanroy's writeups: {% embed url="" %} For working together on this challenge {% endembed %} For fully automated exploits created by my teammates, visit their GitHub profiles: {% embed url="" %} Automated SideQuest Exploits {% endembed %} {% embed url="" %} Automated SideQuest Exploits {% endembed %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://0xb0b.gitbook.io/writeups/tryhackme/2023/advent-of-cyber-23-side-quest/frosteau-busy-with-vim.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.