Seagate is a well-known vendor of hardware solutions, with products available worldwide. Its line of NAS products targeted at businesses is called Business Storage 2-Bay NAS. These can be found inside home and business networks, and in many cases they are publicly exposed.
Products in this line that run firmware versions up to and including version 2014.00319 were found to be vulnerable to a number of issues that allow for remote code execution under the context of the root user. These vulnerabilities are exploitable without requiring any form of authorisation on the device.
This document was updated on 11th June 2015 to include links to the released firmware that attempts to address the issues in this advisory.
Seagate Business NAS products come with a web-enabled management application. This application lets administrators perform the usual device configuration functions, such as adding users, setting up access control, managing files, and more.
The web application is built with the following core technologies:
- PHP version 5.2.13 (Released 25th February 2010)
- CodeIgniter 2.1.0 (Released 23rd November 2011)
- Lighttpd 1.4.28 (Released 22nd August 2010)
All three of these technologies are clearly out of date, and the listed versions of PHP and CodeIgniter are known to have security issues. On top of these technologies sits a custom PHP application, which itself contains a number of security-related issues. Details of each key issue are listed below.
Versions of PHP prior to 5.3.4 allow users to specify file paths that include a NULL byte (CVE-2006-7243). This issue allows user-controlled data to prematurely terminate file paths, allowing for full control over the file extension.
This issue is regularly abused to include unintended files in PHP source code via functions such as
Versions of CodeIgniter prior to 2.2.0 create session tokens that are made up of a serialised PHP associative array (hash) that has been encrypted using a custom algorithm. This PHP hash contains user-controllable data, which makes it possible for users to extract the encryption key and decrypt the content of the cookie (CVE-2014-8686). Once decrypted, users can modify the content of the cookie and re-encrypt it prior to submitting it back to the server, resulting in other potential attack vectors including PHP object injection.
A unique encryption key value should be used for each installation of a CodeIgniter application. However, in the case of this line of NAS products, the encryption key that is used is exactly the same for every instance (CVE-2014-8687).
Custom web application
The custom web application does not appear to maintain session-related information on the web server side. All of the information relevant to a user session is stored inside the session cookie prior to it being encrypted and sent to the browser. The PHP hash inside the cookie contains a number of key/value entries, including the following:
username: this is a string value that represents the name of the user in the current session.
is_admin: this is a string value that can be set to
no, and indicates whether the current user is an administrator on the NAS.
language: this is a string value that represents the current user’s chosen language (eg.
Once a session has been established and the
username field is present in the cookie, the system does no further validation of user credentials. This means that if a user can manipulate this value directly, instead of attempting to log in the standard way, they can bypass the login mechanism completely.
Direct modification (or addition) of the
is_admin value allows a user to self-elevate to administrative privileges in the web application itself.
The fact that a static session encryption key is in use across all instances of the NAS means that once a user has a valid session cookie on one instance, they can apply that same cookie directly to another instance and acquire the same level of access. In short, once a user is logged in as
admin on one instance, they’re effectively
admin on every instance.
language parameter is used to generate a file path that is referenced in the web application PHP code via a call to
include(). Manipulation of this parameter allows for exploitation of a local file inclusion vulnerability.
Finally, the web application is being served by an instance of Lighttpd that is running under the context of the
root user. Hence, any successful exploitation results in activities being conducted as
Two versions of the NAS firmware were tested and shown to be vulnerable. Those versions were:
At the time of writing, it is believed that all versions prior to 2014.00319 are highly likely to contain the same vulnerabilities.
This advisory makes use of prior work referenced in the following CVEs:
- CVE-2014-8684: timing attacks and object injection.
- CVE-2014-8686: a fall-back to the
_xor_encode()method of session encryption.
The vulnerability discovered via the reuse of the session cookie encryption key was allocated the identifier CVE-2014-8687 by MITRE.
It is simple to exploit the issues listed above to gain arbitrary code execution on the device as the
root user. The key steps required to achieve this are:
- The attacker must write PHP code to the file system on the NAS. This can be done in several ways, including:
- HTTP access log file poisoning via the
- HTTP error log file poisoning via the
- Modifying the device description in the web application interface. This writes user-controlled strings to a file located at
/etc/devicedesc, however it does require administrative rights.
- Uploading of files to a file share that the device has exposed.
- HTTP access log file poisoning via the
- The attacker must then manipulate the content of the
languagevariable in the session cookie so that it contains the path to the attacker-controlled PHP on the file system. The NULL byte flaw in PHP must be used at the end of this value to force PHP to ignore any characters that are appended to the file path by the web application.
- The attacker then makes a request with the manipulated cookie, resulting in code execution as
Beyond Binary has produced a Metasploit module and a standalone Python script that automate the process of exploitation. Each of these scripts take the following approach:
- Connects to the target NAS and extracts a
- Decrypts the cookie using the static encryption key of
0f0a000d02011f0248000d290d0b0b0e03010e07and extracts the PHP hash.
- Modifies the serialised PHP hash so that the
usernameis set to
is_adminfield is set to
- Encrypts this updated PHP hash ready for further use as a
ci_sessioncookie. This cookie now allows future requests to operate on the NAS as if they were an administrator.
- Performs a request to extract the host configuration, which includes the device’s description.
- Modifies the host configuration so that the device description contains a small stager payload.
- Performs a request to update the host configuration with the new data so that the stager payload is written to
- Modifies the PHP hash again so that the
languageparameter contains the value
../../../../etc/devicedesc\x00(note the NULL byte at the end).
- Encrypts this new PHP hash ready for future use as a
- Performs a request to the NAS using the cookie created in the previous step. This invokes the stager that was written to disk. This request posts a larger payload which is written to disk under the web server root.
- Performs another request which then resets the host configuration back to what it was prior to exploitation.
From here, the final stage of the exploit is on-disk and ready to be executed. In the case of the Metasploit module, the final stage is a self-deleting file that contains whichever payload was chosen by the user. In the case of the standalone Python script, the final stage is a simple web shell which is continually referenced for each executed command, and is removed when the Python script is closed.
The exploits are available for download here:
The following image shows a sample run of the Metasploit module:
At the time of writing there is no firmware version available for download that contains fixes for the issues listed in this advisory. It is recommended that consumers of these Seagate Business NAS products (and other products using vulnerable firmware) ensure that devices are not accessible via the public Internet. For internal use, it is recommended that the devices be located behind a firewall configured to allow only a trusted set of IP addresses to connect to the web interface.
Edit: 11th June 2015
During April 2015 Seagate released firmware that attempts to resolve these issues. Please see the timeline below.
At the time of writing, Shodan reports that there are over 2,500 publicly exposed devices on the Internet that are likely to be vulnerable.
It appears that the NAS products do not integrate with the likes of Active Directory or LDAP. As a result, they need to store passwords for any users that require access. Passwords are hashed using DES and stored in the
Instances of the NAS housed inside an organisation are likely to contain passwords that are reused by domain users. The DES hashes are very easy to crack, and hence an attacker could easily acquire domain credentials once the NAS has been compromised.
Initial attempts to disclose the above issues to the vendor proved time consuming and unproductive. Staff on the front-line support team repeatedly failed to direct the query to the relevant point of contact. In light of this, a direct security contact was identified using open intelligence, and front-line support was bypassed. This employee handled the query professionally and demonstrated a high level of concern in the early stages.
- 07th October 2014
- Initial bug discovery.
- 08th October 2014
- Simple Proof of Concept exploit created.
- 16th October 2014
- Enhanced exploit created.
- 18th October 2014
- Contacted vendor via website, requested PGP for secure communications.
- Contacted MITRE to discuss potential CVE identifier allocation.
- 20th October 2014
- Contacted vendor via Twitter, requested PGP for secure communications.
- Vendor responded via email, requested disclosure via non-encrypted channels.
- 22nd October 2014
- Contacted vendor via email, disclosed all details of the issues found.
- Beyond Binary established 100 day public disclosure period ending on 30th January 2015.
- 23rd October 2014
- Vendor responded, confirmed receipt, requested 24 hours to confirm issues.
- 23rd October 2014
- Vendor responded, requested firmware version in use. Suggested using latest firmware.
- Contacted vendor via email, informed them that all firmware versions are vulnerable.
- 27th October 2014
- Vendor responded via email, indicated work will be done without further communication.
- Contacted vendor via email, requested updates on progress.
- 02nd November 2014
- Contacted vendor via email, requested confirmation of receipt of previous email.
- Vendor responded, indicated communications will remain open.
- 09th November 2014
- MITRE responded with thorough email about prior work, and CVE allocation.
- 17th November 2014
- Contacted vendor via email, requested status update.
- 02nd December 2014
- Contacted vendor again via email, requested status update.
- 16th December 2014
- Contacted vendor again via Twitter, requested status update.
- Vendor responded again, email content was the same as what was received 27th October 2014.
- Contacted vendor via email, requested a more thorough update.
- 17th December 2014
- Vendor responded, requested confirmation of firmware version and asked if SSH is enabled.
- 19th December 2014
- Contacted vendor, informed them that use of SSH is irrelevant, as is the firmware version.
- 01st January 2015
- Contacted a number of vendor employees via Linked In.
- 09th January 2015
- Established contact with vendor employee responsible for security after interaction with a security professional on Twitter.
- Established secure communications with employee using PGP.
- 10th January 2015
- Second vendor employee responded via Linked In, confirmed receipt of message and indicated knowledge of contact with previous employee. Previous employee will continue handling disclosure.
- 10th-16th January 2015
- Various communications back-and-forth with employee.
- 16th January 2015
- Disclosure documentation rewritten and sent with exploit to employee PGP-encrypted.
- 17th January 2015
- Employee confirmed receipt.
- Beyond Binary revised public disclosure date to 1st March 2015.
- 21st January 2015
- Contacted employee, requested update.
- 23rd January 2015
- Employee responded, indicated successful exploitation using Proof of Concept code.
- 30th January 2015
- Employee proactively established contact and provided an update.
- 05th February 2015
- Employee again proactively established contact and provided an update.
- 17th February 2015
- Contacted employee to request status update for fixes and timeline for release.
- 26th February 2015
- Employee responded indicating there is no update to be shared.
- 01st March 2015
- Public disclosure.
- April 2015 (day unknown)