Frosteau Busy with Vim
Stay frosty! - by am03bam4n
Last updated
Stay frosty! - by am03bam4n
Last updated
All banner and comic images are courtesy of TryHackMe - https://www.tryhackme.com
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.
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:
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:
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.
OK, let's start with side quest number 3 and see what we have in front of us.
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.
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.
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.
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.
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 https://github.com/robxu9/bash-static/releases/tag/5.2.015-1.2.3-2) 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.
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.
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.
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.
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) .
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.
And in the same folder, we find the yetikey3.txt.
Check out Sumanroy's writeups: https://sumanroy.gitbook.io/ctf-writeups/
For fully automated exploits created by my teammates, visit their GitHub profiles:
The following post by 0xb0b is licensed under CC BY 4.0
