Listen and subscribe to our new podcast! Tripwire’s cybersecurity podcast features 20-minute conversations with the people who protect people from cyber threats. Hosted by Tripwire’s VP of Product Management and Strategy, Tim Erlin, each episode brings on a new guest to explore the evolving threat landscape, technology trends, and cybersecurity best practices.
https://open.spotify.com/episode/6g5mStVl3nl2asqWt1XDhh?si=TyqRU_zQRL61djdKmhzo5Q
Spotify: https://open.spotify.com/episode/5wXKv9DiQjfsZNf6heXg67
Stitcher: https://www.stitcher.com/podcast/the-tripwire-cybersecurity-podcast
RSS: https://tripwire.libsyn.com/rss
YouTube: https://www.youtube.com/playlist?list=PLgTfY3TXF9YKE9pUKp57pGSTaapTLpvC3 The following is an edited excerpt from a recent episode of Tripwire’s Cybersecurity Podcast.
Tim Erlin: Welcome to Tripwire’s Cybersecurity Podcast. I am Tim Erlin, VP of product management and strategy at Tripwire. Today I am joined by Craig Young, principal security researcher with the Vulnerability and Exposure Research Team at Tripwire. Welcome, Craig.
Craig Young: Thank you, Tim
A MQTT Primer
TE: Today we’re going to look at MQTT. Craig, why don't you just start by telling us what MQTT is and why are we talking about it?
CY: Sure. MQTT is a very lightweight messaging protocol that allows entities of different types that have different network connections to talk to each other but without having to maintain direct communication links. So the MQTT broker here is actually going to be directing messages between publishers and subscribers.
One way you can kind of think about this as like a TV broadcast scenario. So with the TV broadcast, you've got TV stations who are putting out content in MQTT. They would be publishing content, and this data gets out there for anybody to receive it who wants to tune in or subscribe to the right channel—or in MQTT terminology, it would be a topic.
But it also goes beyond that because unlike a TV broadcast, anybody that's participating on this network can commonly just feed data back into it and publish their own messages onto whatever channel they want and/or create their own channel.
TE: So, let me make sure I understand the model. If we take an example of a network-connected light bulb, the light bulb itself would be the subscriber, right?
CY: Yes, but they would also actually be publishers, as well. The light might want to provide feedback onto the MQTT broker when somebody has physically turned off the device. That way, other assets that are connected could reflect that change of status.
TE: You've got subscribers and publishers and an object or a node on the network that can be both. Where does the broker fit into the scenario with the light bulb?
CY: It would be like a server that's operated by the company that sold you the light bulb.
TE: So, in the light bulb scenario, it's not just that I'm getting network-connected lighting in my house. It's that I'm connecting the light bulb in my house through a publish-and-subscribe system to some external entity run by the company that produced the light bulb.
CY: Yes. The advantage for you for this is that you can now have a much easier time sending a message onto the network to control that light for you without having to actually tunnel a connection back to your light bulb.
TE: Right. As a result, I can make sure that my lights are turned on or off when I'm not home because the light bulb is available via a cloud-based or internet-connected system.
CY: That’s correct. The broker is just making sure that it's tracking who's subscribed to all the different topics. So, the different nodes on the network are able to get all of the information they're expecting that's relevant to them.
The Security and Privacy Issues Surrounding MQTT
TE: As you mentioned, the security in these cases can be somewhat lacking. There's the ability to publish or subscribe to topics without actually being an authenticated user. Is that the right way to think about it?
CY: Yeah. By default, you're not getting authentication controls in MQTT environments. This is up to the implementer to establish what guidelines for authentication and isolation between the different nodes on the network need to exist.
TE: I see. It's not that the protocol itself is flawed. It's that the implementation hasn't adequately considered security in many cases. So, from a research standpoint, you're looking at examples where that implementation is more open than it should be. That allows a malicious actor to publish and subscribe to the topics. That’s hardly life-threatening in the example of light bulbs. But you started to give other examples of where MQTT is being used. What are some of those?
CY: When I'm scanning the Internet now and looking for what types of servers are exposed out there, I'm mainly seeing quite a lot of things that are actually just DIY people, which is probably low risk. But then there are also what appear to be vehicle fleet trackers and stuff like that. Which might be businesses that are tracking logistics shipments. Some are taxi dispatch services. I've been able to correlate these systems to one or two ride sharing apps throughout the world. Also, building controls are being put onto these systems in potentially unsafe ways. So, I found that a very large provider of office space had their building controls exposed. It was making it so that I could see what people’s names were when they swiped into their different facilities. For all I know, I could have injected messages back into that network to cause doors to open or to stop alarms. In that case, I was able to reach out to the organization and help them with that problem.
TE: It’s worth pointing out that when you find this kind of an issue, you disclose it to the vendor and look for their cooperation and remediation, right?
CY: Yes, definitely. Whenever possible. And there are a lot of organizations that I'm currently just waiting for responses from. I've repeatedly reached out to several of these organizations. Some of them have taken down the servers without getting back to me, but others seem to be not getting the message.
TE: I know what you mean. We're now crossing this security and privacy divide where there's definitely a trend around the world towards increased legislation around privacy. We have implementations of MQTT that have significant privacy disclosure problems, as well.
CY: Yeah. And something that came to my mind is how this interacts with GDPR.
TE: That's a great example of an up-and-coming privacy regulation. I don't think we've seen an example where GDPR has been used quite like this. We've seen breaches that have GDPR implications. And I suppose this could be similar to something like an unprotected S3 bucket. It’s another unprotected resource where you can't validate if somebody's taken advantage of it, but you counted it as a disclosure.
CY: Yeah. So, I guess it is a big question on how you classify when a breach has actually occurred and when the disclosure is necessary. But certainly, it would seem that if an MQTT data stream is going to be revealing locational data and/or email addresses or IP addresses of people within regions that are covered by different privacy laws, it should be a breach.
Course of Action for the Future
TE: Well, Craig, you pointed out that this isn't a new problem. It's one that that existed in the past, but your research has shown that it's still a problem or it's potentially getting worse in terms of connected MQTT systems. I think the hard question that we have to ask is what we're supposed to do about it other than finding each and every instance and reporting it to a vendor.
CY: For our listeners who work at an organization that is employing MQTT technology, I would implore you to research this further and make sure that you are using appropriate access controls.
But of course, most of these systems are not going to be controlled by people who are getting these messages. So, it's really a challenging problem. And I think it's very similar to the problem of what do we do about these mass numbers of IoT devices with hard-coded passwords. Is it appropriate that governments need to step in and start kind of being cyber police forces and giving citations to organizations not based on reports of breaches but based on actively identifying security weaknesses and exposures?
I don't know if that's the future. I really don't want that. It certainly feels sometimes like this is an intractable problem.
TE: Well, we've certainly seen compliance standards and some legislation that's aimed at driving a low bar around security and security configuration. But something like MQTT is too narrow to show up in that kind of a standard. How do you create a compliance regulation that casts a wide enough net to capture this MQTT situation but that’s so narrow that it's impossible to enforce?
CY: You have to go after the description of what the types of data that are being exposed or what the types of control that are being exposed might lead to as well as things that have public safety impact like these power grid accessories. With consumer products, I guess you've got other options, as well, like these cyber UL proposals. So, the idea is generally that we're trying to make sets of standards like these baselines but kind of making it so that consumers will have a way of looking at whether or not a product has done their baseline due diligence.
TE: I don't think we're going to solve this problem in this conversation, but the research is certainly interesting. Thanks for joining us, Craig.
This again was Tripwire’s Cybersecurity Podcast. I hope it was interesting for you, and I hope you join us for the next episode. Thanks.
