IoT Disclosure Notice and Guideline

We are security researchers from the Design and Analysis of Communication Systems (DACS) group at Faculty of Electrical Engineering, Mathematics and Computer Science (EEMCS) at the University of Twente. Our research project is funded by the INTERSCT, the cybersecurity project in the Netherlands.

If you reach this site for the recent email notice regarding MQTT, CoAP, and XMPP, please check on the page below. You can find more details about how we conducted the experiment and collected the data.
https://iotscan.eemcs.utwente.nl/

To responsibly disclose our findings, we follow the Coordinated Vulnerability Disclosure policy of the University of Twente and work with the National Cyber Security Center (NCSC) for the disclosure process. To reach out to us, please contact the email address below:

iot-disclosure-2023@utwente.nl

Scanning Methodology

The following methods have been used in scanning and detecting vulnerabilities:

MQTT

Topic Enumeration: In case of a successful connection with the endpoint, we subscribe to the wildcards # and $SYS/#. We then collect all the incoming topic names.
Extract Number of Connected Clients and Broker Version: while in general, we discard all payloads to avoid ethical issues, we do collect some $SYS/# payloads, which give us relevant information for endpoint fingerprinting and security analysis, e.g., the broker version or the number of connected clients.

CoAP

Enumeration of Resources via HEAD Request: we compile a list of 30 resources we check for. We perform a HEAD request for each resource and wait for the return code. We mark the resource as available if we receive return codes 2.05 (Content) or 2.03 (Valid).
Extract Server Version: Cotopaxi allows us to check the adopted library and version for the CoAP server.

XMPP

Extract Server Version, Features, Capabilities, and Authentication Mechanisms: nmap allows us to extract all the information for XMPP servers, including adopted authentication mechanisms and supported capabilities (e.g., TLS). We then check which authentication mechanisms are broken or insecure.

Discovered vulnerabilities

CVE-2018-12550: When Eclipse Mosquitto version 1.0 to 1.5.5 (inclusive) is configured to use an ACL file, and that ACL file is empty, or contains only comments or blank lines, then Mosquitto will treat this as though no ACL file has been defined and use a default allow policy. The new behaviour is to have an empty ACL file mean that all access is denied, which is not a useful configuration but is not unexpected.

CVE-2018-12551: When Eclipse Mosquitto version 1.0 to 1.5.5 (inclusive) is configured to use a password file for authentication, any malformed data in the password file will be treated as valid. This typically means that the malformed data becomes a username and no password. If this occurs, clients can circumvent authentication and get access to the broker by using the malformed username. In particular, a blank line will be treated as a valid empty username. Other security measures are unaffected. Users who have only used the mosquitto_passwd utility to create and modify their password files are unaffected by this vulnerability.

CVE-2018-19417: An issue was discovered in the MQTT server in Contiki-NG before 4.2. The function parse_publish_vhdr() that parses MQTT PUBLISH messages with a variable length header uses memcpy to input data into a fixed size buffer. The allocated buffer can fit only MQTT_MAX_TOPIC_LENGTH (default 64) bytes, and a length check is missing. This could lead to Remote Code Execution via a stack-smashing attack (overwriting the function return address). Contiki-NG does not separate the MQTT server from other servers and the OS modules, so access to all memory regions is possible.

CVE-2017-7655: In Eclipse Mosquitto version from 1.0 to 1.4.15, a Null Dereference vulnerability was found in the Mosquitto library which could lead to crashes for those applications using the library.

CVE-2019-9749: An issue was discovered in the MQTT input plugin in Fluent Bit through 1.0.4. When this plugin acts as an MQTT broker (server), it mishandles incoming network messages. After processing a crafted packet, the plugin's mqtt_packet_drop function (in /plugins/in_mqtt/mqtt_prot.c) executes the memmove() function with a negative size parameter. That leads to a crash of the whole Fluent Bit server via a SIGSEGV signal.