News Synology DSM attacked by SynoLocker malware

First, to clarify: the Synology DiskStation Manager (DSM) software that drives its various NAS models is Linux. You already have a Linux server; just one that comes preconfigured for a certain task and with non-standard software (the web-based user interface) installed.

To the meat of the question: the only stupid thing you have to do is to open the management port to the internet by port-forwarding (or UPnP) on your router, which is the official way you get access to your files from outside your home. That, coupled with not having installed the security patch from December, is enough to get yourself infected. It's a remote code execution vulnerability; no user interaction required. You don't need to visit any sites, download any software, or install anything on the NAS itself; if the port is forwarded and December's security update isn't installed, then SynoLocker will find it and infect it.

Such is the price we pay for convenience, sadly. I can only access my NAS using SSH, and then only from pre-approved systems that have a private key matching public keys stored on the server itself. Not as convenient as Synology's software, but very secure.

 

You don't need to be root to run software, otherwise you'd never be able to open a web browser or play a game. You should need to be root (or have root privileges) to make system-wide changes, but again we're looking at a trade-off of security for convenience: you have to be able to manage the system through the system management interface, otherwise it'd have no purpose. Got a hole in the system management interface? The attacker can manage the system, just like you can. In this case, "manage" being "disable access to the management console and begin encrypting all the files."

Welcome to modern software: code these days is far too complex to be without error. You just have to hope the good guys spot the flaws and fix 'em before the bad guys spot the flaws and exploit 'em. No operating system is immune.

 

You might have known what you meant, but a Linux n00b coming to this thread would have been confused - hence the clarification. No offence was meant!

What security goodness? Linux is, at its heart, no more or less secure than any other operating system - well, now that Windows has got out of the habit of defaulting all users to administrative privileges, anyway. If there's a security hole in a piece of software that runs with root privileges, then an attacker exploiting that hole will get root privileges.

Let's say that Synology changed its software to run as an unprivileged user with no access to anything. Secure, but useless: an attacker can't get at your files, but neither can you. So, you have to expand its permissions to include the ability to read and write the files, right? Boom: if an attacker exploits a security hole, like SynoLocker does, the code he or she runs also has access to read and write the files. There's nothing in Linux or any other operating system that can prevent this: if the attacker has your privileges, he or she can do anything you can do - up to and included encrypting all your files with a key you don't know.

OpenMediaVault is very similar to DSM - a friendly interface to a preconfigured appliance image. It, too, could easily fall victim to security flaws just like SynoLocker; it may, however, be more secure due to its lower popularity. Synology has a big user base of people who have paid real cash money for their NAS many of whom may not be the most technically minded, a tempting target pool for attackers; OpenMediaVault - and other similar projects - have a smaller user base most of whom are technically minded by dint of having decided to build-their-own instead of buying COTS, a far less tempting target.

There's the option of roll-your-own entirely, but a little knowledge can be a dangerous thing: knowing enough to set up a Linux server is one thing; knowing enough to keep a Linux server secure is something quite different.

 

You wouldn't need to execute anything to do a SynoLocker-style attack: just bypass the login requirement. Even if the attacker needed to drop an executable, they're logged in as you - which means they need only chmod +x and their file is now an executable. And, again, permissions won't help: anything that would stop the attacker doing something would also stop you doing that same thing.

But there would have to be some way for you to switch to the temporary super-user account in order to perform these tasks, right? So, if the attacker is logged in as you through a security hole, he or she can also switch to the temporary super-user account. See the problem?

Hah! I'm far from an expert, although - touch wood - I've not been got yet.