Don’t worry—I’m not going to regale you with tales of the vendetta between a sibling of mine and I that stemmed from a $20 cooking griddle gift at a Yankee Swap from long ago, or of the holiday riots that have occurred over the years when mixing gift giving with eggnog. Nor will I gloat about the sweet blanket I scored/stole from a White Elephant with friends this year.
Instead, I’m going to swap you some research we’ve been doing that relates to a simple, cheap and potentially entertaining protocol: MQTT.
MQTT is the Message Queuing Telemetry Transport, or MQ Telemetry Transport, and is a simple publish-subscribe messaging protocol built on TCP/IP.
MQTT messages are sent to and read from topics, which is a simple method of organizing messages that mimics a directory structure. As an example, if MQTT were used as part of a system responsible for collecting temperatures readings from remote sensors, a possible topic structure might be
<location> could be any number of sub-topics broken down by physical location and
<sensor_num> would represent the topic of the temperature from a given sensor.
An MQTT client requires an MQTT broker to be of any use. The MQTT broker is responsible for handling subscription requests from MQTT clients who wish to receive topical messages as well as handling topical publication requests from MQTT clients and the subsequent publication of messages to subscribed MQTT clients. MQTT supports the concept of topic wildcards with
#, but only from a subscription perspective—the protocol does not support publishing to wildcard topics.
For the nitty gritty details on MQTT, I’d recommend reading the OASIS MQTT standard.
From a security perspective, the only capabilities the MQTT standard really provides are optional username and password fields that can be specified in the initial connection, however the standard says that the handling of these fields is implementation specific. All remaining aspects of security with regards to MQTT are, again, implementation specific.
In our testing, the username and password fields are plaintext, null-terminated fields that are compared against hashed versions stored on the broker, if enabled. Some support disabling anonymous authentication. Additionally, in practice, most implementations provide for user, topic, action and client identifier-based restrictions such that the actions of individual clients can be controlled. TLS can be used to encrypt the whole shebang as well as provide additional authentication mechanisms when client certificates are used.
Again, these are all implementation specific and not provided for by the protocol itself. For more depth on this, the folks over at HiveMQ put together a multi-part series on MQTT Security Fundamentals that is worth a read.
Several of MQTT’s characteristics make it ideal for use in IoT applications, which is not surprising considering that what we now know as MQTT was once referred to as the “SCADA protocol” and the “MQ Integrator SCADA Device Protocol” (MQIsdp). It is unclear which real IoT products out there utilize MQTT, but both Amazon and Azure have MQTT support, Hackster.io has a dozen or so MQTT-based IoT projects, and Home Assistant has support for MQTT-enabled lights, vacuums, switches, locks, cameras and more. MQTT places few restrictions on the messages it it handles, and as such, developers integrating MQTT into their solutions are using it for everything from sensor reading and event notification to device configuration and updates, and more, for better or worse.
Even though the protocol has been around in various forms since 1999, there are only a handful of known vulnerabilities in MQTT-enabled products, all from this year, including:
- CVE-2017-9868: Mosquitto MQTT Broker world readable persistence database
- CVE-2017-7650: Mosquitto MQTT Broker ACL bypass
- CVE-2017-9131: Mimosa Client Radio MQTT DoS
- CVE-2017-9132: Mimosa Client Radio MQTT hard-coded credentials and information disclosure
In 2016, Lucas Lundgren gave a presentation on MQTT at Def Con 24 and did a follow-up this past year at Black Hat 2017. Among other takeaways from these two presentations is the fact that MQTT is being used in all sorts of sensitive applications and unfortunately there are a large number of improperly secured MQTT endpoints exposed on the public IPv4 internet.
In order to understand the current and future exposure of MQTT on the public internet, a few months back we put together a Sonar study for MQTT. We’ve been running it monthly against the plaintext (1883/TCP) and TLS-wrapped (8883/TCP) MQTT endpoints.
Sonar’s MQTT study, like the protocol, is very simple. It first locates all public IPv4 nodes with the respective port open with zmap.
Analysis with just this data is deceptive, as for almost any given TCP port you can guarantee that there are millions of public IPv4 addresses listening on that port offering all manner of oddball services. Simply looking at 1883/TCP vs 8883/TCP exposure, we see 3.6M and 3.3M supposedly open endpoints. For the sake of completeness, we did a country-based analysis of 1883/TCP and 8883/TCP combined and saw what we usually see: the United States is high on the list along with an assortment of other technologically adept countries. The table below shows the number of unique IP addresses exposing one or more of the MQTT ports, by country:
count country ------- ------------------------ 1921228 United States 531055 China 333047 Australia 235019 Canada 206429 Hong Kong 110908 Israel 108924 Denmark 92119 France 88686 United Kingdom 70901 Mexico 62693 Japan 51452 Korea, Republic of 33660 Spain 27706 Finland 25994 Russian Federation 24901 Romania 15965 Germany 14237 Netherlands 13949 South Africa 13505 Taiwan
For every IPv4 address claiming to have the given MQTT port open, the study then establishes a connection and sends an MQTT Connect message. While the MQTT protocol does support authentication at this step, our study utilizes anonymous authentication, which is to say that no credentials are specified. Responses are inspected and those other than valid connection acknowledgments are discarded. In this way the study is able to identify endpoints that are truly speaking MQTT and provide additional insight into how the MQTT broker might be configured.
Repeating the same simple counting and grouping exercise from before, but on this new dataset, we observed nearly 36,000 MQTT speaking endpoints on 1883/TCP and just over 10,000 on 8883/TCP, a far cry from the 3 million+ found on each endpoint previously. This indicates that the majority of the things listening on MQTT endpoints on the public IPv4 Internet are not actually speaking MQTT at all. By country, we see a similar smattering of countries but with significantly smaller numbers:
count country ------- ------------------------ 9163 China 8864 United States 3035 Germany 1506 Netherlands 1414 Taiwan 1311 Japan 1291 Singapore 1284 Korea, Republic of 1265 Ireland 1252 France 1179 Brazil 970 United Kingdom 937 Hong Kong 601 Vietnam 579 Australia 547 Canada 530 Russian Federation 524 Sweden 522 India 423 Italy
A final lensing by the registered owner of the IP address exposing the MQTT service looks like this, and it comes as no surprise that large cloud hosting providers dominate:
count organization ------- ------------------------------------- 5016 Hangzhou Alibaba Advertising Co.,Ltd. 4967 Amazon.com 1246 Microsoft Azure 1162 Digital Ocean 849 Vivo 835 HiNet 658 OVH SAS 624 Google Cloud 503 SmarTone Mobile Communications 496 Amazon 491 Tencent cloud computing 446 SingTel Mobile 427 Viettel Group 402 Korea Telecom 365 Amazon Data Services Ireland Limited 348 DigitalOcean 345 SoftLayer Technologies 342 Comcast Cable 329 Linode 317 A100 ROW GmbH
In the connection acknowledgment responses, one field is used to indicate if the connection was successful or not, and if it wasn’t, what might have been the cause. Ignoring, for a moment, the two different endpoints, if we analyze the result codes of the connection acknowledgements across endpoints, we can make the following observations:
count result ------- ---------- 25893 Connection accepted 11081 The Client is not authorized to connect 3778 The data in the user name or password is malformed 443 The Server does not support the level of the MQTT protocol requested by the Client 280 The Network Connection has been made but the MQTT service is unavailable 209 The Client identifier is correct UTF-8 but not allowed by the Server 22 Unknown or proprietary response
Repeating this process against just the plain-text 1883/TCP port:
count result ------- ---------- 24665 Connection accepted 7408 The Client is not authorized to connect 3120 The data in the user name or password is malformed 202 The Network Connection has been made but the MQTT service is unavailable 158 The Server does not support the level of the MQTT protocol requested by the Client 41 The Client identifier is correct UTF-8 but not allowed by the Server 16 Unknown or proprietary response
And again against just the TLS 8883/TCP port:
count result ------- ---------- 4932 The Client is not authorized to connect 2775 Connection accepted 1979 The data in the user name or password is malformed 299 The Server does not support the level of the MQTT protocol requested by the Client 169 The Client identifier is correct UTF-8 but not allowed by the Server 103 The Network Connection has been made but the MQTT service is unavailable 18 Unknown or proprietary response
Some takeaways from this:
- Better than 70% of the plaintext MQTT endpoints require no authentication and have no immediately apparent security restrictions in place.
- More than half of the TLS-wrapped MQTT endpoints require authentication or are using some manner of security restrictions such as IP or client ID based limitations. This is a good thing.
Examining our globally deployed fleet of honeypots for any activity on 1883/TCP or 8883/TCP, it was no surprise to see the evidence of Sonar and other internet scanning projects in there. However, beyond these activities, there is only minimal background noise on these ports on the order of a few hundred unique connections per month, the vast majority of which don’t ultimately attempt to speak MQTT.
Even though the protocol has been around for a considerable amount of time, as mentioned earlier there has only been minimal coverage of this protocol from a security perspective.
Given MQTT’s use in IoT and the rise IoT, I figured it prudent to jumpstart additional work in this area with Metasploit support for MQTT. As such, I’ve added an MQTT connection brute-force module in
metasploit-framework PR #9330 that will identify MQTT endpoints and attempt to brute-force authentication if it is discovered to be in use. Also in that PR I’ve provided documentation on how to configure a mosquitto MQTT broker for purposes of testing the module and exploring MQTT. Additionally I’ve provided a mixin to ease development of future MQTT modules in
metasploit-framework PR #9329 that is now available for use as of becc05b.
Some ideas for future MQTT modules or research include:
- Client ID brute forcing
- Fingerprinting and information leakage through
$SYSand wildcard topics
- Evaluating the security capabilities of MQTT broker implementations
Are you interested in MQTT? Have ideas for future research? Comments? We welcome feedback and collaboration, so please feel free to reach out to us via the comments below or via email.