Exploiting Network File System, (NFS), shares
NFS is predominately insecure in its implementation. System admins
are sometimes under pressure to get things done and its easy setting up
an NFS share and offering out to the default (everyone)! A more
secure format would be to assign hostnames/ IP addresses or utilises
some sort of TCP wrapper for access to the NFS shares i.e.
Export list for 192.168.0.1:
Any attempt then to try and mount these shares remotely returns:
failed, reason given by server: Permission
Use of NFS on a system can be determined if port 2049 is open, this is a
good indication, but it doesn't actually prove any folders are being
offered. A good way to determine this is to issue the command:
showmount -e IP_Address
Hopefully the expectant results will look something like this:
root@attacker]# showmount -e 192.168.0.1
Export list for 192.168.0.1:
In the example above you see /export/home
is open giving a good indication that possibly profiles or home
directories are stored in this directory. If this is the case a
couple of in-built pieces of security exists on the system, they are;
file permissions and the use of the sticky bit i.e. only that user can
interact with their own files.
To mount an NFS share use the following
after first creating a directory on your local machine:
[root@attacker~]#mount -t nfs
Hopefully is this goes well if you change
directory to /local_dir
you can see all sub directories on the remote machine in /export/home.
You ask now, how do you circumvent file
permissions and the use of the sticky bit, this is done with a little
prior planning and slight of hand to confuse the remote machine.
If we have a /export/home/dave
directory that we have gone into, we will see a number of files
belonging to dave, some or all of which you may be able to read.
The one thing the system will give you is the owners UID on the remote
system after issuing an ls -al command i.e.
-rwxr----- 517 wheel 898 daves_secret_doc
The permissions at the moment do not let
you do anything with the file as you are not the owner (yet) and not a
member of the group wheel.
Move away from the mount point and unmount
create a user called dave
and change the UID to 517
Remount the share as local root
Go into daves directory
issue the command
As you are local root you can do this and
as you have an account called dave you will not need a password
Now the quirky stuff - As the UID for your
local account dave matches the username and UID of the remote, the
remote system now thinks your his dave, hey presto you can now do
whatever you want with daves_secret_doc.
As an extention to this you can amend daves
scripts etc. to run commands, tftp stuff onto the box and do basically
whatever you please. The best thing to do obviously is to drop a
hidden netcat listener into daves directory and get it to open a port
and once again you can then get that infamous interactive shell on the
remote box. NEAT!!