Seagate Personal Cloud allows moving of arbitrary files

Abstract

Seagate Personal Cloud is a consumer-grade Network-Attached Storage device (NAS). It was found that the web application used to manage the NAS contains a vulnerability that allows an unauthenticated attacker to move arbitrary files. The move operation is done with root privileges, which basically allows moving any file to any location. The only limitation is that the destination path resides on the same file system as the source path.

Tested versions

This issue was tested on a Seagate Personal Cloud model SRN21C running firmware versions 4.3.16.0 and 4.3.18.0. It is likely that other devices/models are also affected.

Fix

This vulnerability has been fixed in firmware version 4.3.18.4.

Introduction

Seagate Personal Cloud is a consumer-grade Network-Attached Storage device (NAS). Personal Cloud is deployed with software that allows uses to access their files over the internet, even if the devices is not directly accessible over the internet. Files are accessible through the Seagate Access web application.

It was found that the web application used to manage the NAS contains a vulnerability that allows an unauthenticated attacker to move arbitrary files. The NAS is available using the personalcloud.local domain name via multicast Domain Name System (mDNS). Due to this it is possible to exploit this issue via a malicious website without requiring the NAS to be directly accessible over the internet and/or to know its IP address.

Details

Personal Cloud runs a Python application named webapp2 that is created by LACIE. This application is built upon the unicorn library, another proprietary application from LACIE. The NAS ships with various versions of LACIE's REST API (version 3 up till and including version 8). Each REST endpoint is configured in a file named dispatch.py, each API version comes with its own dispatch.py file.

API version 6, 7, and 8 expose a REST endpoint named atomic_move that is accessible to unauthenticated users (public) as can be seen in the endpoint's configuration listed below.

/usr/lib/unicorn/webapp2/api/v8/sv0/system/System.py:

validators = {
	'atomic_move': {
		'input': {
			'source': unicode,
			'destination': unicode,
			'force': bool
		},
		'output': {
		},
		**'auth':['public'],**
		**'_auth':['public']**
},

The atomic_move endpoint can be used to move a file to a different location. It takes three arguments; source, destination, and force. Some validation is done on the source & destination arguments, the application checks whether the source & destination reside on a file share on the NAS. If this is not the case, the application will throw an exception stating that the "Share doesn't exists".

This validation is implemented in the get_share_and_file_path_from_id method (/usr/lib/python2.7/site-packages/unicorn/adaptors/file_browser.py). This method only looks at the first part of the provided path and is thus trivial to bypass using directory traversal. When the force parameter is set to true the destination file will be overwritten if it already exists.

/usr/lib/unicorn/webapp2/backend/v6/sv0/system.py:

class General(v5General):
	# This function does only an atomic move
	# The option 'force' allows to override existing files
	# The path inside the app : <share name>/<file_path>
	# The path outside the app: /media/internal_<id volume>/<id share>/<file_path>
	def atomic_move(self, auth_struct, source, destination, force):
	
		# Gets the volume id and the share id with the share name
		# and converts the bindings to the local filesystem
		try:
			share_source, filepath_source = get_share_and_file_path_from_id(source)
			share_destination, filepath_destination = get_share_and_file_path_from_id(destination)
			local_source = os.path.join(
				share_source.get_data_path(),
				filepath_source
			)
			local_destination = os.path.join(
				share_destination.get_data_path(),
				filepath_destination
			)
[...]
		try:
			**os.rename(local_source, local_destination)**

Because the endpoint is configured as public it allows for unauthenticated attackers to move arbitrary files to arbitrary locations using simple directory traversal. Since the web application runs with root privileges it is possible to move almost any file to arbitrary locations. Because the endpoint uses Python's os.rename method the destination should be on the same file system, if this is not the case os.rename will throw an Invalid cross-device link exception.

Proof of concept

The curl command below uses the atomic_move endpoint to rename the /etc/unicorn.db file, effectively disabling the management web application.

curl -i -s -k  -X $'POST' \
	--data-binary $'{\"source\":\"/Public/../../../../../etc/unicorn.db\", \"destination\":\"/Public/../../../../../etc/unicorn.db~\", \"force\":true}' \
	$'http://personalcloud.local/api/external/8.0/system.System.atomic_move'

Vragen of feedback?