Unofficial Patch for OS3 Zero Day RCE Vulnerability

That is similar to the message I receive on a v4.x firmware first gen. I do not have v2.x firmware unit to test with.

See the article in the initial post for more information about exploit:

I read it yesterday and it does not say a word what the exact vulnerability is.

Did you watch the 25 minute long video they included in that article that appears to detail the exploit(s)?

Obviously not, am doing it now.

EDITED TO ADD #1: I’m not getting the same response where nobody & squeezecenter accounts are considered as authors do to cat /etc/shadow command (~5m45s)

nobody:*:15729:0:99999:7:::

squeezecenter account does not in fact exist.

EDITED TO ADD #2: I’m not getting the same response as authors do to curl ‘http://127.0.0.1/api/2.1/rest/device?auth_username=nobody&auth_password= command (~9m45s)

<?xml version="1.0" encoding="utf-8"?><core><error_code>401</error_code><http_status_code>401</http_status_code><error_id>57</error_id><error_message>User not authorized</error_message></core>WDMyCloud:~#

EDITED TO ADD #3: I’m not getting the same response as authors do to curl -X POST ‘http://127.0.0.1/api/2.1/rest/firmware_update?auth_username=nobody&auth_password= command (~13m00s)

<?xml version="1.0" encoding="utf-8"?><core><error_code>401</error_code><http_status_code>401</http_status_code><error_id>57</error_id><error_message>User not authorized</error_message></core>WDMyCloud:~#

EDITED TO ADD #4: Whole premise of attack assumes using nobody account for nefarious purposes (15m30s)

EDITED TO ADD #5: I’m not getting the same response as authors do to ps faux | grep httpd command (~21m45s)

root     16889  0.0  0.7   2432  1728 pts/0    S+   16:26   0:00          \_ grep httpd

Most users come here seeking solutions that will let them continue using their devices. They have choices. One is your way, another for this specific exploit is the way detailed by the article and the patch the article references.

The information provided by all is what it is. It is up to the reader to to decide for themselves. WD apparently isn’t going to fix OS3 (for now) so doing nothing leaves this exploits potentially active on the OS3 device. Disconnecting from the internet is one option, but leaves the underlying exploit(s) still there. If the patch actually closes this exploit, then its a possible benefit for users even if they choose the prior two options (doing nothing or disconnecting from internet). The ultimate option has always been to remove any WD My Cloud from one’s local network.

@ krzemien, what you are seeing is expected. The v2.x firmware is different than the v4.x firmware which why running commands/code against one firmware version won’t necessarily be replicated on the other. Either due to files or folders being in a different location or because the underlying Linux code (v2.x BusyBox for example) is different than the v4.x firmware code.

What am I seeing is that my device seems to be immune to that vector of attack as user nobody does not seem to respond to the commands as shown in this YouTube video. At least that’s my quick conclusion…

(and sincere apologies for numerous updates and rectifications, those pesky ‘&’ and ‘?’ characters I’m not used to entering so often… I will review it all patiently in the evening once I have more time)

Righto.

I just revisited all the above with the clear eyes and corrected typos accordingly. Nonetheless the result remains the same, as per the screenshot just grabbed:

The unit I own is 1st Gen (v4.x), with the latest available firmware (v04.05.00-342) installed. No faffing with its content, with the exception of HD Sentinel installation (as per the other thread & my post here: Monitor Network Attached Storage (NAS) status via HD Sentinel - #6 by krzemien)

@Bennor, as you seem to have an access to similar unit, are you able to run these commands as per the above / YouTube movie and to advise accordingly?

The results I am seeing - but I might be missing something bleeding obvious - seem to indicate that 1st Gen units might be immune to this vulnerability.

Apparently so - as just proven above.

That being the case it’s probably good to know that I and others in similar circumstances might be okay for the time being, n’est-ce-pas?

Bye and EOT.

Due to the different nature of the firmware between the two single bay My Cloud versions you are going to find cases (like this) where a security vulnerability will only affect one of the two branches of OS3 firmware. In this case, the v2.x firmware appears to be affected by this specific vulnerability while the v4.x is not.

Provided I ran the correct commands they used; I was receiving “User not authorized” on a v04.05.00-342 firmware single bay unit for their test examples.

Good to know, thanks for checking.

I will sit tight and will await developments.

I thought you were off?

Also did it ever cross your mind that your attitude simply puts people off (regardless of you being right, or wrong)?

You seem to be that corporate IT bod hiding from Legal (and possibly also HR folk) sitting long evenings in darkest corner of some obscure office, always full of excuses and ready to tell others why ‘can’t do, mate’ is always best (safest) thing to do.

For the v4.x firmware, one line the suggested code-change remains relevant, being:

sed -i ‘s/USER_AUTH</post>/ADMIN_AUTH</post>/’ /var/www/rest-api/api/System/config/module.config.xml

The errors in the scripts are related to the different apache2 commands that are used in the v4.x firmware.

However, the change above persists after rebooting. So in an ssh shell executing the command above as root followed by a reboot should be OK.

Il est inadmissible que Western Digital laisse ses clients avec des failles de vulnérabilité.
It is unacceptable that Western Digital leaves its customers with vulnerabilities.

Yes first gen v4.x firmware users can run the script to make the change in the module.config.xml file even though it appears that the latest v4.x firmware is not affected by the methods used to test for the vulnerability detailed by the guys mentioned in that Krebs article.

Yes, because of the difference in firmware, making this change in the v4.x firmware module.config.xml file will persist (ie not be reverted back) after a reboot or power on. The v2.x firmware users are not so lucky due to the way that firmware reloads various core files during boot/reboot.

WD has stated OS3 firmware will no longer be updated. And some devices that run OS3 cannot be updated to OS5 and are at End of Updates due to no longer being manufactured.

While we would ideally like device manufacturers to update their firmware indefinitely. The reality is almost all do not. Most all have end of life or end of updates on their no longer produced products. If one has a second gen v2.x single bay My Cloud they have the option to update their units to OS5 (and possibly experience the problems that come with it, primarily the indexing issue). Otherwise one can, at their own risk, try using alternate firmware on their first gen single bay My Cloud unit (with varying degrees of success). Typically however trying to install alternate firmware/OS involves some additional knowledge and skill on the end user’s part.

Clean OS (Debian), OpenMediaVault and other “firmwares”(Clean OS (Debian), OpenMediaVault and other "firmwares")

Edit to add: WD makes the GPL OS3 source code for the OS3 firmware available for those who want it. One could take on the task of updating the OS3 firmware to close current/future security vulnerabilities themselves if they so desired (and had the knowledge/skill to do so).

Thanks, all correct and I just confirmed this my end either: script has made relevant changes in the right places (i.e. XML file) and once unit was restarted, this avenue of exploration got closed and updated XML remains in place.

Also, an additional finding as per my dialogue with researchers: although v4.x firmware (or Gen 1 unit) does not furnish users with nobody account, the same trick as per the exploit presented in the movie can be done using guest account.
Obviously this script addresses this vulnerability in this case as well.

Thanks Krzemien for the confirmation of the v4.x firmware (Gen 1 unit) WD mycloud.

However, please note that your statement “the v4.x firmware (or Gen 1 unit) does not furnish users with nobody account” appears not to be correct for all existing v4.x firmwares.

my firmware (v04.05.00-342) comprises both a :

  • nobody account
  • guest account

However, as indicated correctly by Krzemien, getting in without passwd only worked using the guest account. So only the guest account would make my device accessible using the known vulnerability.
Obviously, I did delete the guest account straight away on my mycloud after finding this out.

Correct, apologies for this slip: it’s the other account (squeezecenter) that does not exist, nobody account exists indeed.

My fix for the Zero-Day security vulnerability on WD NAS devices involves the “fork” function…

…as in, I’m going to fork-out for another manufacturer’s NAS product. Preferably one that can write decent firmware and that provides actual customer support.

WD make great disks; they make rubbish NAS drives (IMO).

–N.