-
Notifications
You must be signed in to change notification settings - Fork 2
5_2_3 PrivEsc Server
If you have a shell on an NFS server and want to escalate privileges, you can use the same attacks that were shown against clients before.
Depending on the server configuration there are different approaches.
As a non-privileged user you can read the /etc/exports file to see the configuration of each export and use the mount command to see the mount options for the underlying file systems.
There are four cases where an attack is possible.
The first three attacks are exactly the same as the privilege escalation attacks on the client with the only difference that you execute the setuid binaries or access the device files from an unpriveileged shell on the server instead of the client.
Same as for clients in same situation. Upload a setuid binary that sets the uid to 0 from a client and run it on the server.
Same as for clients in same situation. Upload a device accessible to everyone from a client and access it on the server.
Same as for clients in same situation. Upload a setgid binary that starts a shell with the gid of the disk or the respective sudo group.
Export does not have no_root_squash set, underlying file system has nosuid set and export is not the root of the file system
With this configuration it is not possible to run any setuid binaries or upload device files.
There is still a method to access files which are outside the exported directory but on the same file system and accessible by a non-root user account to which you currently don't have access.
This works by creating hard links to these files in the export and then using the correct uid to access them via NFS.
The advantage of this attack over the file handle manipulation attack we discussed earlier is that it works on any file system that supports hard links even if subtree_check is enabled.
The exact attack is described in this article.
For this attack, the file has to be on the same file system as the export because hard links do not work across file systems.
Symbolic links will not work because in most cases they are only interpreted by the NFS client, not the server.
Here is an example on how to check if the preconditions are met and choose the right attack for a server. Assume that there is the following line in /etc/exports
/mnt/storage *(rw,no_root_squash)
And the following line when running mount
/dev/sdb1 on /mnt/storage type ext4 (rw,nosuid,relatime)
We can see that the export has no_root_squash set and the underlying file system is mounted with the nosuid option but without the nodev option.
In this case we cannot perform the first or third attack but the second one would work.
The fourth attack wouldn't be successful because the exported directory is the root of the file system which means that there are no other files to which we could create hard links.