Command injection and backdoor account in D-Link NAS devices(github.com)
github.com
Command injection and backdoor account in D-Link NAS devices
https://github.com/netsecfish/dlink
113 comments
I think people should learn how to configure their network in the first place.
- Don't get a cloud router (ever!)
- learn about vlans and use them.
- never hook a critical device like a NAS to the wider internet
- Don't get a cloud router (ever!)
- learn about vlans and use them.
- never hook a critical device like a NAS to the wider internet
What good is VLAN if an attacker breaks into your router? (non-rhetorical question) He could forge any packets and networks after that. I also have doubts in my separate wire setup (data LAN + management LAN) because any device with both cables attached can potentially be made into a bridge.
Most likely - ANY (even business-class) device, not limited to storage, is prone to this, unfortunately. Most terrifying of which are routers, mobile phones and home security cams/doorbells/etc.
s/NAS/network/
s/NAS/network/
Terramaster is a cheap young Chinese nas brand.
Never had issues with Synology.
Never had issues with Synology.
As I said, while that was the brand I had, brands like QNAP and Asustor have also had the exact same issues. These devices are all just examples of poorly supported hardware, where a solution where you control the hardware and software installed on it is far more likely to be supported going forward.
QNAP is known to have garbage security though. I personally have a Synology NAS with no internet access (blocked using my firewall)
> You are far better off getting cheap hardware and running TrueNAS or Unraid on it as they actually get regular software updates and don't have a history of major security issues.
Unpopular opinion: really you'd be "far better off" using Dropbox or Drive or whatever. By demanding to store your junk yourself you've already walked away from the clearly most robust solution.
Obviously this will engender the standard HN freakout about privacy and Big Tech and whatever, and I won't engage. But at the narrow level of robustness and security, the cloud experts are going to do this objectively better than anything under your personal control, probably by more than an order of magnitude.
Unpopular opinion: really you'd be "far better off" using Dropbox or Drive or whatever. By demanding to store your junk yourself you've already walked away from the clearly most robust solution.
Obviously this will engender the standard HN freakout about privacy and Big Tech and whatever, and I won't engage. But at the narrow level of robustness and security, the cloud experts are going to do this objectively better than anything under your personal control, probably by more than an order of magnitude.
Those aren't an equivalent solution at all. A NAS is for storage of lots of data, even the biggest options from the companies you mentioned wouldn't provide as much data as I have on my NAS. If I were to host the data in a real solution for larger amounts of data such as with Backblaze I'd have to pay nearly $1000/year.
There are multiple different tiers of data that I keep: on device, encrypted snapshots, cloud, and NAS. There is differing amounts of money and effort I'm willing to spend depending on the type of data, but no one solutions is sufficient for everything.
There are multiple different tiers of data that I keep: on device, encrypted snapshots, cloud, and NAS. There is differing amounts of money and effort I'm willing to spend depending on the type of data, but no one solutions is sufficient for everything.
seems pretty cheap tbh
Have you seen how much those services charge for even just 10tb of storage? It's insane.
Looks like $15 a month at Dropbox (it's true that the other providers don't count that high[1] in their standard rates, so you end up having to do it as more expensive overage). Seems like a bargain for not getting backdoored to me. But then I did say it was an unpopular opinion.
[1] I do chuckle at the use of "just 10tb". Obviously the real issue here is that these NAS boxes are deployed in service of movie and porn collections that people don't want to leave with a third party. But my point was about reliability and security, not legality or propriety.
[1] I do chuckle at the use of "just 10tb". Obviously the real issue here is that these NAS boxes are deployed in service of movie and porn collections that people don't want to leave with a third party. But my point was about reliability and security, not legality or propriety.
It shows "€12/user/month" for Business (9TB), but that's with a 3 user minimum, so €36/month. The "Essentials" package for individuals is €16.58/month, but has only 3TB of storage. I don't know what it would cost to add extra storage for that (doesn't show a price), but I would be surprised if it was less than €25/month, and wouldn't be surprised if it was quite a bit more than that.
From what I can tell dropbox will charge you E14.50*3=43.5/month (Business plan with a minimum of 3 users) or E522/year for 9TB, but maybe I'm missing something in their pricing?
> I do chuckle at the use of "just 10tb"
It's 2024. 2TB SSDs can be bought cheaply, and so can 16TB HDDs.
> I do chuckle at the use of "just 10tb"
It's 2024. 2TB SSDs can be bought cheaply, and so can 16TB HDDs.
Yeah but the fact that you can buy a 10TB disk doesn't mean it's normal to need to store 10TB of data.
I think bandwidth is a bigger issue with cloud storage. Most people have terrible upload bandwidth.
I think bandwidth is a bigger issue with cloud storage. Most people have terrible upload bandwidth.
My upload bandwidth is 3Mbps. My NAS is an old computer running Linux and samba. Due to the bandwidth issue cloud is a complete non-starter.
It's not normal for you.
It's not normal full stop. A tiny fraction of people might need it but it's definitely not the norm.
Shrug. Neither is posting on HN or caring about other people their data retention preferences.
Dropbox speed is low. Even in Dropbox plus, ordinary features are behind paywall. Not interesting.
Also, it’s not a good idea to store TBs of personal information on someone else’s computer or potentially the internet.
Also, it’s not a good idea to store TBs of personal information on someone else’s computer or potentially the internet.
If you're using a NAS as regular storage as I do, having it on your LAN gives you far superior performance. NFS exposed only over wireguard is secure enough for me and I've never had any worries about "robustness".
Inb4 the old "dropbox/ftp HN suggestion" meme. I'm not recommending my setup for common users, or even for you. It suits my needs and that's all that I really care about.
Inb4 the old "dropbox/ftp HN suggestion" meme. I'm not recommending my setup for common users, or even for you. It suits my needs and that's all that I really care about.
You are leaving out the other primary reasons for a local NAS -- upload bandwidth, data caps, and special usage scenarios. Not to say that cloud-hosted solutions purely for backup purposes don't have their place, but it is just one component of a 3-2-1 backup policy.
Unraid is not confidence inspiring either. It's just more commercial closed source software, developed behind closed doors and with a slow update cadence (~3 months). They have made questionable security choices anywhere you can see, and I have strong doubts that their code quality is any better.
The PHP scripts certainly are a horrible mess, in all ways. For example, shell injection prevention is based on using escapeshellarg at each call site... that pattern is _exactly_ the structural root cause for vulnerabilities like the one D-Link had.
In no particular order, and obviously not exhaustive: Everything runs directly as root - nginx, php-fpm, smb, ... No AppArmor/SELinux. There is no Secure Boot support (especially unfortunate since boot is from USB stick). No HTTPS access to web frontend by default. SMB protocol defaults are insecure. SMB shares default to public. SSH allows password-based root login. Pools are unencrypted at rest by default. They have a checkbox to enable telnet for management! Very permissive iptables rules. Almost any features that real competitors like Synology would officially provide come from third parties via a moderately shady app store.
Note it's not about any of these individual points. I see above as signal that they are not security experts and see security as an afterthought, rather than as something that deserves a team of experts that specifically cares about it.
(There's certainly other fields they also aren't experts in, like UX - their predominant UI pattern is "list of dropdown fields". Even in storage, one could have a longer discussion how their Array feature - the true core of their product -, compares to modern solutions. There's a reason they've evolved cache pools to just pools as a separate thing, and some users do pool-only Unraid...)
That's all quite understandable since it's a small team with only 2-3 coders (https://unraid.net/about). But nevertheless.
The PHP scripts certainly are a horrible mess, in all ways. For example, shell injection prevention is based on using escapeshellarg at each call site... that pattern is _exactly_ the structural root cause for vulnerabilities like the one D-Link had.
In no particular order, and obviously not exhaustive: Everything runs directly as root - nginx, php-fpm, smb, ... No AppArmor/SELinux. There is no Secure Boot support (especially unfortunate since boot is from USB stick). No HTTPS access to web frontend by default. SMB protocol defaults are insecure. SMB shares default to public. SSH allows password-based root login. Pools are unencrypted at rest by default. They have a checkbox to enable telnet for management! Very permissive iptables rules. Almost any features that real competitors like Synology would officially provide come from third parties via a moderately shady app store.
Note it's not about any of these individual points. I see above as signal that they are not security experts and see security as an afterthought, rather than as something that deserves a team of experts that specifically cares about it.
(There's certainly other fields they also aren't experts in, like UX - their predominant UI pattern is "list of dropdown fields". Even in storage, one could have a longer discussion how their Array feature - the true core of their product -, compares to modern solutions. There's a reason they've evolved cache pools to just pools as a separate thing, and some users do pool-only Unraid...)
That's all quite understandable since it's a small team with only 2-3 coders (https://unraid.net/about). But nevertheless.
> Everything runs directly as root - nginx, php-fpm, smb,
For the record: you need root on Linux to open ports below 1000. By necessity, these programs need at least one thread that runs as root just from that.
Can't comment on the rest. As I never used it. Fedora server + cockpit UI was enough for me when I switched from my Synology NAS the other day
For the record: you need root on Linux to open ports below 1000. By necessity, these programs need at least one thread that runs as root just from that.
Can't comment on the rest. As I never used it. Fedora server + cockpit UI was enough for me when I switched from my Synology NAS the other day
You can use cap_net_bind_service to bind ports <1024. You can listen on >1024 and redirect in iptables, or even with a trivial TCP proxy.
There are options on pretty much any system, but certainly on Linux with capabilities. None of these require direct support from the application (dropping root after binding does).
You almost never need to run anything as root, especially not with these "run 6 different types of services in a box" type of appliances.
None of this is new; this was already widely considered best practice when I was starting out 25 years ago.
There are options on pretty much any system, but certainly on Linux with capabilities. None of these require direct support from the application (dropping root after binding does).
You almost never need to run anything as root, especially not with these "run 6 different types of services in a box" type of appliances.
None of this is new; this was already widely considered best practice when I was starting out 25 years ago.
> There are options on pretty much any system, but certainly on Linux with capabilities.
If you're using systemd, you can grant the appropriate capability to the process by setting:
If you're using systemd, you can grant the appropriate capability to the process by setting:
[Service]
AmbientCapabilities=CAP_NET_BIND_SERVICE
[deleted]
You can drop root after binding, or you can use capabilities to allow a particular program to bind on privileged ports. php-fpm could listen on a UNIX socket instead of a TCP socket.
Exactly. A more modern secure approach is to let the init system open the socket and pass it as an FD. This has some side benefits too (not even temporary root for daemon, less custom code, standard&declarative config, socket activation).
(Of course Unraid, being based on Slackware, has a legacy init system that doesn't support this scheme. But there are enough other options.)
(Of course Unraid, being based on Slackware, has a legacy init system that doesn't support this scheme. But there are enough other options.)
[deleted]
[deleted]
The thing of interest is that although the DNS-320L, and the other D-Link NASes, is EOL (End Of Life), there are more than 90,000 devices still operating out there!
The bad thing here is that many manufacturers, even big ones, tend to forget “old” products and drop support for them. Usually it’s a market/business decision, but this is what happens with closed systems :-(
Quoting from https://www.dlink.com/uk/en/products/dns-320l-sharecenter-2-... :
>> This product was phased out on: 13/11/2017
>> This product's last date of support is on: 13/11/2019
Being an owner of 320L, I don’t expect D-Link to offer us an updated firmware any time soon.
The bad thing here is that many manufacturers, even big ones, tend to forget “old” products and drop support for them. Usually it’s a market/business decision, but this is what happens with closed systems :-(
Quoting from https://www.dlink.com/uk/en/products/dns-320l-sharecenter-2-... :
>> This product was phased out on: 13/11/2017
>> This product's last date of support is on: 13/11/2019
Being an owner of 320L, I don’t expect D-Link to offer us an updated firmware any time soon.
>I don’t expect D-Link to offer us an updated firmware any time soon
Don't worry, some botnet will infect all of these and fix the vulnerability in order to prevent competing malware from gaining access. This fix will deploy within an impressively tight timeline.
Don't worry, some botnet will infect all of these and fix the vulnerability in order to prevent competing malware from gaining access. This fix will deploy within an impressively tight timeline.
Sometime ago I found an alternative "OS" for my DNS-320L called Alt-f [0]. Granted its UI is very old-school but it has worked flawlessly. There has been no release since 2022 but at least it's more recent than the last official firmware (and I assume is not impacted by the vulnerability).
IIRC I didn't even had to format or move the data I had on it before installing.
[0] https://sourceforge.net/projects/alt-f/
IIRC I didn't even had to format or move the data I had on it before installing.
[0] https://sourceforge.net/projects/alt-f/
Is there a better way to track D-Link EOLs? Would be nice to have this up at the endoflife.date.
Yeah it's not even surprising - does ANYONE in their right mind go through all their gadgets/home appliances to check their EOL status??
The whole reason for buying a completely set up and ready to go device that you don't configure yourself is to "put it and forget it". And that is the part when manufacturers screw you.
(I myself am running 10+yo hardware and pretty happy about it.)
Synology DSM and apps are closed source. It’s a Taiwanese company, and I wonder to what extent it can be trusted?
Anyone has information on the security of DSM? Like, is it compliant for use in sensitive departments?
Anyone has information on the security of DSM? Like, is it compliant for use in sensitive departments?
I honestly don't know, but the fact that they give updates for 10 years is impressive compared to everyone else.
I bought one in fall 2012 and it got the DSM 7.0 update on 2022 or 2023; even though the UI is really really slow, it gives me a lot of confidence that they know what they're doing.
I bought one in fall 2012 and it got the DSM 7.0 update on 2022 or 2023; even though the UI is really really slow, it gives me a lot of confidence that they know what they're doing.
Remember the recent stories about how FOSS is inherently less secure than proprietary systems - and because of the xz exploit, which was infinitely more complex? I'm trying to remember a FOSS system with a hardcoded, passwordless backdoor - it's a big world; there must be some. I almost expect a backdoor (though with a password!) in a consumer NAS.
I don't knee-jerk reject proprietary solutions. And they might have an advantage if there was liability for this sort of thing. D-Link should be paying hefty fines for selling this obviously substandard, unprofessional crap to the public.
I don't knee-jerk reject proprietary solutions. And they might have an advantage if there was liability for this sort of thing. D-Link should be paying hefty fines for selling this obviously substandard, unprofessional crap to the public.
Ask HN: Are there any hardware manufacturers that can be relied upon not to have big security problems?
These problems all go away if you don't expose crappy management software directly to the Internet.
Don't allow anonymous inbound traffic on your firewall to hit your NAS (or any other interface that you're not updating and monitoring rigorously).
If you need remote access to your NAS, install a VPN (e.g., Tailscale, ZeroTier) on the NAS or a different host on your internal network, and then access it remotely over an SSH tunnel.
I understand that the casual home user doesn't know how to install a VPN or do SSH tunneling, so they end up exposing their NAS through the firewall, and that's why these issues are widespread. But for people who are a bit more technically savvy, you can massively reduce your attack surface by denying any inbound connections through your home firewall.
Don't allow anonymous inbound traffic on your firewall to hit your NAS (or any other interface that you're not updating and monitoring rigorously).
If you need remote access to your NAS, install a VPN (e.g., Tailscale, ZeroTier) on the NAS or a different host on your internal network, and then access it remotely over an SSH tunnel.
I understand that the casual home user doesn't know how to install a VPN or do SSH tunneling, so they end up exposing their NAS through the firewall, and that's why these issues are widespread. But for people who are a bit more technically savvy, you can massively reduce your attack surface by denying any inbound connections through your home firewall.
While "don't let any possible attacker see the device" is good defence in depth it is a pretty shitty only level of security. Even if it is protected outside of your local network many people have crappy IoT devices or even just laptops with malware on their network.
In top of that this won't even really prevent this vulnerability as it can be triggered by a GET request. This means that if you are connected to the VPN any site you visit can trigger it. (If they can guess the hostname or IP)
In top of that this won't even really prevent this vulnerability as it can be triggered by a GET request. This means that if you are connected to the VPN any site you visit can trigger it. (If they can guess the hostname or IP)
>While "don't let any possible attacker see the device" is good defence in depth it is a pretty shitty only level of security.
If we're talking about a company, I agree. For a home, I think VPN + firewall is sufficient security against insecure management software on network devices.
>Even if it is protected outside of your local network many people have crappy IoT devices or even just laptops with malware on their network.
If there's a malicious laptop within your network, what difference does it make if your NAS has a security vulnerability? If your laptop is compromised, it's game over anyway because the attacker can steal your cookies or install a keylogger. If it's a housemate's laptop that doesn't have access to the NAS, they can do ARP poisoning[0] and MitM your NAS to steal your credentials (unless you're also vigorous about managing your own TLS CA).
>In top of that this won't even really prevent this vulnerability as it can be triggered by a GET request. This means that if you are connected to the VPN any site you visit can trigger it. (If they can guess the hostname or IP)
Other websites can trigger the behavior, but they can't read any responses because of same origin policy, so they can't exploit anything.[1]
Correction: I overlooked in the writeup that the GET request allows RCE. So, you're right is that malicious websites can exploit this despite SOP. Still, firewall + VPN reduces your risk by many orders of magnitude. Instead of the attacker trivially scanning for your device or looking it up on Shodan, they have to trick you into visiting a malicious site.
[0] https://en.wikipedia.org/wiki/ARP_spoofing
[1] https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...
If we're talking about a company, I agree. For a home, I think VPN + firewall is sufficient security against insecure management software on network devices.
>Even if it is protected outside of your local network many people have crappy IoT devices or even just laptops with malware on their network.
If there's a malicious laptop within your network, what difference does it make if your NAS has a security vulnerability? If your laptop is compromised, it's game over anyway because the attacker can steal your cookies or install a keylogger. If it's a housemate's laptop that doesn't have access to the NAS, they can do ARP poisoning[0] and MitM your NAS to steal your credentials (unless you're also vigorous about managing your own TLS CA).
>In top of that this won't even really prevent this vulnerability as it can be triggered by a GET request. This means that if you are connected to the VPN any site you visit can trigger it. (If they can guess the hostname or IP)
Other websites can trigger the behavior, but they can't read any responses because of same origin policy, so they can't exploit anything.[1]
Correction: I overlooked in the writeup that the GET request allows RCE. So, you're right is that malicious websites can exploit this despite SOP. Still, firewall + VPN reduces your risk by many orders of magnitude. Instead of the attacker trivially scanning for your device or looking it up on Shodan, they have to trick you into visiting a malicious site.
[0] https://en.wikipedia.org/wiki/ARP_spoofing
[1] https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...
> they can do ARP poisoning[0] and MitM your NAS to steal your credentials (unless you're also vigorous about managing your own TLS CA)
All traffic to my NAS is secured, even over the local network. I don't trust the network and I don't think it should be game-over for my NAS because my housemate installs some malware. I use SSH with pinned keys and TLS (thanks Let's Encrypt).
I think if any NAS appliance doesn't provide some basic security like this it is a failing of that vendor. Even a self-signed TLS cert to provide TOFU validation would go a long way. (And actually in many ways be more secure than a public CA issued certificate.)
All traffic to my NAS is secured, even over the local network. I don't trust the network and I don't think it should be game-over for my NAS because my housemate installs some malware. I use SSH with pinned keys and TLS (thanks Let's Encrypt).
I think if any NAS appliance doesn't provide some basic security like this it is a failing of that vendor. Even a self-signed TLS cert to provide TOFU validation would go a long way. (And actually in many ways be more secure than a public CA issued certificate.)
I guess I'm not really sure what you're advocating.
These measures sound good for you, but what percentage of HN readers can do that? How many threats does it eliminate in practice beyond what you'd get from basic VPN + firewall?
There's always additional security measures you can take, but the costs go up and the marginal benefits go down.
It's a bit like saying it's not sufficient for other HN users to deadbolt their doors because it's weaker than the armed guards that patrol your property 24/7.
These measures sound good for you, but what percentage of HN readers can do that? How many threats does it eliminate in practice beyond what you'd get from basic VPN + firewall?
There's always additional security measures you can take, but the costs go up and the marginal benefits go down.
It's a bit like saying it's not sufficient for other HN users to deadbolt their doors because it's weaker than the armed guards that patrol your property 24/7.
Well what are you advocating? It seems like you are suggesting that device security isn't important because it is hard to do and a firewall will solve most problems.
But at the same time we are looking at a vulnerability that works through a firewall.
I am just suggesting that even in a presence of a firewall we should expect appliances to be secure on a hostile network. That is the standard we should hold vendors to. Much like Android, iOS, Windows and macOS hold themselves to this standard.
I'm also not saying that you should test this standard, defence in depth is very valuable. But I don't think saying "it is hard and a firewall solves many issues" is a good reason to forgive these vendors for shit security.
But at the same time we are looking at a vulnerability that works through a firewall.
I am just suggesting that even in a presence of a firewall we should expect appliances to be secure on a hostile network. That is the standard we should hold vendors to. Much like Android, iOS, Windows and macOS hold themselves to this standard.
I'm also not saying that you should test this standard, defence in depth is very valuable. But I don't think saying "it is hard and a firewall solves many issues" is a good reason to forgive these vendors for shit security.
>Well what are you advocating? It seems like you are suggesting that device security isn't important because it is hard to do and a firewall will solve most problems.
I'm advocating firewall with no inbound traffic + VPN for remote access. It mitigates most of the risk of devices on your network having security vulnerabilities.
My original comment in this thread was that it's more important to firewall + VPN your network than it is to pick a network appliance with a good security record.
I agree that there certainly are additional precautions you can take, but I think firewall + VPN defends against most practical attacks the average HN user would encounter.
Firewall + VPN is something a large proportion of HN (40%?) is capable of doing with about an hour of effort. I think it's a pretty small segment of HN that's even capable of the precautions you're talking about (separate VLANs, custom certificates, hardening every host), and it would take person-days of effort to replicate.
>But I don't think saying "it is hard and a firewall solves many issues" is a good reason to forgive these vendors for shit security.
I don't forgive vendors for shit security. I agree with you that we should hold vendors accountable. RCE on an unauthenticated GET request is absurdly incompetent and irresponsible, and D-Link deserves punishment. That said, I'm not in a position to influence D-Link, but I am in a position to help users protect themselves if appliances on their network have mistakes like this.
I'm advocating firewall with no inbound traffic + VPN for remote access. It mitigates most of the risk of devices on your network having security vulnerabilities.
My original comment in this thread was that it's more important to firewall + VPN your network than it is to pick a network appliance with a good security record.
I agree that there certainly are additional precautions you can take, but I think firewall + VPN defends against most practical attacks the average HN user would encounter.
Firewall + VPN is something a large proportion of HN (40%?) is capable of doing with about an hour of effort. I think it's a pretty small segment of HN that's even capable of the precautions you're talking about (separate VLANs, custom certificates, hardening every host), and it would take person-days of effort to replicate.
>But I don't think saying "it is hard and a firewall solves many issues" is a good reason to forgive these vendors for shit security.
I don't forgive vendors for shit security. I agree with you that we should hold vendors accountable. RCE on an unauthenticated GET request is absurdly incompetent and irresponsible, and D-Link deserves punishment. That said, I'm not in a position to influence D-Link, but I am in a position to help users protect themselves if appliances on their network have mistakes like this.
> For a home, I think VPN + firewall is sufficient security against insecure management software on network devices.
If you have some iot devices which phone home on the same network, then this theoretically could be a vector. It can be hard to know if that's the case.
On the more paranoid side, be sure your guest wifi can't access these devices.
If you have some iot devices which phone home on the same network, then this theoretically could be a vector. It can be hard to know if that's the case.
On the more paranoid side, be sure your guest wifi can't access these devices.
>crappy IoT devices
Those should all go on their own vlan, or for a more Joe Average(tm) approach the guest network.
>laptops with malware on their network.
At that point you've got bigger fish to fry than shitty firmware, all bets are off.
Those should all go on their own vlan, or for a more Joe Average(tm) approach the guest network.
>laptops with malware on their network.
At that point you've got bigger fish to fry than shitty firmware, all bets are off.
Why are all bets off if you have malware on my network. My devices are hardened with the expectation of being on hostile networks. My computers, phone and home server all assume that they are exposed to malicious actors. Of course defence in depth is also important, but there is no reason that all bets should be off if an attacker can access your device over the network.
This is the only sane way. You are then able to reason about impact and reasonably investigate when you inevitably end up dealing with a incident. Relying on a "trusted internal network" went out of fashion a long time ago.
Do you consider yourself a malicious actor to yourself? Because that's what you're saying.
I am assuming the hypothetical compromised laptop is your own, and thus assuming it contains credentials.
What credentials? Everything. All your credentials are belong to us.
At that point, the only way to defend against that is to have never trusted yourself. That's a ridiculous stance for any normal person; their home network is a trusted space.
That's why I'm saying all bets are off, you have bigger fish to fry than caring about some shitass firmware written by some third rate bank clerk in Bangladesh in a plastic box made by the finest sweatshops in China.
I am assuming the hypothetical compromised laptop is your own, and thus assuming it contains credentials.
What credentials? Everything. All your credentials are belong to us.
At that point, the only way to defend against that is to have never trusted yourself. That's a ridiculous stance for any normal person; their home network is a trusted space.
That's why I'm saying all bets are off, you have bigger fish to fry than caring about some shitass firmware written by some third rate bank clerk in Bangladesh in a plastic box made by the finest sweatshops in China.
Why would you assume the compromised laptop is my own? What if I have roommates? Or a friend comes over for a LAN party? I want them on my real network for Steam game transfers and game traffic. Maybe I want them to pull mods off of my NAS.
In that case, yes that network isn't a home network and should be untrusted as such.
Personally were I in your situation, I would have individual computers for each network as needed for total and proper segregation of trust; a NAS for the home and a NAS for the public (eg: LAN party) network. I would not trust a single computer with all sorts of data to safely handle two wildly different levels of trust simultaneously like that.
I consider the home network a trusted enclave. Thus, all bets are off if a compromised laptop is in the home network. I assumed the laptop was your own as a worst case scenario (Credentials! In plain arm's reach!). If an untrusted third party laptop breached or was invited into your home network, that's not immediately as bad but the bets are still off.
Basically: I see worrying about shitass firmware when you haven't secured the network as pointless. The hypothetical situation presented was a compromised laptop in the network; forget the firmware, you need to deal with that laptop and then commence cleanup of the network first.
Personally were I in your situation, I would have individual computers for each network as needed for total and proper segregation of trust; a NAS for the home and a NAS for the public (eg: LAN party) network. I would not trust a single computer with all sorts of data to safely handle two wildly different levels of trust simultaneously like that.
I consider the home network a trusted enclave. Thus, all bets are off if a compromised laptop is in the home network. I assumed the laptop was your own as a worst case scenario (Credentials! In plain arm's reach!). If an untrusted third party laptop breached or was invited into your home network, that's not immediately as bad but the bets are still off.
Basically: I see worrying about shitass firmware when you haven't secured the network as pointless. The hypothetical situation presented was a compromised laptop in the network; forget the firmware, you need to deal with that laptop and then commence cleanup of the network first.
We seem to have very different approaches to security. I'd instead say "forget about the network, you need to secure your servers".
I fundamentally dislike "secure enclaves", since they amount to giving up at some point. You can instead meaningfully exercise "defence in depth" by trying to keep file servers secure against unauthenticated attackers, or even authenticated ones; by not running unneeded network services on your desktops; etc.
Securing one layer perfectly might be tempting, but it's much more work than securing multiple layers "well enough". In other words, "shared WPA2 WiFi + an up-to-date TrueNAS system + multiple accounts for different users" will be much less work and more practical than any network-only solution you can suggest.
A layered approach also means that you don't need to worry so much about someone else's screwups. A friend had malware on their laptop, but didn't have credentials for the NAS? Not much need to worry, maybe just change the WiFi password and you're probably fine. They had access to a limited account? Probably only the data on that account is compromised. Most times you won't even get to check logs to confirm or start some top-to-bottom "cleanup", since you'll never know this even happened.
I fundamentally dislike "secure enclaves", since they amount to giving up at some point. You can instead meaningfully exercise "defence in depth" by trying to keep file servers secure against unauthenticated attackers, or even authenticated ones; by not running unneeded network services on your desktops; etc.
Securing one layer perfectly might be tempting, but it's much more work than securing multiple layers "well enough". In other words, "shared WPA2 WiFi + an up-to-date TrueNAS system + multiple accounts for different users" will be much less work and more practical than any network-only solution you can suggest.
A layered approach also means that you don't need to worry so much about someone else's screwups. A friend had malware on their laptop, but didn't have credentials for the NAS? Not much need to worry, maybe just change the WiFi password and you're probably fine. They had access to a limited account? Probably only the data on that account is compromised. Most times you won't even get to check logs to confirm or start some top-to-bottom "cleanup", since you'll never know this even happened.
At some point you have to put more trust into your home network than you would a public network. Not as far as accepting all communications, obviously, but in the sense that you have to open ports and services in order to accept incoming authentication requests and subsequent authenticated connections.
A locked door is weaker than a stone wall, after all. You're trusting that it's safe to have a locked door than a stone wall.
A locked door is weaker than a stone wall, after all. You're trusting that it's safe to have a locked door than a stone wall.
There are two major problems with this approach:
1. With gadgets like this, the gadget is likely to be your firewall.
2. You are almost certainly running a sandboxed agent inside your firewall that runs untrusted code: your web browser. CSRF attacks taking over crappy devices like the devices in question are a thing.
1. With gadgets like this, the gadget is likely to be your firewall.
2. You are almost certainly running a sandboxed agent inside your firewall that runs untrusted code: your web browser. CSRF attacks taking over crappy devices like the devices in question are a thing.
This advice massively reduces the largest risk, but “problems all go away” is wildly wrong
There are a ton of remote access and update functionality in these things that make them fully exploitable even with no internet exposure.
Theyll do crazy things like VPN back to home servers, where every single device is on a flat /8 with no additional security. So anyone who dumps the VPN keys from one is basically on your eth.
Or update unsigned firmware from domains that end up abandoned and left hanging
Etc etc
There are a ton of remote access and update functionality in these things that make them fully exploitable even with no internet exposure.
Theyll do crazy things like VPN back to home servers, where every single device is on a flat /8 with no additional security. So anyone who dumps the VPN keys from one is basically on your eth.
Or update unsigned firmware from domains that end up abandoned and left hanging
Etc etc
>This advice massively reduces the largest risk, but “problems all go away” is wildly wrong
By the problems all go away, I meant the problems associated with a network appliance handling malicious input that leads to a security issue. If the device isn't exposed to the Internet, it can't bungle malicious input.
>Theyll do crazy things like VPN back to home servers, where every single device is on a flat /8 with no additional security. So anyone who dumps the VPN keys from one is basically on your eth. > >Or update unsigned firmware from domains that end up abandoned and left hanging
Are there cases of that happening with products that have wide usage? Like 1M+ devices in the field?
The only time I can recall hearing of anything like that, was for a very small time vendor.[0]
Every security vulnerability I've heard about around NAS devices required the device to be exposed to the public Internet or for the attacker to be on the same local network as the vulnerable device.
[0] https://news.ycombinator.com/item?id=34325695
By the problems all go away, I meant the problems associated with a network appliance handling malicious input that leads to a security issue. If the device isn't exposed to the Internet, it can't bungle malicious input.
>Theyll do crazy things like VPN back to home servers, where every single device is on a flat /8 with no additional security. So anyone who dumps the VPN keys from one is basically on your eth. > >Or update unsigned firmware from domains that end up abandoned and left hanging
Are there cases of that happening with products that have wide usage? Like 1M+ devices in the field?
The only time I can recall hearing of anything like that, was for a very small time vendor.[0]
Every security vulnerability I've heard about around NAS devices required the device to be exposed to the public Internet or for the attacker to be on the same local network as the vulnerable device.
[0] https://news.ycombinator.com/item?id=34325695
Yeah, there have been a bunch. The last one I remember was a fairly well used security camera. VPN was how they streamed video back to storage. A really “simple” solution to turning a LAN-based video camera into an internet-connected one.
I’ll see if I can drag up some references, a quick google doesn’t show what I’m looking for.
I’ll see if I can drag up some references, a quick google doesn’t show what I’m looking for.
What kind of hardware? For home networking? Ubiquiti is okay. As bugs in these enterprise/SMB networking gear worth a little $$$ so there's at least people looking for low hanging fruits.
The best option however, is to find a recent MediaTek-based (because they are currently the most upstream-friendly WiFi AP SoC vendor) home router with vulnerable firmware (for easier flash lol) and replace the firmware with OpenWRT.
For NAS just build your own, or buy used rack-mount servers off eBay and leave them in basement.
The best option however, is to find a recent MediaTek-based (because they are currently the most upstream-friendly WiFi AP SoC vendor) home router with vulnerable firmware (for easier flash lol) and replace the firmware with OpenWRT.
For NAS just build your own, or buy used rack-mount servers off eBay and leave them in basement.
Amazon, Apple, Google tend to ship hardware that at least doesn’t having gaping 1997 style vulnerabilities everywhere.
Cisco have had some doozies but overall aren’t terrible.
Everything else is probably bad.
Cisco have had some doozies but overall aren’t terrible.
Everything else is probably bad.
I wish Apple hadn’t dropped out of the router business. The only good replacements all seem to be considerably more involved, e.g. a full Ubiquiti setup or one of the more mainstream routers with third party firmware. AirPorts were excellent for shoving into a corner and not having to think about aside from the odd firmware update every few years.
D-Link always was an almost trash kinda company.
To the best of my knowledge there has never been a remote exploit for a Commodore 64.
Morning standup at a state sponsored hacking organization.
Bob: I hope everyone had a good weekend. I’d like to start out by giving some kudos to Fred and Jane for the D-Link NAS back door!
A round of polite clapping.
Bob: Let’s start with Igor, how's it going?
Igor: Bah, my target is running web server on Commodore 64 so I spend all weekend to write 6502 remote exploit for Contiki OS. Unfortunately, I found out target keeps secrets on ZX81 but I don’t know Z80 assembly.
Bob: Fortunately we’re a state sponsored hacking organization so we have considerable resources. Federico, do you think you could give Igor a hand?
Federico: Certamente!
Bob: I hope everyone had a good weekend. I’d like to start out by giving some kudos to Fred and Jane for the D-Link NAS back door!
A round of polite clapping.
Bob: Let’s start with Igor, how's it going?
Igor: Bah, my target is running web server on Commodore 64 so I spend all weekend to write 6502 remote exploit for Contiki OS. Unfortunately, I found out target keeps secrets on ZX81 but I don’t know Z80 assembly.
Bob: Fortunately we’re a state sponsored hacking organization so we have considerable resources. Federico, do you think you could give Igor a hand?
Federico: Certamente!
Use generic hardware or build your own, and install an OS you can manage yourself
Mikrotik seems to be pretty regularly updated, even old devices - assuming they're not NSA frontend :)
Short answer --- no.
The key term here is *hardware manufacturers*.
They have no financial incentive to worry too much about software. The solution to every problem is to buy new hardware. Software bugs are just added incentive.
The key term here is *hardware manufacturers*.
They have no financial incentive to worry too much about software. The solution to every problem is to buy new hardware. Software bugs are just added incentive.
Use your own hardware and something like Unraid
[deleted]
[deleted]
How did this pass code review?
Walter Shao [0] says lgtm... (There is simply little awareness and not even minimum standards in the industry)
[0] https://forum.qnap.com/viewtopic.php?f=45&t=160849&start=450...
[0] https://forum.qnap.com/viewtopic.php?f=45&t=160849&start=450...
ouch…
This is completely usual for IoT/networking devices. It’s the longstanding reality. They just come at this stuff differently.
As I understand, the problem is that authentication used users from /etc/passwd and allowed to log in as any user, even as system user like "messagebus" which has no password. It is annoying that linux software uses system database for authorization, for example, Postgres and Samba do this and there is always a risk that you have some system user you don't know about which can be used to access your system.
Samba has its own user DB with the default auth backend and allows per share restrictions. Same with Postgres. "PostgreSQL database user names are logically separate from user names of the operating system in which the server runs." [https://www.postgresql.org/docs/current/client-authenticatio...]
"No password = locked account" is today's default policy on most systems, for a reason.
Not really. To be really sure, set ! as a password in /etc/shadow. That's what most distributions do. PAM has another security measure, if user's shell is not in /etc/shells, it's also considered a locked account and will not allow login.
Of course, follow the best practices if you want to be really sure, e.g. set the password field to "!" so it's invalid, set the shell to /sbin/nologin, set the home directory to /dev/null (doesn't really do anything but it's a convention), etc, etc, etc. The "must have password" policy is for preventing accidental mistakes by people who don't know anything about what we just said, and my experience is that it's an effective one.
Setting the home directory to a special device node file "/dev/null" sounds like a good way to shoot yourself in the foot, and I've never heard of this practice before. On Debian, at least, it seems like setting the home directory to "/nonexistent" is more common.
For example, running "deluser" later could end up performing a "remove home" cleanup operation, and you certainly don't want to remove the /dev/null file.
For example, running "deluser" later could end up performing a "remove home" cleanup operation, and you certainly don't want to remove the /dev/null file.
Yup and for outgoing traffic firewalling rules can also be put in place to only allow users authorized to emit traffic. Drop or reject anything by default, then only allow some users to send packets (like "john" and "_apt" [to update packages], etc.).
It's not incompatible with the other measures you described.
FWIW I also log, for every "user" on the system, anything from a user that's not supposed to access the net.
It's not incompatible with the other measures you described.
FWIW I also log, for every "user" on the system, anything from a user that's not supposed to access the net.
Unraveling this and dumping NSS would probably have a measurable increase in security and isolation. A backdoor xz thing in libnss would be catastrophic.
You're probably thinking of PAM (passwords and authentication), not NSS (hostname lookup). Both are direly in need of modernization, though.
Samba doesn't use the passwords or users in /etc/passwd directly. You have to map any SMB users into /etc/passwd users in Sambas database. Without that mapping they don't exist for Samba.
Yeah. It’s a pretty old-hat way of thinking. The ‘unified authentication database’ ship sailed long ago, for better or worse.
When my bosses want to know why a quote for a device like a NAS is thousands and thousands of dollars instead of hundreds of dollars I use examples like this.
Running consumer gear, especially public facing internet consumer gear is just asking for trouble.
TrueNAS/FreeNAS whatever it’s called these days - a real OS with real vendor and community support keeping the project alive and up to date is just necessary.
Buying these consumer devices that are set and forget with limited or zero firmware updates is BAD. Not to mention the code quality and unknown closed source backdoors
Running consumer gear, especially public facing internet consumer gear is just asking for trouble.
TrueNAS/FreeNAS whatever it’s called these days - a real OS with real vendor and community support keeping the project alive and up to date is just necessary.
Buying these consumer devices that are set and forget with limited or zero firmware updates is BAD. Not to mention the code quality and unknown closed source backdoors
> TrueNAS/FreeNAS whatever it’s called these days - a real OS with real vendor and community support keeping the project alive and up to date is just necessary.
and for routers there is OpenWRT. For example Turris is built on that and provides automatic firmware updates, that's a huge security benefit for those devices:
https://www.turris.com/en/
and for routers there is OpenWRT. For example Turris is built on that and provides automatic firmware updates, that's a huge security benefit for those devices:
https://www.turris.com/en/
Huge OpenWRT fan I’d almost even be tempted to deploy an OpenWRT device somehow as a NAS over any prebuilt consumer device.
It’s build it yourself (and get what you pay for) or buy junk and similarly roll the dice.
It’s not a terrible difficult value proposition to explain but there’s always the person in the room that knows just enough to not know this is something you do not introduce on your corporate network; you leave it home tucked away behind a firewall
It’s build it yourself (and get what you pay for) or buy junk and similarly roll the dice.
It’s not a terrible difficult value proposition to explain but there’s always the person in the room that knows just enough to not know this is something you do not introduce on your corporate network; you leave it home tucked away behind a firewall
> I’d almost even be tempted to deploy an OpenWRT device somehow as a NAS over any prebuilt consumer device.
No ZFS, but it appears to support mdadm and btrfs so that could work if you can get good hardware for it.
No ZFS, but it appears to support mdadm and btrfs so that could work if you can get good hardware for it.
Have I woken up in some universe where the word “backdoor” doesn’t mean what it used to? I am used to backdoor implying malicious intent on the part of the vendor / author, or something left by an attacker. I’m just not seeing that here. This just looks like utterly unsurprising incompetence on the part of a consumer networking / IoT gear manufacturer.
Yes, I know what a literal ‘back door’ is, and yes, I know that “make it look like incompetence” could be a strategy.
I’d partially blame people being all hot and bothered about xz, but I can see that these files were committed two weeks ago.
I also get the impression that the definition has shifted, though I don't recall malicious intent from the vendor/author being a part of it. Classical backdoors include things like service accounts that were intended for the vendor, which were genuinely intended for service. Granted, those passwords were intended to be changed. (Also, that's not really appropriate for consumer grade gear though, since consumers have not received that level of support in decades and were not connected to networks when that level of service actually existed.)
Either way though, I do seem to recall intention being part of the definition. Ah well. It's just a new meaning to get used to!
Either way though, I do seem to recall intention being part of the definition. Ah well. It's just a new meaning to get used to!
They knowingly created a password less account because of their authentication system!
If it isn’t a true backdoor, then it is utter stupidity and negligence!
When it comes to security, why is EOL allowed by society?
We don’t give 5 or 10 yr old cars a free pass to blow up or stop working without a manufacturer recall.
Software is even easier to fix!
If it isn’t a true backdoor, then it is utter stupidity and negligence!
When it comes to security, why is EOL allowed by society?
We don’t give 5 or 10 yr old cars a free pass to blow up or stop working without a manufacturer recall.
Software is even easier to fix!
The tricky part is determining how long software should be supported for, at least with respect to security updates. I'm sure that most people would agree that 5 years is insufficient. Twenty five years, many would say is too long.
As for the car analogy, it is a weak comparison. First of all, the owner is expected to do some upkeep. A car is more likely to be deemed unroadworth from a lack of upkeep as it is from a design flaw or manufacturer defect. The other consideration is that the notion of secure software is a shifting target. In the case of cars, physics is a passive adversary. In the case of computer security, the adversary is active. Is software security to be judged by the security standards of when it is developed, or of when it is used? The former will catch cases like this, but will prove ineffective in the long term. The latter will bankrupt the industry.
As for the car analogy, it is a weak comparison. First of all, the owner is expected to do some upkeep. A car is more likely to be deemed unroadworth from a lack of upkeep as it is from a design flaw or manufacturer defect. The other consideration is that the notion of secure software is a shifting target. In the case of cars, physics is a passive adversary. In the case of computer security, the adversary is active. Is software security to be judged by the security standards of when it is developed, or of when it is used? The former will catch cases like this, but will prove ineffective in the long term. The latter will bankrupt the industry.
I think you went to sleep in some other universe and are waking up in the real world where backdoor has always meant "bypasses the front door."
> This just looks like utterly unsurprising incompetence on the part of a consumer networking / IoT gear manufacturer.
Then how about Xiongmai NVRs [1]? Can I say it's just an incompetently implemented debug feature left enabled in production?
[1] https://habr.com/en/articles/486856/
Then how about Xiongmai NVRs [1]? Can I say it's just an incompetently implemented debug feature left enabled in production?
[1] https://habr.com/en/articles/486856/
I'm surprised it wasn't "authentication bypass" too.
I see IoT devices are still the weakest link in any network.
> I see IoT devices are still the weakest link in any network.
That's why IoT stood for, since the very beginning, for "Internet of shitty insecure Things" : )
That's why IoT stood for, since the very beginning, for "Internet of shitty insecure Things" : )
Or just "Insecurity of Things" )
I bought used DNS-320L and first thing is to load it with ALT-F alternative firmware. Worked great but device was too slow for my needs.
I’m surprised that there aren’t projects that aggregate a bunch of these known exploits together with these security search engines to find vulnerable devices and use them to create a TOR-like network of proxy server nodes. Presumably most of these vulnerable devices are running in homes of consumers with residential internet, making the traffic hard to identify as being from a VPN service. Not that I’m suggesting anyone actually do this since it would be highly illegal…
I've seen compromised iot devices used to run proxy servers. They are mostly resold on black market as residential IPs for web scrapping and such. Since there is a black market for it they mostly get resold, instead of put to use on the free TOR network I guess.
Residential ISPs usually monitor the blacklisting of their IP addresses and will contact/suspend the customer once the IPs get listed on public black lists.
Residential ISPs usually monitor the blacklisting of their IP addresses and will contact/suspend the customer once the IPs get listed on public black lists.
How unlikely is it that some major iot device manufacturers outsource the firmware to someone who puts botnets in to start with? Who writes fridge firmware? Does ge or Samsung do that in house? Ovens? Definitely some liability there, but I'm not sure which way that drives it, out or in.
Why do that for free? Folks are perfectly happy to pay to be part of NordVPN's proxy network.
This is why I always use an encrypted file system, where the encryption keys are only known to the client (and not the NAS or other storage provider).
I just use an old computer full of drives on which I ssh mount. I don't even care setting up samba these days.
Even NAS distros/OSes are usually overkill for home and less than 5 different users. In a typical family context you usually only need one filesystem for each user + 1 shared fs with same RW for everyone.
Even NAS distros/OSes are usually overkill for home and less than 5 different users. In a typical family context you usually only need one filesystem for each user + 1 shared fs with same RW for everyone.
Exactly - just a Linux box, mounted with SSHFS. To be fair, I have spent some time over the years writing my own scripts for SMART alerts, but the end result is better monitoring and alerting than a NAS would provide.
You are far better off getting cheap hardware and running TrueNAS or Unraid on it as they actually get regular software updates and don't have a history of major security issues.