Hack The Box - Poison

Enumeration

Nmap scans show only TCP ports 22 and 80 open, running SSH and HTTP. The web server is Apache 2.4.29, running on FreeBSD.

# Nmap 7.80SVN scan initiated Tue Feb 25 10:37:37 2020 as: nmap -A -Pn -p- --reason -oN scans/tcp_full 10.10.10.84
Nmap scan report for 10.10.10.84
Host is up, received user-set (0.046s latency).
Not shown: 65533 closed ports
Reason: 65533 conn-refused
PORT   STATE SERVICE REASON  VERSION
22/tcp open  ssh     syn-ack OpenSSH 7.2 (FreeBSD 20161230; protocol 2.0)
| ssh-hostkey: 
|   2048 e3:3b:7d:3c:8f:4b:8c:f9:cd:7f:d2:3a:ce:2d:ff:bb (RSA)
|   256 4c:e8:c6:02:bd:fc:83:ff:c9:80:01:54:7d:22:81:72 (ECDSA)
|_  256 0b:8f:d5:71:85:90:13:85:61:8b:eb:34:13:5f:94:3b (ED25519)
80/tcp open  http    syn-ack Apache httpd 2.4.29 ((FreeBSD) PHP/5.6.32)
|_http-server-header: Apache/2.4.29 (FreeBSD) PHP/5.6.32
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
Service Info: OS: FreeBSD; CPE: cpe:/o:freebsd:freebsd

Navigating to the webpage gives a fairly basic page, listing some PHP pages, and a field to insert a file to test.

Additional web directory search with dirsearch found no additional directories or files.


Initial Shell

LFI on PHP test page

When we put in the first test file in the list, ini.php, we’re redirected to the contents of the file. Not much interesting besides a few directory names here. However, that URL parameter looks like a great spot for an LFI. By the way, viewing the source on these pages makes them much more readable.

We can test this by inserting /etc/passwd into the file parameter in the URL. Sure enough, we have a solid LFI here, that can read out files on the server. From the output of /etc/passwd, we can see that we have a username of charix.

Cracking base64 encoded password

As interesting as the LFI is, we should keep looking at the other listed PHP files.

The info.php file gives a uname -a readout, containing the OS and kernel info.

When we open listfiles.php, we get another nice surprise. The pwdbackup.txt file looks to be in the same location as the PHP files we’ve been looking at, and should be accessible via the LFI we found.

Pulling up the pwdbackup.txt file in the LFI gives us this block of text.

This password is secure, it's encoded atleast 13 times.. what could go wrong really.. Vm0wd2QyUXlVWGxWV0d4WFlURndVRlpzWkZOalJsWjBUVlpPV0ZKc2JETlhhMk0xVmpKS1IySkVU bGhoTVVwVVZtcEdZV015U2tWVQpiR2hvVFZWd1ZWWnRjRWRUTWxKSVZtdGtXQXBpUm5CUFdWZDBS bVZHV25SalJYUlVUVlUxU1ZadGRGZFZaM0JwVmxad1dWWnRNVFJqCk1EQjRXa1prWVZKR1NsVlVW M040VGtaa2NtRkdaR2hWV0VKVVdXeGFTMVZHWkZoTlZGSlRDazFFUWpSV01qVlRZVEZLYzJOSVRs WmkKV0doNlZHeGFZVk5IVWtsVWJXaFdWMFZLVlZkWGVHRlRNbEY0VjI1U2ExSXdXbUZEYkZwelYy eG9XR0V4Y0hKWFZscExVakZPZEZKcwpaR2dLWVRCWk1GWkhkR0ZaVms1R1RsWmtZVkl5YUZkV01G WkxWbFprV0dWSFJsUk5WbkJZVmpKMGExWnRSWHBWYmtKRVlYcEdlVmxyClVsTldNREZ4Vm10NFYw MXVUak5hVm1SSFVqRldjd3BqUjJ0TFZXMDFRMkl4WkhOYVJGSlhUV3hLUjFSc1dtdFpWa2w1WVVa T1YwMUcKV2t4V2JGcHJWMGRXU0dSSGJFNWlSWEEyVmpKMFlXRXhXblJTV0hCV1ltczFSVmxzVm5k WFJsbDVDbVJIT1ZkTlJFWjRWbTEwTkZkRwpXbk5qUlhoV1lXdGFVRmw2UmxkamQzQlhZa2RPVEZk WGRHOVJiVlp6VjI1U2FsSlhVbGRVVmxwelRrWlplVTVWT1ZwV2EydzFXVlZhCmExWXdNVWNLVjJ0 NFYySkdjR2hhUlZWNFZsWkdkR1JGTldoTmJtTjNWbXBLTUdJeFVYaGlSbVJWWVRKb1YxbHJWVEZT Vm14elZteHcKVG1KR2NEQkRiVlpJVDFaa2FWWllRa3BYVmxadlpERlpkd3BOV0VaVFlrZG9hRlZz WkZOWFJsWnhVbXM1YW1RelFtaFZiVEZQVkVaawpXR1ZHV210TmJFWTBWakowVjFVeVNraFZiRnBW VmpOU00xcFhlRmRYUjFaSFdrWldhVkpZUW1GV2EyUXdDazVHU2tkalJGbExWRlZTCmMxSkdjRFpO Ukd4RVdub3dPVU5uUFQwSwo= 

Interesting. It seems they base64 encoded a password, and repeated it at least 13 times to better obfucate it. Let’s break it down. I saved the base64 text to a file called b64.pass, and used the below command to iterate thorugh it.

data=$(cat b64.pass); for i in $(seq 1 13); do data=$(echo $data | tr -d ' ' | base64 -d); done; echo $data

Running the command gives us a password of Charix!2#4%6&8(0.

We can now use this password on the SSH server as charix.

We can read user.txt from /home/charix/user.txt


Privilege Escalation

Secret.zip file

When we look in the /home/charix directory, we can see the secret.zip file.

After transferring it locally, we can try to unzip it, but it seems it requires a password.

Before jumping into cracking the ZIP, let’s just try to reuse the password for the charix account that we already have.

It worked! It seems the ZIP contained another file called secret, which looks to be a small binary file of some sort. Not really useful right now, but let’s keep it in mind.

TightVNC Service

In our enumeration, the ps -aux command reveals that there is a TightVNC service running as root.

A look at netstat -an reveals that indeed, it’s running on local ports 5801/5901, which is why we didn’t see them with our initial enumeration.

Since these are local ports, we can use our existing SSH credentials as charix to open an SSH tunnel for connection to them using our local machine.

The command ssh -L 5901:127.0.0.1:5901 charix@10.10.10.84 will open a new SSH connection, that will forward all traffic from port 5901 on our machine, to port 5901 on the target machine.

So remember that secret file we unzipped? We can use it as a credential for VNC. The below command will open a VNC session using the forwarded port, and captured credential.

vncviewer 127.0.0.1:5901 -passwd secret

We can read root.txt at /root/root.txt.