[Paul] (00:03)

Welcome back to Exploited the Cyber Truth. I am Paul Ducklin, joined as usual by Joe Saunders, CEO and founder of Run Safe Security. Hello there, Joe.

[Joe] (00:19)

Good day, Paul. Great to be here.

[Paul] (00:21)

And this episode’s special guest is Gabriel Gonzalez, is Director of Hardware Security at IOActive. Welcome, indeed, Gabriel.

[Gabriel] (00:33)

Thank you for having me.

[Paul] (00:34)

It’s a great pleasure. Gabriel, maybe we can start by you telling our listeners how you got into cybersecurity and particularly how you got into embedded cybersecurity and what caused your great passion for it.

[Gabriel] (00:50)

Like most researchers, we began at very young age playing with open source software, trying to learn about why binary worked at the internals of the system. For example, like mobile phones and even a keyboard was very interesting to me. And also cars back then, right? I was very interested in how the people were able to change the horsepower. That was a very important thing.

[Paul] (01:21)

We won’t ask too many questions about that. 

[Gabriel] (01:24)

Yeah. So that’s how I got into security. Then I went to the university, but I kept interested in security. And then I made my passion my work. The things that I do, automotive is a very big part of the research and also the work that I do for clients that are  IOActive.

[Paul] (01:46)

Gabriel, can you share a recent example of a vulnerability that you and your team actually found in an automotive system? Something that was already there, that had gone out into the wild and either was exploited or could have put people at risk? What made that particularly interesting to you?

[Gabriel] (02:06)

So well, when I asked you, we were the ones that put out the Jeep hack a long time ago that maybe some of the viewers remember that. It was very interesting, right? But it was a while ago. But recently a couple of my coworkers, Ramiro and Justin, this is something that has been published, right? So we can openly talk about it. They were actually looking at a T-box, a Telematics box that was the part of the car or the vehicles that communicate the car with the outside world.

Most of the time via cellular networks. And they found that this particular unit used MQTT. For those that I don’t know, MQTT is a protocol that is mostly used to communicate in queues.

[Paul] (02:52)

So that’s a message queuing system that’s very much more efficient and easy to use than say HTTP or HTTPS, right? So it’s quite well favored in the embedded industry.

[Gabriel] (03:00)

Yeah, exactly.

They found that these devices were using that protocol. And of course, when we see something that operates on the cloud, it’s one of the points that we like to look at. When they found out that the MQTT broker, so basically the server that all the devices communicate with was not correctly configured, they could connect to the broker, see all messages from all the vehicles.

Of course, it took them a little bit to reverse engineering the binary protocol, but it turns out in summary that they were able to pinpoint any single vehicle. It was possible for them to send binary commands and specific commands to the canvas. So they found that they could actually fully control the car, could unlock the car, and get all the messages from the car. So this is the particular very, I think, concerning vulnerability.

[Paul] (03:58)

So from a surveillance point of view, if that were in the hands of say a nation state attacker, they’d be able to track pretty much whoever they want. Or if they were a car thief, they’d basically be able to open the car and drive off as though it was theirs.

[Gabriel] (04:05)

Yeah, exactly.

This fleet of vehicles were fully exposed on the internet. Of course, the researchers, Ramiro and Yashin, contacted the relevant authorities and everything got fixed in time. Everything was properly disclosed. But yeah, it’s a type of vulnerability that I think is one of the worst enigmas that could have, right? Like someone getting access to your fleet of vehicles.

[Paul] (04:37)

Yes, particularly if you’re a business and you run a whole load of vehicles, that’s an awful lot of data that you probably don’t want in your attackers hands. So that wasn’t actually a flaw in the protocol itself. It was actually an incorrectly configured part, if you like, what you might call the data supply chain.

[Gabriel] (04:57)

Yeah, exactly. It was on the backend. In MQTT, the isolation between clients needs to be currently configured. And the queues that MQTT has, you can allow and restrict the write and read access. So all those things were not currently set up. And of course, the actual authentication to the system, only authorized systems with the right type of authentication should only be the ones that should access to the server. Not everyone on the internet.

[Paul] (05:28)

Joe, maybe I can ask you now why this kind of thing continues to happen. Why aren’t we there yet and how can we get there so that this kind of thing is prevented in advance rather than fielding it and then hoping that Gabriel and his team find it before the bad guys do?

[Joe] (05:46)

Yeah. And actually with folks like Gabriel, we want to make sure organizations do find them before the bad guys do. Researchers inspire me because they do think about what can go wrong. And the fact remains also that if you go back to the Jeep and forward and you think about all the hundreds of millions of lines of code now on automobiles and vehicles today, there is a lot of attack surface and therefore a lot of opportunity for things to go awry.

I think in some autonomous vehicles, there may be as many as a hundred applications, certainly 40, 50, 60 is a reasonable number on cars when you consider infotainment and all the digital controls on a vehicle, think in the automotive industry.  It’s interesting because as the architectures of the vehicles change, there’s a lot of stuff that still is built around the CAN bus and things like that. And so there’s always little things that can be done to manipulate the CAN bus protocol and

trick it into sending some test messages and whatnot that might result in something that the driver’s not intending to do. And just to go back to the original question, I think mature software development practices is one thing certainly people can do. And the other thing is we need researchers like Gabriel to help us make sure we do have that extra perspective on our process in our systems before the bad actors find them.

[Paul] (07:08)

So Gabriel, it’s obvious from that rather terrifying story that you just told that an important part of what happened after you’d found these vulnerabilities was the responsive and rapid collaboration between US researchers and the vendor who was able to fix the problem. How much do you see that researcher-vendor collaboration improving in embedded systems in general, but in the automotive industry in particular?

[Gabriel] (07:38)

Things have improved a lot. Maybe 15 years ago when you submitted a vulnerability, companies didn’t even know what we were talking about. Some companies were thinking that we were trying to get money out of them.

[Paul] (07:52)

So would you sometimes get threatened with legal action and we’ll sue you if you say a word.

[Gabriel] (07:57)

Yeah, yeah. Sometimes that would happen because it was totally new, yes. Most companies didn’t have cybersecurity teams and maybe not even a security consultant. I sometimes maybe never heard about a cybersecurity review, but those things have changed. Also, there are more government-related entities like all the certs and all the organizations that help to be in the middle  and work with the end companies. Everything has improved.

Large companies nowadays, most of them, have very well established  cybersecurity teams. Then when a vulnerability reaches them, they have a strict process on the timelines and how to process that vulnerability internally. And also navigate with the consultants, with the researchers in this case, to help them fix their vulnerability and get the patch out there so everyone can benefit from that.

Nowadays, all the certs and all these entities, they help with this process, especially with companies that are not well known and they are not too large. I think it’s good to go through the certs.

[Paul] (09:08)

The supply chain into the automotive industry is quite huge and I imagine some of the vulnerabilities you find in the automotive sector might not be in code that’s directly created and managed by the big name. It might be some smaller company that provides their product, perhaps not only to the automotive industry.

[Gabriel] (09:29)

Yeah, exactly. As you said, in automotive, there are different types of companies. Some of them are just integrators. So they get all the ECUs, everything from OEMs, and they get the battery management system, the infotainment unit, the PMS, whatever, everything. And then they plug it in together with their own requirements, and they’re basically integrators. They don’t even know all the code for the ECUs. So in that case, when you find an issue, it’s not even theirs. And even sometimes, these OEMs have another supplier, right? Like for example, a modem. There are a large number of companies that produce modems, but I just said they produce modems for automotive, for IoT, for whatever.

[Paul] (10:11)

Joe, it sounds like we’re talking here not so much about a supply chain as a supply web. Specifically in the automotive industry, there are some standards like ISO 26262, which firstly are compulsory so you have to comply with them, but also that dictate just how far you’re supposed to chase that supply chain back in the automotive world. And you have to go at least four steps, don’t you?

Do want to say something about that standard and how it should help to improve security?

[Joe] (10:47)

Well, certainly there’s good guidelines that the standard offers. In particular, when you get to the ASIL side of it, which is the autonomous standard, and there’s four levels for ASIL compliance, depending on just how involved the autonomous controls are. Is it pure driverless or is it driver assisted and related functionality, if you will?

[Paul] (11:09)

Is that the difference between maybe keeping you in your lane when you’re driving on the freeway and sitting in the backseat reading a book while the vehicle drives you along?

[Joe] (11:19)

Exactly.

But when you consider the supply chain then, yes, you have other tier one suppliers, which are major corporations providing components. As we talked about earlier, you might be getting your infotainment system from one provider and your braking system from someone else and your battery system from somebody else. So it is important then as the OEM that you have a view on the security practices and the level of compliance that those systems have, but the supply chain goes further and includes things like the underlying operating system. And one of the most dominant operating systems on vehicles today is from BlackBerry. It’s QNX real-time operating system.

[Paul] (12:02)

Thatis  isn’t it? People think BlackBerry are gone and forgotten because they don’t see their phones anymore, but actually in the embedded space they’re the provider of operating system, the real-time operating system itself.

[Joe] (12:15)

Exactly. So now BlackBerry, obviously a great company, QNX is on 250 million vehicles or more, I think globally the last I checked. You can imagine the complexity of all this. From one angle, organizations want to know where these software components are coming from? On another angle, there may be drivers or low level system components that contain vulnerabilities. Just last year or in the past two years now, I’m losing track.

Tesla had a classic buffer overflow and it was discovered in Tesla Model 3 vehicles. And it was a specific driver in the operating system that was putting Tesla vehicles at risk. And it was the kind of vulnerability that enabled potentially an attacker to execute arbitrary code on the target system. Those kinds of vulnerabilities are some of the most severe. I go to all that detail to say the supply chain itself, all these suppliers, talking to your second cousin, your third cousin, your fourth cousin, it matters because these are complex systems and you do have to have a sense for what the security is. And so what that means is people should be looking at the vulnerabilities across the entire ecosystem, especially if you’re complying with a safety standard.

[Paul] (13:32)

Joe, you mentioned AISL there, the standards for autonomous driving, all the way from basic driver assist. I’ll help you do a hill start. You just use the clutch. Don’t worry about the brake. I’ll take care of it for you. You better hope it works. So you’re going to roll backwards unexpectedly all the way to sit in the passenger seat and watch a movie. I’ll drive you to Pasadena or whatever it is. Are we going to find a different class of vulnerabilities relating to autonomous driving that are based on just the sheer complexity of the system itself? Or do we still have to focus on problems like, hey, there’s a bug in the modem? What difference do you think the increasing number of autonomous vehicles on the road will make to vehicle security and to automotive security research?

[Gabriel] (14:21)

Well, that’s a good question. I think we are continuing to get similar kinds of vulnerabilities that we’ve been seeing out there now, right? Companies are getting better at securing, as John mentioned, buffer overflows. It’s very difficult to get rid of everything. Yes. We will still see things here and there. Of course, the autonomous vehicles have a large exposure to the internet and also in the fully autonomous taxis kind of services.

Also, physical attacks, I think, probably will become more relevant. In a taxi or similar autonomous vehicles, you don’t know what the previous passenger did to the vehicle.

[Paul] (15:00)

Indeed. I don’t own a car. When I need a car, I just go and rent one. And it always takes me about 10 minutes to go through the infotainment system to get rid of all the previous renters Bluetooth pairings and MP3 files they’ve uploaded. It’s incredible what gets left behind, even by people who aren’t trying to do anything bad.

[Gabriel] (15:16)

Yeah, exactly. So I think that’s going to be something that probably the company is working on that they already have teams thinking on how to secure cars physically. Of course, if there is a Wi-Fi exposed, something’s going to be very relevant. Bluetooth, NFC, even USBs, right? They will probably need to have a very strong physical gap between whatever the user can touch or attach to.

[Paul] (15:43)

Indeed.

[Gabriel] (15:53)

Because otherwise it’s going to be a nightmare. So in autonomous vehicles, I’m going to say again, those that are going to be fully autonomous and shared between people, it will be a new research area and probably, and also a little bit of a headache.

[Paul] (16:11)

So how do you think security collaboration between researchers and automotive vendors will evolve over the next, say, two, five, ten years? As cars get ever more complicated.

[Gabriel] (16:26)

In terms of collaboration, I think nowadays it works well with most of the or almost all of the other manufacturers, cybersecurity problems or issues, everyone is aware of them. Nowadays there are more certifications that the vehicles need to comply with to be able to be sold in different countries. And well, all these things help to increase the security. As everyone knows, are these events where they to put a vehicle so everyone can go there and play with them and try to find vulnerabilities.

[Paul] (17:00)

So this would be something like the car hacking village at DEFCON or cars showing up at the Pwn2Own competition in Vancouver.

[Gabriel] (17:03)

Yeah, exactly.

I don’t know in 10 years what this will look like.

[Paul] (17:11)

But certainly 10 years ago, automotive vendors would not have been bringing their products at all. They’d have had a much more closed approach, wouldn’t they? Whereas today they sort of recognise that that’s a fantastic way of learning about weaknesses that might otherwise get found first by cyber criminals and state-sponsored actors.

[Gabriel] (17:20)

Yeah, exactly.

Think of the deep hack that we did years ago, it was a good example of the things that researchers can do with a little bit of time and access to a vehicle. Yeah. That helped the industry realize that there was a problem. I know that everyone knows that companies and they are much more proactive and they work craftily to improve the security of their of their vehicles and all the things that they use.

[Paul] (17:58)

So Joe, maybe we can go back instead of talking about the whole web of intrigue that is the AI that goes into self-driving and all the cloud services. Let’s zoom into what I guess would be level zero in the Purdue model, the actual individual devices that might be in a car, like the thing that detects that you’ve turned the steering wheel a bit left or a bit right. Given that those can be harder to patch and it’s much better to get them right in the first place, particularly when you’ve just talked about steering.

I would like to think that they were correct out of the box, not only after 17 patches. What sort of approaches can manufacturers and vendors take for devices that aren’t quite so amenable to over-the-air updates as infotainment systems?

[Joe] (18:45)

I mean, there’s a couple different philosophies people can take because in the automotive industry, there are ECUs, right? Electronic control units, things that might control individual components that you’re talking about, brakes and others. And many of those are proprietary oriented products, yet there are several versions of open system architecture components. In fact, in the auto industry, you talk about AUTOSAR. You look at POSIX compliant components on a vehicle.

And so I think it’s as much about the architecture that you take as well as the standards and the working groups and the frameworks that are available that help you navigate some of the security issues. Also, having a good robust software development process is good. And I always say it’s a good thing cars are not produced in five days or 30 days and a new model year might take two, three years to come out. And so if you don’t have a way to really update the vehicles, building security into those components prior to shipping can certainly reduce the exposure and the problem that you would suffer from having to patch components.

[Paul] (19:54)

So that’s something that you do at build time that either detects that something has gone wrong in the build process so you’re not building really what you want to think.

[Joe] (20:05)

Build-in security that protects the device at runtime, I think ultimately is a good approach.

[Paul] (20:11)

So can you describe a real world scenario where build time security prevented a possible exploit, an automotive one?

[Joe] (20:19)

The examples I gave earlier around a buffer overflow on an infotainment system, having the memory protected from exploitation, certainly avoiding the ability for an exploit to target ROP gadgets and ROP chains and take advantage of those buffer overflows is probably the perfect example of things that have been out there that have gotten thwarted. There were some disclosures earlier this year about vulnerabilities in infotainment systems that I think people can look up. And with that said, I think there’s other advances where suppliers and OEMs are working together on some of these open frameworks. I bring it back to that because I do think that if you think about researchers, you think about the software development process, and you think about some of these open frameworks, when those three items are working together and OEMs and tier one suppliers are committing to an overall architecture, then I think we have a better chance of, as an ecosystem, helping to defend the underlying systems. 

What really makes me nervous in the modern world for software-defined vehicles is when you have proprietary systems that are black boxes. And in the end, that’s where I think security researchers are going to find more vulnerabilities than the ones where there’s collaboration and an open framework in place.

[Paul] (21:42)

I’ll put this question openly to both of you. It strikes me that what we refer to as the infotainment system in the average car is very different from the way you might think of an infotainment system in an aircraft, where you’ve got a little screen on the back of the seat in front of you, you can press some buttons and you can choose a movie or listen to music or watch the flight path across the globe, etc. Certainly on most of the cars I’ve rented recently, in the same interface, there’ll be a button that says, do you want the lane keeping assistance on? Do you want the hill start assistant on or off? Would you like the display to show you liters per hundred kilometres or miles per gallon? There seems to be much less natural separation between what you might call the infotainment system and all its input and output systems and the rest of the car itself compared to systems where the infotainment system was plumbed in later like autoplay.  Gabriel, do you have a thought on that?

[Gabriel] (22:43)

That’s a good way to put it, right? On the plane you have limited functionality and in the car they want to have, for example, even Wi-Fi. They’ve got a USB to connect your phone to have the maps loaded and get access to your music as well. And at the same time, you want to have control to certain aspects of the car, like maybe even moving a seat back and forth. That’s something that could be dangerous if it can be controlled by an attacker, right? If you’re driving, you can just flip.

[Paul] (23:15)

It gives a whole new dangerous meaning to sudden relaxation. I hadn’t even thought of that. There is quite a lot that you think, doesn’t control the engine so I shouldn’t worry about it. But it does control your ability to control the vehicle safely.

[Gabriel] (23:31)

Yeah, exactly. There are safety related issues with all the functionality. And as you mentioned, the separation between, let’s say, pure car functions versus entertainment or more pleasure kind of functions. And that’s when we do reviews. Those are the kinds of things that we do, right? Because sometimes the infotainment units allow installing apps. So why are the accesses, these applications, third party applications can have in this infotainment. Can they send messages to the car seat, for example? They are properly containerized and correctly isolated. In fact, the infotainment unit is very complicated and very important in terms of security as well.

[Paul] (24:16)

And guess particularly since you mentioned the idea that many modern car infotainment systems will allow the user to add their own apps just like they can on a mobile phone. That expands the attack surface even more, particularly if those app stores accept submissions from all over the place to give you the best experience. If somebody has your worst interests at heart, they could be just looking for a way to have an app approved that will then find its way into a large number of vehicles. 

Maybe not so they can control a car, but they can just learn more about the operation of a business, the movement of people, something about how society works. All of the things that you kind of think I wouldn’t have given that information away willingly if somebody had asked me. So Joe, what sort of innovations or changes do you think we need? For example, in the automotive software supply chain to deal with all these burgeoning problems.

[Joe] (25:18)

Yeah, there’s certainly software systems with wheels as opposed to cars with individual components at this point, they’re integrated systems.

[Paul] (25:25)

Well put, think that’s a great way to think about it. And like you say, software defined car.

[Joe] (25:31)

They are loaded with software. If you think about it from the auto manufacturers perspective or the OEMs, they are motivated to deliver driver experience and experience in the vehicle to help differentiate their vehicles. And if you’re BMW or you’re Mercedes or you’re Acura or you’re Ford and you’re trying to compete, you’re looking for ways to delight consumers with that overall experience. We’ve become well-trained to bring our own devices, connect phones and leverage AirPlay or CarPlay on the vehicle, we have become accustomed to some of those comforts and some of those sound systems and some of those video displays that make that overall experience just different. I guess the point to the question then is what can you do security wise to enable the drive and the motivation to differentiate on driver experience and customer experience? I believe security is a key role. I believe collaboration around open standards and frameworks is a key role. I believe pen testing and doing your own security research on components and modules is a key role. I do believe in understanding the vulnerabilities that come from your supply chain, analyzing software bill and materials and the components, the underlying components, what components are on those products you get from your suppliers. 

I believe all these play a role and I also would then add that inserting in security protections when you build the software is a lot better than trying to chase things after the fact. You want to embed security into your devices and make it a part of that experience. It’s a full discipline. It requires cooperation and open standards and really good software and security methodology.

[Paul] (27:20)

Well said. Gabriel, maybe we can finish up by me asking you a very open-ended, future-looking question, if you don’t mind. What do you think are the biggest opportunities for innovation and improvement in the vulnerability research side in the automotive world?

[Gabriel] (27:41)

Well, I think the best way is for companies to keep doing what they are doing right now and improving their processes. I think they are doing a good job increasing the SDL and getting third party reviews.

[Paul] (27:56)

So SDL, that’s Software Development Lifecycle. So that’s where security comes at the beginning, the middle and the end of development, not just something that you wait till there’s a problem and then say, hey, let’s paint over it and hope nobody notices.

[Gabriel] (28:00)

And keep working with independent researchers as well. That’s a way to have more people looking at the devices, not only in automotive. We look for vulnerabilities, but not for pride, it’s just for trying to apply our knowledge and get a safer world for everyone.

[Paul] (28:31)

Yes, it’s not showing off. It’s not trying to rejoice in somebody else’s weakness. It’s trying to make it obvious so that the good guys find it first. Therefore, if there is a problem that got through, it can be fixed before the bad guys get there. I wish we could all be out of a job tomorrow because security was a done deal. But cybersecurity is always going to be a journey and not a destination. I like it. Gabriel, it’s great to have people like you being part of that journey and helping us all to do it better. And Joe, lovely once again to hear your passion about getting the whole community to do things, right? Not just standing up and saying, I own a company that sells something, buy it. I really love that. So that is a wrap for this episode of Exploited: the Cyber Truth. If you enjoyed this episode, please don’t forget to subscribe so you know when every week’s new episode arrives.

Don’t forget to recommend us on social media and to share us with all of your team. And don’t forget, stay ahead of the threat. See you next time.