"The My Book Live device received its final firmware update in 2015."
A unpatched in 6 years linux device directly connected to the internet? What could possibly go wrong?
"There is no IoT, there is only the internet of unpatched linux boxes."
A unpatched in 6 years linux device directly connected to the internet? What could possibly go wrong?
"There is no IoT, there is only the internet of unpatched linux boxes."
So, yes, essentially you end up with a bunch of devices running vendor-specific unmaintained Linux distros on the wide open Internet. The “unmaintained” part of that sentence is the problem, not the “Linux” part.
Shouldn't we design systems that are hard to break by default? Shouldn't the OS assume that terrible things are going to happen anyway, and provide protection from bad faith actors in case the OS is indeed left unpatched for 10 years while being fully exposed to the internet? Is it even possible to design a system that provides this level of security so that we can get away with near-zero additional security expertise from product designers who build on top of it?
I think that, first of all, it's Western Digital's responsibility that things went south here. But shouldn't we build systems that provide bomb-proof security for the many companies that build on top of it? Is it even possible? And if so, how? In the end we would be doing ourselves (as consumers) a favor.
I highly doubt it, at least not with 100% certainty. We build bridges to last and to stand weather. These are enormous constructions with large safety margins, teams designated just for security (against weather, earthquakes etc) with peoples lives on the line. Yet, we need to inspect them on the regular to make sure no assumption broke, no safety system was triggered and nothing unexpected happened.
If we can't make this work at this scale, I have no hopes that software for comparatively cheap consumer devices manages to achieve this.
However this is a problem the industry has been struggling with for decades. It's simply not easy (and maybe not even possible) to achieve what you claimed "should" happen. Nobody knows how to produce bug-free software at scale.
So if anyone wants to support their 11 year old drive they can do so.
[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=OpenSSH
For this particular attack (assuming c2 server compromise?) that might not matter, but ultimately there is a massive difference in attack surface when comparing “direct” with “NATed”
How much would you bet against that being an unauthenticated call or one with leaked hard coded reds?
Or are you assuming the user's browser itself is compromised and is running random javascript hitting the NAS address? That would be unfortunate, but I'm not sure I'd blame it on the "6 years past EOL consumer linux device"
Classic old cross origin request forgery. It ranks #7 I owasp’s top 10 website security flaws, and they have this to say about it:
“XSS is the second most prevalent issue in the OWASP Top 10, and is found in around two thirds of all applications.“
Assume some javascript that loops through:
http://192.168.0.1/cgi-bin/factoryRestore.sh
http://192.168.0.2/cgi-bin/factoryRestore.sh
http://192.168.0.3/cgi-bin/factoryRestore.sh
up to
http://192.168.0.254/cgi-bin/factoryRestore.sh
Those just give connection errors for me, but:
http://192.168.1.1/cgi/ACT_FACTORY_RESET
gives me a 403 Forbidden error, and if there was a known default password to my router - it'd try and do a factory reset on it. (It actually wouldn't, it'd send back a confirmation popup, but...)