CVE-2025-65291

Executive Summary

CVE-2025-65291 exposes a critical security flaw in Aqara Hub devices (M2, M3, and Camera Hub G3). The vulnerability stems from the failure to validate server certificates during TLS connections for discovery services and CoAP gateway communications. This allows an attacker positioned on the network to perform a man-in-the-middle (MITM) attack, intercepting and manipulating device control and monitoring traffic. The lack of certificate validation effectively nullifies the security provided by TLS, making the devices susceptible to credential theft, command injection, and unauthorized access to the smart home ecosystem. No public proof-of-concept (PoC) or patch is currently available.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It is a firmware-level issue in Aqara Hub devices.

CVSS Breakdown & Threat Level

CVSS Score: 9.8 (Critical) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

• Attack Vector (AV): Network - The attack can be launched remotely over the network.
• Attack Complexity (AC): Low - No special conditions or complex steps are required.
• Privileges Required (PR): None - The attacker does not need any prior access.
• User Interaction (UI): None - The victim does not need to perform any action.
• Scope (S): Unchanged - The impact is confined to the vulnerable component.
• Confidentiality (C): High - All traffic, including credentials and sensor data, can be read.
• Integrity (I): High - Commands and data can be modified.
• Availability (A): High - The attacker could disrupt device functionality.

Threat Level: Critical. The vulnerability allows complete compromise of the Aqara Hub and its connected devices.

Deep Dive & Mechanics

The vulnerability lies in the TLS client implementation within the Aqara Hub firmware. When the hub establishes TLS connections for two critical services:

1. Discovery Services: Used for initial device pairing and network discovery.
2. CoAP Gateway Communications: Used for ongoing control and monitoring of IoT devices (sensors, switches, etc.).

The client does not validate the server's certificate against a trusted Certificate Authority (CA) store. This means:

• The client will accept any certificate presented by a server.
• An attacker can perform an ARP spoofing or DNS poisoning attack to redirect the hub's traffic to a malicious server.
• The attacker's server presents a self-signed or otherwise invalid certificate.
• The hub accepts the certificate and establishes an encrypted session with the attacker.
• The attacker can then decrypt, read, modify, and re-encrypt all traffic between the hub and the legitimate cloud service.

This effectively bypasses the security of TLS, turning an encrypted channel into a plaintext channel controlled by the attacker.

Vulnerable vs. Patched Code

Since no patch is available, a direct code comparison is not possible. However, the vulnerable code pattern is:

Vulnerable (Conceptual):

// No certificate verification
SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL);
// or
// Certificate verification callback always returns success
int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx) {
    return 1; // Always accept
}

Patched (Conceptual):

// Enable strict certificate verification
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);
// Load trusted CA certificates
SSL_CTX_load_verify_locations(ctx, "/etc/ssl/certs/ca-certificates.crt", NULL);

Exploitation & Lab Setup

Red Team (Offensive)

Lab Setup:

1. Target: Aqara Hub M2 (firmware 4.3.6_0027) on a local network (192.168.1.0/24).
2. Attacker Machine: Kali Linux with bettercap and mitmproxy installed.
3. Network: The attacker machine must be on the same subnet as the hub.

Exploitation Steps:

1. ARP Spoofing: Use bettercap to perform ARP spoofing between the hub and the gateway.

   sudo bettercap -eval "set arp.spoof.targets 192.168.1.100; arp.spoof on"
   

2. Setup MITM Proxy: Configure mitmproxy to intercept TLS traffic.

   mitmproxy --mode transparent --listen-port 8080
   

3. Redirect Traffic: Use iptables to redirect traffic from the hub to the proxy.

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

4. Intercept and Modify: Since the hub does not validate the certificate, mitmproxy will present its own certificate, and the hub will accept it. The attacker can now view and modify all traffic.

Blue Team (Defensive)

Detection:

1. Network Monitoring: Monitor for ARP spoofing attacks using tools like arpwatch or Snort.
2. TLS Anomaly Detection: Look for connections to unknown or self-signed certificates from the Aqara Hub's IP address.
3. Firmware Integrity: Regularly check for firmware updates from Aqara and verify the integrity of the installed firmware.

Mitigation:

1. Network Segmentation: Place IoT devices on a separate VLAN with strict firewall rules.
2. Disable Unused Services: If possible, disable discovery services and CoAP gateway communications if not needed.
3. Monitor for Unusual Traffic: Use a SIEM to alert on any unexpected outbound connections from the hub.

Indicators of Compromise (IOCs)

• Network:
  • Unexpected ARP replies indicating ARP spoofing.
  • TLS connections from the hub to IP addresses not belonging to Aqara's known cloud infrastructure.
  • Presence of self-signed certificates in the hub's TLS sessions.
• Host:
  • Unusual processes running on the hub (if accessible).
  • Modified configuration files related to TLS settings.
• Logs:
  • Hub logs showing failed certificate validation attempts (if logging is enabled).

Detection Engineering

YARA Rule

rule Aqara_Hub_Certificate_Validation_Bypass {
    meta:
        description = "Detects firmware versions of Aqara Hubs vulnerable to CVE-2025-65291"
        author = "Valters IT"
        date = "2025-04-10"
        hash = "sha256:EXAMPLE_HASH"
    strings:
        $firmware_m2 = "4.3.6_0027"
        $firmware_m3 = "4.3.6_0025"
        $firmware_g3 = "4.1.9_0027"
        $tls_bypass = "SSL_VERIFY_NONE"
    condition:
        any of ($firmware_*) and $tls_bypass
}

Sigma Rule

title: Aqara Hub TLS Certificate Validation Bypass
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects network traffic indicating a potential MITM attack on Aqara Hubs
author: Valters IT
date: 2025/04/10
logsource:
    category: network_connection
    product: zeek
detection:
    selection:
        server_name: "*.aqara.com"
        certificate_validation: "self-signed"
    condition: selection
falsepositives:
    - Legitimate self-signed certificates used in testing environments
level: high

Suricata Rule

alert tls $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Aqara Hub TLS Certificate Validation Bypass - Self-Signed Cert"; flow:to_server; tls.cert_issuer:"CN=*"; tls.cert_subject:"CN=*"; tls.cert_notbefore:"*"; tls.cert_notafter:"*"; tls.cert_serial:"*"; tls.cert_fingerprint:"*"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate Vulnerable Devices: Place the Aqara Hub on a separate VLAN with no direct access to the internet or other critical systems.
2. Monitor Network Traffic: Use network monitoring tools to detect any suspicious TLS connections from the hub.
3. Disable Unnecessary Services: If possible, disable the discovery service and CoAP gateway communications.

Long-Term Fix:

1. Firmware Update: Await an official firmware update from Aqara that implements proper certificate validation.
2. Vendor Notification: Contact Aqara support to inquire about the patch status and timeline.
3. Device Replacement: If no patch is released, consider replacing the hub with a device from a vendor with a better security track record.

Valters IT Signature This report was generated by Valters IT Cyber Threat Intelligence. For questions, contact intelligence@valters-it.com.