Team82 today shares some details about a unique attack technique that could allow an attacker to impersonate Western Digital (WD) network-attached storage (NAS) devices.
Our technique allowed us to enumerate all cloud-connected WD devices, impersonate them, and gain access to every device via the WD MyCloud services.
We found four vulnerabilities, all of which were disclosed during Pwn2Own Toronto last December.
An attacker could have chained these vulnerabilities to not only enumerate all devices, but also access their information and files, and remotely run code on the device.
Western Digital has provided firmware updates for all affected devices and also released advisories (here, here and here). Connected devices have been updated automatically.
Any device yet to be updated has been banned by WD from connecting to the MyCloud service until it’s running the current firmware version.
The Zero Day Initiative, which organizes the Pwn2Own events, also published advisories:
Western Digital, one of the biggest network-attached storage (NAS) vendors in the world, provides its users with a cloud service called MyCloud OS5 that allows them to access their device remotely via a web-based or mobile application. Like most cloud services that are marketed for convenience and functionality, there are potentially severe risks that run in parallel.
In preparation for last December’s Pwn2Own Toronto hacking competition, we conducted research into WD’s cloud architecture to expose those risks with a goal of not only accessing files but also to execute code on other devices.
One of the first things we do when we look for vulnerabilities in a product, is to better understand the functionality and use-cases of the device. This includes answering questions like:
What features does the device have?
How do users interact with the device?
What open services does the device expose?
What internet services does the device connect to?
What is the trust model in place on the system?
Our job is to better understand the attack vectors that are relevant for the device, which translates to how attackers could approach and try to exploit the device.
Similar to our research into Synology’s DS920+ NAS devices and cloud service, we understood that unauthorized access to user devices through the front door would be difficult. Developers are well versed in today’s authentication frameworks and libraries to ensure that API requests are well protected, requiring valid authentication tokens and deploying checks on all authorization requests to interact with resources. This security mechanism blocks potential IDOR vulnerabilities (insecure direct object references) and prevents one user from accessing another’s assets.
We instead focused on targeting the device’s end of the cloud-based architecture—in both cases—to reach our research goals of access and code execution. We developed a unique approach by which we were able to find weaknesses in the cloud-based communication channel in order to impersonate the device and force the cloud to trust any device connecting to it.
By impersonating the device, we were able to “steal” the device-to-cloud communication tunnel, and redirect users to a device we controlled instead of the real device. We used this to steal the user credentials and session tokens, which are constantly sent to the device for a background content refresh. We then chained multiple additional vulnerabilities that enabled us to leverage our newly gained permissions to achieve remote code execution on the NAS devices, giving us full control over the device.
At the end of our research, we devised both a method of enumeration of all cloud connected devices, along with the ability to impersonate the devices in order to execute arbitrary code on them. By leveraging the cloud, attackers could attack and exploit all WD-cloud connected devices, potentially giving them access to billions of files and hundreds-of-thousands of home networks and devices.
Western Digital has fixed all of the vulnerabilities we uncovered and disclosed during Pwn2Own Toronto. Updated firmware versions are available for affected versions of Western Digital My Cloud OS 5, My Cloud Home, and SanDisk ibi. Devices still running vulnerable firmware, as of March 23, were banned by Western Digital from connecting to cloud services; users should upgrade affected firmware versions immediately given the severity of these vulnerabilities.
Western Digital My Cloud Pro Series PR4100 is a network-attached storage product that aims to provide storage solutions for the “small office/home office” marketplace. The PR4100 offers an easy-to-use ecosystem, allowing users to manage their device, set up new shares for file accessibility, and enable automatic backups.
Behind the scenes, PR4100 devices run a customized Intel X86 64-bit Linux OS. The NAS exposes multiple network services:
Web management service (nasAdmin): n HTTP/S web server written in Golang. This service binds on TCP/80 for its HTTP server, and TCP/8543 for its HTTPS server.
Cloud communication service (restsdk-server): an HTTP/S web server written in Golang, handling most cloud communication. This service binds multiple ports: TCP/8001, TCP/8003 and TCP/4430.
SMB server (smbd): TCP/139 and TCP/445.
UPNP Service (upnp_nas_device): TCP/49152
FTP service (Pure-FTPd): TCP/21
We usually try to use an actual device when we can because it makes the researching process easier and more reliable. Owning a device also enables us to interact with the vendor’s other services that require an actual device, such as a cloud service.
When we began our research, we immediately bought and shipped a device, however we could not hold our excitement and wait for the device to arrive, so we started researching it before it arrived. Luckily for us, WD provides the device firmware on its website, so we downloaded the file and started exploring it.
Usually firmware is a big binary blob composed of multiple sections, either in an encrypted or unencrypted form. Luckily for us, this firmware was not encrypted, meaning we could extract it using binwalk.
There were 3 important sections in WD’s firmware:
Squashfs: The device’s filesystem, including general-purpose binaries, device-specific binaries, directory structure etc.
gzip: The device’s configuration files, containing all of its service’s configurations.
xz: Libraries for the device’s binaries.
Sadly, since we had multiple sections in the firmware, and most binaries required a specific directory and file structure to work correctly, we could not just “boot up” the emulated device: first we had to reconstruct its filesystem.
Lucky for us, we discovered a bash script named system_init inside the firmware that tries to copy many of the configuration files and binaries to their intended directory. By working with this script as a baseline, and making minor adjustments to the script, we were able to reconstruct the filesystem inside a virtual machine.
We then used chroot in order to “enter” our newly created filesystem, and started the different services on the device. We now had a usable NAS device we could explore while waiting for our own device to arrive, however we also have a better understanding of the device’s filesystem and service which was even more important.
In the past, Western Digital used an Apache httpd server along with multiple PHP and CGI scripts. Multiple vulnerabilities were discovered in that service in the past, so it was the entry point for our research. While we did see the PHP files and CGI binaries inside the firmware, we discovered that Western Digital changed the management server architecture. It was no longer exposed. Httpd now only binded to port 8000 on the localhost interface. This meant that a new binary now acted as the front for the management server.
After some digging, we discovered that a new Golang binary actually exposed port 80: nasAdmin. After some reverse engineering, we learned that this new binary’s main purpose was session management: it handles the authentication routes for the HTTP server. After a user authenticates successfully, nasAdmin issues the user a JSON web token (JWT) session key, and forwards any requests that contain this session key to the backend httpd server.
While we did manage to identify a few remote code execution vulnerabilities in the PHP files and CGI scripts, since only authenticated requests could actually access them, these vulnerabilities were not practical. Since we did not manage to identify a method of bypassing the nasAdmin authentication check, we had to look elsewhere for our vulnerabilities.
This was when we decided to take a closer look at Western Digital cloud services: OS5 My Cloud.
In order to allow users to access their files at any time from anywhere, Western Digital implemented a cloud service called OS5 My Cloud. This service allows users to access their NAS device through a designated mobile/web application. It also introduces new attack vectors for attackers to abuse.
Our goal in the research into OS5 cloud was to see if we could leverage its functionality in order to interact with other people’s NAS devices. Even if we were able to access other people’s files, it could affect millions of people, however our underlying goal was not only gaining access to files but gaining the ability to execute code on other people’s devices.
We started by enabling the cloud feature on our device, and registering it to the cloud. We then created a user account for ourselves, and started exploring the web application.
When we looked at the HTTP requests performed by the application, we noticed that whenever the application tries to fetch information from the actual device, the following URL suffix is used:
https://prod-940b1d9bbad9901.wdckeystone.com/
6eff0470-804a-4d12-9e3d-88f090de36f0/sdk/v1/volumes
This GUID was used as an identifier to tell the cloud which device we want to access. We then tried the naive approach, and tried accessing the same URL without our session tokens: and were blocked. This meant we were not authorized to access the device without a valid OS5 token.
However, when we took a closer look, we noticed that something did happen: a new connection to our device was created. This meant that we did not get blocked by Western Digital cloud, instead we reached the device and did not have permissions. This was actually a pretty big deal, because we actually reached the device which was sitting in an internal network and was not network exposed. This meant that by only knowing a device GUID, we could interact with it. While this did not give us immediate control over the device, just gaining access was a good point to start.
Our goal now was simple: leak a device GUID in order to gain access to one of its web servers, through Western Digital cloud.
After our device was enrolled in the cloud service, we noticed that something changed. Whenever we accessed the device using HTTPS, a new certificate was presented to us. While in the past this certificate was self-signed, now the device had a new certificate issued by Let’s Encrypt.
While this did not raise any flags immediately, we soon noticed one condemning detail in this certificate: its Common Name (CN). We noticed that inside the CN there was the device GUID. The pattern in the CN was as follows:
device-local-<GUID>.remotewd.com
This meant that by accessing the device’s HTTPS server, we were able to leak its GUID.
However, this technique had one (critical) limitation: we had to have access to the device to leak its GUID. Since we wanted to reach devices we did not have access to, this was not helpful, however we used our newly acquired knowledge to improve our GUID leaking technique.
One use case Western Digital had to account for was users wanting to access their devices when they were home. It’s not practical to fetch files over Western Digital cloud when the device is locally available because it introduces massive latency. Instead, Western Digital tries to redirect the user to their home NAS device, and if it’s accessible, all file-fetching will be performed over local access.
However, in order to make sure the user only fetches files from the real device, Western Digital uses the issued certificate to validate the connection. Only if the device has the real signed certificate will the user connect to it.
This is done by using HTTPS to fetch files from the device. However, in order to validate the certificate, the user must access the NAS using a DNS name and not an IP address. The DNS name must match the CN in the issued certificate for the user to validate they are talking to the actual device.
This is done by issuing a unique DNS name correlating to the internal IP address of the device.
We were able to abuse this by using Passive DNS Records. In some cases, some DNS servers sell their user records to earn money. By buying records from multiple DNS servers, some companies offer users the ability to search for DNS queries people performed, querying it against the DNS records database they bought from the DNS server.
By using these types of services, we were able to exfiltrate more than 10,000 unique GUIDs, each mapped to real-life devices.
This gave a lot of device GUIDs, however upon second check, many of which were out of date. Since many of these DNS records were old, the devices that owned that GUID were no longer accessible/changed their GUID. While many of which were still accessible, we had to improve our method and reach ALL of the devices GUID.
After reaching a dead-end with the passive DNS records, we looked for another method to leak GUIDs. That method came in by using Certificate Harvesting services. Many services on the internet save a record of all the certificates they encountered, and allow users to query that database records, searching for certificates. There are many platforms offering that kind of service, including:
Censys
crt.sh
SecurityTrails
Rapid7 Sonar
Many more…
Currently, these platforms hold records of billions of certificates. We tried using one of these services (Censys.io) to look for Western Digital devices certificates, and in result we got a hold of millions of certificates, each containing a device GUID. By searching only for certificates issued in the last three months, we were able to obtain more than 1.5M records!
After seeing how sites such as Censys can map WD certificates, we wanted to gain the same ability: leaking WD certificates in real time from our own computer. As it turns out, these sites use a standard called Certificate Transparency Log (CTL).
CTL is an internet security standard for monitoring and auditing the issuing of digital certificates. This standard's main goal is to improve the transparency of certificates on the internet, giving people the ability to detect certificate issuing anomalies, detect impersonation attempts etc.
By adopting this standard, Certificate Authorities (CAs) release a feed of metadata about all certificates they issue. By subscribing to this open feed, people are able to get records of certificate metadata in real time, as they are being issued. Currently, many CAs support this standard, meaning that it is possible to get notified whenever they issue a new certificate.
Many tools exist that enable users to subscribe to the CTL feed, so we used one looking for WD’s certificate pattern. This gave us the ability to leak devices’ GUID in real-time, as they are being issued. By subscribing to the CTL feed for a few days, we had access to any devices’ GUID that enrolled during that time.
We now had access to all of the cloud-enabled devices GUID.
After leaking all of the GUIDs, we started to research the binary handling cloud connections, looking for possible vulnerabilities. Our goal was to better understand how the Device ←→ Cloud ←→ User communication channel is created, and to look for vulnerabilities that could enable us to take control over devices.
However, in order to better understand how it behaves, and what functionality it offers, we had to debug, establish a man-in-the-middle (MiTM) position, and reverse engineer the cloud binary.
Our first goal was to understand how requests performed on the cloud reach our device. In order to do so, we wanted to log every request being performed on our device. We started by examining the Golang binary that handles cloud connection: restsdk-server.
Since this binary was written in Golang, and because we reached the conclusion it uses the http2 library for its web server, a quick Google search resulted in the following debug environment variable: http2debug=2.
By supplying this environment variable to the restsdk-server binary, we were able to fully log any HTTP traffic to the server. We then monitored the log file and launched the cloud application, which gave us a full log of every request our client cloud application performed.
After gaining better logging capabilities, our next step was to MiTM traffic between our device and WD’s cloud. When looking at the restsdk-server binary, we noticed it uses a configuration file: restsdk-server.toml. This file contained all of the settings for the restSDK binary, one of which was super important for this step: configURL.
As it turns out, the binary uses the URL specified in the configURL parameter, and fetches a JSON configuration file from it. In this JSON, we see all of the endpoint URLs the device will use to communicate with the different cloud services of WD.
In this JSON file we saw all of WD’s cloud services, including:
Service Name | Endpoint |
proxy | |
account.login | |
device | |
ota | |
auth0 | |
m2m |
By editing this configURL parameter, and supplying our own server instead, we were able to supply our own version of this JSON file. We then edited it, downgrading all of the URLs from HTTPS to HTTP, allowing us to MiTM the traffic sent to them.
This gave us a simple solution to MiTM the HTTP traffic. Sadly for us, one of the first requests the device performs is fetching a list of proxy backends it can use to create the cloud communication tunnel. This request returned URL endpoints of the proxy backends, however this URL was not a full URL, instead it only contained the hostname and port of the endpoint, missing the SCHEME component. This meant we could not simply change HTTPS to HTTP, instead we had to gain the ability to MiTM HTTPS requests.
In order to MiTM HTTPS traffic, we first issued a new CA, and added it to the list of trusted CAs on our device. We then issued a new certificate to one of the proxy endpoints using our newly generated CA, and used it to MiTM HTTPS traffic to this endpoint. We now had full MiTM between our device and WD cloud.
After achieving full MiTM, we were then exposed to the entire tunnel creation process: first the device initiates a new TLS connection to the proxy endpoint. After the TLS handshakes, the proxy sends an HTTP2 request to the NAS to the following URL: /sdk/v1/proxyConnect. In response, the device returns a 200 OK status code, telling the proxy it is ready to connect, However, along the status code, the device also returns a parameter -DeviceID, which is actually the device GUID. The cloud will then forward requests sent to that GUID to that proxy connection.
Immediately when we saw this initialization process we realized that it was flawed. The only required “secret” for a device to authenticate to the cloud is its GUID, which was not actually a secret but instead public knowledge.
So we implemented the tunnel creation process using a simple python HTTP2 server, and it worked. Not only were we now connected to WDs cloud, we disconnected the real device that was previously connected.
This meant that the only thing we needed to know in order to create a new cloud tunnel is the GUID of the device we want to impersonate, and we would be able to steal its connection to the cloud. Furthermore, since we already leaked all of the devices GUID, we now had the ability to steal all of the devices’ tunnels.
After the immediate shock of being able to steal a tunnel connection, we tried looking at the requests sent to our server, and were surprised once again: all of the requests contained a valid user JWT. As it turns out, in order to continuously refresh the content, the cloud application constantly sends background app refreshes to the device. This meant that whenever we stole the tunnel, these requests were redirected to our impersonated device, giving us access to the user JWT.
Chained together, we were able to steal the cloud tunnel of any WD NAS device in the world, and leak its user’s JWT token. Then, using this token, we were able to perform actions on behalf of the user, meaning we had essentially admin privileges on the compromised NAS.
We managed to gain admin privileges on any WD NAS device connected to WD’s cloud services. This meant we now had access to all of the personal files stored on any device. However, we wanted to increase our hold, and leverage our admin privileges to achieve remote code execution on any device we choose. This would not only give us access to anything stored on the NAS, it would also allow us to reach user’s personal home networks, bypassing NAT protection.
Note: We did so on WD devices we had local access to, sourced from a friend :)
In order to achieve RCE, we had to chain multiple vulnerabilities together. Here is the journey into finding those vulnerabilities.
After we essentially bypassed the authentication requirement, we wanted to explore what new attack surface opened before us. We looked at the API routes the restSDK binary exposes, mainly through reverse engineering, and soon enough we found one that might be abused by attackers. The main functionality of the cloud service is giving users access to their shares: a directory containing all of their files. These shares are then mapped to an actual directory hosted on the NAS.
We then asked ourselves, can we create a new share folder, and map it to arbitrary locations on the NAS. sadly, the UI did not showcase such functionality, however we were sure it should exist. We then reverse engineered the restsdk-server binary, looking for a way to the API route that could allow us to create new shares, and after some time we did discover it: /sdk/v1/filesystems.
By accessing the API /sdk/v1/filesystems, and supplying a path, a new share will be created. In legitimate use, all shares should be created under /mnt/HD/*, which is the mount point for the external harddisk in the system. However, we discovered that the server does not validate this, meaning we could supply arbitrary paths, creating shares in arbitrary locations.
Then, by using legitimate APIs, we can access the files in that share.
After creating a share in the root directory (/) directory, we tried writing a binary file to achieve remote code execution, however it did not work. After a short investigation, we discovered that many locations on the NAS filesystem were not writable, either because the directory was mounted in read-only mode, or because we did not have the proper permissions.
The list of locations we were able to write to are:
/usr/local/tmp_wdnas_config: Configuration files for the NAS stored between reboots
/var/log: Location for all the logs of the device to
/tmp: Linux temp directory
/usr/local/upload: Default directory for user uploads
/mnt/HD*: Default location for shares
We were only able to write to these locations, so we had to look for another vulnerability that could use this limited file-write primitive in order to achieve RCE.
After we achieved a primitive allowing us to write files in some specific directories, we decided to continue looking for other vulnerabilities. We started by looking for other legitimate functionality we can invoke using the cloud. That’s when we noticed the feature enabling users to shut down/reboot their devices from the cloud.
Behind the scenes, this functionality calls the following binary: do_reboot. This binary is supposed to halt the NAS device before rebooting, making sure the reboot is performed only in a safe state. We started by reverse engineering the binary, and that’s when we encountered the following vulnerable code:
As we can see, first the binary checks for the existence of the file /tmp/upload_fw_success. This file signals to the do_reboot binary that a firmware upgrade is happening, which triggers a different code path. Then, the content of this file is read using the cat command, and is then used inside an OS command. Luckily for us, this file is saved under /tmp, which is a directory we can write to.
By combining both vulnerabilities, we can first create a share mapped to /tmp. Then, we write a malicious reverse shell to upload_fw_success, and call the reboot procedure through the cloud, which will execute do_reboot and trigger our malicious reverse shell payload.
By combining all of the vulnerabilities we discovered, attackers were able to take full control over any cloud-connected device, without the need for the device to be internet exposed.
First, we enumerate all of the devices GUID, and choose our target list. We then impersonate the device, stealing its cloud tunnel and disconnecting the device. Any requests performed to the device will now reach us, giving us the authentication tokens for the device admin.
Using our newly gained permissions, we created a new share on the device, mapping it to the /tmp directory. We then write our reverse shell payload to that directory, and invoke a reboot through the cloud. Whenever the device will reboot, our payload will be executed, resulting in us executing code on the device.
By the end of our research journey, we were able to build a full exploit chain targeting Western Digital’s cloud-enabled NAS devices. Our chain allowed us to enumerate every connected WD NAS device, as well as access them remotely to steal stored data and private information. Apart from gaining access to the personal files stored on the NAS, we were able to remotely execute code, and control the device completely.
The core issue we uncovered was weak device authentication which enabled device impersonation and spoofing attacks. It’s clear that manufacturers and developers must, going forward, invest the same security resources in device authentication as they do in user authentication. Our attack technique allowed us to impersonate a legitimate WD device in order to enumerate and attack other devices. Our rogue device, once we understood the authentication mechanisms in place, was given the same access to the cloud and data as legitimate devices.
Our impersonation technique exposed and exploited the fact that WD relied on publicly known device identifiers—rather than secrets—to build its authentication scheme. It’s likely that weak device authentication is not limited to Western Digital, but instead likely affects many vendors and platforms.
These vulnerabilities are severe, and we wish to acknowledge Western Digital’s cooperation and collaboration in acknowledging these flaws and fixing them in a timely manner. These vulnerabilities were disclosed during Pwn2Own Toronto, and we also wish to acknowledge the Zero Day Initiative’s role in fixing these issues that put the data of millions of users at risk around the world.
This vulnerability allows remote attackers to disclose sensitive information on affected installations of Western Digital MyCloud PR4100 NAS devices. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the generation of TLS certificates. The issue results from the inclusion of sensitive information in publicly accessible channels. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root.
CVSS v3: 8.8
This vulnerability allows remote attackers to create and read arbitrary files on affected installations of Western Digital MyCloud PR4100 NAS devices. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.
The specific flaw exists within the restsdk binary. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root.
CVSS v3: 8.8
This vulnerability allows remote attackers to execute arbitrary code on affected installations of Western Digital MyCloud PR4100 NAS devices. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.
The specific flaw exists within the do_reboot binary. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root.
CVSS v3: 8.8
CWE-288 Path Traversal:
A path traversal vulnerability that could allow an attacker to write files to locations with certain critical filesystem types leading to remote code execution.
CVSS v3: 9.8
