top of page

HTB Walkthrough: Shoppy




Tools and Resources

NoSQLMap: https://github.com/codingo/NoSQLMap

GTFOBins: https://gtfobins.github.io/

PayloadAllTheThings: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/NoSQL%20Injection#authentication-bypass




Enumeration with Nmap

We start with a basic Nmap enumeration and get the following:


We see we have the following open ports:

22/tcp

80/tcp

9093/tcp


We navigate to the IP address in our browser and see that it can't resolve to the domain name shoppy.htb, so we update our /etc/hosts file and get the following web page:



Directory Enumeration

We can use a tool like gobuster to enumerate the directories available on shoppy.htb:



We discover that there is a login page we can access and navigate to it in our browser:



Subdomain Enumeration

Before we continue digging on our login page, it's worth doing some subdomain enumeration to see if any subdomains exist for shoppy.htb. We can also use gobuster for this:



Upon completion, we can see that mattermost.shoppy.htb exists. When we navigate to it (after updating /etc/hosts) we see that we are also presented with a login page:



Authentication Bypass via NoSQL Injection


We start by pressing our luck on the admin login page for shoppy.htb. I tried a few generic login combinations and none seemed to work. I then checked to see if any of the fields (or the error parameter) were vulnerable to XSS, but that was also not the case. My next technique to explore was SQL injection. I noticed that I would get a gateway timeout error whenever I passed a payload with SQL query characters such as single quotes. This led me to believe that I was onto something.


I looked into what the actual POST request looked like using Burp Suite:


At the bottom we see our data parameters and how they're formatted, which will be helpful with our next step.


I copied the POST request to a text file and passed it to sqlmap to check for SQLi against the username parameter:


I wasn't really getting anywhere, so I started exploring the possibility of a NoSQLi. Enter NoSQLmap.


NoSQLMap Setup

NoSQLMap is available at http://github.com/codingo/nosqlmap.git


As of the writing of this blog post, NoSQLMap is only compatible with Python 2.7 and below. After cloning using git, pivot into the nosqlmap directory and execute the following:



sudo python2.7 setup.py install


After installation, you may encounter the following error when you try to run NoSQLMap:


This can be remediated by running the following commands:


sudo pip2 uninstall certifi
sudo pip2 install certifi==2018.10.15

After this, NoSQLMap should run fine and prompt you with a wizard-style interface:



Select 1 to set options, and make sure to set options 1, 3, and 6. From there, return to the main menu and select option 3:


From there, we get the following results:


We can determine that the web app interface is vulnerable to a NoSQLi. After attempting a plethora of NoSQLi payloads, this was the one that worked in the username field:


admin'||'1==1


Cred Dump

Once we login, we're presented with the following interface:


If we click on "search for users" and submit the same payload in the search bar, we're presented with an output of users and the MD5 sum of their passwords.


User Flag

Let's start with Josh's credentials. Save the MD5 string to a file and run hashcat against it and output it to a file:


When we try the creds against SSH, we see that they don't work. Where do we go next?


Remember that Mattermost subdomain? Let's try them there.


We are able to login and see we have several channels to pick from. After scouring through all of them, you'll find the following:


With those credentials, we can now SSH into the target host. The user flag is in the home file of the user you logged in with.


Root Flag

Looking through the directories with our newly established SSH connection, we come across a creds.txt file we don't have permissions to access under /home/deploy. From looking throuhg Mattermost, we figure out that the user jaeger made a password manager, which happens to reside in the same directory as creds.txt. We aren't able to just run the password-manager without sudo privileges, but just regular sudo doesn't work. We have to run it in the context of the user 'deploy':


sudo -u deploy /home/deploy/password-manager

(I figured out the above by running sudo -l)


We are then prompted for a master password. This can be obtained by "catting" the password-manager binary and skimming through what's readable.


Once you're in the password manager, you're presented with a new set of credentials for the deploy user. Use those to initiate another SSH session:



Once you've SSH'ed in, you'll see you're dropped into /home/deploy and you also have no sudo privileges. There's a hint in the mattermost chat that guides you into what you should gun for next:


The machine is using docker. If you google "docker privilege escalations" you'll come across the following page which is super helpful and I recommend bookmarking: https://gtfobins.github.io/gtfobins/docker/



Run the following command to escape the restricted environment and move into a root-level shell:


docker run -v /:/mnt --rm -it alpine chroot /mnt sh


146 views0 comments

Recent Posts

See All
bottom of page