Seagate vulnerability raises questions about security disclosures and proprietary NAS solutions

James Sanders
seagate-green-stacked.jpg
seagate-green-stacked.jpg

 Image: Seagate

The Seagate Business NAS (Network Attached Storage) product aimed at small business users has a major vulnerability in which attackers are able to execute code as the root user without authentication, according to Australian security researcher OJ Reeves. The firmware version in question -- 2014.00319, the latest version available for the product -- contains a web-based management interface, which utilizes PHP, CodeIgniter, and Lighttpd (which runs as root).

The versions of these programs are far outdated, with PHP 5.2.13 being five years old. PHP 5.2.13 is vulnerable to a file path specification bug that allows users to specify file paths, which include a NULL byte; this gives attackers the ability to terminate file paths, which can lead to the ability to access files arbitrarily. Older versions of CodeIgniter have substantive issues with the way in which session token encryption is handled, as the information is encrypted using a key defined in the config file, and then stored in a cookie. These faults, used in conjunction with the issues relating to the proprietary web-based management interface, allow attackers to execute arbitrary code as root (described in further detail in this disclosure).

The only fix currently is to put Seagate Business NAS behind a firewall to prevent access by attackers.

How should public disclosure be handled?

Balancing the need for the public at large to be informed of vulnerabilities with the need for vendors to have adequate time to patch those vulnerabilities is a difficult compromise.

Google's Project Zero came under criticism for an incident in which Google disclosed a Windows vulnerability the day before the Patch Tuesday update would be published to fix it, and shortly thereafter disclosed three unpatched OS X vulnerabilities, as its 90-day timeline for release had been reached. Google subsequently added a 14-day grace period for cases where vendors have a scheduled release for the patch.

For comparison, Google notes that Yahoo! has a 90-day disclosure policy, whereas CERT has a 45-day disclosure policy, and ZDI allows for 120 days. For this vulnerability, Reeves originally set out with a 100-day timeline, but even after 130 days and an open chain of communications, it became apparent no fix was forthcoming.

Security collaboration vs. responsible disclosure

From the timeline of events provided by Reeves, Seagate's conduct throughout this issue is very troubling from a security and support standpoint. From the initial contact, Reeves requested PGP use, though Seagate requested disclosure through non-encrypted means. When the disclosure was made, Reeves explicitly indicated a 100-day timeline for public disclosure. Seagate's responses throughout 2014 were boilerplate troubleshooting guides, preoccupied with verifying settings irrelevant to the nature of the vulnerability, and providing duplicated responses to multiple requests for a patch.

In a blog post on Reeves' personal site in January 2015, he notes the challenges in trying to strike a balance between allowing time to develop a patch, and disclosure in the public interest. He also notes that at that point he "totally failed to get hold of the right people" and that they "clearly had no idea how to respond to me, nor did they have a clear path on how to handle the issue."

Reeves then took to Twitter and contacted people associated with Seagate on LinkedIn, eventually finding people who demonstrated some competence in trying to get the problem resolved, and extended his timeline another 30 days -- giving the new contact 45 days total to test, package, and release a patch. According to Reeves, the new contact verified that he was able to reproduce the issue, and proactively gave status updates on January 30, 2015 and February 5, 2015. On the February 17, 2015, Reeves reached out again, and received a response on the February 26, 2015 indicating that there is "no update to be shared."

In an email to Seagate's Public Relations department requesting information regarding plans for a patch to this vulnerability, a representative replied to me: "Security and data privacy are a priority for Seagate. We are aware of the vulnerability report and will take appropriate action to resolve."

Greater context: Should boxed NAS solutions be trusted?

Seagate is not alone in the difficulties it has faced with security and reliability issues on NAS products. In August 2014, some Synology users were attacked with cyberlocker malware, which demanded a ransom of $350 USD in exchange for the decryption key to their files. Similarly, the WD MyCloud series of products faced a protracted outage from late March 2014 to early April 2014. In response to consumer complaints on the WD website, users reported that posts on the website had spontaneously gone missing.

For products like NAS systems, how a company stands behind its product post-sale is as important as the device functionality and MSRP. Buying a device in this category without any guarantee of continued support -- or, for closed systems such as these, that the support provided is adequate -- is a risky proposition, and one that should be given a great deal of consideration. Storing data locally -- yet insecurely -- is a poor justification for not moving data to the cloud, which may be a more appropriate solution for small business use cases of NAS systems.

For those who need a full-fledged, on-premises NAS solution, a better option would be the open-source FreeNAS software, which can be used on any commodity hardware. Jordan Hubbard, CTO of iXsystems, notes that the drawback of security on proprietary solutions is that "your only recourse is to file an enhancement request and hope that it somehow aligns with their own roadmap and will be actioned anytime reasonably soon," whereas users of FreeNAS are "able to audit the source code and see every single change that goes into FreeNAS, either by viewing the change histories on github.com, or subscribing to the commit log mailing lists (thus seeing changes in close to real-time), or both."

In consideration of the vulnerability in the Seagate product and the company's response, and similar issues with other vendors, I asked Reeves if he would advise against using prepackaged NAS solutions. In an email, he stated:

"What's clear to many in the security world is that no piece of software, nor any hardware device, is completely free of bugs. Whether it be a vendor product, open source software, or something else, it really makes no difference. While the "out of the box" security position of the product is important, what is more important is how the product owner manages, and responds to, security related issues. One would think that vendors who earn decent revenue from these products would make more of an effort to respond well to such issues in an effort to protect their clients, their reputation and their revenue stream. However, we've seen way too many cases where this stance has not been held.

I think it isn't necessarily wise to advise people to move onto another product, such as the FreeNAS project or another vendor, as we don't know if they're jumping from the frying pan into the fire. Vendors may have shown to be lacking when it comes to due diligence and proper process, but this doesn't mean that the alternatives are any better. What we need is more transparency, better communication, and more proactive responses when security issues are uncovered. If anything, I would recommend that consumers put pressure on their vendor to resolve the issues within a reasonable time frame, or return the product due it being faulty."

What's your view?

Was Seagate's response to this disclosure adequate? Do you use prepackaged NAS products from Seagate, WD, Synology, or some other vendor? Or, do you build your own box for use with FreeNAS? Share your opinion in the comments.

Also read

Disclaimer: TechRepublic, ZDNet, and Tech Pro Research are CBS Interactive properties.