CyberWire Daily - An IoT educational exercise reveals a far-reaching vulnerability. [Research Saturday]

Episode Date: September 18, 2021

Guest Jake Valletta, Director of Professional Services at Mandiant, joins Dave to talk about the critical vulnerability Mandiant disclosed that affects millions of IoT devices. Mandiant disclosed a critical risk vulnerability in coordination with the Cybersecurity and Infrastructure Security Agency (“CISA”) that affects millions of IoT devices that use the ThroughTek “Kalay” network. This vulnerability, discovered by researchers on Mandiant’s Red Team in late 2020, would enable adversaries to remotely compromise victim IoT devices, resulting in the ability to listen to live audio, watch real time video data, and compromise device credentials for further attacks based on exposed device functionality. These further attacks could include actions that would allow an adversary to remotely control affected devices. The research can be found here: Mandiant Discloses Critical Vulnerability Affecting Millions of IoT Devices Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. of you, I was concerned about my data being sold by data brokers. So I decided to try Delete.me. I have to say, Delete.me is a game changer. Within days of signing up, they started removing my personal information from hundreds of data brokers. I finally have peace of mind knowing my data privacy is protected. Delete.me's team does all the work for you with detailed reports so you know exactly what's been done. Take control of your data and keep your private life Thank you. JoinDeleteMe.com slash N2K and use promo code N2K at checkout. The only way to get 20% off is to go to JoinDeleteMe.com slash N2K and enter code N2K at checkout. That's JoinDeleteMe.com slash N2K, code N2K. Hello everyone and welcome to the CyberWire's Research Saturday. I'm Dave Bittner and this is our weekly conversation with researchers and analysts

tracking down threats and vulnerabilities, solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. So initially, we had no drive for this protocol in general. So we really were looking more at just smart cameras from a higher level. And we kind of stumbled upon this doing just some independent research. That's Jake Valletta.

He's Director of Professional Services at Mandiant. The research we're discussing today is titled Mandiant Discloses Critical Vulnerability Affecting Millions of IoT Devices. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust plus AI stops attackers

by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management

with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com security. One of the individuals who was part of the research team was fairly new to the company and expressed an interest in getting into embedded security. So we thought, hey, let's go out, let's get some cameras as a way to do an educational exercise, and let's see what we can find. So we started actually looking at some of the security of the cameras that we were looking at themselves, and we encountered this protocol and this network while doing that research. So it kind of caught our eye once we started digging into a technical level and saw this traffic that

looked pretty unique, and it was exciting for us because it, you know, doing some quick searches online, it wasn't really turning up any results or any immediate, you know, parsers or things to understand the protocol. So that got us excited to actually look into the protocol. And then from there, it ended up just being, you know, some research on our side over the course of several months to learn more about the protocol. And then ultimately led to, you know to the disclosure that we published earlier this month, or last month, rather. Now, the protocol we're talking about here is from an organization called ThruTech, and it's their Calais network. Can you give us an overview of exactly what's going on

with this protocol? Yeah, sure. So the protocol is designed to be very easy to use for companies that want to develop and sell IoT products. So one of the examples that we've seen is smart cameras, right? So let's say you're a company who's building a smart camera, and you have a lot of things that you want to focus on. you want the branding, the aesthetic of the device, maybe the functionality and the camera on the unit. But one thing that's really important is being able to connect the cameras to a smartphone or maybe a desktop application.

And that can be a challenging engineering problem for someone to reinvent. So what the Cali protocol allows is for you to basically use the network that ThruTech has built to take that out of the equation for your development purposes. You essentially would use their protocols and use their network, and you don't have to think about the implementation. It just kind of works, right? So it's very attractive to these companies who want to build cameras because it's one less thing that they have to worry about. And in our experience, it does work very well from a user standpoint. It's

fast, it's snappy, the camera feed looks good. So it's one less thing that these developers have to worry about. So they provide the developers with an SDK that they build in. And I suppose that the folks who are building this hardware would tend to think that this would be secure being on as many devices as it is. But you and your colleagues discovered some issues here. Yep, that's correct. And there are, you know,

there's a lot of different versions out there in the wild. And I think, you know, there's some older devices which were on more earlier iterations of the platform. I think over time, older devices which were on more earlier iterations of the platform. I think over time, ThruTech has added features and security controls onto the platform to just make it more robust. But at the end of the day, it really does depend on the OEMs and the people building these devices to stay current and build in the latest version of the SDK as new versions come out.

Well, walk us through the vulnerability that you discovered here. What exactly is going on? Sure. So the vulnerability that we disclosed is essentially device impersonation. So through our research, we discovered that basically when these devices need to access the network, if you have a camera sitting in a house somewhere or some smart device somewhere, it needs to register itself onto the network so that when I open my phone, I can very easily find that device and then establish the connection, thus using the protocol. And what we found is that the way that the registration works is it's really only requiring a single piece of information to actually register and join the network. And that piece of information, as we highlighted in our blog, is what's called the UID. It's essentially a randomly generated string that's assigned to a specific device, right? So if you have 10,000 or 100,000 devices in your fleet, each one of them is going

to have a unique UID. And that's the piece of information that gets you on the network. So with that ID, your device will register on the network. And then whenever somebody wants to connect to you, they would find you using that ID. And that's how the protocol is able to work so effectively and so quickly is it's just looking up on their side where that ID lives and making the connection and facilitating the conversation if needed. And what we found is that, you know, because that's the only piece of information, that makes it dangerous and risky for an attacker to be able to, you know, one, obtain UIDs and two, you know, then use those IDs to stage a more serious attack, right? So what we found in the issue, again, is device impersonation,

is that we can masquerade as a device. So if we have an ID for a victim or just anyone, any camera we want to masquerade as, we can register on the network, and maybe it's just a Python script. But the end result is whenever someone attempts to connect to that ID, instead of connecting to the real device, they're actually going to connect to us. And the impact here is when they connect to us, by they, I mean the mobile application, will then attempt to authenticate to us because we are essentially the device. So they will send a username and password for the camera or whatever,

and then we can capture those as an attacker. Once we have those creds, we now have all three of the pieces of information, the UID, the username, and the password to be able to then connect to the real device using the Kali protocol, right? So we can then connect to the actual camera and then initiate a connection to say, do the video or listen to audio or access some of the functionalities that are available past authentication. So that's really at the heart of it, what the issue is here, is being able to impersonate devices and obtain materials that can be used to access sensitive data. And how do you insert your spoofing device onto the network in such a way that you supersede the actual device? Basically, the way the protocol is designed is at the core, it's essentially a peer-to-peer network. So it's meant to allow various nodes to connect, most of the time, directly to each other, right? So let's say I'm in a coffee shop and a camera is sitting at a house. When I'd like to connect to that camera,

I will reach out to the Kali network and say, I'm looking to connect to this UID. Can you help me? And the Kali network will make a determination based on the various network topologies that we're both sitting in and say, okay, you two can both communicate directly. Here's the ports and IPs you need to use if you'd like to communicate directly. So it'll essentially broker that peer-to-peer connection for the parties. Or if the network topology doesn't allow that for some versions of NAT or something, it will actually act as a relay server to get the data to and from the two parties. So what this means is, if I'm masquerading a device, right, I'm registering a particular device on the network, the servers only remember or know of

one device. So let's say there's a device plugged in, and it is beaking it out, you know, maybe every minute or so saying, hey, I'm here, log me in, register me. If I'm an attacker and I come along and I start registering over that device, well, the servers get confused and then they think that I'm the actual device. So that when a user attempts to find the real device, because of that peer-to-peer nature, it's going to then provide the details to the both parties, which is me, and not the actual device sitting in the home. So it's unfortunately the server is maintaining essentially only one device in their memory

instead of realizing that there's a new device interjecting itself is what's causing the problem here. So I mean, to help make sure I understand correctly, I mean, the fundamental issue here is that UID is really the only thing that tells the network that that device is what it claims to be. There's no secondary method of verification. Yep, that's correct. And in some of the mitigations on the platform, and if you read through the blog and the disclosure that we put out, the recommendations here are essentially to upgrade to the latest version of the Kali protocol. And what that provides is there's a specific feature that ThruTech developed, and it's called AuthKey.

And AuthKey actually provides an additional layer of security when attempting to connect to a device, which validates that the connecting party is who it claims to be. So it doesn't actually address the fact that you can spoof, but it does mitigate the risk on the other end of it. When an attacker attempts to use it, they will need a secondary piece of information to weaponize the vulnerability. And that's why we've encouraged everyone to upgrade and use this feature because it's really the easiest win here to fix this. And will that work with older devices? I mean, is this a matter of more the protocol within the Cali network itself and not the – I'm thinking if I have an old camera that's been sitting, you know, minding its own business on a shelf somewhere for five or more years, is it going to have to be updated or replaced?

Or will the mitigations you describe work even with an older device? So that's going to depend on the company that's, you know, developing and selling the product, right? They're going to have to produce a new firmware image, which a lot of these cameras in our experience have an over-the-air or a remote firmware update capability. There's nothing hardware specific

that would make it so you couldn't do this, right? In our research. But they would need to build a new firmware image with this updated version of the software, as well as using the off-key. So there would be some changes that would need to take place for manufacturers of these devices to be able to actually secure themselves with off-key. Well, you mentioned some of the remediations. Can we go through that specifically? What are you and the team recommending here for folks to take care of this vulnerability? Yeah, we have a whole series of recommendations to try to kind devices that they upgrade to the version of the Kali protocol, which provides the off-key feature.

So that's probably first and foremost, make sure the platform is using the security features that are available to them to reduce the risk of this particular vulnerability. vulnerability. Now, the second thing that we want, and this is maybe more or less for the manufacturer of the devices, but more for the companies that sell them, is a lot of the way that this system's architected is your mobile device needs to obtain that UID somehow. I'm Jake Valletta, and I have a smart camera, and I'd like to talk to my camera remotely. Well, my mobile app needs to get that UID so that I can then connect to that camera using the Kali network. So it's going to obtain that UID somehow, usually using a web API. What we found is, you know, there's oftentimes an API on, you know, companywebsite.com forward slash get UID or something. And that's fine, but you need to

make sure that that API is developed with, you know, the best security you can. There can't be enumeration, there can't be brute forcing abilities there. You really need to make sure that that API is secured adequately, because you can think of a doomsday scenario, which we kind of played through in our heads is, you know, what if you had a company that manufactures a particular model of device, let's say they have hundreds of thousands of devices out there in deployment, what happens if they have a weakness in their API which leaks UIDs, and I can somehow obtain all the UIDs for a given model?

Well then, due to the nature of this vulnerability, I can potentially intercept any one of those connections by just launching the attack with a given UID. I don't know who they are, maybe, but once I have all them, you can potentially exploit this in mass to do a lot of bad things there. So that's something that we really recommend, too. And we put that on the blog, making sure that that API security is really crucial to this.

And then the last thing is really more of a hardening practice. So one thing we notice is it a hardening practice. So, you know, one thing we notice is it's not just the network here, right? These are cameras that are IoT devices, and they have the, you know, level of IoT security that we've seen consistent with other devices in the world, right? So a lot of these devices are running as, you know, a privileged user for all processes are running privileged. They're not using the latest kernels for Linux. They lack hardening features, specific bits and platform independent execution. So all these security hardening things, which you'll see in, let's say, a modern Linux operating system, not all of these are being used in these smart devices.

So thinking back to the attack, right? If someone's able to perform this attack, it allows them to connect to your camera. Okay, that's bad. But as I mentioned, it's written in the blog, there's a lot of functionality that you can access after you've logged in, right? So things like, you know, rebooting the device or obtaining metadata from the device is all accessible over the Kali network. And sometimes even remote firmware updates are available once you've authenticated. So all these hardening features that we recommend on the device are really important for further attacks, right? So if I'm able to, you know, establish a connection to a

camera out there, you want it to end at being able to view audio and video. Of course, you don't want that. But me being able to do something trivial like a buffer overflow and cause a remote code execution as the root user, well, now I have a shell in your house using this protocol, and now the attack is much bigger, right? So there's some other things that can be done on the camera side and unlike the hardware itself, and making sure that the software that's installed on there is as modern as possible. So those three things together are what we're recommending that the manufacturers and the developers of these devices will use and do to mitigate this. devices will use and do to mitigate this. Now, the UIDs themselves, are they complex enough that they're really resistant to brute forcing?

So they're fairly long. They're actually 20 characters long. And in our experience, and this isn't the full analysis of it, but we did not see an easy avenue for brute forcing. It's a fairly large key space, and they do appear to be random. It wasn't very obvious to us that the first four bytes are the manufacturer, the second three are the year. They do appear to be random, and it, the full A through Z and numbers. So it's a fairly large key space. And we did some preliminary analysis and determined it'd be

infeasible to collide very reliably. So that was not something we fully explored, but we did notice based on the key space, it would be a challenge for someone to carry out. You know, I'm curious, Jake, you mentioned at the outset that you sort of took this on partially as, you know, kind of an educational sort of thing, a what if. For you and your team, I mean, how often do you head down this path? And I guess when you head down a path like this, are you expecting to find vulnerabilities? Is that more likely than not what you're going to find when you start down a journey like this? Yeah. I mean, you know, for us and my team, you know, we are professional penetration testers. So this is, you know, sort of an

augment to our role, right? We do this professionally for clients day in and day out. And we more often than not do find vulnerabilities in the work that we do. And I would say on these side projects, they oftentimes do yield pretty exciting results. This one, I think, more exciting than some of the other recent ones. Sometimes you maybe don't find anything that's as exciting as this, but the goal in our mind is to see what's there and what we can find, whether it's vulnerabilities in, you know, the UDP protocol that it's using to talk to on the network or device or vulnerabilities in the software. You know, it is the goal. And I'd say the team is quite successful. And it's there's a lot of passion for us to be successful. It's a good energy, I think.

Our thanks to Jake Valletta for joining us. The research is titled Mandiant Discloses Critical Vulnerability Affecting Millions of IoT Devices. We'll have a link in the show notes. affecting millions of IoT devices. We'll have a link in the show notes. Cyber threats are evolving every second, and staying ahead is more than just a challenge. It's a necessity. That's why we're thrilled to partner with ThreatLocker, a cybersecurity solution trusted by businesses worldwide.

ThreatLocker is a full suite of solutions designed to give you total control, stopping unauthorized applications, securing sensitive data, and ensuring your organization runs smoothly and securely. Visit ThreatLocker.com today to see how a default-deny approach can keep your company safe and compliant. can keep your company safe and compliant. Thanks for listening. We'll see you back here next week.