Help! All data in mybook live gone and owner password unknown

The fact is that these compromised MBL devices were rooted, and no matter what precautions are taken afterward, I suggest that these compromised MBL devices can no longer be trusted.

How important is your data to you? It’s more important to me than the cost of a new NAS, and I’m not going to be in a position where I’m always wondering how safe that drive is. There could be more, and even worse attacks. Even if you can successfully block the MBL from the internet, do you still want this potentially-compromised device on your network?

Once these drives were rooted, they’re all suspect now. Factory resets won’t fix the issue. I think they should be retired permanently and replaced.

@WolfishHickory Great news! Thank you for the update. Some did not have good results with PhotoRec.
Let us know how it ends up?

@spigot You are a champion! Does it say how many files are recoverable?

I’m not tech savvy enough to trust that drive (or recover the data myself) so it’s a write off for me. It served me well for 10-ish years (I bought it to stream movies through my blue-ray player originally). I’ll have to pick up an external drive for laptop backups (not from WD most likely after this) and cross my fingers that no personal data was stolen. Stupid pandemic already had my anxiety through the roof, this does not help.

1 Like

@andyman1222 , Great news. Could you post a link to the application you are using? There is DiskInternals and Microsoft has a Sysinternals Suite. Thank you, Jeff

You can shuck the the drive from the MBL and reformat it for whatever you want to use it for so it won’t be a total loss for you. Most people that aren’t tech savvy can do it and if you break the MBL in the process you’ve lost nothing anyway:

These look like a botnet setup, every hour and every day these entries download a script from those IPs and run them.
Probably they decommission your MBL by downloading a script to do factory reset and erase everything.

Once these are there, upnp, auto update, remote access, all don’t matter.

You might want to check if other machines on your Lan have the same problem too and ticking time bomb

1 Like

Good idea, comrade. :ru:

Screen Shot 2021-06-27 at 7.53.51 PM

1 Like

@check Shouldn’t surprise anyone the IP are in Russia and Latvia

Decimal: 3160164481
Hostname: 188.92.72.129
ASN: 43513
ISP: Sia Nano IT
Organization: Sia Nano IT
Services: None detected
Type: Broadband
Assignment: Likely Static IP
Continent: Europe
Country: Latvia

Decimal: 3587768504
Hostname: 213.217.0.184
ASN: 50340
ISP: OOO Network of data-centers Selectel
Organization: OOO Network of data-centers Selectel
Services: None detected
Type: Corporate
Assignment: Likely Static IP
Continent: Europe
Country: Russia

213.217.0.184 appears to be located in St petersburg, Russia and allocated to OOO Network of data-centers Selectel.
Autonomous System Number (ASN) code for 213.217.0.184 is AS50340.
IP Address local time zone is Europe/Moscow (+0300). PTR record is set to 213.217.0.184.

1 Like

Yep, it was established earlier in the thread, but now that this thing is going on 580 posts, I figured it was lost in the weeds for newcomers.

Perhaps we should all keep in mind if you take a closer look at those Russian and Latvian servers, the latter is riddled with upatched vulnerabilities.

So while it may be Russian hackers, it may also be that this was a NSA, GCHQ and/or IDF Unit 8200 operation. They compromise a Russian server, then launch the attack and pi$$ off a bunch of Americans who lose their family photos and the media blames our adversary Russia. It might of just as well been the Chinese, but they are somewhat allied with Russia and want us to keep buying those cheap NAS components made in China.

As an added bonus, the NSA, etc. scare the American public away from using their own NAS devices and instead put everything in the Cloud where they have more universal backdoor access. On top of that, John McAfee’s drug-addled ghost in the machine causes more chaos, I tell you.

/tinfoil hat

3 Likes

ooh that might be a fun project for later (while I doubt at this point WD is gonna do anything I think I’ll keep the thing intact until we get some answers – at least for a little while anyway, unless my curiosity gets the better of me.) Thanks for this.

2 Likes

I was not affected. I had UPnP disabled on both router and MBL. Remote access disabled. SSH enabled but with root login disabled. Auto updates disabled and also removed firmware check script from cron. Router firewall also blocks all WAN pings.

For anyone that hasn’t had their drive wiped but wants to check for any new files that could be malware or modified by malware, then use this command from the root directory:

sudo find -type f -mtime -14 -ls

It will search for any files modified in the last 14 days. Note that this isn’t foolproof since the modification time can be altered.

Use this command to search for the trojan that WD identified:

sudo find -iname "*nttp*"

I would recommend pulling out the drive from the enclosure and hooking it up to a PC to analyze instead of powering up the NAS (while disconnected from the Internet) since there could be malware set to go off once the operating system on the NAS boots up.

Using a Linux PC, you can access the system partition on the drive using debugfs /dev/sda1 (device name may vary) and dumping the contents to a new location with the rdump / <destination> command. From there change into the directory of the dump and you can use the find commands above. The same can be done for /dev/sda4 (the largest partition) to dump / backup your personal data.

Personally, I will not toss out the NAS board but will toss out the WD firmware in favour of Openwrt, which does receive constant updates. I would not try to upgrade the NAS to Debian 8 (last supported version for PowerPC architecture) since updates ended last year.

1 Like

To work correctly, shouldn’t that be:

 sudo find / -name "*nttp*"

Forgive the crappy cell phone picture, easiest way to do this. Has anyone else noticed this in their network while dealing with this. I noticed it earlier today on the my laptop and the desktop but didn’t put two and two together.

This is a picture from my netbook which has never been attached to this network so it can’t be any other network device. This showed up when I attached the MBL to it. I’d never noticed it being there before today but I also don’t look at the network page often.

It’s no longer showing up on network, so that’s good I guess. And my network shows no devices I’m not familiar with, so that’s also good. Is it just the chipset of the MBL? Has anyone had this show up?

My post above had the same IP in my Router logs 213.217.0.184 ramped up attacks maybe for about a week prior. Mostly exactly on the hour. One got through an viola. We have the s**t show we have today

1 Like

Working on a cloned image is definitely safer. However, it should be noted that WD used a 64K block size for the filesystem so mounting the drive or a cloned image on x86 systems is not possible with conventional methods, which is why I had to use debugfs. If you plan to dump your data from a cloned image, you will need twice the amount of spare storage.

That’s a good reminder for mounting as read-only. By default, debugfs opens the filesystem as read-only.

If you are dumping out the data to a location on your Linux PC then you can specify the path explicitly or you can omit it if you change to the directory of the dump. If you SSH into the NAS then the root path / works fine, but on your own Linux PC, starting with / as a path will needlessly search your entire system.

-iname is the same as -name but ignores case to match any uppercase letters. I was not certain of the exact name of the trojan.

A better method would be to scan all files using one of the few Antivirus engines that can currently detect it.

You can also try to get a hash list of all your files and match it against one of the hashes on VirusTotal. This command will match the trojan’s SHA1 hash value:

sudo find -type f -exec sha1sum {} + | grep 6a4f531f3e05de4d1499e0242e280dc60bd87a71
1 Like

I’m glad I avoided using Live Duo for backup purposes. They were tempting. I did use a single WD Live for redundant media, and as a bridge for moving files between incompatible devices. Backups of that were recent, so losing 2TB due to this hack amounted to a minor inconvenience. I never trusted these things to begin with. Cloud service you can’t unsubscribe from, without tech support? Nothing suspicious about that at all!

They say support ended in 2015? How come the cloud service is running? How come the drive can still ping for firmware updates, if none are coming? Why not release a “bottle cork” update. One that seals off the thing from the internet. Kills all remote call ports and leaves it as a LAN only thing? They want their cake and to eat it too.

By the way. As soon as I analyzed the drive I put some files on it and connected it right back up. There’s nothing on it that I can’t afford to lose. I just want to see what happens. It’s been running since after the attack. No subsequent resets. I did not change anything. I wanted to see if the attack was continuous, or only a short burst. Because if it was, as WD seems to indicate, a bruteforce execution, with no user data being stolen, and no firmware update servers being hacked - I don’t buy that one bit. I say that it was their firmware homebase that got hacked and either assisted with IP redirects, or served as a target list.

I say, WD got hacked, and they’re looking to avoid lawsuits. They found the problem and fixed it, but didn’t go public with the find. They are stalling, and pretending it’s not their problem anymore. Because if they are at fault, they may owe ever data recovery client up to $5K. This will snowball.

1 Like

Sorry I wasn’t clear. I meant you needed the forward slash for it to work at all with either -name or -iname when using ssh directly into the MBL.

Which one got through and why, I wonder?