reader comments
92 with 73 posters participating
Last week’s mass-wiping of Western Digital My Book Live storage devices involved the exploitation of not just one vulnerability but a second critical security bug that allowed hackers to remotely perform a factory reset without a password, an investigation shows.
The vulnerability is remarkable because it made it trivial to wipe what is likely petabytes of user data. More notable still was that, according to the vulnerable code itself, a Western Digital developer actively removed code that required a valid user password before allowing factory resets to proceed.
Done and undone
The undocumented vulnerability resided in a file aptly named system_factory_restore. It contains a PHP script that performs resets, allowing users to restore all default configurations and wipe all data stored on the devices.
Normally, and for good reason, factory resets require the person making the request to provide a user password. This authentication ensures that devices exposed to the Internet can only be reset by the legitimate owner and not by a malicious hacker.
As the following script shows, however, a Western Digital developer created five lines of code to password-protect the reset command. For unknown reasons, the authentication check was cancelled, or in developer parlance, it was commented out as indicated by the double / character at the beginning of each line.
function get($urlPath, $queryParams=null, $ouputFormat='xml')
// if(!authenticateAsOwner($queryParams))
//
// header("HTTP/1.0 401 Unauthorized");
// return;
//
“The vendor commenting out the authentication in the system restore endpoint really doesn’t make things look good for them,” HD Moore, a security expert and the CEO of network discovery platform Rumble, told Ars. “It’s like they intentionally enabled the bypass.”
To exploit the vulnerability, the attacker would have had to know the format of the XML request that triggers the reset. That’s “not quite as easy as hitting a random URL with a GET request, but [it’s] not that far off, either,” Moore said.
Dude, where’s my data?
The discovery of the second exploit comes five days after people all over the world reported that their My Book Live devices had been compromised and then factory-reset so that all stored data was wiped. My Book Live is a book-sized storage device that uses an Ethernet jack to connect to home and office networks so that connected computers have access to the data on it. Authorized users can also access their files and make configuration changes over the Internet. Western Digital stopped supporting the My Book Live in 2015.
Western Digital personnel posted an advisory following the mass wiping that said it resulted from attackers exploiting CVE-2018-18472. The remote command execution vulnerability was discovered in late 2018 by security researchers Paulos Yibelo and Daniel Eshetu. Because it came to light three years after Western Digital stopped supporting the My Book Live, the company never fixed it.
posted in the Western Digital support forum where the mass compromise first came to light. It shows someone from the IP address 94.102.49.104 successfully restoring a device:
rest_api.log.1:Jun 23 15:46:11 MyBookLiveDuo REST_API[9529]: 94.102.49.104 PARAMETER System_factory_restore POST : erase = none
rest_api.log.1:Jun 23 15:46:11 MyBookLiveDuo REST_API[9529]: 94.102.49.104 OUTPUT System_factory_restore POST SUCCESS
A second log file I obtained from a hacked My Book Live device showed a different IP address—23.154.177.131—exploiting the same vulnerability. Here are the telltale lines:
Jun 16 07:28:41 MyBookLive REST_API[28538]: 23.154.177.131 PARAMETER System_factory_restore POST : erase = format
Jun 16 07:28:42 MyBookLive REST_API[28538]: 23.154.177.131 OUTPUT System_factory_restore POST SUCCESS
After presenting these findings to Western Digital representatives, I received the following confirmation: “We can confirm that in at least some of the cases, the attackers exploited the command injection vulnerability (CVE-2018-18472), followed by the factory reset vulnerability. 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.”
This vulnerability has been password-protected
The discovery raises a vexing question: if the hackers had already obtained full root access by exploiting CVE-2018-18472, what need did they have for this second security flaw? There’s no clear answer, but based on the evidence available, Abdine has come up with a plausible theory—that one hacker first exploited CVE-2018-18472 and a rival hacker later exploited the other vulnerability in an attempt to wrest control of those already compromised devices.
The attacker who exploited CVE-2018-18472 used the code execution capability it provided to modify a file in the My Book Live stack named language_configuration.php, which is where the vulnerability is located. According to a recovered file, the modification added the following lines:
function put($urlPath, $queryParams=null, $ouputFormat='xml'){
if(!isset($changes["submit"]) || sha1($changes["submit"]) != "05951edd7f05318019c4cfafab8e567afe7936d4")
die();
The change prevented anyone from exploiting the vulnerability without the password that corresponds to the cryptographic SHA1 hash 05951edd7f05318019c4cfafab8e567afe7936d4. It turns out that the password for this hash is p$EFx3tQWoUbFc%B%R$k@. The plaintext appears in the recovered log file here.
A separate modified language_configuration.php file recovered from a hacked device used a different password that corresponds to the hash 56f650e16801d38f47bb0eeac39e21a8142d7da1. The hackers used a third hash—b18c3795fd377b51b7925b2b68ff818cc9115a47—to password-protect a separate file named accessDenied.php. It was likely done as an insurance policy in the event that Western Digital released an update that patched language_configuration.
.nttpd,1-ppc-be-t1-z, which was written to run on the PowerPC hardware used by My Book Live devices. One user in the support forum reported a hacked My Book Live receiving this malware, which makes devices part of a botnet called Linux.Ngioweb.
A theory emerges
So why would someone who successfully wrangled so many My Book Live devices into a botnet turn around and wipe and reset them? And why would someone use an undocumented authentication bypass when they already have root access?
The most likely answer is that the mass wipe and reset was performed by a different attacker, very possibly a rival who either attempted to take control of the rival’s botnet or simply wanted to sabotage it.
“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,” Abdine wrote in a recent blog post.
The discovery of this second vulnerability means that My Book Live devices are even more insecure than most people thought. It adds authority to Western Digital’s recommendation to all users to disconnect their devices from the Internet. Anyone using one of these devices should heed the call immediately.
For many hacked users who lost years’ or decades’ worth of data, the thought of buying another Western Digital storage device is probably out of the question. Abdine, however, says that My Cloud Live devices, which replaced Western Digital’s My Book Live products, have a different codebase that doesn’t contain either of the vulnerabilities exploited in the recent mass wiping.
“I took a look at the My Cloud firmware, too,” he told me. “It’s rewritten and bears some, but mostly little, resemblance to My Book Live code. So it doesn’t share the same issues.”
