Cross posting this article posted by another user in the OS5 My Cloud subforum since it mentions a possible fix for a Zero Day RCE security vulnerability in OS3.
At issue is a remote code execution flaw residing in all Western Digital network attached storage (NAS) devices running MyCloudOS 3 , an operating system the company only recently stopped supporting.
Researchers Radek Domanski and Pedro Ribeirooriginally planned to present their findings at the Pwn2Own hacking competition in Tokyo last year. But just days before the event Western Digital released MyCloud OS 5 , which eliminated the bug they found. That update effectively nullified their chances at competing in Pwn2Own, which requires exploits to work against the latest firmware or software supported by the targeted device.
…
In recognition of this, the researchers have developed and released their own patch that fixes the vulnerabilities they found in OS 3 (the patch needs to be reapplied each time the device is rebooted). Western Digital said it is aware of third parties offering security patches for My Cloud OS 3.
“We have not evaluated any such patches and we are unable to provide any support for such patches,” the company stated.
NOTE: USE AT YOUR OWN RISK!!! Note: Unknown if this applies to both v4.x and v2.x firmware or is for only for v2.x firmware. Script generates errors (for me) on first gen single bay My Cloud v4.x firmware. So use at your own risk!
One may be able to have this patch execute upon each My Cloud boot/reboot by putting the script “.sh” file into /etc/rc2.d/S98user-start if it exists on one’s OS3 My Cloud firmware/root.
We will not provide any further security updates to the My Cloud OS3 firmware. We strongly encourage moving to the My Cloud OS5 firmware. If your device is not eligible for upgrade to My Cloud OS 5, we recommend that you upgrade to one of our other My Cloud offerings that support My Cloud OS 5. More information can be found here: WD My Cloud OS 5 Mobile App and Desktop Web Access | Western Digital
Could perhaps somebody in the know put this patch into some sort of step-by-step tutorial for those less technically-minded?
I am more than happy to faff with my device via Putty etc. - as I’ve done in the past - but am not familiar with UNIX-type environment and last thing I want is to break something by incorrect syntax etc.
Warning: The following is a general procedure and may require modification to work on your My Cloud!!! The following may only work on v2.x firmware My Cloud units. The following requires some additional SSH or WinSCP knowledge by the user. Do NOT proceed if you are unsure about how to do the steps detailed below. PROCEED AT YOUR OWN RISK!!!
Connect to your My Cloud using SSH (using Putty for example)
Navigate to the root level. (ex: cd ..)
Create a “.sh” file (for example, using nano) with a name of your choice: nano authfix.sh
Past the following into it, then save the file:
#!/bin/bash
echo "> weekend_destroyer_patch: patch for 0 day sploit by"
echo " Pedro Ribeiro (@pedrib1337 | pedrib@gmail.com)"
echo " Radek Domanski (@RabbitPro | radek.domanski@gmail.com)"
echo "v0.1, released 25/02/2021"
echo ""
echo "> Patching vulnerability and restarting httpd..."
# Yup, this is the only POST with USER_AUTH in the whole file, so this is safe
sed -i 's/<post>USER_AUTH<\/post>/<post>ADMIN_AUTH<\/post>/' /var/www/rest-api/api/System/config/module.config.xml
killall httpd
sleep 1
httpd -f /usr/local/apache2/conf/httpd.conf -k graceful &
sleep 1
echo "> Vulnerability patched. Don't forget to run this script at every reboot!"
Change permissions on the file to executable. Example: chmod 0777 authfix.sh
Execute the file: sh authfix.sh
Note: On a v4.x firmware single bay My Cloud, the script produces errors so it may only work on v2.x firmware My Cloud units.
USE AT YOUR OWN RISK!!! IF YOU BRICK YOUR MACHINE DON’T BLAME ME OR THE WRITERS OF THE CODE FIX!!!
As explained in the first post, this patch does not appear to work on a v4.x firmware first single bay My Cloud. It appears this patch may only apply to v2.x firmware and further may need to be modified to work on specific v2.x firmware My Cloud models.
Which is why, as always, one proceeds at their own risk with these things. And why copious warnings are issued to the user.
Unfortunately this situation is what it is. One can take the risk and try to run the patch on their v2.x firmware My Cloud. Or they can disconnect their OS3 My Cloud from the Internet. Or they can do nothing. Or they can stop using the My Cloud all together. Choice is theirs. Now at least there is a possible option that might possibly fix the sloppy (again) firmware coding by WD. It may work, it may not. The end user assumes all the risks if they decide to run the patch. YMMV and all that.
This device in my case - due to its capricious behaviours when its rather unimpressive various apps are considered - is merely a backup device, and one of many either.
And yes, I messed with it few times - to recall: to downgrade the firmware once or twice (using the information provided by others from these very forums) in the past, and recently to make HD Sentinel run on it. So although I might not be familiar with UNIX-type of environment, I think I would know how to proceed if given detailed tutorial.
Given your style of response above I cannot say I’m surprised - and can only guess the feedback you’ve got from the end users.
One verifies it by testing the original exploit and by seeing if the change indicated in the patch was made to the file the patch updates. See the link(s) in the first post that explain the exploit then learn how to test for it.
Thanks. That’s what I just got when I created and ran the script:
Patching vulnerability and restarting httpd…
httpd: no process found
authfix.sh: line 15: httpd: command not found
Vulnerability patched. Don’t forget to run this script at every reboot!
Do you have the same response?
Also, does anybody actually know what this vulnerability entails exactly, given that the above scrips seems doing something to httpd which apparently does not run on my device?
“I” fully understand the risks when I access a My Cloud using SSH. Whether or not other users fully understand the risks when they access their devices using SSH is entirely their responsibility and risk. The information with accompanying warnings is there for the user to do with what they wish; even if they choose not to know what they are doing and brick their devices.
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)
<?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:~#
<?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)
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)
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:
@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.
).
