Hack the Box - BackDoor
Updated: May 28, 2022
Another easy machine that required several twists and turn along the way to root.
Starting off with a narrow attack surface on top of wordpress we find a plugins folder that reveals the use of a vulnerable plugin "ebook". From here we leverage a LFI vulnerability and this opens the door to dumping tcp information and discovering a hidden GDB server on port 1337. With the Metasploit console we can gain access as a user.
From here we conduct internal enumeration that reveals a root sessions of the "GNU screen" application. Researching the use of GNU screen we learn we can list existing sessions. Here we see the root session and attach to this session for access as root.
local file inclusion
GNU screen attaching
We start off with some basic enumeration and learn we have a very narrow attack surface. From here we conduct a more in depth scan. This is performed by using the NMAP flags
sC - use nse default enum scripts
sV - enumerate for versions
On further look we learn that port 22 is hosting SSH.
Port 80 is an Apache server running 2.4.41 with a banner that displays backdoor Real-Life. The banner also runs WordPress 5.8.1 which will require further investigation.
Port 5999 is currently filtered.
WhatWeb is highly customizable with over 900 plugins, each to help recognize something different. WhatWeb also looks for identification version numbers, email addresses, accounts ID's, web framework modules, SQL errors and more.
Apache - 2.4.41
Email - firstname.lastname@example.org
HTTPServer - Ubuntu Linux
JQuery - 3.6.0
MetaGenerator - WordPress 5.8.1
Poweredby WordPress - 5.8.1
Title - Backdoor
From here we enumerate WordPress 5.8.1 and look for exploits
Interesting Finding(s): [+] Headers | Interesting Entry: Server: Apache/2.4.41 (Ubuntu) | Found By: Headers (Passive Detection) | Confidence: 100% [+] XML-RPC seems to be enabled: http://backdoor.htb/xmlrpc.php | Found By: Direct Access (Aggressive Detection) | Confidence: 100% | References: | - http://codex.wordpress.org/XML-RPC_Pingback_API | - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_ghost_scanner/ | - https://www.rapid7.com/db/modules/auxiliary/dos/http/wordpress_xmlrpc_dos/ | - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_xmlrpc_login/ | - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_pingback_access/ [+] WordPress readme found: http://backdoor.htb/readme.html | Found By: Direct Access (Aggressive Detection) | Confidence: 100% [+] Upload directory has listing enabled: http://backdoor.htb/wp-content/uploads/ | Found By: Direct Access (Aggressive Detection) | Confidence: 100% [+] The external WP-Cron seems to be enabled: http://backdoor.htb/wp-cron.php | Found By: Direct Access (Aggressive Detection) | Confidence: 60% | References: | - https://www.iplocation.net/defend-wordpress-from-ddos | - https://github.com/wpscanteam/wpscan/issues/1299 [+] WordPress version 5.8.1 identified (Insecure, released on 2021-09-09). | Found By: Rss Generator (Passive Detection) | - http://backdoor.htb/index.php/feed/, <generator>https://wordpress.org/?v=5.8.1</generator> | - http://backdoor.htb/index.php/comments/feed/, <generator>https://wordpress.org/?v=5.8.1</generator> [+] WordPress theme in use: twentyseventeen | Location: http://backdoor.htb/wp-content/themes/twentyseventeen/ | Last Updated: 2022-01-25T00:00:00.000Z | Readme: http://backdoor.htb/wp-content/themes/twentyseventeen/readme.txt | [!] The version is out of date, the latest version is 2.9 | Style URL: http://backdoor.htb/wp-content/themes/twentyseventeen/style.css?ver=20201208 | Style Name: Twenty Seventeen | Style URI: https://wordpress.org/themes/twentyseventeen/ | Description: Twenty Seventeen brings your site to life with header video and immersive featured images. With a fo... | Author: the WordPress team | Author URI: https://wordpress.org/ | | Found By: Css Style In Homepage (Passive Detection) | | Version: 2.8 (80% confidence) | Found By: Style (Passive Detection) | - http://backdoor.htb/wp-content/themes/twentyseventeen/style.css?ver=20201208, Match: 'Version: 2.8' [+] Enumerating All Plugins (via Passive Methods) [i] No plugins Found. [+] Enumerating Config Backups (via Passive and Aggressive Methods) Checking Config Backups - Time: 00:00:04 <======================> (137 / 137) 100.00% Time: 00:00:04 [i] No Config Backups Found.
Dirbusting initially provides allot of results. But when we look recursively into the wp-content folder we see a plugin folder and learn about the ebook plugin.
Researching wordpress ebook exploit provides may results and we start from the top and land a useful found on exploit db.
We first see that this exploit is for version 1.1 which we will need to confirm.
We have a look at the POC of the payload and fortunately it is a simple LFI vulnerability.
Looking at the readme.txt of the file shows us we are indeed using version 1.1 and this exploit is indeed the matching version and therefore has potential.
Looking at the readme.txt confirmed the version of "stable tag" is 1.1.
=== Plugin Name === Contributors: zedna Donate link: https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=3ZVGZTC7ZPCH2&lc=CZ&item_name=Zedna%20Brickick%20Website¤cy_code=USD&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted Tags: ebook, file, download Requires at least: 3.0.4 Tested up to: 4.4 Stable tag: 1.1 License: GPLv2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Allow user to download your ebook custom file when insert an email.
Testing the vulnerability actually works and we receive the wp-config.php file.
Juicy information was found in this config file, however these credentials did not work on the wp-admin login page. So we will keep them in our back pocket for later if we perhaps have a MySQL server.
To further test our LFI vulnerability we target the /etc/password file in order to provide user information. It works and we successfully download and inspect the etc/passwd file.
/../etc/passwd/../etc/passwd/../etc/passwdroot:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin systemd-network:x:100:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin systemd-timesync:x:102:104:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin messagebus:x:103:106::/nonexistent:/usr/sbin/nologin syslog:x:104:110::/home/syslog:/usr/sbin/nologin _apt:x:105:65534::/nonexistent:/usr/sbin/nologin tss:x:106:111:TPM software stack,,,:/var/lib/tpm:/bin/false uuidd:x:107:112::/run/uuidd:/usr/sbin/nologin tcpdump:x:108:113::/nonexistent:/usr/sbin/nologin landscape:x:109:115::/var/lib/landscape:/usr/sbin/nologin pollinate:x:110:1::/var/cache/pollinate:/bin/false usbmux:x:111:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin sshd:x:112:65534::/run/sshd:/usr/sbin/nologin systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin user:x:1000:1000:user:/home/user:/bin/bash lxd:x:998:100::/var/snap/lxd/common/lxd:/bin/false mysql:x:113:118:MySQL Server,,,:/nonexistent:/bin/false <script>window.close()</script>
From here we understand there is a possible mySQL server running. We can't inject commands such as netstat in order to help determine the port of this mySQL server. We can however reference the /proc/net/tcp file file for a list of all active connections.
Reading this file however is not so straight forward. I had to reference the guide here.
With out /proc/net/tcp file on the left, we follow the instructions to identify our ports which are displayed in hexadecimal. We convert these to decimal and eventually find port 1337. We did in fact enumerate all the ports here and 1337 was the only open port. On top of that, it is a bit of an easter egg given the leet port number.
Running and nmap scan shows us the port is indeed open and the service is waste.
From here we couldn't interact with this port "waste" so we had to dive deeper.
Some research lead to the guide below which provided the /proc/sched_debug/ folder which holds information related to the active processes.
We download /proc/sched_debug file using our LFI vulnerability and notice that there was a gdbserver running which is quite anomalous and warrants further investigation. We can actually pull the specific commands involved in running that PID "22997" by downloading that PID folder where the read/writes occure.
This is accomplished below.
From here we look at the file and learn that the GDBServer is indeed on our 1337 port.
┌──(kali㉿kali)-[~/Downloads] └─$ cat cmdline /proc/22997/cmdline/proc/22997/cmdline/proc/22997/cmdlinegdbserver--once0.0.0.0:1337/bin/true<script>window.close()</script>
From here we configure the metasploit options.
We have to pay particular attention to the Exploit target ensuring it is of x64 architecture. We also pay particular attention to the payload, which is to be /linux/x64/shell_reverse_tcp as indicated in the exploit found on exploit DB.
We run the exploit and it works for access as user.
We perform our initial shell upgrade as usual with python3 -c 'import pty; pty.spawn("/bin/bash")'.
From here we upload linpeas as usual. From here, the GNU screen application executed as a cron job catches our eye. We can see it was run as root and carries an active session. However I don't know anything about the GNU screen application.
We do a little research on the wiki.
We do some research for exploits. Even check GTFO bins.
Here we find a vulnerability which however is for a different version of GNU screen. We confirm this buy checking the version of our GNU screen.
We use the info screen command and just check the header of the output.
Because the application was running as root, we look at the application manual.
Upgraded shell from here.
python3 -c 'import pty; pty.spawn("/bin/bash")'
Ran the screen command and received a weird error.
Running pspy64 for more information.
We satisfy the error by exporting the terminal required.
From here we are able to execute the screen command and pass appropriate flags.
We have several screens available to us and one of them is root. Unfortunately this was only because I had exploited this earlier and had not realized it with the following CVE.
Switching screens however gave me access as root.