The vulnerable system is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or through terminal emulation (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document).
Attack Complexity
High
AC
The successful attack depends on the evasion or circumvention of security-enhancing techniques in place that would otherwise hinder the attack. These include: Evasion of exploit mitigation techniques. The attacker must have additional methods available to bypass security measures in place. For example, circumvention of address space randomization (ASLR) or data execution prevention must be performed for the attack to be successful. Obtaining target-specific secrets. The attacker must gather some target-specific secret before the attack can be successful. A secret is any piece of information that cannot be obtained through any amount of reconnaissance. To obtain the secret the attacker must perform additional attacks or break otherwise secure measures (e.g. knowledge of a secret key may be needed to break a crypto channel). This operation must be performed for each attacked target.
Privileges Required
Low
PR
The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: Seagate Personal Cloud SRN21C Arbitrary File Move
------------------------------------------------------------------------
Seagate Personal Cloud allows moving of arbitrary files
------------------------------------------------------------------------
Yorick Koster, September 2017
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
Details
------------------------------------------------------------------------
https://sumofpwn.nl/advisory/2017/seagate-personal-cloud-allows-moving-of-arbitrary-files.html
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 <name> 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'
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum