Fix root ssh login vulnerability on Seagate Central Cloud Storage.

Correction Pending. I am only leaving this up to make sure that the truth is out there, whether I am right or not. For the record, I did test this out, and was able to log in as “root” with no password. I am currently attempting to recreate the issue, but the device may have been “in-between” reboots.

By default, the Seagate Central Cloud Storage Series of NAS drives are vulnerable to attack because as shipped, they do not require a password for root. This would not be a “critical” error, if they had not enabled logins from SSH without a password. My next post will be about why I chose to disclose this vulnerability without notifying Seagate first. I will give the short answer: this is a critical error, and would be found by any attacker on the local network segment with this device. With errors, vulnerabilities, and other errors in configuration of either WIFI or firewalls, this would leave any “private” files on the device open to view, and make all data vulnerable to loss. Why the password for root is not set by default is open to interpretation. It is simple “best practice” to set a password for the superuser account. It is also simple “best practice” not to allow the superuser to log in from ssh. These two issues, when shipped together, represent an inexcusable lack of respect for their customers.

The version of the firmware that I tested this on is: 2014.0410.0026-F. I suspect it is also the same for all versions and sizes of this device.

I recommend all users of the Seagate Central Cloud Storage device owners patch their system as follows:

Caution: this procedure is correct to the best of my knowledge, but may not work for all devices and users. The user alone bears responsibility for following my advice and recommendations. Use at your own risk.

Note: To the best of my knowledge, it is not possible to set the “root” users password, and have it remain set after a reboot. While it is possible to use the “passwd” command to set the password once, it will be null after the device is rebooted or loses power.

1) Obtain a secure shell client (ssh). On all modern Linux distributions, this is already done. On windows, download “PuTTY”, which can be found at: On android phones use “connect bot”. I am not versed in ssh clients for Mac, but I am sure there are several. Use the google.

2) Login to your Seagate Central device using ssh. Use one of the user/passwords you set when you installed your device on its web interface. (you could also login as root with no password, but as this is bad practice, I do not wish to encourage such behavior.)

3) Type “su” at the command prompt. You are now the superuser. You will know this because the character at the end of the prompt changed from “$” to “#”. You can fix or destroy your device with a few keystrokes. Be careful from here on.

4) Use the “nano” editor to change the last line in the file “sshd_config” by typing on the command line: “nano /etc/ssh/sshd_config”. Use the arrow keys to scroll to the bottom of the file.

5) Change the last line from “PermitRootLogin without-password” to “#PermitRootLogin without-password”. Then add a new line below this that reads: “PermitRootLogin no”.

6) Exit nano by pressing the <CTRL> and <X> keys at the same time. At the bottom of the screen, you will be prompted to save the file by typing “yes”. Do so.

7) Reboot your Seagate Central by typing “/sbin/shutdown -r now”. You will be logged out and your device will reboot.

8) Your device will be unavailable while it reboots for several minutes. You can find out when it is ready by using the ping command, or by trying the web interface repeatedly.

9) After the reboot, when you attempt to login using ssh as root, you will be prompted for a password, but as long as there is none set, you will not be able to log in. This will also keep out people with malicious intent for your data.

Enjoy a small improvement in security. -Jim


2 thoughts on “Fix root ssh login vulnerability on Seagate Central Cloud Storage.

  1. Pingback: My manefesto for manufacturers. | BigGear's Blog

  2. It might serve you to read the man page and additional documentation before you ‘discover’ a security flaw which does not exist.

    The simple fact is that the without-password parameter means that login as root can only occur with a public key based login. It does not mean that no authentication is required.

    Further you will note, on closer examination, that there is no ‘authorized_keys’ file in the in the .ssh directory of the home directory of root, as the Central is shipped. Without the authorized_keys file, no public key access can be performed.

    So, the net effect is that neither password nor public key access is enabled (nor is a no-password access) for root as the Central is shipped.

    A correction would be appropriate.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s