Restsdk server что это
Restsdk server что это
With NuGet on Windows for Android
For other platforms, install options, how to build from source, and more, take a look at our Documentation.
Once you have the library, look at our tutorial to use the http_client. It walks through how to setup a project to use the C++ Rest SDK and make a basic Http request.
Is there a feature missing that you’d like to see, or found a bug that you have a fix for? Or do you have an idea or just interest in helping out in building the library? Let us know and we’d love to work with you. For a good starting point on where we are headed and feature ideas, take a look at our requested features and bugs.
Big or small we’d like to take your contributions back to help improve the C++ Rest SDK for everyone. If interested contact us askcasablanca at Microsoft dot com.
We’d love to get your review score, whether good or bad, but even more than that, we want to fix your problem. If you submit your issue as a Review, we won’t be able to respond to your problem and ask any follow-up questions that may be necessary. The most efficient way to do that is to open an issue in our issue tracker.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
About
The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.
v0lkan / silence.sh
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This comment has been minimized.
Copy link Quote reply
yehgdotnet commented Apr 22, 2018 •
I just use WD only as file storage through sftp/ftp, not as media players Timemachine backups.
So, I solved it by disabling a couple of services.
Reboot after the following commands:
update-rc.d netatalk disable
update-rc.d restsdk-serverd disable
update-rc.d samba disable
update-rc.d nfs-kernel-server disable
update-rc.d nfs-common disable
update-rc.d upnp_nas disable
update-rc.d mDNSResponder disable
update-rc.d mdadm disable
update-rc.d rpcbind disable
update-rc.d itunes disable
update-rc.d wdphotodbmergerd disable
update-rd.d wdmcserverd disable
update-rc.d twonky disable
update-rc.d openvpn disable
update-rc.d ssh enable
update-rc.d vsftpd enable
update-rc.d apache2 enable
This comment has been minimized.
Copy link Quote reply
lonmiller commented Jun 20, 2018
update-rc.d is no longer found on some models of WD My Cloud. There are workarounds about startup scripts to run the stop command, etc but WD is doing integrity checks on the devices post-firmware update and changes like this can get your device in an unstable state and make it difficult to connect without a re-image.
This comment has been minimized.
Copy link Quote reply
Pedrolitor commented Dec 14, 2019
Hi thank you for this amazing tutorial it worked perfectly the first time.
But this time, after the last update, when i try to stop the bastards (step 3) I get that message :
sh: you need to specify whom to kill
Do you know what it means?
This comment has been minimized.
Copy link Quote reply
v0lkan commented Dec 15, 2019
Unfortuntaley, I removed the hard drives in that unit (after being fed up enough) and switched using a QNAP Direct Attached Storage.
Since I can access a DAS (attached to my PC, and my PC is never down) from the network anyway, it is still doubles as a NAS to a certain extent without all the useless crap.
I think unless you have an organization of 4-5 people with different users, profiles, and needs; a NAS is kinda overrated.
So I don’t know what that command may entail; but since you’ve rooted into the system at least you can cat /etc/init.d/wdmcserverd and try to see what it is trying to do and what it’s not finding.
This comment has been minimized.
Copy link Quote reply
lonmiller commented Jan 3, 2020
The issue is here in the script (this is for /etc/init.d/wdphotodbmerger but same for wdmcserved).
the kill process is complaining about the process id because the pidof wdphotodbmerger command should return a process id for kill to, well, kill but that command returns null. Which means either wdphotodbmerger is not running, or it’s at some other level that isn’t available to the shell.
Western Digital MyCloud
«Although the information we release has been verified and shown to work to the best our knowledge, we cant be held accountable for bricked devices or roots gone wrong.«
Contents
About
The Western Digital «MyCloud» is a series of network attached storage devices.
Purchase
Buying devices is expensive and, in a lot of cases our testing leads to bricked equipment. If you would like to help support our group, site, and research please use one of the links below to purchase your next device. Purchase the Western Digital MyCloud PR4100 at Amazon
Models
As of 3/03/2017, the following are the current available models.
Firmware
Firmware can be found at the WD Support webpage «MyCloud» firmware download section.
Reversing Firmware
Firmware from the MyCloud devices can be unpacked using binwalk with the following command.
This runs binwalk with the following options
Firmware Contents
After extracting the firmware the following items can usually be found.
Web Server
The web root for the web server is located at /var/www/.
Writing To LCD Display
The code below allows for writing to the display on the WD MyCloud NAS.
Paste the following code below into two files, then compile against the «liblcd_management.so» library taken from the mycloud device or firmware with the following.
Vulnerabilities
The following are the vulnerabilities found in this product.
Login Bypass Vulnerability
We divide this into two sections, one with the original state of the login_checker.php vulnerability (Prior to 12/20/2016), and one with current version. Both contains vulnerabilities which allow for the bypassing of authentication validation.
login_checker.php (pre 12/20/2016)
A majority of the PHP scripts on the server contain a check to see if a user is logged in, the code for one of which is below.
Patched as of time of publication.
In the above, the «login_check()» function checks to see if a cookie exists with the name «username» (Ln. 18). It then proceeds to check to see if the username cookie is empty. If the cookie is not empty, the function sets the «ret» variable to 2 signifying that a user is logged in.
The function then also checks to see if the «isAdmin» cookie is equal to 1 (Ln. 21), if the cookie is set and is equal to 1 the «ret» variable is set to 1 signifying that the user logged in is an administrator.
The above code uses a user supplied value to determine if the user is logged in and does not properly validate or store any of the user information preventing an unauthorized user the ability to bypass the authentication.
This can be done by accessing any of the backend PHP scripts and adding the following cookies.
login_checker.php (post 12/20/2016)
A majority of the PHP scripts on the server contain a check to see if a user is logged in, the current code (as of 1/1/2017) for one of which is below.
In the below we begin by looking at the function «login_check()» which is called within the header of php scripts and is used to validate the user info.
In the above, the «login_check()» function checks to see if a cookie exists with the name «username» (Ln. 32). It then proceeds to check to see if the username cookie is empty. If the cookie is not empty, the function sets the «ret» variable to 2 signifying that a user is logged in.
The function then also checks to see if the «isAdmin» cookie is equal to 1 (Ln. 37), if the cookie is set and is equal to 1 the «ret» variable is set to 1 signifying that the user logged in is an administrator.
Finally, we reach the part of the code that was added to prevent the vulnerability mentioned in the above section (and patched prior to our publishing of this document) portion of the code. On line 40, a call is made to the “wto_check()” function with the username cookie value as an argument. This function is used to verify that the user has already logged in and uses the IP address of the user, the user supplied username, and a with a timer to determine if the user has recently logged in and should be allowed to continue. Within this function is where the new vulnerability exists.
The code for “wto_check()” can be found below.
Looking at the 2 pieces from above (the “wto_check()” function and the arguments to the “wto” binary), we can see that the call within “wto_check()” to the binary is using the ip address and username to check to see if the user’s login timer has expired. This however contains 1 issue, the programmer who patched the code chose to use the wrong PHP function for filtering input. The programmer used the PHP function “escapeshellcmd()” which is used to escape an entire command (as opposed to a single argument) and doesn’t comment out new function arguments. The correct use would have included the similarly named PHP function “escapeshellarg()”, which is used on single arguments within a command. Because the programmer used the wrong function, we are able to use the PHP “exec()” call to reset the login timeout by supplying an extra “-s TIMEOUTVALUE” argument for the user therefore signing them in (as opposed to just checking to see if the user is logged in). The following is an example of such a payload.
This can be paired with the fact that an administrator is just signified by the presence of a cookie with the name «isAdmin» and the value of 1 for full administrator access to the device.
The above can be added to any PHP based RCE requiring authentication for remote root command execution on the device.
network_mgr.cgi (added 8/6/2017)
The cgi binary «network_mgr.cgi» logs in a user prior to validating their credentials while also displaying a 404 error.
In the above screen shot of the hex-rays decompilation of «network_mgr.cgi», the following are performed in the listed order.
As can be seen, prior to «kindaAuth()» call (function named by us), the wto_setTime function is called. This means that even if the supplied credentials are incorrect, the «wto» (as specified in the previous login bypass above) binary is used to reset the logged in users originating ip address and login timeout. This allows the attacker to simply supply the «isAdmin» and «username» cookies to sufficiently access any authenticated functionality within the administrative interface.
Arbitrary Root File Write
The following allow for the ability to place a file anywhere on the NAS without authentication.
/web/addons/upload.php
This PHP page allows for the ability to upload a file to a location anywhere on the server.
Below is the code for the vulnerable PHP file.
In the code above there is no authentication done for file uploads and although a «-» is forced into the file name, this can be bypassed by placing the entire path in the «index» variable. Placing the entire path within the «index» request variable and using the «../» pattern to navigate different paths allows for complete control of the uploaded file and path where it’s placed.
/jquery/uploader/multi_uploadify.php (added 08/06/2017)
This PHP page allows for the ability to upload a file to a location anywhere on the server.
Below is the code for the vulnerable PHP file.
In the code above, on line 36, a web request is made to the following URL on the MyCloud web-server (/mydlink/mydlink.cgi). Then, on line 41, the output of the request is compared to the following string.
If the string is found the script exists (line 43-47).
Unfortunately, this request is used to authenticate the user for the file uploads and because this file does not exist within the NAS web directory, a 404 error is returned. This 404 error does not contain the string the script expects and therefore the script allows the user to upload a file. This file can be placed anywhere (including the web root directory) and therefore can result in remote code execution.
Pre-Auth Remote Command Execution
The following vulnerabilities allow for privileged access to the NAS without any form of authentication. All commands are executed as root.
/web/addons/ftp_download.php
Authentication Commented Out
This isn’t really a vulnerability but just a place where if the authentication had been in place the RCE within the same code wouldn’t have been made accessible without the login bypass bug.
As you can see from the above, the normal authentication code has been commented out allowing for all functionality within the file to be reached or exploited.
This alone would allow a user to backup to and from an FTP Site.
The following bugs are then accessible through different paths and different variables within the file.
Remote Command Execution
A remote command execution vulnerability exists in the ftp_download functionality of the MyCloud web interface when the «action» variable is set to «create.» This bug is accessible without authentication as the normal authentication code has been commented out.
The code below shows the vulnerable area.
In lines 133-144, a number of post values are moved into local variables. The variables are then used a few lines later within a system() call. This is all done without any sanitization on the supplied values allowing for command execution through multiple variables.
The «stop_job()» call also contains a command injection bug through its use of the «taskname» variable.
In the above, on line 118, the «taskname» variable is passed in as a function argument. It is then stored in the «cmd» variable in the proper syntax to stop a job through the ftp_download binary. On the next line we can see that the cmd variable is then executed through the popen() call allowing for command injection.
The stop_job method is accessible through the following POC.
Remote Command Execution
A remote command execution vulnerability exists in the ftp_download functionality of the MyCloud web interface when the «action» variable is set to «modify».
In lines 183-198, a number of post values are moved into local variables. The variables are then used a few lines later within a system() call. This is all done without any sanitization on the supplied values allowing for command execution through multiple variables.
This path also suffers from a command injection vulnerability using the «$taskname» variable through the same «stop_job» code mentioned previously.
Remote Command Execution
A remote command execution vulnerability exists in the ftp_download functionality of the MyCloud web interface when the «action» variable is set to «del».
In the above, on line 233 the posted «taskname» variable is put into the local «$taskname» var. It is then loaded into the «$cmd» variable as an argument in a command which deletes a job using the ftp_download binary. The cmd variable is then used within the system() call on line 238.
This path also suffers from command injection using the «$taskname» within the same «stop_job» bug mentioned previously.
Remote Command Execution
A remote command execution bug exists in the ftp_download functionality of the MyCloud web interface when the «action» variable is set to «go_jobs».
On line 252 the posted value for the «taskname» variable is put into the «$taskname» local variable. Then on line 257, the «$taskname» variable is put into «$cmd» and is formatted into the syntax as an argument for the ftp_download binary. Finally on line 258, «$cmd» is used as an argument to the popen() call allowing for command injection.
Remote Command Execution
A remote command execution vulnerability exists in the ftp_download functionality of the MyCloud web interface when the «action» variable is set to «go_restore».
In the above, on line 282 the posted «taskname» variable is put into the local «$taskname» var. Then on line 292 the variable is loaded into «$cmd» as an argument for the ftp_download binary. The «$cmd» variable is then used as an argument for the popen() call on line 293 allowing for command injection.
/web/storage/raid_cgi.php
Authentication Commented Out
This isn’t really a vulnerability but just a place where if the authentication had been in place the RCE within the same code wouldn’t have been made accessible without the login bypass bug.
As you can see from the above, the normal authentication code has been commented out allowing for all the functionality within the file to be reached and exploited.
This bug alone would allow a user to conduct device specific tests and get RAID system information.
Because authentication is commented out, the following bug is accessible.
Remote Command Execution
A remote command execution vulnerability exists in the RAID testing functionality of the MyCloud web interface when the «cmd» post variable is set to «cgi_Run_Smart_Test».This bug is accessible without authentication as the normal authentication code has been commented out.
/web/addons/jqueryFileTree.php
A remote command execution vulnerability exists in the «addons/jqueryFileTree.php» script within the MyCloud web interface. This file contains and uses no authentication code, making this bug «pre-auth».
Remote Command Execution
The following code shows the vulnerability.
/cgi-bin/snmp_mgr.cgi
Five remote command execution vulnerabilities exists in the «cgi-bin/snmp_mgr.cgi» binary within the MyCloud web interface. This file contains and uses no authentication code, making these bugs «pre-auth».
These bugs for now will be released as just POCs and we will be writing up the analysis for these bugs at a later point.
Remote Command Execution
Remote Command Execution
This RCE has limitation of a 32 character limit for the “uid” field.
Remote Command Execution
This RCE has limitation of a 32 character limit for the “uid” field.
Remote Command Execution
When modifying this RCE, you must ensure that the “data_len” variable contains the correct string length of the “data” variable.
Remote Command Execution
When modifying this RCE, you must ensure that the “data_len” variable contains the correct string length of the “data” variable.
/cgi-bin/login_mgr.cgi
A remote command execution vulnerabilities exists in the «cgi-bin/login_mgr.cgi» binary within the MyCloud web interface. This file contains and uses no authentication code, making this bug «pre-auth».
This bug for now will be released as a POC and we will be writing up the analysis for this bug at a later point.
Remote Command Execution
Authentication Required Remote Command Execution
The following bugs require authentication but, this requirement can be overcome by using the login bypass method listed in the login bypass section above.
A quick example POC using CURL for this bug is:
/web/php/users.php
A remote command execution vulnerability exists in the «php/users.php» script within the MyCloud web interface.
Remote Command Execution
The «php/users.php» file is vulnerable to a remote command execution bug allowing for a logged in user to execute commands.The following code illustrates the vulnerability.
This bug is very simple, on line 15 the value of the «username» cookie is pulled into a local variable «$username», on the next line the value is used in the exec() call.
/web/php/upload.php
A remote command execution vulnerability exists in the «php/upload.php» script within the MyCloud web interface.
Remote Command Execution
The «php/upload.php» file is vulnerable to a remote command execution bug allowing for a logged in user to execute commands.The following code illustrates the vulnerability.
On line 15 the value of the «username» cookie is pulled into a local variable, on the next line the value is used in the exec() call.
/web/setting/recycle_bin.php
A remote command execution vulnerability exists in the «setting/recycle_bin.php» script within the MyCloud web interface.
Remote Command Execution
The «setting/recycle_bin.php» file is vulnerable to a remote command execution bug allowing for a logged in user to execute commands.The following code illustrates the vulnerability.
In the above, when «action» is set to «save», the set_xml_value_to_memory() is called. The user supplied post value for «enable_auto_clear» and «clear_days» are then used as the second argument for the set_xml_value_to_memory() function. The code for set_xml_value_to_memory() can be found below.
The above function «set_xml_value_to_memory» accepts two arguments, «$node» and «$val». In both calls to this code, «$node» is a static value while «$val» is user supplied. On line 25, both the «$node» and «$val» are used to craft a command which is stored in «$cmd» without any sanitization. On line 26, the «$cmd» variable is then used as the argument to popen(), which executes the command within. This allows for remote command execution
/web/php/sendLogToSupport.php
A remote command execution vulnerability exists in the «php/sendLogToSupport.php» script within the MyCloud web interface.
Remote Command Execution
The «php/sendLogToSupport.php» file is vulnerable to a remote command execution bug allowing for a logged in user to execute commands. The following code illustrates the vulnerability.
On line 15 the value of the «username» cookie is pulled into a local variable. In the next line the value is used in an exec() call.
/web/php/remoteBackups.php
A remote command execution bug exists in the «php/remoteBackups.php» script within the MyCloud web interface.
Remote Command Execution
The «php/remoteBackups.php» file is vulnerable to a remote command execution bug allowing for a logged in user to execute commands.The following code illustrates the vulnerability.
On line 18 above the «$cmd» variable is used to determine the path of the code through the use of a switch statement (even though there is only 1 case). If «$cmd» is set to «getRecoverItems», we reach the getRecoverItems() method of the «RemoteBackupsAPI» class. Within this function, the «jobName» request variable (which can be a cookie, get or post value) is loaded into the «$jobName» local var (Ln. 32). From here, a pattern similar to all the rest of the command injection bugs on this page is used which consists of loading the user supplied value (within jobName) into the syntax of an argument for a command (Ln 36). The value is then stored in the «$cmd» variable and used in the PHP system() call on line 37.
/web/php/noHDD.php
A remote command execution vulnerability exists in the «php/noHDD.php» script within the MyCloud web interface.
Remote Command Execution
The «php/noHDD.php» file is vulnerable to a remote command execution bug allowing for a logged in user to execute commands.The following code illustrates the vulnerability.
The above does depend on the /tmp/system_ready file existing.
/web/php/modUserName.php
A remote command execution vulnerability exists in the «php/modUserName.php» script within the MyCloud web interface.
Remote Command Execution
The «php/modUserName.php» file is vulnerable to a remote command execution bug allowing for a logged in user to execute commands.The following code shows the vulnerability.
The above path has two different command injection bugs within it, one through the use of the «username» post value and the other through the «oldName» post value.
Similarly, in line 16, the «username» post value is moved into the «$username» local variable. On line 48, «$username» is put into the «$cmd» variable as an argument for the «wto» binary without any sanitization. Finally, on line 49, a «system()» call is made using the «$cmd» variable which results in code execution.
/web/php/chk_vv_sharename.php
A remote command execution vulnerability exists in the «php/chk_vv_sharename.php» script within the MyCloud web interface.
Remote Command Execution
The «php/chk_vv_sharename.php» file is vulnerable to a remote command execution bug allowing for a logged in user to execute commands.The following code shows the vulnerability.
On line 17 of the code above, the «vv_sharename» get variable is moved into the «$vv_sharename» local variable. Then, on line 19, a check is done on the get «vv_sharename» variable to verify it is not empty. If the value is empty the script returns with an error. Otherwise, «$vv_sharename» is stored in the «$cmd» variable as an argument to the «vvctl» binary. The «$cmd» variable is then executed on line 26, through the PHP «system()» call.
/web/google_analytics.php
A remote command execution bug exists in the «google_analytics.php» script within the MyCloud web interface.
Remote Command Execution
The «google_analytics.php» file is vulnerable to a remote command execution bug allowing for a logged in user to execute commands.The following code shows the vulnerability.
In the above, the posted «cmd» value is put into the local variable «$action», this value is used to control the path of the code. If the «$cmd» variable is set to «set», the code on lines 22-26 is used. On line 22, the post variable «opt» is stored into the local variable «$opt». The same is done on line 23 for the posted variable «arg» with the local variable «$arg». Following both assignments, the code on line 24 adds the values from «$opt» and «$arg» as arguments to the «ganalytics» binary and stores the string within the «$run_cmd» variable. Finally, the variable is passed as the first argument to the PHP «system()» call, and is then executed.
/web/dsdk/DsdkProxy.php
A remote command execution vulnerability exists in the «dsdk/DsdkProxy.php» script within the MyCloud web interface.
Remote Command Execution
The «dsdk/DsdkProxy.php» file is vulnerable to a remote command execution bug allowing for a logged in user to execute commands. The following code shows the vulnerability.
In the above code, on line 12, a Boolean value is stored within the «$postOrPutRequest» variable. Following this, the script begins to create a string («$curlCommand») with the contents of a «curl» command that will be used later (Ln 14). On line 18, the Boolean value within «$postOrPutRequest» is used to determine if the contents of the php://input is appended to the CURL command. This is where our command injection comes into play, the contents of «php://input» are not sanitized and are stored directly in the CURL command within «$curlCommand». After a few more modifications (but no sanitization), the contents of «$curlCommand» are executed through a call to shell_exec() (Ln 35).
/web/backups/usb_backup.php
The «backups/usb_backup.php» file contains multiple paths which lead to remote command execution. The following code shows the vulnerability.
Remote Command Execution
A remote command execution bug exists in the usb_backup functionality of the MyCloud web interface when the «action» variable is set to «go_restore».
Remote Command Execution
A remote command execution bug exists in the usb_backup functionality of the MyCloud web interface when the «action» variable is set to «stop_jobs».
The above code contains a bug identical to the bug mentioned before it, in that through a separate path (using the «stops_jobs» action) the «taskname» posted variable is passed to the stop_job() method. This puts the value of the variable as an argument for the «usb_backup» binary.
Remote Command Execution
A remote command execution bug exists in the usb_backup functionality of the MyCloud web interface when the «action» variable is set to «del».
The above code contains paths to two different command execution bugs, one involving the previously mentioned «stop_job()» method, which through the posted variable «taskname» is executed in a PHP «popen()» call and another involving the same variable «taskname» in a separate PHP «popen()» call. Because we’ve detailed the command execution bug within the «stop_job» method a few times above, we’ll just skip straight to the popen() bug.
Remote Command Execution
A remote command execution vulnerability exists in the usb_backup functionality of the MyCloud web interface when the «action» variable is set to «go_jobs».
In the above code, on line 216 the posted variable «taskname» is stored within the PHP «$taskname» variable. On line 221, the «$taskname» variable value is then stored within the «$cmd» variable in the syntax as an argument for the «usb_backup» binary. Then, on line 222, the «$cmd» variable is executed through the use of the PHP «popen()» function.
Remote Command Execution
A remote command execution vulnerability exists in the «usb_backup» functionality of the MyCloud web interface when the «action» variable is set to «modify».
The posted taskname variable is involved in two more PHP «exec» calls. The variable is used as an argument to the already mentioned vulnerable function «stop_job()» (Ln. 174) allowing for command injection, as well as in an argument for «usb_backup» binary (Ln. 185) which is then executed through a popen() call on line 186.
Remote Command Execution
A remote command execution vulnerability exists in the usb_backup functionality of the MyCloud web interface when the «action» variable is set to «create».
The above code is slightly unique compared to a majority of all of the other code segments on this page. This code contains some sanitization, in particular for the posted variable «dest_dir» (Ln. 142) and the posted array source_dir (Ln. 144-145). However the other posted values are not sanitized and are all used within a PHP «popen()» call without any sanitization allowing for command injection. In particular the posted variables «taskname», «category», «backup_type», and «autostart» are stored within the «$cmd» variable as arguments for the usb_backup binary (Ln. 141-142) and are then called through the use of a PHP «popen()» on line 147.
The posted taskname variable is involved in two more PHP «exec» calls. The variable is used as an argument to the already mentioned vulnerable function «stop_job()» (Ln. 151) allowing for command injection, as well as as an argument for «usb_backup» binary (Ln. 154) which is then executed through a popen() call on line 155.
backups/internal_backup.php
Remote Command Execution
A remote command execution bug exists in the internal_backup functionality of the MyCloud web interface when the «action» variable is set to «create».
The above code contains multiple different variables left unsanitized that can be used for command injection.
The code begins with the posted variables being stored into local variables (Ln. 137-146). Following, a set of conditionals are used to create a local variable «$sch_command» with the proper format for the «-r» argument for the «internal_backup» binary (Ln. 149-152). During this process, based on the value of the «$schedule» variable, the posted values for «hour», «week» and «day» are put into the the «$sch_command» variable. This variable is then used on lines 144-145 to create a command which executes the «internal_backup» binary along with some of the posted variables. The following variables created from posted values are added without any sanitization to the internal_backup command: «$backup_type», «$taskname», and «$sch_command». The «$dest_dir» variable is also added but is sanitized through the use of PHP’s «escapeshellarg()» function. More values are added to the «$cmd» variable storing the «internal_backup» command on lines 157-160, but they are either sanitized or aren’t user supplied. Finally, on line 172, the «$cmd» variable is executed through the use of a PHP «system()» function call.
Another path to command execution can be seen starting on line 174, on this line, a file name «/tmp/r_internal!_» has the value of the local variable «$taskname» appended to it and the result is stored in «$pname». This variable contains an un-sanitized value created from a posted user supplied variable. Then, on line 176, the «$pname» value is appended to an «rm» command and is executed through the use of a PHP «system()» call without sanitization. This allows for another command injection path through the use of «$taskname».
Yet another path to command execution can be seen starting on line 181. In this line the «$taskname» local variable (containing user supplied input) is inserted into a string in the «$cmd» variable containing the syntax for the «internal_backup» binary as its «-a» argument. Then, on line 182, the PHP «system()» function is called with the «$cmd» variable as its first argument, executing the command within. This is all done without any sanitization being done on «$taskname», which contains a user supplied input.
Finally, another path to command execution leveraging the «$taskname» variable can be seen starting on line 178. This line contains a call into the stop_job function with the taskname as its only argument. The code for the «stop_job()» call can be seen below.
In the above function, we can see that the only argument to the function «$taskname» is put into the proper syntax for the «internal_backup» command for the «-a» argument (Ln. 115) and stored in the variable «$cmd». Then, on line 116, the «$cmd» local variable is passed to the PHP «popen()» function executing the command within. The above is all concluded without any sanitization done on the user supplied input.
Remote Command Execution
A remote command execution vulnerability exists in the internal_backup functionality of the MyCloud web interface when the «action» variable is set to «modify».
The above code contains multiple different variables left unsanitized that can be used for command injection.
The code above begins with the posted variables being stored into local variables (Ln. 194-204). Following, a set of conditionals are used to create a local variable «$sch_command» with the proper format for the «-r» argument for the «internal_backup» binary (Ln. 206-210). During this process, based on the value of the «$schedule» variable, the posted values for «hour», «week» and «day» are put into the the «$sch_command» variable. This variable is then used on lines 214-215 to create a command which executes the «internal_backup» binary along with some of the posted variables. The following variables created from posted values are added without any sanitization to the internal_backup command: «$old_taskname», «$taskname», «backup_type», and «$sch_command». The «$dest_dir» variable is also added but, is sanitized through the use of PHP’s «escapeshellarg()» function. More values are added to the «$cmd» variable storing the «internal_backup» command on lines 216-219, but they are either sanitized or aren’t user supplied. Finally on line 220, the «$cmd» variable is executed through the use of a PHP «system()» function call.
Another path to command injection exists in an identical manner as the «create» path within the same PHP file. This involves the «stop_job» function along with the «$taskname» local variable (Ln. 212), more info on the vulnerability can be found above.
Finally, one last path to command injection can be found starting on line 226. Here, we have the «$taskname» variable, which contains user supplied data, inserted into the «$cmdS» variable with the syntax as an argument for the «internal_backup» binary without sanitization. Following, on line 227, the «$cmdS» command is executed through the use of a PHP «system()» call allowing for command injection.
Remote Command Execution
A remote command execution bug exists in the internal_backup functionality of the MyCloud web interface when the «action» variable is set to «del».
In the above, we only have 1 posted value used, which is «taskname». On line 242, we can see that the posted variable is stored into a local variable «$taskname». Then, on line 246, this variable is used to craft a command stored in «$cmd» which executes the «internal_backup» binary with the local variable «$taskname» within the «-a» argument. Then, on line 247, the PHP «system()» function is called with «$cmd» as an argument, executing the command. This is all done without any sanitization on the user supplied value allowing for command injection.
In the above there is also a call to the «stop_job» function with the «$taskname» variable allowing for command injection in a path identical to the «create» and «modify» «stop_job» paths mentioned above.
Remote Command Execution
A remote command execution vulnerability exists in the internal_backup functionality of the MyCloud web interface when the «action» variable is set to «go_jobs».
On line 261, the posted variable «taskname» is moved into the local variable «$taskname». Then, on line 266, the variable is put into a syntax to be used as the «-a» argument for the «internal_backup» command and is stored in «$cmd». Then, on line 267, PHP’s «popen()» is called with «$cmd» as an argument executing the command within. Because «$taskname» is used without any sanitization, this leads to a command injection vulnerability.
Remote Command Execution
A remote command execution vulnerability exists in the internal_backup functionality of the MyCloud web interface when the «action» variable is set to «stop_jobs».
In the code above, a call to the «stop_job» function with the «$taskname» variable (Ln. 280) allows for command injection in a path identical to the «create», «modify», and «del» «stop_job()» paths mentioned above.
Remote Command Execution
A remote command execution vulnerability exists in the internal_backup functionality of the MyCloud web interface when the «action» variable is set to «go_restore».
In the above there is also a call to the «stop_job» function with the «$taskname» variable (line 296) allowing for command injection in a path identical to the «create», «modify», and «del» «stop_job()» paths mentioned above.
/web/backups/elephant_drive.php
Two remote command execution vulnerabilities exists in the «elephant_drive» functionality of the MyCloud web interface
Remote Command Execution
On lines 15-17, the posted variables for «attion», «e_email», and «e_password» are stored into local variables «$action», «$_email», and «$_password». Then, when the «$action» variable is set to «apply», the «apply» case is used which begins on line 201. When this path is taken, the vulnerability is triggered when the variable «$_password» is appended as an argument (Ln. 227) to the «$cmd» variable in a command which executes the «elephant_drive» binary with a PHP «exec()» function call. The «$_password» value is user supplied and used without any sanitization allowing for command injection.
Remote Command Execution
/web/addons/safepoints_api.php
Six remote command execution vulnerabilities exists in the «safepoints_api» functionality of the MyCloud web interface
Remote Command Execution
On line 21, the posted variable «action» is stored into the local variable «$action». Then, when the «$action» variable is set to «usb_get_safepoints» the code path starting at line 65 is followed. In this segment the vulnerable code begins on line 67 where the posted variable «sp_path» is stored as the local variable «$sp_path». Then, on line 73 the «$sp_path» variable is used as an argument for the «discover_dev» binary and are stored within the «$cmd» variable. On the following line, the command within the «$cmd» variable is executed through the use of a PHP «popen()» call. This is all performed without any sanitization on the user supplied data allowing for command injection.
Remote Command Execution
On line 21, the posted variable «action» is stored into the local variable «$action». Then, when the «$action» variable is set to «usb_do_recover» the code path starting at line 82 is followed. In this segment, the vulnerable code begins on lines 84-86 where the posted variables for «usb_sharename», «sp_name» and «path» are stored in local variables «$usb_sharename», «$sp_name», and «$_path». These 3 variables are then all used as arguments for the «sprb» binary in a command created and are then stored in the «$cmd» variable (Ln. 90). Following the command being created, on line 91 the PHP «popen()» function is called with «$cmd» as an argument executing the command within. This is all done without sanitization on any of the user supplied input allowing for command injection.
Remote Command Execution
On line 21, the posted variable «action» is stored into the local variable «$action». Then, when the «$action» variable is set to «network_get_sharefolder» the code path starting at line 177 is followed. In this segment, the vulnerable code begins on lines 182-184 where the posted variables for «ip», «user» and «pwd» are stored in local variables «$ip», «$user», and «$pwd». Then, on line 191, the three variables are inserted within the proper syntax as arguments for the «discover_dev» binary and are stored in the «$cmd» variable. Then, on line 192 the PHP «popen()» function is called with «$cmd» as an argument executing the command within. All of the above is accomplished without ever sanitizing any of the user input within allowing for command injection.
Remote Command Execution
On line 21, the posted variable «action» is stored into the local variable «$action». Then, when the «$action» variable is set to «network_share_auth» the code path starting at line 218 is followed. In this segment the vulnerable code begins on lines 222-225 where the posted variables for «ip», «username», «password», and «sharename» are stored in local variables «$ip», «$username», «$password», and «$sharename». Then on line 228, the four variables are inserted within the proper syntax as arguments for the «discover_dev» binary and are stored in the «$cmd» variable. Following, on line 229 the PHP «popen()» function is called with «$cmd» as an argument executing the command within. All of the above is accomplished without ever sanitizing any of the user input within allowing for arbitrary command injection.
Remote Command Execution
On line 21, the posted variable «action» is stored into the local variable «$action». Then, when the «$action» variable is set to «network_get_safepoints» the code path starting at line 243 is followed. In this segment the vulnerable code begins on lines 245-248 where the posted variables for «ip», «username», «password», and «sp_sharename» are stored in local variables «$ip», «$username», «$password», and «$sp_sharename». Then, on line 254, the four variables are inserted within the proper syntax as arguments for the «discover_dev» binary and are stored in the «$cmd» variable. Following, on line 255 the PHP «popen()» function is called with «$cmd» as an argument executing the command within. All of the above is accomplished without ever sanitizing any of the user input within, allowing for arbitrary command injection.
Remote Command Execution
On line 21, the posted variable «action» is stored into the local variable «$action». Then, when the «$action» variable is set to «network_do_recover» the code path starting at line 263 is followed. In this segment the vulnerable code begins on lines 265-270 where the posted variables for «ip», «share_name», «username», «sp_name», and «hostname» are stored in local variables «$ip», «$share_name», «$username», «$sp_name», and «$hostname». Then, on line 276, the five variables are inserted within the proper syntax as arguments for the «discover_dev» binary and are stored in the «$cmd» variable. Following, on line 277 the PHP «popen()» function is called with «$cmd» as an argument executing the command within. All of the above is accomplished without ever sanitizing any of the user input within allowing for arbitrary command injection.