I’m certainly no expert on this stuff and thank you for your comment.
Can you explain a little further as I think my understanding and reason for using Raid may have been misplaced?
I thought one drive contained almost identical data as the other and so being able to swap out a failed drive or data recovery was easy.
Some of us had more secure firewalls.
Lots of consumer routers have default firewall configurations that are insecure. It’s cheaper/better to do it that way because otherwise your product gets poor reviews from people who don’t understand why insecure stuff doesn’t work, and/or the cost of support increases. Then when a hack actually occurs (like this one) everyone blames the maker of the device that was hacked (i.e. Western Digital). So for some router manufacturers, there’s every reason NOT to ship their products secure by default.
I prefer to operate under the assumption that every internet-connected device I own has some sort of security hole. Even if it hasn’t been discovered yet, one day it will be.
So it seems like people have had some success with:
Photo Rec
R Studio
Ease US Data Recovery
Any of these better for family photos and family videos?
This is the same response I got to my ticket so they clearly just have a canned response for anyone regarding this issue right now. Not holding my breath on a lot of transparency here.
2 Likes
@salman.jaffer Did they promise a restoration with file folder structure and also file name? I’m interested to know what professionals can actually offer.
Head’s up, in case you didn’t know - your log was featured in an Ars Technica article updating on the exploit:
Important snippet via article:
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.
One thing the article didn’t note was the patch on this forum here for both vulnerabilities created by the wonderful @dracenmarx - I wish these writers did a more through job and noted it for people, but here it is again for those who may have missed it within this thread:
And for those in this thread that are pointing their shaky fingers at the Russian boogeyman for this attack, bear in mind I’ve taken a close look at the Russian/Latvian servers that were utilized and one is riddled with unpatched security vulnerabilities. That means hackers could have compromised the Russian/Latvian server(s) and utilized them for the attack. So while it could still be Russian hackers, it could also be a NSA, GCHQ an/or IDF Unit 8200 attack.
Why? To make Americans who lost their family photos angry at a foreign adversary and feed yet more hysteria (and money) into the military-industrial complex. That’s why, and with added bonus of making people fear personal NAS storage and have them running back to Cloud storage where the NSA, etc. are known to have more universal access (backdoors or otherwise).
Actually, according to this the bizarre Ars Technica article it even appears several adversaries were fighting for control over the alleged botnet and one even password protected the factory restore during the “battle”. For all we know, Russia found a hacker group jacking their server to make attacks and tried to stop the process because they knew they’d be blamed for it. 
/tinfoil hat
1 Like
Two different vulnerabilities in the REST API. Not necessarily the same attackers. Unless the attackers covered their tracks, you should be able to see the calls in /var/log/rest_api.log.
The “device/language_configuration” endpoint is how attackers were able to inject code to upload and/or execute arbitrary scripts as “root”. I see an attack as early as May 22.
The more recent /DataVolume wipe is attributable to WD commenting out the authentication requirement for the “system_configuration/system_factory_restore” endpoint; this allowed attackers to remote wipe /DataVolume without a login session.
3 Likes
Yep, and I just posted that there’s been a patch for both on this forum for ~3 days now. So despite WD’s utter ineptitude and total disregard for their customers @dracenmarx was able to analyze and create patches just a day or two after the mass exploit appeared in the media.
2 Likes
Uploading: PXL_20210629_171134220.jpg…
i am currently a 3rd through R Suite. Looking at it, its looking like it has found a fair amount of data. Anyone else confirm this??
THIS WDSTAFF IS WHAT WE NEED and are asking for.
I dont want to do this coder stuff, not because Im an assh** and dont want to do something, its just because Im just a consumer, an end user…
Is not our responsability to do such things, WD, its only yours.
Ball is on your court WD, you need to act and act now. At least to avoid the root cause of all those affected users that can claim against you about stress, document loss, business irreversible registry. Just pointing that root cause was this flaw. So act proactively or prepare to be sued by them.
And dont get me wrong, this is just commom sense. You need to have empathy with your community (aka Customers) we buy your stuff and this is 2021. Now brands listen to their community, dont manage their business with programmed obsolescence and give their backs to the community. Just because we have the final word here.
This just will make a person cry everytime the WD brand appears on their faces and will go buy anywhere but from you. Dont you think about that on your business plan? 2021 remember, empathy.
2 Likes
Привет, я тоже из Росии, у меня версия не DUO, а просто MBL, подскажи должно получится?
Скинь пжлста свой способ, я не разбираюсь, найду умельца айтишника и передам ему твои знания)) Спасибо большое заранее!
WOW! I didn’t knew about the other vulnerability with the unprotected factory reset! I just learned by the ArsTechnica article.
The vulnerable file is
/var/www/Admin/webapp/classes/api/1.0/rest/system_configuration/system_factory_restore.php
WD negligently violated security here! They explicitly allow anybody in the network to wipe the NAS! They explicitly commented out the security check!
The patch is simple:
Find (2 times)
// if(!authenticateAsOwner($queryParams))
// {
// header("HTTP/1.0 401 Unauthorized");
// return;
// }
Replace with:
if(!authenticateAsOwner($queryParams))
{
header("HTTP/1.0 401 Unauthorized");
return;
}
Though I don’t know if the attackers used this vulnerbaility or the 2018 CVE one. With both vulnerabilities you can wipe the drive. Actually, if you use the 2018 CVE, you can also call the “wipe factory reset” which will completely zero the drive, making data-recovery impossible. We can be glad the hackers didn’t do that.
By the way, I think WD won’t do anything more. I hoped that there will be a final statement / analysis, but I think their security advisory is finished, with the conclusion “pull the plug”…
About the theory, I wonder if somebody wanted to sabotage an enemy botnet, why didn’t they just remove the entries in crontab “deactivating” the enemy botnet and install their own stuff?
1 Like
Very good idea to look in the apache logs @ericshufro
I also looked for the logs, they are in the /var/log/apache2 directory, and appear as files error.log and and error.log.1, etc.
I have no error activity in the logs prior to June 16, 2021.
On June 16, 2021 at 08:02:03 AM, my device was accessed by IP number 94.102.49.104, evidenced by these entries:
[Wed Jun 16 08:02:05 2021] [notice] Apache/2.2.9 (Debian) DAV/2 mod_ssl/2.2.9 OpenSSL/0.9.8zf configured – resuming normal operations
[Wed Jun 16 08:20:20 2021] [error] [client 94.102.49.104] PHP Notice: Undefined index: x in /var/www/logout.php on line 1
[Wed Jun 16 08:20:20 2021] [error] [client 94.102.49.104] PHP Warning: system(): Cannot execute a blank command in /var/www/logout.php on line 1
After the above took place, numerous unsuccessful attempts (that continued until 10:20 AM) were made to remove web files from the system, clearly indicating that the attacker had some form of root access to the system:
rm: cannot remove
WSC0': No such file or directory rm: cannot removeZWQF’: No such file or directory
rm: cannot removeQSRG': No such file or directory rm: cannot removeQJFK’: No such file or directory
After each unsuccessful attempt was made, these errors repeat themselves:
PHP Notice: Undefined index: x in /var/www/logout.php on line 1
PHP Warning: system(): Cannot execute a blank command in /var/www/logout.php on line 1
Overall, the web interface was accessed 1,823 times by 139 IP numbers between June 16, 2021 08:02:03 and Jun 23 15:27:27, around the time the device was factory reset.
1 Like
Hm… the file /var/www/logout.php does not exist in the default MyBook system. I guess they placed code in this PHP file in order to access it via HTTP (webshell?). And they named it logout.php so that nobody notices it.
Do you have the contents of that file?
I thought this started on the 12th on mine but I forgot to look at the second error file, that one starts May 24th, assuming all these errors in these files are access attempts by malicious parties. Between the two files there are close on 3000 lines so… It looks like initial access for various drives may have been different? But we were all erased round the same time.
I just want to understand why WD never took any action in this critical vulnerability during the few years they’ve known about it? Why didn’t WD attempt to reach out to their customers to let them know of the risks?
It’s proven that WD was very well aware of the vulnerability for at least three years.
1 Like
My Apache logs go back to January, and show that my device went through several periods where it was was getting hit daily by dozens of access requests from numerous IPs. As far as I can tell, it wasn’t breached. I haven’t found any signs of malicious code or files that were recently modified, but it is strange that it rebooted at roughly the same time as all the affected devices.
Not on my system either. However - some of the log files show that they were looking in
/var/www/Admin/webapp/
[Sun Jun 20 22:11:59 2021] [error] [client 195.3.146.170] PHP Notice: Undefined index: username in /var/www/Admin/webapp/htdocs/secureCommon.inc on line 49
[Sun Jun 20 22:11:59 2021] [error] [client 195.3.146.170] PHP Notice: Undefined index: username in /var/www/Admin/webapp/htdocs/header.inc on line 24
I did find these:
linuxcpa@computer:~/WesternDigital> find . -name “logout.php”
./var/www/Admin/webapp/htdocs/logout.php
./var/www/Admin/webapp/classes/api/1.0/rest/logout/logout.php
1 Like
All 4 files exist on my device (actually, I checked the extracted firmware, not my device).
The md5sum just in case you want to compare:
d3e327f8ba1c239e4f09e52d86d50e9f Admin/webapp/htdocs/header.inc
440ddf506e013b004ecf677ea9cc3440 Admin/webapp/htdocs/secureCommon.inc
0c9f590015a0d60639049297c0abc80e Admin/webapp/htdocs/logout.php
504bce4571bc55b5c25a5b08c22671fb Admin/webapp/classes/api/1.0/rest/logout/logout.php
The error message in secureCommon seems to be a “normal” error because the developers didn’t check if the key exists?
Line 49 is:
$displayName = $_SESSION['username'];
1 Like
There’s no money in it.
Realistically, in a month or two, everyone’s going to forget about this. Better put development resources into products they actually sell today.
