Page cover

HTB Unbalanced

10.10.10.200 | 40 pts

PART 1 : INITIAL RECON

1.1 NMAP SCAN

$ nmap -oN nmap.tcp.initial --min-rate 5000 -p- -v 10.10.10.200

  PORT     STATE SERVICE
  22/tcp   open  ssh
  873/tcp  open  rsync
  3128/tcp open  squid-http

$ nmap -oN nmap.tcp.unbalanced -p 22,873,3128 -sC -sV -T4 10.10.10.200

  PORT     STATE SERVICE    VERSION
  22/tcp   open  ssh        OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
  | ssh-hostkey:
  |   2048 a2:76:5c:b0:88:6f:9e:62:e8:83:51:e7:cf:bf:2d:f2 (RSA)
  |   256 d0:65:fb:f6:3e:11:b1:d6:e6:f7:5e:c0:15:0c:0a:77 (ECDSA)
  |_  256 5e:2b:93:59:1d:49:28:8d:43:2c:c1:f7:e3:37:0f:83 (ED25519)
  873/tcp  open  rsync      (protocol version 31)
  3128/tcp open  http-proxy Squid http proxy 4.6
  |_http-server-header: squid/4.6
  |_http-title: ERROR: The requested URL could not be retrieved
  Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

PART 2 : PORT ENUMERATION

rsync seems to be open on port 873 and checking if there are any shared folders:

There is a shared folder named, conf_backups, which based on the description is probably an encrypted file share but it contains config files so some sort of credentials might be lying around somewhere.

There are a lot of files but it still needs to be decrypted. One way to do this is by using encfs2john:

Now that the files have been decrypted, the directory looks like this:

Since the files are now readable, we can begin searching for interesting information:

There is a password explicitly written in the Squid Proxy config file. This makes sense being the name of the box is Unbalanced so this must be about a misconfigured load balancer or something as there is an http proxy setup at port 3128.

What was also listed beside the cachemgr_passwd password are the options we could explore in the Squid Proxy Cache Manager.

I wrote a simple python script in order to explore the cache manager:

And now checking what we could do and get:

There are three things interesting here — intranet.unbalanced.htb (172.17.0.1), intranet-host2.unbalanced.htb (172.31.179.2), and intranet-host3.unbalanced.htb (172.31.179.3).

Opening intranet.unbalanced.htb after setting up my proxy (Foxy Proxy) leads me to:

Figure 1. Proxy Settings
Figure 2. Intranet Landing Page (/intranet.php)

Examining the reponse headers using curl:

The internal load balancer will either bring you to intranet-host2 or intranet-host3 which contains a login form and a contact form which doesn’t seem to do anything when you submit entries or fail to login.

But then you’ll notice something missing…​ what happened to intranet-host1? Since host2 is at 172.31.179.2 and host3 is at 172.31.179.3, maybe it’s at 172.31.179.1.

And it does exist but this time, when you go to /intranet.php and try to login, an error message now appears which was not apparent in the other hosted applications.

PART 3 : EXPLOITATION

After testing a simple SQL injection payload like ' or '1'='1, the form seems to be vulnerable as it returns a list of users and their respective roles. It is important to note that the form rejects capital letters so ' OR '1'='1 will not work. Comment characters also seem to be rejected.

Figure 4. User list

Since we have an error message and given the limitations of the form, maybe it could be leveraged to extract passwords for the listed users. I’ll focus on bryan since he has the role of System Administrator.

I wrote another python script for this:

Checking to see if the password works:

Figure 5. Successful login as bryan

And it does!

PART 4 : GENERATE USER SHELL (bryan)

PART 5 : PRIVILEGE ESCALATION (bryan → root)

Examining the TODO file in bryan’s home directory:

The file basically confirms the path to user where intranet-host1 is being troubleshooted but the important thing here is that there is a Pi-hole service running but is only available locally. It uses a temporary password so it’s probably insecure and new credentials may probably be found in the configuration script being created as of the moment.

Checking to see what we can connect to locally:

There is an error when trying to access the service running at port 8080 locally but according to this Reddit thread, it seems like you can go directly to /admin/.

The Pi-hole service can now be reached! However, it’s running via docker so I decided to look for an IP it might be running from and maybe access it via Squid Proxy. Looking back into the file, squid.conf:

Access to the IP range 172.16.0.0/12 (172.16.0.0 – 172.31.255.255) is allowed via the proxy and checking the interfaces available to the machine, I decided to do a ping sweep in the IP range, 172.31.0.1/16.

Aside from the previous intranet hosts, there is a new host identified --172.31.11.3. Trying to access it via Squid Proxy leads you to:

Figure 6. Pi-hole Landing Page

Now going to the login page, and remembering that a temporary password is set for the admin account, I tried "admin" and it went through but there is not much to do so I search also for an exploit for the current version of Pi-hole being run.

Figure 7. Pi-hole Login Page
Figure 8. Pi-hole Admin Panel
Figure 9. Pi-hole Version

Looking for exploits:

Setting up the exploit — I forwarded the locally available service inside the machine since HTTP proxies are very unreliable when establishing reverse shells afterwhich I setup a listener via netcat in my machine:

Then I ran the exploit:

Going back to the listener:

The /root directory is readable and in there is the Pi-hole config file mentioned earlier. A new password is visible and maybe this could be used to su to root:

And now, we have root!

PreviousHTB APTNextHTB Travel

Last updated