Last updated at Thu, 08 Aug 2019 17:32:27 GMT

Yankee Swap and the White Elephant are popular, simpler, cheaper and entertaining variations on holiday gift giving.

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.

Primer

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 temperatures/<location>/<sensor_num>, where <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 + and #, 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:

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.

Exposure

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.

Exploitation

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.

Exploration

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 $SYS and 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.

Cheers!

Read the rest of our HaXmas series here, or wander through the archives of Sonar and Heisenberg studies past.