Shoppy HackTheBox WalkThrough
This is the Shoppy HackTheBox machine walkthrough. In this write-up, I have demonstrated step-by-step how I rooted the Shoppy HackTheBox machine. Before starting let us know something about this box. It is a Linux OS box with IP address 10.10.11.180 and difficulty easy assigned by its maker.
First, connect your PC with HackTheBox VPN and make sure you have connectivity with the Shoppy box by pinging its IP 10.10.11.180. If all goes correctly then start hacking. As usual, I started by scanning the machine. Scanning gives us an idea of how we have to proceed further. Like, it helps in banner grabbing the services running over different ports, and sometimes it helps in vulnerability assessment also. I have used $ nmap [a popular port scanner] for this task and the result is given below: –
Scanning
$ sudo nmap -p- -sT -oN fullTcpScan.nmap --min-rate=2000 10.10.11.180
$ sudo nmap -p22,80,9093 -sC -sV -oN ScriptScan.nmap 10.10.11.180
Full port scan with $ nmap found port no. 22, 80, and 9093 as open. OpenSSH on port 22, Nginx web server on port 80, and an unknown service named copycat on port 9093 are running. Didn’t know anything about copycat service. Googling it, revealed that it is some type of data replication service. We will dig deeper into it once we won’t get anything interesting on the other two ports which are ports 20 and 80.
On port 22, OpenSSH server of version 8.4p1 is running. Googling this version didn’t find any interesting vulnerability that can help us in further enumeration so we will skip the enumeration on this port. Using SSH we will remotely access the Shoppy machine once we will get any login credentials in the further enumeration.
On port 80, Nginx web server of version 1.23.1 is running. Again, googling this version didn’t find any interesting vulnerability that can help us in the further enumeration. Also, the $ nmap script http-title, revealed a virtual host shoppy.htb. So let us add shoppy.htb to our hosts file.
hosts file in Windows [located at C:\Windows\System32\drivers\etc\hosts] and Linux [located at /etc/hosts] operating system, translates hostnames [e.g. shoppy.htb] to IP addresses [e.g 10.10.11.180]. For example, if you add shoppy.htb 10.10.11.180 in the hosts file then when you visit http://shoppy.htb in the browser, its request will go to the server which is hosted at the IP 10.10.11.180.
And if there will be some virtual host routing enabled on the Nginx server, we will get a new website to enumerate on.
Hosts File After Modification 1
$ cat /etc/hosts
Ongoing to the URL http://shoppy.htb/ found a simple countdown page that is talking about Shoppy Beta be coming soon. Checked page source using the shortcut CTRL+U but did not find anything interesting. The information which I generally search for in the page source is, keywords content-generator [which gives us information of the CMS/web framework used by the application], comments [some hints are given by the developer for CTF players], and some similar sensitive information which help us in further enumeration.
While I was enumerating, I put my directory brute-forcing tool $ feroxbuster to run in the background and it found a login page that can be accessed through the URL http://shoppy.htb/login.
$ feroxbuster -u http://shoppy.htb/ -s 200
Ongoing to the URL http://shoppy.htb/login tried to log in with some well-known/default login credentials like admin : admin, admin : password, shoppy : password, etc., but none of them worked. Also tried some SQL Injection bypass payload but it also not worked. While I was watching a video on PHP juggling on @ippsec's YouTube channel, there he mentioned about converting the Content-Type of the request to perform juggling in PHP language to bypass the authentication. After following the same, I got some errors. I just changed the Content-Type of the login request from application/x-www-form-urlencoded to application/json and got the error.
Original Request
Modified Request
From the above error, we found the following information about the application.
Username: jaeger
Web Application Installation Directory: /home/jaeger/ShoppyApp
Application Language Info: JavaScript, Node.js [as a runtime environment]
According to the error, the application is using node_module which hints to us that the application is using node.js as a runtime environment and the application is written in JavaScript language. Once I get the name node JS some common points that strike my mind are, like
- the backend database used by the application may be a non-relational DB like
MongoDB,CouchDB,Redis, etc. - And the language used to access these DBs is
NoSQL[Not only SQL or non-SQL]. - In the
NoSQLdatabase, data is stored in the form of a document calledBSON[Binary JSON]Document. - We use
$ bsondumpcommand line tool to readBSONfiles. It converts BSON files into human-readable formats, including JSON.
Since the application is using some NoSQL database so I tried NoSQL injection in the login panel and found that it is vulnerable to NoSQL injection attack and I was able to bypass the login screen using the following payload.
Username: admin' || '3==3
Password: admin' || '3==3
Refer to this blog post at Imperva for more info regarding NoSQL injection vulnerability.
Click on the Search for users button and enter the same above payload there too [as shown in the screenshot given below] because the search field is also vulnerable to NoSQL injection attack. Click on the download button to download the content of the file.
We found two hashes at http://shoppy.htb/exports/export-search.json which is most probably an MD5 hash. We will identify them using tools like $ hashid or $ hash-identifier.
admin: 23c6877d9e2b564ef8b32c3a23de27b2
josh: 6ebcea65320589ca4f2f1ce039975995
Let us identify the type of hash and start cracking.
Identifying Hash
$ hash-identifier
HASH: 23c6877d9e2b564ef8b32c3a23de27b2
Hash-identifier found the type of hash is md5. Let us crack the hash. I have used JohnTheRipper [an offline password cracker] tool using rockyou.txt wordlist to crack the hash. rockyou.txt is present inside the directory /usr/share/wordlists/.
$ echo "23c6877d9e2b564ef8b32c3a23de27b2" > hashes
$ echo "6ebcea65320589ca4f2f1ce039975995" >> hashes
$ john --format=Raw-MD5 --wordlist=/usr/share/wordlists/rockyou.txt hashes
$ john --format=Raw-MD5 hashes --show
$ cat ~/.john/john.pot
The cracked hash is 6ebcea65320589ca4f2f1ce039975995 so the found credential is Josh : remembermethisway. When I tried to log in at http://shoppy.htb/login using this credential I could not log in. Tried to use this credential to login into the SSH account of user jaeger but got login failed again. When I didn’t find any way to proceed further then performed vhosts brute force. I have used $ ffuf tool with the wordlist bitquark-subdomains-top100000.txt to perform vhost brute force. bitquark-subdomains-top100000.txt wordlist is present inside the directory /usr/share/seclists/Discovery/DNS/.
$ ffuf -w /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt -u http://shoppy.htb -H "Host: FUZZ.shoppy.htb" -mc 200 -t 111
Vhost Bruteforce found a new host mattermost.shoppy.htb. Let us add it to our hosts file.
Hosts File After Modification 2
$ cat /etc/hosts
After adding the host mattermost.shoppy.htb to hosts file and going to the URL http://mattermost.shoppy.htb/ redirects to the login page.
When I tried to login into the account using the credential josh : remembermethisway it logged me in successfully. Ongoing to the URL http://mattermost.shoppy.htb/shoppy/channels/deploy after login, found some login credential jaeger : Sh0ppyBest@pp!.
When I tried to use this credential to SSH into jaeger’s account I could log in. So let’s get user shell.
Getting User Shell
$ ssh [email protected]
~Sh0ppyBest@pp!
$ whoami && id
Let us capture the user flag.
Capture User Flag
$ cat user.txt
Lateral Movement
Once we get into the machine, we do lateral movement in which we explore deeper into the compromised system to find files containing sensitive data, intellectual information, and other high-value assets that help us to proceed for privilege escalation or to do some high-level tasks.
During our lateral movement steps, we use various post-exploitation enumeration scripts like LinPEAS, LinEnum, pspy [for process monitoring], etc., or sometimes do manual enumeration to find misconfiguration in the system and various files.
$ sudo -l command found that user jaeger can run the password-manager file with the permission of user deploy. Or we can say user jaeger will become user deploy while password-manager is being executed.
When I ran password-manager using the user deploy’s permission it asked for the password. Entered the password of Sudo viz. Sh0ppyBest@pp!. It again, asked for the master password and tried to use the same password but it didn’t work. I also tried to use the password remembermethisway to login into the password-manager but it didn’t work.
$ sudo -u deploy /home/deploy/password-manager
~Sh0ppyBest@pp!
Please enter your master password: Sh0ppyBest@pp!
$ sudo -u deploy /home/deploy/password-manager
Please enter your master password: remembermethisway
Soon after I got Access denied! error I checked the content of the password-manager file using $ cat command. We can see the content of the file clearly as the file is not obfuscated. We can find the password of the file as shown in the highlighted part. The password of the file appears to be: Sample.
$ cat /home/deploy/password-manager
When I tried to open the file using the password Sample I could log in to the password-manager.
$ sudo -u deploy /home/deploy/password-manager
~Sample
Password-manager file contains the credential deploy : Deploying@pp!. Let us use this credential to switch to user deploy using the $ su command.
Switching to User Deploy
$ su deploy
~Deploying@pp!
$ bash
$ whoami && id
We can also SSH into shoppy box using the deploy credential.
$ ssh [email protected]
~Deploying@pp!
$ bash
$ whoami && id
We have successfully logged in to the deploy account.
Privilege Escalation
To escalate the privilege to root we have to first find Privilege Escalation Vector, using which we can perform privilege escalation. We can find the PrivEsc vector either manually or using some post-exploitation enumeration scripts like LinPEAS, LinEnum, pspy and there are a lot more. I commonly use LinPEAS first. This time too used LinPEAS.
Finding PrivEsc Vector
To run LinPEAS on shoppy box first download it to your kali machine using this URL. Then transfer it to shoppy box using the $ scp command. At last, execute the file on the shoppy box.
$ wget -q https://github.com/carlospolop/PEASS-ng/releases/download/20221113/linpeas.sh # Download LinPEAS locally
$ scp linpeas.sh [email protected]:/dev/shm # transfer the LinPEAS to Shoppy Box
~ Deploying@pp!
$ bash /dev/shm/linpeas.sh # On Shoppy Box
LinPEAS found that user deploy is the part of docker group, so it can be our potential privilege escalation vector and hence can be used to perform privilege escalation.
Googling docker privilege escalation Linux, found this link on the very first page of the search result. There are various ways to escalate the privilege by escaping the docker container. I have followed the below method and could easily escalate the privilege to root. So here our potential privilege escalation vector is privilege escalation by escaping the docker container.
Getting Root Shell
To perform privilege escalation, follow the below steps:
$ docker images
$ docker run -it -v /:/host/ --cap-add=ALL --security-opt apparmor=unconfined --security-opt seccomp=unconfined --security-opt label:disable --pid=host --userns=host --uts=host --cgroupns=host alpine chroot /host/ bash
# whoami && id
We have successfully performed the privilege escalation by escaping the docker container. Let us capture the root flag.
Capture Root Flag
# cat root/root.txt
Dumping Root Hash
# cat /etc/shadow | grep -i root
This was how I rooted the Shoppy HackTheBox machine. Learned a lot after this challenge, hope you will have also learned some new things. Thanks for reading this walkthrough. For any queries and suggestions about the walkthrough feel free to write us at [email protected].
