Western Digital will start providing free data-recovery services in July for people whose data was wiped off their network-attached storage (NAS) devices last week, the company said in an update on Tuesday.
The company is also planning to offer a trade-in program to get customers onto the cloud – specifically, onto a supported My Cloud device – and off of old My Book Live and My Book Live Duo devices, an indeterminate number of which were remotely eviscerated in an attack that exploited what turns out to have been a zero-day vulnerability.
In fact, there were two vulnerabilities that were exploited: An old remote-code execution (RCE) bug from 2018 that Western Digital first blamed, and then a previously unknown flaw that enabled unauthenticated remote factory-reset device wipes. Theories about why the attack involved two devastating exploits include the suggestion that rival threat actors were duking it out for control of the compromised devices.
Western Digital also released new details about that zero day, which exploited the newly identified vulnerability CVE-2021-35941. The bug is in Western Digital’s WD My Book Live (2.x and later) and WD My Book Live Duo (all versions), which have an administrator API that can perform a system factory restore without authentication. Its severity hasn’t yet been rated.
Besides the unauthenticated factory-reset operation, Western Digital said that the firmware for My Book Live is also vulnerable to a remotely exploitable command-injection vulnerability when the device has remote access enabled. “This vulnerability may be exploited to run arbitrary commands with root privileges,” according to Western Digital’s updated advisory.
Provenance of the Factory-Reset Bug
The company shared more technical details about the newly discovered vulnerability to address questions that have arisen in the wake of the global data wipeout. Its advisory explained that the company traced the unauthenticated factory reset vulnerability back to April 2011, when My Book Live underwent “a refactor of authentication logic” in the device firmware. Refactoring is a process meant to improve the design, structure, and/or implementation of software’s non-functional attributes while preserving its functionality.
Western Digital said that this is how the bug crept in during the refactor back in 2011:
The refactor centralized the authentication logic into a single file, which is present on the device as includes/component_config.php and contains the authentication type required by each endpoint. In this refactor, the authentication logic in system_factory_restore.php was correctly disabled, but the appropriate authentication type of ADMIN_AUTH_LAN_ALL was not added to component_config.php, resulting in the vulnerability. The same refactor removed authentication logic from other files and correctly added the appropriate authentication type to the component_config.php file.
That’s a startling admission: In other words, a Western Digital developer actively removed authentication code that would require the input of a valid user password before factory resets could be executed. That slip-up, unfortunately, has cost users what’s likely petabytes of data, given that anguished users complained about years worth of data being obliterated.
Provenance of the Old Bug
Western Digital noted that there was also an old, previously discovered bug exploited in the incident: CVE-2018-18472. This one shouldn’t have come as a surprise: The remote command-execution (RCE) vulnerability was discovered in October 2018. It was extremely high risk, with a CVSS score of 9.8 out of 10. Nonetheless, Western Digital never fixed it, given that it was discovered three years after the company had stopped supporting My Book Live.
The bug was brought to light by Paulos Yibelo and Daniel Eshetu, who updated their findings as recently as last November. The researchers wrote that “WD My Book Live and some models of WD My Cloud NAS contain a remotely exploitable vulnerability that lets anyone run commands on the device as root.”
Attack Chain for My Book Live Wipe
Log files from customers who lost data show that attackers directly connected to their My Book Live devices from a variety of IP addresses in different countries, Western Digital said. Its investigation has shown that “in some cases, the same attacker exploited both vulnerabilities on the device, as evidenced by the source IP. The first vulnerability was exploited to install a malicious binary on the device, and the second vulnerability was later exploited to reset the device.”
On some devices, the company explained, the attackers installed a trojan with a file named “.nttpd,1-ppc-be-t1-z” – a Linux ELF binary compiled for the PowerPC architecture used by the My Book Live and Live Duo. Western Digital captured a sample of the trojan and uploaded it to VirusTotal. One user in Western Digital’s support forum reported that their My Book Live was infected with this malware, which makes devices part of a botnet called Linux.Ngioweb that mostly comprises malicious proxy servers.
The company’s investigation still hasn’t uncovered evidence that Western Digital cloud services, firmware update servers or customer credentials were compromised.
“As the My Book Live devices can be directly exposed to the internet through port forwarding, the attackers may be able to discover vulnerable devices through port scanning,” according to Western Digital’s update. “The vulnerabilities being exploited in this attack are limited to the My Book Live series, which was introduced to the market in 2010 and received a final firmware update in 2015. These vulnerabilities do not affect our current My Cloud product family.”
Why Two Bugs?
Last week, Western Digital’s initial advisory attributed the mass data wipe to attackers exploiting the old, unpatched RCE vulnerability from 2018.
But the plot thickened, as Ars Technica’s Dan Goodin detailed. Ars and Derek Abdine, CTO at security firm Censys, conducted an analysis of logs from the affected devices that showed that devices hit by the mass hack had also been subjected to attacks that exploited the new, unauthorized reset vulnerability. The additional exploit was documented in log files extracted from two hacked devices. One of the logs posted in the Western Digital support forum where the attack first came to light showed that someone from the IP address 94.102.49.104 had successfully restored a device. But a second log file from an affected My Book Live device showed a different IP address – 23.154.177.131 – exploiting the same vulnerability.
When Goodin reached out to Western Digital, the company confirmed that in some cases, the attackers exploited the old RCE vulnerability, then they went ahead and exploited the new factory-reset vulnerability.
Why? Western Digital told Goodin at the time that it wasn’t sure, but that it would request a CVE for the new bug: “It’s not clear why the attackers exploited both vulnerabilities. We’ll request a CVE for the factory-reset vulnerability and will update our bulletin to include this information.”
Why Password-Protect a Vulnerability?
It’s not clear why attackers who’d already retained full root with the old bug would need to exploit a second one, but Abdine has a theory: Namely, there could be two attackers at work. The first could have exploited the old bug – CVE-2018-18472 – while a second, rival threat actor may have tried to wrest control of already compromised devices by exploiting the second, new vulnerability.
Whoever exploited the old bug tweaked a file in the My Book Live stack named language_configuration.php – where the vulnerability is located – to add code that stops anyone from exploiting the vulnerability unless they have a password that corresponds to the cryptographic SHA1 hash 56f650e16801d38f47bb0eeac39e21a8142d7da1. The password for the hash turns out to be p$EFx3tQWoUbFc%B%R$k@, which shows up in one of the recovered log files.
The log files show another password with the hash 05951edd7f05318019c4cfafab8e567afe7936d4 set up to protect a separate, modified language_configuration.php. To boot, the attackers used a third hash, b18c3795fd377b51b7925b2b68ff818cc9115a47, to password-protect a separate file named accessDenied.php: What Goodin suggested could have been put in place as “an insurance policy in the event that Western Digital released an update that patched language_configuration.”
Abdine wrote about that theory in a blog post: “As for motive for POSTing to this [system_factory_restore] endpoint on a mass scale, it is unknown, but it could be an attempt at a rival botnet operator to take over these devices or render them useless, or someone who wanted to otherwise disrupt the botnet which has likely been around for some time, since these issues have existed since 2015.”
The first vulnerability was bad enough, but the second one adds to the urgency underscoring Western Digital’s advice to disconnect its devices from the internet. As far as moving to the company’s My Cloud Live devices goes, Abdine told Ars that the replacement devices don’t have the bugs that were exploited last week. He told Goodin that he also took a look at the My Cloud firmware, which mostly seems copacetic.
“It’s rewritten and bears some, but mostly little, resemblance to My Book Live code,” Abdine told Ars. “So it doesn’t share the same issues.”
Was the Code Snipped on Purpose?
Western Digital’s discovery of the new bug gives rise to the question of whether the firmware code’s password authentication was snipped on purpose – for usability reasons, perhaps – or by mistake. “I suspect the product once enforced password authentication before reset but that this may have led to a usability issue such that the vendor made the conscious decision to disable password verification on this script,” suggested Craig Young, principal security researcher with Tripwire. “A researcher reviewing the firmware can then find this oversight, recreate the appropriate request, and trigger a factory reset without a password.”
The prospect of a vendor intentionally shipping code in this way, on a product that’s regularly exposed to the Internet, is “alarming,” Young told Threatpost on Wednesday, but, unfortunately, it’s “very common” for vendors to take shortcuts with respect to authorization and authentication on embedded devices in order to simplify the user experience.
That sad fact is compounded by the fact that it’s “nearly impossible” for an average consumer to gauge whether a given product has been designed securely without “serious third-party scrutiny,” Young said. “When buying IoT gadgets, consumers must consider the consequences of an attack against this system and use this to inform their behavior. Having your own ‘cloud storage’ device is great, but if disclosure or destruction of this data would be devastating, it is critical that the system be secure.”
Threatpost asked Western Digital to comment on whether the removal of password authentication was intentional or amounted to a developer’s slip, but a spokesperson refrained from commenting on Wednesday, instead referring back to Tuesday’s advisory.
John Bambenek, threat intelligence advisor at resolution intelligence provider Netenrich, told Threatpost that this isn’t an issue of trustworthy code. “Vulnerabilities are found all the time,” he said via email. “It’s an issue of a technology company creating long-lasting technology but not [wanting] to support their customers who then pay the price later.”
For Bambenek, the core problem in this case is “a technology company creating a technology that users will continue to use long after a very limited support window. People are going to store files for a long time and the notion that a storage device can be end-of-life’d after four years and leaving the users to fend for their own after 0-days are discovered in 2018. Zero days that the users themselves can’t address or mitigate.”
Dirk Schrader, global vice president at New Net Technologies, called the situation – i.e., a legacy device connected to the public internet, allowing remote access – a “recipe for disaster.” He pointed to other recent examples, such as the case of the Accellion legacy File Transfer Appliance (FTA) product that suffered global zero-day attacks in February. “Users, whether corporate or private, tend to forget that connected devices do age, and the longer they are connected to the internet the more likely it will be for them to be targeted,” he told Threatpost on Wednesday. “Regularly checking the exposure, what is connected and does it still have to be, is the first step in reducing one’s attack surface.”
Schrader’s guess at what happened at Western Digital is that “someone had the idea to centralize all the authentication into a single file and forgot to remove all line-disabling comments from the code before releasing it,” he said via email. “That this is used in an exploit about two month later is a surprise, but only because it took that long. What kind of QA is done at Western Digital? Even if the affected product is out of official support, this is a vital aspect and should be controlled during the development process. If you comment out, check back on it.”
063021 14:44 UPDATE: Added input from Dirk Schrader, John Bambenek, Craig Young, and a Western Digital spokesperson.
Join Threatpost for “Tips and Tactics for Better Threat Hunting” — a LIVE event on Wed., June 30 at 2:00 PM ET in partnership with Palo Alto Networks. Learn from Palo Alto’s Unit 42 experts the best way to hunt down threats and how to use automation to help. Register HERE for free.
