I would love to submit this to https://support.wdc.com/ as asked in some other threads but i’m not able to create an account there since a few days. It just says “registration failed” after submitting the registration form without giving ANY information why it failed.
If some one here has an account please go ahead and submit it.
It seems the second vulnerability is even known since more then a year:
Exactly, that’s why i had pointed out in my initial post that my observations are from a MyCloud Mirror 1st Gen:
and that it might be possible that other models / generations are affected as well by those known / existing vulnerabilities:
And most stuff on the https://www.exploitee.rs wiki page seems to have been tested on a MyCloud EX2 but the MyCloud Mirror 1st Gen was affected by all vulnerabilities as well.
As the MyCloud Mirror Changelog is containing notes about fixed vulnerabilities, where not all known are fixed as shown above this might apply for the plain MyClouds as well. Thus i assume that the Changelogs can’t be trusted fully.
So if you’re on a MyCloud (which you’re obviously are based on this forum) you can verify the two posted vulnerabilities against your device. And if the device is still vulnerable the posts are fitting here (in the “Latest firmware still vulnerable thread”) as well.
Regardless of whether the vulnerabilities were closed with the latest updates, I would like to summarize for myself: what are the steps to protect yourself? So I update the firmware, it is firstly and for sure.
Disabling Cloud Access was also important. But what else can / must one do? On the router? On MyCloud device? In the dashoard? Disabling UpNp as I can remember?
It’s best to disconnect it from power supply, as a web page loaded in some device on a machine on the local network can exploit the backdoor just as well.
I find it hard to accept that this vulnerability should have been known to WD since June last year, and no fix has been provided. This is bad. The statements made by WD staff members in this thread (much earlier) about them taking security issues seriously sound pretty derisive.
Whew for once the first gen v4.x single bay units are not affected…
Always a good suggestion in any event with or without a My Cloud device on the local network. If one is serious about their network security they’d restrict guest access and ensure guest systems are clean before being allowed to access the full local network. Otherwise confine those guests and their systems to a guest network that is blocked from being able to access the main local network where devices like the My Cloud reside. Most consumers however are not that anal (even if it’s good practice) about securing their local network and their devices (like the My Cloud).
Edit to add: It should be noted that the Gulftech.org vulnerability was against the 2.30.165 firmware. No word (at least i didn’t see it in the article) if the current v2.30.172 firmware released on 11/16/17 for the single bay My Cloud units is affected or if the vuln hole was closed.
Also from that Gulftech.org link comes the following which is interesting to read.
–[ 04 - D-Link DNS-320L ShareCenter
As I have mentioned earlier in this article, I found it peculiar that
the username used for the backdoor is “mydlinkBRionyg”, and that the
vulnerability in Section 1 of this paper refers to a non existent file name
of “mydlink.cgi”. This really piqued my curiosity, and so I started using
google to try to track down some leads. After searching for the term of
“mydlink.cgi” I came across a reference to a post made by a D-Link user
regarding their D-Link DNS-320L ShareCenter NAS device.
Within that post were references to file names and directory structure that
were fairly unique, and from the D-link device. But, they also perfectly
matched my WDMyCloud device. The more I looked into this the weirder it
seemed. So, I gained access to a D-Link DNS-320L ShareCenter. Once I had it
things became pretty clear to me as the D-Link DNS-320L had the same exact
hard coded backdoor and same exact file upload vulnerability that was
present within the WDMyCloud. So, it seems that the WDMyCloud software
shares a large amount of the D-Link DNS-320L code, backdoor and all. There
are also other undeniable examples such as misspelled function names and
other anomalies that match up within both the WDMyCloud and the D-Link
DNS-320L ShareCenter code.
It should be noted that unlike the WDMyCloud the D-Link DNS-320L is
currently NOT vulnerable to the backdoor and file upload issues, so you
should upgrade your DNS-320L firmware as soon as possible as the issues can
be leveraged to gain a remote root shell on the DNS-320L if you are not up
to date with your device firmware. The backdoor was first removed in the
1.0.6 firmware release. (July 28, 2014)
It is interesting to think about how before D-Link updated their software
two of the most popular NAS device families in the world, sold by two of
the most popular tech companies in the world were both vulnerable at the
same time, to the same backdoor for a while. The time frame in which both
devices were vulnerable at the same time in the wild was roughly from early
2014 to later in 2014 based on comparing firmware release note dates.
Because my MyCloud is powered-off already more than 1 year since I read this posting here, unfortuntunatly I forgot how it works… if I disable the remote access will I be able to access my data on the MyCloud when I am in my home network? Also, can I then login into the dashboard the change settings for example?
No it doesn’t get much worse then that, other than the fact that WD will probably take their sweet time as in months (just like in the past) to issue a firmware update to fix this latest round of vulnerabilities.
If one disables Cloud Access via the My Cloud Dashboard Settings all one is doing is turning off the remote access capabilities (not FTP though as that is a separate setting) of the unit. One will still have local network access to the device including Dashboard access.
Simple steps are to ensure your network is secure by using strong WiFi password(s). Do not allow any guests to access the network (wired or WiFi). Turn off Guest WiFi if router supports it. Review router port forwarding settings and remove any unneeded port forward entries. Make sure all computers connected to the local network are using antivirus/antimalware/security software that is up to date and to run scans often/weekly to keep computers clean of viruses and malware.
Do what on the hardware side? Improve security? There’s not much you can about that, since it’s the firmware that handles the vulnerable protocols.
I recommend disabling UPnP control of router ports, as it prevents rogue software opening ports in your router, thus providing an external access mechanism. That’s still firmware/software, though, not hardware…
One would still be disabing UPnP via firmware on the My Cloud (/etc/init.d/upnp_nas stop) or better on the router itself. Some routers have an option to disable UPnP.
One can try to turn off UPnP via SSH on the My Cloud by issing the /etc/init.d/upnp_nas stop command. Depending on which My Cloud version you have you can put that command into a CRON or user-start file to try and stop UPnP on the My Cloud. Use the forum search feature to search for how to stop UPnP as there is probably some past discussion on it in the discussions on the sleep issue.
and what is better or what has less consequences: disabling UPnP on the router side or on the MyCloud device? Because disabling on the router has effect on all future connections. On the Mycloud device this should influence only the device. Or am I wrong?