More like this

Synology and the NAS-ty malware-flingers: What can be learned

'Security first' gets more NB for little guys

Sysadmin blog The recent Synology Synolocker issue should serve as a splash of cold water to any vendors in the tech industry that design and sell systems that are largely unattended or unmanaged.

As described in The Reg yesterday, Synology NAS boxes are being hit by a Cryptolocker-like piece of malware dubbed Synolocker. Like Cryptolocker, the "ransomware" encrypts all your files and then demands a ransom to unlock them.

How did it happen and what should be done?

Mistakes were made in the design, implementation and recommended system configuration of Synology's NASes that allowed attackers to target internet-facing Synology NASes and install malware that encrypted all files on the NASes in question.

While I happen to know that better security features – such as two-factor authentication – are being planned by Synology, there are other things that can and should be done.

All "root" and "admin" passwords for all packages should be changed as part of the initial setup process for a new unit install. These should also be easily changeable in the administration page itself. Ideally, if administrative pages need to be exposed, there should be options available such that internet-facing administrative pages are only accessible from unprivileged accounts.

Synology should not have any other services running off the same web server – let alone the same ports – as the administration page. If there are services I want to expose to the internet, I should be able to do so individually, and absolutely must be able to do so without ever exposing the administration interface.

I have been personally following up on this issue with Synology and have told them the above point blank. In addition, if they want to have any hope of surviving the rapid growth they're currently undergoing there are some important – and costly – security changes that they absolutely must engage in.

Immediately commence a full internal audit of all security practices on all supported packages and the core DSM offering.

Engage in an external audit of DSM administration page and any other "core" DSM components/protocols that are exposed to the internet.

Commission a complete rewrite of "recommended configurations" with an eye to security.

Create a change management process where all new changes are vetted for security before commit.

Optionally, I would like to see Synology work with a firewall vendor to have an application layer gateway-class firewall offered as part of the Synology package to help mitigate unknown issues in the future.

It's an expensive ask, but despite the security issues of recent months, I like Synology's products and I intend to keep on using them. I'd like to see them evolve into products with more complete defence in depth, even if it means I'll have to pay more.

Beyond a NAS

Synology NASes offer far more than simply file-sharing or block-storage capabilities. They offer everything from email to LDAP servers, web servers to antivirus. A proper application-aware firewall shipped with the device would be a great step towards detecting and mitigating attacks.

And that – right there – is the key component missing here: intrusion detection. Synology doesn't appear have a Fail2Ban equivalent installed.

All of this is a problem to be solved by Synology because a Synology DiskStation or RackStation is more than just a NAS. These units are full-blown servers with a complexity and capability that rivals earlier versions of Microsoft's Small Business Server.

As Synology grows beyond "just a file server" and becomes a "complete network in a box" appliance, it needs to add intrusion detection, full blown monitoring and even configuration analytics with recommended remediation.

It is probably unfair to hold the firm to a standard that none of the other SMB NAS vendors have managed to achieve, but ultimately, they will all face their trial by fire as well. Pick a random home NAS and there's a long list of vulnerabilities. These vendors are also going to want to be more things to more people and they too will run face-first into the exact same problems.

Shared responsibility

Security is a shared responsibility. So, while perhaps Synology needs a cuff upside the head for making the monumental mistake of trusting that its own code is secure, there are thousands of systems administrators and end users that deserve a beating about the nose with a newspaper for blindly trusting that any firm ships a product secure enough to expose an administrative interface to the internet.

Companies many times Synology's size still have problems with security, many of them just as severe. Microsoft took a decade to reinvent itself as a "security first" company after the disastrous Windows XP viral apocalypse, and it still has security problems on a regular basis. If any of us thought for a second that we could just toss the admin panel for any device – from our home router to our NAS to our internet connected lightbulbs – onto the internet, we should get our heads read.

Some companies are putting money into finding novel solutions to these "internet of things" problems, but the problems still persist. Automating defence in depth – and having it work out of the box by default – is not easy. It is still required that we engage our brains before using IT equipment from any vendor.

It is our job as systems administrators to never assume that any product, application or service we use is secure. It is our job to learn as much as we can about how the products we deploy operate so that we can secure them as completely as possible.

In today's appliance and internet-of-things world, not only do you still need firewalls, proxy servers, application layer gateways and intrusion detection systems, but they are more critical than ever. Security is as much the responsibility of the sysadmin as it is of the vendor.

Synology's response

In addition to the measures outlined above, there are a bunch of internal meetings occurring at Synology where it plans not only to figure out how to solve the current crisis, but how to prevent it from ever happening again. I have sent the firm my two cents (as per above) on how to solve this.

The NAS box maker has certainly fielded a lot of responses from users on social media over the past day or so – ranging from the pragmatic to less polite variants.

I have personally trusted Synology to support the businesses of my clients for years. They make reliable and performant storage servers that have proven more than adequate to the tasks I have put before them. I make use of the many downloadable packages to create a small business server that has come to replace many of my older Microsoft SBS deployments.

This works today, in an IPv4 world where I can hunker these systems down behind a firewall and not expose them to the internet. But a huge part of Synology's value proposition is increasingly the ability to remotely access the files and services on these devices. IPv6 will also make everything on our networks publicly addressable and bring a new threat model into play that Synology needs to be ready to deal with.

Given this, I'm not ready to drag Synology out and crucify it for its mistakes. The current crisis is shaping up to be Synology's crucible. How it deals with it will determine its long-term viability, especially as Synology moves upmarket into the enterprise. ®

Update

Synology has been in touch to provide an update on SynoLocker. It says:

Based on our current observations, this issue only affects Synology NAS servers running some older versions of DSM (DSM 4.3-3810 or earlier), by exploiting a security vulnerability that was fixed and patched in December, 2013. At present, we have not observed this vulnerability in DSM 5.0.

If users notice any strange behaviour or suspect their Synology NAS server has been affected by the above issue, we encourage them to contact us at security@synology.com, where a dedicated team will look into their case.

We sincerely apologise for any problems or inconvenience this issue has caused our users.