Does AZNFS SUID your needs? A Path to Root Privilege Escalation on Azure AI and HPC Workloads Using an Azure Storage Utility

An Azure utility for mounting Azure Storage that comes preinstalled on Azure HPC/AI images allowed an unprivileged user on a Linux machine with this utility installed to escalate their privileges to root.  

Varonis Threat Labs discovered the vulnerability in Azure AI and HPC workloads and found that it involves a classic privilege escalation method involving a SUID binary that is part of the installation of AZNFS-mount, a utility for mounting Azure Storage Account NFS endpoints. All versions up to 2.0.10 of the utility are affected. The vulnerability was disclosed to Azure, and although it was classified as low severity, a fix was merged to version 2.0.11 of the AZNFS-mount utility.   

Continue reading to learn more.

Azure Blob Storage overview 

One of the most popular cloud storage solutions, Azure Blob Storage is Microsoft’s solution for storing large amounts of unstructured data in the cloud.  

Blob storage supports several access methods, including a REST API that allows both authenticated and anonymous access, SFTP, and the NFS protocol. It is worth noting that access via SFTP or NFS does not interoperate with other Azure Storage permission models, such as role-based and attribute access controls.  

For instance, the NFS endpoint does not support access controls, and access to the endpoint allows access to all objects in the storage container. Varonis Threat Labs published an advisory about common pitfalls that customers face in Azure networking, including many areas in Azure Storage, in which you can read more details about such issues. 

Think like a threat with the Attacker's Playbook.

Learn more

AZNFS Mount utility 

 A utility called AZNFS Mount is used to mount a Blob Storage container to a Linux instance using the NFS protocol. This utility enables users to reliably access Azure Blob storage via NFS when the endpoint's IP address changes.  

Installation process 

AZNFS Mount is installed using an installation script, aznfs_install.sh, that is run as the root account since it will create binaries that will run as a super user to create mount points and change DNAT rules.  

To perform a mount to a storage account NFS endpoint, one would execute mount -t aznfs. This runs a binary called mount.aznfs, which calls a script to create the mount point. The binary mount.aznfs, installed as a SUID binary, used an insecure c function that could be exploited to run arbitrary commands as root on the system.  

SUID Binary: The key to privilege escalation 

A SUID binary is a binary with the Set User ID file mode bit activated. This bit means that the file should run with the UID of its owner instead of the UID of the user executing the file. 

A classic privilege escalation technique used in both capture-the-flag hacking challenges and real world scenarios involves searching for an exploitable SUID binary. This allows the attacker to read an inaccessible file or run a privileges command as another user.  

As shown in the above snippet, mount.aznfs is packaged with the 4755 mode. The 4 at the beginning means that the SUID bit is on, and 755 means that anyone can execute the binary. Now look at the code for this binary, which executes a Bash file located in /opt/microsoft/aznfs/mountscript.sh, and see if you can identify the vulnerability. 

Source code analysis 

This runs the Bash script using the function execv, which changes the running binary to the one provided, /bin/bash in this case, and starts executing it while keeping the original environment. This is unlike the function execve, which overrides the environment variables. Bash protects itself from being used for lateral movement and privilege escalation attacks by not agreeing to run if the UID is not equal to the real UID.  

Therefore, this code first uses setreuid to set the real UID to 0. To summarize, this binary allows us to set arbitrary environment variables and then execute /bin/bash with root permissions. 

Exploitation example 

The environment variable BASH_ENV contains an environment file for Bash to load before it starts executing. The following excerpt from the man page of Bash explains how this works: 

If this parameter is set when bash is executing a shell script, its value is interpreted as a filename containing commands to initialize the shell, as in ~/.bashrc. The value of BASH_ENV is subjected to parameter expansion, command substitution, and arithmetic expansion before being interpreted as a file name. PATH is not used to search for the resultant file name. 

The value of BASH_ENV is subject to command substitution before being used as a file name. By setting BASH_ENV to a value such as “$(command)”, Bash executes command and tries to evaluate its result as a filename to load. To reiterate the flow, an attacker needs to set the BASH_ENV environment variable to command and execute mount.aznfs to execute arbitrary commands as the root user on a Linux machine that has AZNFS-mount installed. 

Demonstration of the attack 

For example, a user could elevate permissions to root and use those permissions to mount additional Azure Storage containers, install malware or ransomware on the machine, and attempt to move laterally in the network or cloud environments. 

Disclosure and remediation 

The vulnerability was disclosed to Azure, and although it was classified as low severity, a fix was merged to version 2.0.11 of the AZNFS-mount utility. Azure customers using Azure HPC images or otherwise utilizing NFS for Azure Storage are advised to enable the utility's auto feature or to manually update the AZNFS-mount utility as soon as possible to protect their workloads.