On this article we will be focused on the identification and exploitation of CVE-2020-26124 , a remote code execution (RCE) vulnerability affecting OpenMediaVault ,on specific versions before 4.1.36 and 5.x before 5.5.12.
OpenMediaVault is a free Linux distribution designed for Network-Attached Storage (NAS) that offers services like SSH, (S)FTP, SMB/CIFS, DAAP media server, RSync, BitTorrent client and many more. OpenMediaVault is based on the Debian operating system, and is licensed under the GNU General Public License v3 while project’s lead developer is Volker Theile, who instituted by the end of 2009.
Our research began on 2020-09-26, when we initially installed the (latest till then) version 5.5.11-1 of OpenMediaVault, which is freely available for downloading though SourceForge , on a virtual machine in our lab. After the successful installation and setup of OpenMediaVault, we logged in to the web-based provisioning GUI, using the default administrative credentials (i.e. username:”admin” and password:“openmediavault”).
Image 1: OpenMediaVault web-based provisioning GUI.
Following a long journey and several tests on OpenMediaVault’s functionalities, it was identified that the version 5.5.11-1 is vulnerable to post-authenticated PHP code injection attacks, affecting the “shortfield” POST parameter of the “rpc.php” page. Code injection vulnerabilities, in general, arise when an application incorporates user supplied data into a string that is dynamically evaluated by a code interpreter.
Wherefore, a potential attacker may leverage this vulnerability and inject arbitrary PHP code that will be executed server-side, resulting to potential takeover of the underlying operating system. As it can be observed on the following demonstration, by concatenating the “exec()” function – a built-in function of PHP which is used to execute an external program – command execution on operating system level can be achieved:
Image 2: Generic PHP code concatenation and external operating system command execution via the “exec()” PHP function.
Owing to the facts that (a) the identified vulnerability was “blind” (i.e. it was not feasible to retrieve the output of the executed commands via “exec()” PHP function), (b) the usage of “sleep()” PHP function and/or operating system command was not effective (the application hangs always after the execution) and (c) time-based attacks like leveraging the “usleep()” PHP function are time consuming, we decided to make use of an Out-Of-Band (OOB) technique in order to retrieve command output and exfiltrate data as a proof of concept.
Typically, the OOB techniques are based on triggering an outbound TCP/UDP/ICMP request through which the attacker exfiltrates data. According to the aforementioned approach, the following payload was created and used:
Image 3: A sample of the used Out-Of-Band data exfiltration payload.
The payload incorporates the output of the “id” command and encodes it in base64 format (without line wrapping – using “base64 -w 0” that is appropriate for transmission in the URL). Finally, through the “wget” command the generated base64 string is sent via a GET HTTP request to the attacker.
Image 4: Out-Of-Band data exfiltration in action.
Additionally, it was identified that the application process is running with root privileges and served through Nginx. The aforementioned conceptual issue amplifies the impact of a successful exploitation of any vulnerability in the context of the application, since any unauthorized action will be executed with “root” privileges.
As a final step, we managed to get a reverse TCP connection using the code injection vulnerability, which as verified previously, allows for arbitrary command execution on the underlying operating system with “root” privileges.
Image 5: Received reverse TCP connection with “root” privileges.
The Metasploit Framework Module.
Even so, as a Proof-of-Concept (POC) of that research, we developed and submitted  a Metasploit module for CVE-2020-26124, which exploits the identified remote code execution (RCE) vulnerability of OpenMediaVault, versions before 4.1.36 and 5.x before 5.5.12.
Image 6: The Metasploit module in action.
Since user input – as a principle – should be considered as non-trusted, it is highly recommended that applications should avoid incorporating user-controllable data into dynamically evaluated code. The validation algorithm should allow only characters that are included in a whitelist, explicitly defined by the business needs of the application. Moreover, only alphanumeric strings should be accepted and thus input containing any other symbols should be proactively included in a blacklist that will be applied for validation after the initial whitelist check.
Moreover, regarding the application which is running with excessive privileges, it is highly recommended to use a dedicated functional account for that purpose, following the principle of least privilege.
Public Disclosure Timeline