Command injection and backdoor account in D-Link NAS devices
github.com
github.com
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.
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.
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
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.
If you're using systemd, you can grant the appropriate capability to the process by setting:
[Service]
AmbientCapabilities=CAP_NET_BIND_SERVICE
(Of course Unraid, being based on Slackware, has a legacy init system that doesn't support this scheme. But there are enough other options.)
Never had issues with Synology.
- 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
s/NAS/network/
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.
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.
[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.
> I do chuckle at the use of "just 10tb"
It's 2024. 2TB SSDs can be bought cheaply, and so can 16TB HDDs.
I think bandwidth is a bigger issue with cloud storage. Most people have terrible upload bandwidth.
Also, it’s not a good idea to store TBs of personal information on someone else’s computer or potentially the internet.
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.
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.
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.
IIRC I didn't even had to format or move the data I had on it before installing.
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
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:
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
No ZFS, but it appears to support mdadm and btrfs so that could work if you can get good hardware for it.
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.
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.
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.
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)
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...
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
I’ll see if I can drag up some references, a quick google doesn’t show what I’m looking for.
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.
Cisco have had some doozies but overall aren’t terrible.
Everything else is probably bad.
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!
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.
Anyone has information on the security of DSM? Like, is it compliant for use in sensitive departments?
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.
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.
That's why IoT stood for, since the very beginning, for "Internet of shitty insecure Things" : )
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.
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.
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!
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!
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.
Then how about Xiongmai NVRs [1]? Can I say it's just an incompetently implemented debug feature left enabled in production?
[0] https://forum.qnap.com/viewtopic.php?f=45&t=160849&start=450...