Topics:
Rapid7 Principal Security Research (IoT) lead Deral Heiland joins the Nexus Podcast to discuss work his team did on how attackers might weaponize cellular-based IoT.
Rapid7 conducted three phases of this research, with the most recent digging into how attackers with access to these systems can abuse them to gain unauthorized access, potentially exfiltrate critical data, or pivot into backend network infrastructure.
MIMOSO 0:14
All right, welcome back to the Nexus Podcast. Dural Hyland is my guest. Durall is the principal security researcher for IoT for Rapid 7, and he's been part of some great research on exploitable weaknesses in cellular enabled IoT. So that's what we're going to talk about. How are you? I'm doing good. Yourself? I'm doing good doing good. Great. Glad we uh can do these face-to-face. I do a lot of these remotely, so it's always better. These are a lot better. Um good to meet you. Um tell me a little bit about your day-to-day, your background.
HEILAND 0:46
So as a principal security researcher uh on IoT, I'm obviously the focus is embedded technology, IoT technology, and it's around uh discovering uh security issues, vulnerabilities, you know, uh failures within the ability to uh deploy these technologies. Yeah. Trying to always come up with methods, methodologies for us to start thinking about risk in those environments. Because if we don't know about the risk or potential risk, we can't really mitigate them. So the goal is to discover those type of things. Sometimes it's deep dive into hardware like this research was. Others it's it may be high level on how you deploy and and uh maintain and manage those technologies and decommission them and things like that. But the ultimate goal is how do we deliver better security? And that's where the research always meant to go. Or we also uh focus a lot of the research around testing methodologies. Yeah. So uh pen testers that do IoT technology testing will have uh methods, methodologies, and the ability to look deeper and further into the products.
MIMOSO 1:53
Right. So this is feels really niche though, and I know this is kind of like part three of this overall research project. Is that fair to say?
HEILAND 2:00
Yes, it is. Yes, it is.
MIMOSO 2:01
So um what what was the initial motivation to look at this? Okay.
HEILAND 2:07
So yeah, so uh start looking at uh cellular-based IoT, we were seeing this trend. You start seeing more and more devices have cellular for back-end communications out to the internet or to back-end networks, devices, everything from medical wearable devices, cars, transportation, they all have telemetry units, it's cellular, and they call home. Uh we also, you know, I was out to CES this year, and you see this massive increase in in autonomous robotic systems that have to communicate out, and they often have cellular technology. And also there are pen testers. We're starting to engage more tech that had cellular in it. And the goal was to get past that. Hey, there's a cell module, but you know, I can't see you know the communications, it's encrypted, it's FCC regulated. How do I know what's flowing through that line? And that's where we got into the idea of interchip comms. Let's start looking at that communications between the main CPUs or MCUs that exist on IoT technology and the actual cellular module and start analyzing that. And then that led to hey, can we send data into that? Can we control the cellular module? What can we make it do? How's it work in detail? Yeah. And how to leverage that in our testing or how someone would leverage it in attacks.
MIMOSO 3:24
So before we talk specifically about the research, like w for in a factory setting, for example, what would something, you know, what would cellular-based IoT be handling or I think in a lot of cases uh a lot of these places have uh remote sensors.
HEILAND 3:39
Like if you have gas pipelines or or things like that, you may have a lot of sensors that collect telemetry data and send it back over the cellular to things uh but often it's the uh remote devices that don't have the ability to have an Ethernet connection or standard Wi-Fi connection because of the distance. Uh is probably the key thing. Any environment would have that. You m might see cellular being implemented.
MIMOSO 4:03
Right. And so they're interacting obviously with the cloud or some kind of IT service before, you know, in order to ship that data through.
HEILAND 4:11
So yeah, in some in some cases, these devices uh they they could actually use like uh private 5G or something. That's something we've seen in advance of. So you may have sensors that have that ability to go straight back into your corporate network. You may have ones that go out through um uh very direct private APNs that go VPN into a network, and then you have some that connect right out to the internet, they may connect to you know the standard S3 bucket, they may do uh MPTP uh controls out to the cloud, cloud services, and things that are actually on the internet. So you have a whole gambit and the and the risk of those vary from hey, is it going to the internet, is it going to a private network? Right. The big difference between the risk model that could exist there.
MIMOSO 4:54
Okay, so while before we talk about this phase of the research, which is involves weaponization of the previous two, kind of walk me through from a high level the the first two kind of uh segments of this research.
HEILAND 5:05
So the very early research probably started like six years ago. Okay, where we were looking at devices and an IoT device, and I'm like, I really want to understand the end-to-end security. And if we're doing, let's say, for example, uh not cellular base, but let's say we have a device that has a bridge and you connect to it with various RF, it could be Zigbee, Z-Wave, uh, you know, pretty much Bluetooth, Bluetooth, low energy, things like that. What if that's all encrypted? It's really hard to see it, it's difficult to really find out what's going on there if it's done right. And if it goes out the other end over Ethernet or Wi-Fi and they're crypting it there, those are good security models. But now as a tester, I don't really have the ability to see that whole security model from end to end. But we found out if I analyze the chip communications on the actual board between microprocessors, the communication modules and the main CPUs, I can glean tons of data on how this device handles all of its security in the background. And that was the first phase. And then it progressively went, as we've seen cellular technology, to that next phase. It's like, okay, now we have cell devices in here, cell modules in these, how do they work? I had no clue how they work, didn't know anything about them. So that was their challenge. How do these things function? So we got data sheets, development boards, devices with cellular modules in them, pulled down all their AT command manuals, how do they take commands? How do they programmed? How are they controlled? How do the CPU talk to them? And we built all of that knowledge. Once we figured out how we could talk to them, the next thing was how do we connect to them? So then we get into the hardware hacking. How do we do it over USB? How do we do it over serial? And then, okay, now that we can connect to them, now we know the command structure, let's start sending commands, let's start asking them to carry out functions for us. Let's start telling them, like, hey, start setting up raw sockets, HTTP connections, all of this type of stuff on our behalf so that we can get insight into their whole trust relationship. Who trusts them and at what level do they trust them? And is there shared trust between different devices? A company produces 10,000 devices and they sell it to, you know, 5,000 people. Now, all of that is a big ecosystem. Now these devices should not share data. We would expect them not to. But how do we know they don't? How do we know they don't have a shared trust? We don't know unless we test it. So that's where we got to the point is like, let's build the methodologies so that we can validate those trust associations and see if there is issues. And then start talking about well, if there are issues and we encounter them, we can now mitigate them because we can understand and we can test for them.
MIMOSO 7:54
So these are all legitimate functions you're asking it to do and just kind of. So this is the realm of advanced attackers if someone chooses to kind of exploit this.
HEILAND 8:13
Um I think it is, but but but the the the crazy things is there's complete manuals out there on how to talk to these things. Most of the manufacturers produce uh their AT command manuals that have all the command structures, all the syntax on how they work. So if anyone wants to do it, it's it's no different than just learning how anything else works. The data's out there. Spending the time and spending the time. I think the harder part is in some cases more of the hardware hacking. How do I tap into that circuit? How do I interact with that circuit and dealing with the electronic nuances that may be involved in that?
MIMOSO 8:47
And was that prior to this weaponization phase you had to kind of sort that out first?
HEILAND 8:51
Yeah, we we sorted that out first. I think paper two, we got into all those methodologies. It's like, you know, how do we how do how do we interact with this circuit? How do we connect to it? How do we find the circuit? You know, how do we figure that out? So we built these methodologies and then went through a whole complex level. Here's the easiest way, but what if that doesn't work? What do we do next? Well, we pull the we pull the board off, um, you know, pull the module off the device and then wire in our own circuits, put the module back on. Now we have access to those communication lines. It's gone down to the point where it's like, hey, what if I look at this module, I turn it up on edge, and I can see the land grid arrays around the edge of the up underneath the chip. Can I use acupuncture needles and actually insert acupuncture needles up under the body of the chip? You went deep. So we did that and that worked. Uh and then was like, okay, uh, what if all of that fails? And then we start going, okay, once we map out the structure of the board and where the most common locations may be for these circuits, and if they're not on the surface of the board, they're in one of the sublayers. How do we cut into the board? So we sacrifice the board and we start delaying sections of it until we'd find these runs. And once we found these runs in a pinpoint place we can penetrate through there, then we can actually take a functioning board, do those penetrations, tap into the communication circuits in the sublayers of the board. So we took it from the most easiest finds all the way to what if all of those fails, all the way to the complex. And we tested every one of those methodologies in the lab to see how viable it was.
MIMOSO 10:25
Right. So take me into the current research, the weaponization part of this. First of all, are you seeing any types of attacks in the wild that might be kind of leveraging any of this?
HEILAND 10:37
Not in this capacity. Not yet. Not yet. It doesn't mean they don't exist.
MIMOSO 10:43
Sure.
HEILAND 10:44
Uh because because obviously you're in the device, you're communicating on its channel using its trust association, may not easy to spot.
MIMOSO 10:52
Right.
HEILAND 10:53
And you know, it's the device just communicating normal.
MIMOSO 10:55
Right. Um I mean, depending on the industry, there's a lot of value to something like this for an attacker or I would assume. Exactly, exactly. Yeah. Um okay, so uh uh start with the trust relationships. Kind of explain what you mean there in terms of like is it just kind of uh a native trust between the Yeah, I mean we'll start off, we'll start off with the most simple.
HEILAND 11:16
Sure. So a lot of consumer devices don't go into a private network. They connect out to the cloud, they connect to like S3 buckets. Um and and we can we can assume we we can make assumptions that that's done correctly, but there may be devices that actually share S3 buckets or back-end storage in the cloud. Okay. That means the device that I purchased looks like it's functioning normal, it's authenticating out. Because we the goal with this was let the device do all of the authentication for us and just use it as a tunnel to get in it. So, how are these how are these devices connecting out there? Are we failing at that machine-to-machine comms? You know, that's like, hey, it's just a machine talking to another machine. What risk is there? There's no humans in there. So we inject us humans into it, into that, and then it's like, what can it connect to? You know, it's let's say it connects to an S3 bucket, it dumps everything out of that S3 bucket, and I'm looking at a single device, and it connects out to the S3 bucket, it authenticates, it's trusted now, it starts putting stuff out there. Is that S3 bucket shared with any other devices? And we you don't know that until you have that insight into it. And then you have the ability. We wrote uh basic proof of concept code that would actually enumerate S3 buckets through the device for us and do brute force looking for stuff.
MIMOSO 12:46
Just looking for uh stuff.
HEILAND 12:47
Yeah, looking for stuff. That's that's one of the more simple examples. The more complex example is some of the higher-end devices, uh, transportation, autonomous robots, maybe medical devices. Right. There's even certain um industry-level tracking devices that are fleet tracking systems that don't always attach to the internet directly. Uh they actually tack to uh attach to like a private APN, which is basically a VPN connection into an internal network.
MIMOSO 13:16
Okay.
HEILAND 13:16
So if they connect into an internal network, has good security been done? That means this device can only talk to a certain port on a certain device. That's not the case because of that machine-to-machine trust being over-elevated. Now I can pivot through into that internal network. Now I can actually start running port scans on the internal network. We've written SOX 5 proxies that'll communicate from a laptop through serial to these devices and connect out. So then you can run tools like Metasploit and stuff like that against these environments. So it's that it's that whole trust of uh the trust relation here is this device has access. Right. What it has access to may vary, maybe simple, not a risk, all the way up to extremely high risk. But that device inherently is trusted, either through its authentication mechanism or just by what it is.
MIMOSO 14:11
Yeah. And is that necessary or is it just a matter of convenience on the development and implementation side?
HEILAND 14:17
It's a matter of convenience. You know, we want to get a product up to market. Let's make this work, and not considering the potential security implications of that shared trust.
MIMOSO 14:28
So the device is basically the attack vector to move further onto the service. Got it. Okay. So what's possible when an attacker achieves this kind of access and and okay, we'll take the worst case scenario where I mentioned a private private APN, uh, where it's connecting into an internal network.
HEILAND 14:49
This device is trusted in, no one's paying attention to it, it's just doing its thing. Uh we've developed tools because we want all proof of concepts on this, that gives us the ability to uh, as an example, through the serial port. It turns out that cellular modules, the ones I've looked at, or MB MB IoT class and LTM class modules, have two channels. They have a USB channel and a serial channel. Those two main two channels communicate to the actual cellular module and configure it, set it up.
MIMOSO 15:23
Yeah.
HEILAND 15:23
And they also push all the data through them from the main CPU. The thing is, is only one of those is used. The other one's wide open, and it's not one sitting there for you. There's one sitting there. So if you can locate that one, then you can connect to it. The device will continue functioning completely normal. No one will know the difference. And now you have a side channel on the device to set up communication. And as a proof of concept, on this on the serial, we wrote a bunch of tools. One was we wrote a port scanner that would actually do rudimentary port scanning using the raw sockets on the cellular module. We wrote a SOX5 proxy, it allows me to, through serial, fire up a SOX5 proxy and run most of my applications through that with some limitations. The cellular module can only do so many sockets at a time. On top of that, we have the USB channel. So in our case, what we did was we hacked the USB on the device and spliced in a multiplexer, a USB multiplexer. It would let us go two to one. So the one side would actually be the cell module, the two side, one would be the CPU, one would be our laptop. So once we got that working, the device would come up, the host would connect to the device, so the CPU would connect to the cellular module, carry out all authentication, passwords, codes, everything. Connect to the cellular network, connect to the back-end network, connect to any VPNs. We'd throw the switch, it would give our laptop an IP address, and you were just like you were connected to the network. Sure. Fully functioning, every tool worked. And the uh USB on more of the LTM1 devices or LTM devices has what's known as ECM, it's Ethernet control mode. It's an Ethernet port over USB. So your laptop has all the software, at least all the operating system I check. So when it sees this ECM on this device, it immediately uh negotiates USB to Ethernet and gives you And you're in. You're in full access. And that's that's how we developed out our tools as proof of concepts. And again, this this whole tool suite thing is not is one to prove that this attack vector does exist, but also to give tools to people that are testing these products for companies. Now they have elevated tools to be able to interact in circuit to actually test the device security and the trust associated.
MIMOSO 17:52
So in terms of like what an attack would look like, uh is physical access required?
HEILAND 17:57
Yeah, you're gonna have to have one of the devices. So you're gonna have to have one of the IoT devices in your possession. But it's one of what, millions out there? So how much trust is there across the different products, or how much trust is given that device by the cloud, by the S3 buckets, by the uh back-end databases, or the internal networks.
MIMOSO 18:18
Yeah, there could be some serious scale there. Yeah. And is there any way to trigger this remotely or or no, not at this point.
HEILAND 18:25
I I haven't identified any methods to to attack the device. Now, obviously, if you can attack the device and let's say route the CPU on the device, then you would have that level of access to from a remote attack. So if you can attack the device remotely through some other method, whether it's some RF, you know, uh it's done, it has Wi-Fi in there also, because a lot of these devices have everything. You may have Bluetooth, Wi-Fi, and cellular capability. If you happen to have a case like that and you have a vulnerability on the device, physical access may not be needed, because then if you can control the CPU on the device, then obviously you're inside already.
MIMOSO 19:03
Right.
HEILAND 19:04
So are these types of attacks detectable? That was one of the uh uh I mean, obviously, if you're if you're connecting in or you're attacking somebody's S3 bucket, yeah. Somebody should be monitoring.
MIMOSO 19:19
There's a trail there, yeah.
HEILAND 19:20
Or are we being attacked? Has something been exploited? If you're connecting to an internal network, then standard network security protocols come into effect. Are you monitoring? Are you segment, uh, or you're doing any kind of behavior analytics? Hey, I have this autonomous vehicle, it connects out, it transfers this type of data. Is it doing port scans? Is it trying to brute force an SSH on a machine? Yeah. Those are key indicators that just something's going south. Right.
MIMOSO 19:49
Right. But in terms of like there aren't CVEs that can be patched here. This is is it back to the drawing board kind of thing?
HEILAND 19:56
And I I think I think in some cases with the cellular modules, adding um mitigations in there, uh like I mentioned, there's there's two channels, only one of them's used. Can the other one typically the approach is you disconnect it in circuit. But if I have the physical device, I can reconnect to that circuit. That's that's not a problem, some way or some fashion. But the ability to completely shut it off. That means if I'm using USB, completely shut the serial off so it's not on. And it can't be turned on. That's the thing. Right. Because if I have communication to the cellular module even through the USB, I can reprogram and say turn your serial back on or turn this back on. So you want to be able to stop those. Now, when I talked about the MBIT or LTEM class devices, none of those I looked at had any kind of security in those. Now I have been poking around, um I'm not gonna say the brand, but uh an automobile telemetry unit that has a cellular module on it, and it's an OEM, so there's no AT manuals, very little documentation. But I was able to find enough technical documentation to determine that some of those features were built into it. It has the ability to program, turn on, turn off very serial and functionalities. But then the thing you also want to be able to, like, let's say password protect those functions. Once the vendor deploys something into the gets ready to deploy something into uh the wild or put a sell it, it'd be nice if they could say, hey, it's time to go to market with this, let's lock this password protective so that somebody who would connect in would have more trouble controlling or manipulating the device. All right, make sure that it's a good idea. Those don't currently exist. Maybe they should.
MIMOSO 21:36
So I'm curious, have you heard back from manufacturers?
HEILAND 21:39
Like what's the interaction been like at this eye opening or this potentially I I have not. Okay. Um so this is uh in our research, we our test and we use a specific module in our demos. Yeah. Uh this is not an attacker target on this particular vendor. All of these classes are all the same. So the MBIoT and LTEM classes that I looked at from like a half dozen vendors all function exactly as well.
MIMOSO 22:08
Regardless of vendor, right. Something like this, when you find something like this, do you wh where does where does it fall down? Is it the design? Is it implementation? Um again, not to pick on anybody in particular.
HEILAND 22:21
I think it I think it's all of those. Yeah. It's it's design. Uh I I'll be honest, when it comes to the cellular modules design, they think about at least from the physical aspect of the device, they think about security. I've interacted, I have interacted with vendors in the past. Um and I've talked with I've talked to some about their module, and I've actually when when I when I do get a module or find a device that has a cell module, I go buy a couple of those cell modules, I tear them down.
MIMOSO 22:55
Yeah.
HEILAND 22:56
I take all the components off of them, get down to the circuit boards. I may try to de layer the circuit boards, I try to map out the whole thing. And I have to be honest, almost all of them I looked at from a physical design perspective, absolutely brilliant. From a security perspective, to be able to break into the device, uh it's inherently more complex. Doable, still sure, but much more complex. So I think they do a good job uh with their intentions of the devices and how they're to be used. Uh but I don't think they ever expect it the approach I'm taking on these particular devices. And because of this, maybe we need to rethink some of these designs and come out with uh cut capabilities within these cellular modules to be able to add more security. So when a company buys these to deploy in their product, they have a more suite of uh mitigations that they can implement to improve their product security. And I think from an industry it would be great to see us move in that direction for some of these.
MIMOSO 23:57
I mean, just listening to how you kind of broke all this stuff down, it's it's not trivial. I mean, it takes a lot of work.
HEILAND 24:03
No, it well, it's I I've never looked at any of this as complex. Uh I've looked at it as like, and I've done this with a lot of research in the past. You know, vulnerability research is cool when you can, you know, you send a buffer overflow and you attack a device, it's like, ooh, see what happens, yeah. Cool. In this case, it's like, hey, and this is something I've done throughout my career. How's this supposed to work? Now, how can I leverage its expected functionality in my favor? And that's all we're doing here. We're taking something, learning how it works, and going, okay, let's make it do what we want. Because now we understand how to talk to it, communicate to it, connect to it. Right. Uh, and I think I think that aspect of research adds a level of complexity uh in in protecting, because it isn't like, hey, I can change, I can change the code so the buffer overflow is not there. We do a firmware upgrade. In this particular case, uh, a lot of this is how the device physically functions, and that's often hard to protect to protect from.
MIMOSO 25:05
So is just as a last question, last thought, is there a next stage to this or is this wrapped for you guys?
HEILAND 25:11
So no, there it there is a next stage. Um not sure if I discuss it here. That's okay. But uh there there is a next stage you're gonna see coming um that because we're talking about communication outgoing from the device. Uh uh we're interested in examining uh communication incoming to the device and how that would play out uh and understanding how how that can be manipulated or controlled to have adverse effects also. We want to cover the full gamut so that so in the end we can better secure the products.
MIMOSO 25:44
Right. All right, we're gonna have to keep an eye out for it. Thanks for joining me at first.
HEILAND 25:48
Thank you very much.
Michael Mimoso is Director of Influencer Marketing at Claroty and Editorial Director of Nexus.
