NFS (Network File System) is a protocol that allows for easy sharing of files, primarily within a Linux environment. However, with that ease comes a number of security weaknesses, particularly if servers are poorly configured.

In particular, NFS typically relies on the client to enforce access controls – in corporate networks where all systems are centrally controlled, this isn’t a problem. If you can connect a rogue device however (or compromise another device on the network), then you can access files belonging to other users just by having the same user ID as the owner of the file. From a Linux system you have root access to, that’s fairly easy to achieve :-). In some cases, if you’re root on your machine, the NFS server will let you access any files root can.

Identifying NFS

NFS typically runs on port 2049, and uses the Linux Portmapper service – it will show up in NMap results like this

You can then enumerate any shares on the server with the “showmount” command, which is part of the “nfs-common” package on Debian based systems, and “nfs-utils” on RedHat based systems:

In this instance, we can see that “/public” and “/home” are shared. Mounting the NFS shares to browse them is fairly easy, and can be done by running the following commands as root:

mkdir /mnt/home-nfs/
mount -t nfs 10.13.37.146:home /mnt/home-nfs

You can then just browse to them as if they were a local file:

In this case we can see a list of user directories on the remote system. If we then try to access one, we can see that access is denied:

This would suggest that “root squashing” is enabled on the filesystem, as we were accessing it as the root user, but couldn’t access the content.

Accessing Other Users’ Content

If root squashing is enabled,  then in most cases you can access folders belonging to other users by creating a user with the same user ID (UID) as that user (other than UID 0 – root).
If this doesn’t work, then it’s likely that all users are “squashed” (i.e. have their UID set to “nfsnobody” or similar). This means you won’t be able to access any files belonging to other users.

In this example, only the root user is squashed. We can therefore access the “aaron” folder if we have a UID of 1018. The fact that we are seeing the UID tells us that no local user exists with that UID, so we will need to create one. This can be done with the following command (as root):

useradd -u 1018 pentest

To switch to the newly created user, just run:

su - pentest

We can then browse to the directory and see what’s inside:

The presence of the “.bash_history” and “.ssh” folders suggest that this is a user’s home directory, and the “public_html” folder suggests that the Apache “UserDir” plugin is in use.

If you already have a user with a UID that corresponds to one of folders you want to access, the username of the local user will be listed instead of the UID:

You can then just access the files as that user:

Getting a Shell

Depending on the folders that are shared, it may be possible to view or modify files with a view to gaining a shell – of particular interest are the following:

• config or history files containing passwords
• writeable web directories
• writeable directories containing executables (such as /sbin or /bin)
• writeable user profiles

Interesting Configuration Files

It’s worth looking through any configuration files for passwords – of particular value can be files within the web root, such as wp-config.php, web.config, .htaccess files or similar; as well as user or administrator scripts, which may contain hard coded passwords. If you’ve got lots to search through, some clever grepping may be in order.

User command history files can also be a treasure trove of passwords, especially if users type in the password as part of the command, or paste it into the terminal by mistake.

Uploading Web Content

If you have write access to a web directory (such as /var/www/html or /home/user/public_html),  depending on the configuration, it may be possible to upload a custom PHP file containing a web shell, such as the following:

This can then be called via HTTP to execute arbitrary commands on the server:

Uploading an SSH Key

If you have write access to a user’s home directory, and the server also has SSH listening, then you could add your own SSH key to the authorized_keys file. If the “.ssh” directory within the user profile doesn’t already exist, creating it is quite simple.

If you don’t already have an SSH key, you will need to create one:

You can then just copy your public key into the authorized_keys file with the following command:

cat ~/.ssh/id_rsa.pub >> .ssh/authorized_keys

Make sure that the file permissions are appropriately set on the authorized_keys file (it should be 600).

Next SSH into the server as that user:

Privilege Escalation

If you have a method of executing code on a system, and have access to an NFS share that doesn’t utilise root squashing, then it might be possible to gain elevated (root) privileges on the system

Simply put, the lack of root squashing will let you upload your own binary files that have a Set UID to root – if you then run these as a normal user on the remote system, they will execute with root privileges.

It turns out Bash won’t run with root privileges if it has the SetUID bit set; but other tools, like Nano or VIM will.

Setting the SUID Bit

To set the SUID bit, connect to the share as root and run the following command against your uploaded file:

chmod u+s uploadedfile

If you then run “ls -la”, you will see that the “s” flag appears in the user permissions, indicating that it is a SUID binary:

Privilege Escalation with a Text Editor

If you have access to a SUID text editor, then you access any file that root can, with the permissions that root has. This means you can read the shadow file, or modify any number of configuration files. In this instance, we’re going to add an entry to the sudoers file.

To do this, launch the copy of nano in the NFS folder, and tell it to open /etc/sudoers:

Then add a sudoers entry to allow our user to run any command as root, without the password (as we don’t know it):

Save the file, and then you should be able to sudo:

As always, patching can break things; but I’ve generally not had too many issues, and I usually just blindly patch anyway – if you read the patch notes before deploying updates, and check for compatibility, this probably isn’t for you :-).

Anyway – to configure automatic updates in Linux, you need to create the cron jobs as root, so the easiest way is to either login as root (typically a bad idea) or su to root from your usual user account. In my case, this was done with:

sudo su -

You can then add your automatic update command by editing the crontab file with the following command:

crontab -e

If you are given a choice,  Nano is typically easier to use for novices. With vi, you will need to use the following steps:

1. Press”i” to begin editing
2. Enter the desired Values
3. Press “Esc” to stop editing
4. Type “:wq” and press Enter to exit.

RedHat/CentOS

RedHat, CentOS, Fedora and other RedHat derived operating systems use RPM as their package manager, with the “yum” tool used to manage the updates. For automated Linux patching on these systems, you can use the following entry:

@reboot yum update
0 09,21 * * * yum update -y

This will run “yum update” at every reboot, and at 09:00 and 21:00 each day. Updating every 12 hours should be frequent enough for most systems.

Debian/Ubuntu

Debian based operating systems, such as Ubuntu and Linux Mint, use DPKG as their package manager, with the “apt” tool used to manage the updates. To automatically update your Debian/Ubuntu system, you can use the following entry:

@reboot apt-get update && apt-get upgrade -y
50 09,21 * * * apt-get update && apt-get upgrade -y

This will update the apt package manager software list, and then install any updates at every reboot, and at 09:50 and 21:50 each day.

I’ve been playing around with AWS for a while, and had worked out a fairly easy way to keep the underlying OS of my EC2 instance patched; but wanted a way to avoid having to manually update WordPress and all its plugins, templates, etc.

I know that it’s generally considered a bad idea to install updates without reading the patch notes, but I’m usually the kind of guy who clicks “Update” without reading them anyway – so, if you’re happy to take the risk, keep reading, otherwise, it’s probably best to update manually (ensuring you still apply your updates regularly!).

In short, the aim of this post is to document how to:

• Configure WordPress to automatically update itself
• Configure WordPress to automatically update plugins and themes
• Run a Cron job to automatically trigger the WordPress update process

Patching WordPress

By default, WordPress will happily update minor versions. To apply major updates as well, you need to add the following to your wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', true );

To patch plugins and themes, you need to add in some filters, which WordPress recommend you do in a custom plugin. They suggest a must-use plugin for this purpose, which can be configured by adding a “mu-plugins” folder to the “wp-content” directory

Within this folder, you can then create a php file containing the following:

<?php
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' );
?>

Configuring Cron Jobs

Disable WP-Cron

As I wanted to use cron jobs to manage the update process for me, I disabled wp-cron by adding the following to the wp-config.php file:

define('DISABLE_WP_CRON', true);

Add a Crontab Entry

You can then add the following to the crontab file for the user you want to run the updates as (for ease, this could be “apache”, but I went with a custom user:

*/15 * * * * cd /var/www/html; php /var/www/html/wp-cron.php

This will run every 15 minutes and perform any other actions you have set to run with WP-Cron.

Force Updates

I found that I had issues with getting the updates to trigger reliably though, so discovered the following will force WordPress to update immediately:

<?php
 // request-update.php
 require( dirname(__FILE__) . '/wp-load.php' );
 wp_maybe_auto_update();
?>