Seagate Central NAS vulnerabilities

A couple years ago (2013), to assist in migrating an old ZFS array and in order to have a temporary backup of said system, I purchased the Seagate Central NAS with 4TB of internal storage. At the time, I used it to complete said task and haven’t used it much since, except for the rare desire hold some large files that didn’t need the reliability of RAID.

When I purchased this device, I did some benchmarks, took a quick glance at the Linux system, but was mostly concerned with performance. I found the performance more than acceptable with some tweaks, but with the practical and immediate task over, I eventually powered the device back on and took a look at its security.

Over its life, this device has had a number of critical vulnerabilities made public and patched, but I’ll concentrate today on those I’ve discovered in the firmware I’m running.

The fact that embedded devices are vulnerable is not new. This is really not newsworthy, but perhaps we can aim higher? The Central NAS is not Seagate’s most popular model, but it does share code with other, more popular products such as the BlackArmor range.

I have contacted Seagate regarding the following and was twice informed of a 90-day window for disclosure. I followed up to no response and have decided, following the culmination of those 90-days, to publish.

Vulnerabilities

• Web application allows unauthorized modification of IP address and hostname.
• World-writable system files allow local users to compromise configuration and perform local privilege escalation. (I’ve been informed an updated firmware patch “somewhat” mitigates this, but is unconfirmed)
• Common root password is set on all devices and /etc/shadow is world-readable.
• Firmware updates are vulnerable to a MITM attack. These are performed over plain HTTP and are not signed, allowing attackers to readily deliver malicious payloads.
• The NAS supports multi-user / multi-tenant operation. The files of these users are all set, by default, to mode 777. Users are given SSH access and may readily access and modify each other’s files.
• The device exposes a phpinfo() page to unauthorized users (information disclosure).

Firmware updates & caveat emptor

Seagate has told me that at least one firmware update has been released to address some of the mode-777 files scattered throughout the system. I cannot confirm this. Currently, I am unable to access the firmware download page, which may be a temporary error on their servers (or not). As I have not seen communication from Seagate, nor have I seen published information regarding new firmware, nor can I find or access new firmware, I will presume these issues remain unpatched.

Personally, I have made myself immune to firmware updates through my meddling, opting to disable all web access and now operate the device as a slightly more standard Linux system. This device, either through my meddling or by design, does not support a true device reset, so I am limited only to resetting the system to the hacked-up install that I put onto it. (In a way, the device is also rootkit-able in this fashion)

About responsible disclosure

I believe in contacting vendors and giving them the opportunity to resolve issues. I do feel, however, this must be balanced against the risk posed to users by inaction. In this case, I contacted the vendor and was offered an explicit expectation. That expectation was not met. I also followed up to see if the vendor desired to manage those expectations, but was not offered a response. Furthermore, there may be users significantly impacted by these vulnerabilities.

Having been on both sides of discovery and response, I know vendors sometimes need time to resolve issues. Those vendors sometimes care deeply and despite their efforts, make mistakes. Sometimes those vendors need time to make true, lasting changes across their product lines. On other occasions, it’s clear that security is not at all seen as a feature or necessary component of a product, and such vendors might see consumer products as disposable and temporary. From this, I feel I must make judgement calls and do what I personally feel is ethical and appropriate, especially as we see more companies shipping Linux into networked “devices” such as light switches.

I did not seek to find any remotely exploitable vulnerabilities. These issues were really low-hanging-fruit. I’m certain a number of remaining issues have yet to be discovered here, but for myself, I’m done investigating the Central NAS.

Timeline:

July 10~13th, 2015 — Contacted Seagate via web contact form informing them I found a vulnerability. (I could find no published email contact)
July 14th, 2015 — Received communication from a “Seagate Security Response Coordinator” (SSRC)
July 15th, 2015 — Sent a detailed list of vulnerabilities to the SSRC.
July 16th, 2015 — Sent details on newly discovered information disclosure to SSRC.
July 25th, 2015 — Requested status update
August 3rd, 2015 — Requested status update
August 4th, 2015 — Received status update. Given a 90 day window for resolution.
August 14th, 2015 — Received status update. Seagate identified 5 vulnerabilities based on my report. Informed that since my report, a firmware update had been made available, partially addressing one of the vulnerabilities. The 90 day window is restated and told that, should they need an extension, I will be notified.
October 2nd, 2015 — Requested status update.
October 19th, 2015 — Published vulnerabilities (via blog)