Slashdot Mirror
Buggy Software in Popular Connected Storage Drives Can Let Hackers Read Private Data (techcrunch.com)
Security researchers have found flaws in four popular connected storage drives that they say could let hackers access a user's private and sensitive data. From a report: The researchers Paulos Yibelo and Daniel Eshetu said the software running on three of the devices they tested -- NetGear Stora, Seagate Home and Medion LifeCloud -- can allow an attacker to remotely read, change and delete data without requiring a password. Yibelo, who shared the research with TechCrunch this week and posted the findings Friday, said that many other devices may be at risk.
The software, Hipserv, built by tech company Axentra, was largely to blame for three of the four flaws they found. Hipserv is Linux-based, and uses several web technologies -- including PHP -- to power the web interface. But the researchers found that bugs could let them read files on the drive without any authentication. It also meant they could run any command they wanted as "root" -- the built-in user account with the highest level of access -- making the data on the device vulnerable to prying eyes or destruction.
The software, Hipserv, built by tech company Axentra, was largely to blame for three of the four flaws they found. Hipserv is Linux-based, and uses several web technologies -- including PHP -- to power the web interface. But the researchers found that bugs could let them read files on the drive without any authentication. It also meant they could run any command they wanted as "root" -- the built-in user account with the highest level of access -- making the data on the device vulnerable to prying eyes or destruction.
You mean cheap software written in PHP is insecure?
So it seems like it's up to Axentra to fix their poorly coded Piece Of Shit? But do they really even care?
This kind of sloppy programming needs to come with easy-to-litigate civil remedie$ and then maybe it will stop.
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
Well at least the hackers aren't turning them into bombs.
https://media-wired-com.cdn.am...
Somebody felt the need to explain the notion of the root user? On /.?
Goodness.
ceci n'est pas un sig.
You say that, but to what extent is it true?
Let's take the hypothetical scenario - you've an A1+ OB-rated computer with hardware-enforced memory segmentation and memory security labelling, and network security labelling. There's no root and everything is by mandatory access control.
Let's say the firewall has been set to block all incoming connections.
The computer is online, but in what sense is all of it online? How do you propose to hack the hard drive of such a machine?
The problem with simplistic descriptions is that they lead to naive optimism or naive conservatism.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
What if it's a house on top of K2, with the entrance on the roof reachable only by a deadly maze?
I'd have thought you could leave the front door wide open.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
+1
nothing to see here - move along
I would imagine an Internet-connected router could be handy. NAS and SAN drives are, by their nature, capable of being on the Internet.
However, anyone buying a networked appliance should be a fully-qualified firewall admin, and the cloud should really be evaporated.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
There are some quality devices. Synology and QNAP NAS models have solid security, and if you need to add stuff like fail2ban, borg backup, gpg, or other items, that is easily accomplished.
You can have a NAS that is secure enough to sit on a public IP space (not sure why you want to), and be resistant to attack, provided you limit the IP space, enable 2FA, SSH RSA keys, and keep good backups.
Secure NAS products are out there... it is just that some companies just don't seem to care enough about making a securable device.
Why would anybody ever have a hard coded admin account?!? That is unbelievable. That is why Linux sucks so bad it has hard coded backdoor accounts! I'm so glad I use BeOS, I don't have to worry about hackers!
From the "Wizcase" article:
But CVE-2018-18471 and CVE-2018-18472 are not listed at mitre.org or the NIST database:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18471
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18472
This is basically a single-drive NAS that has a way to log in and access your files when away from home. Sort of like Dropbox in a way, but with apparently terrible security.
No reason why it would cost that, but blanket statements don't come with an implicit upper bound. If you want claim "for all", you'd best either state range or be damn sure I can't provide an existence proof for an exception.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Won't work.
First, the firewall is set to block all incoming connections. Makes it impossible to break into, since you can't connect to it.
Second, security labeling means even if you got into the firewall, the firewall can't generate any packets the machine would accept.
Third, because incoming connections are blocked, there are no credentials to intercept.
It doesn't matter what you can get around, it matters only if there's a vector that runs from where you start to where you want to end. No complete path, no luck. No matter what you can work around.
You don't know if your frameworks are secure? You've never looked at, oh, validating the code? Give you some suggestions.
First, look up CERT Secure Programming. Then look up NASA's Power of Ten. If you're using interacting threads, learn about Pi calculus. Splint is not terribly good, better static checkers are out there - some built into LLVM. You won't use all of these, but that's unimportant.
If you code is:
1) Easy to read
2) Free of defective underlying functions
3) Free of known standard coding errors
4) An implementation of a validated state machine
5) Properly tested at unit and integrated levels
6) Tested against linguistic anomalies (such as injectable escape codes and terminators)
Then you can be confident that the defect density is very low indeed. If you choose not to be, that's your problem.
If you want to increase confidence further, you want to make sure:
A) Test harnesses are developed prior to implementation
B) Additional theorems are developed about how the code operates
C) Everything is properly encapsulated and isolated under minimum privilege doctrine
D) One module does one thing and does it well (UNIX doctrine)
The point of C is that even if a bug exists, it simply doesn't matter. Either it can't be reached or you can't get anywhere from it. You cannot prove a program 100% correct, but you don't have to. You only have to prove that any remaining defects are disjoint.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)