Exploited: The Cyber Truth,  a podcast by RunSafe Security. 

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

[Joe]
Good day, Paul. Great to be here.

[Paul]
And this episode’s special guest is Gabriel Gonzalez, who is Director of Hardware Security at IOAC. Welcome indeed, Gabriel.

[Gabriel]
Thank you for having me.

[Paul]
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]
Like most researchers, we began at a very young age, playing with open source software, trying to learn about why binary. It 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]
We won’t ask too many questions about that.

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

[Paul]
So 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]
So, well, when I asked you what were the ones that I 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 co-workers, Ramiro and Justin, this is something that is in publish, right? So we can openly talk about it.

[Paul]
Yes.

[Gabriel]
They were actually looking at a T-box, a telematics box. So they were looking at a T-box, a telematics box. that was the part of the car of the vehicles that communicate the car with the outside world most of the times 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 to communicate and queues

[Paul]
so that’s a message queuing system that’s very much more efficient and easy to use than say

[Gabriel]
http or https right yeah exactly so it’s quite well favored in the embedded industry they found that these devices were using that protocol and of course when we we see something that operates on the cloud is 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 communicated with was not currently configured they could connect to the broker and 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 to send binary commands and specific commands to the canvas so they found that they could actually fully control the car it could unlock the car get all the messages from the car so this is the particular very i think concerning

[Paul]
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 wanted yeah exactly 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]
Yeah exactly these fleet of vehicles were fully exposed on the internet of course the the researchers and ramira and jashin contacted the the relevant authorities and everything got a fix in time it was everything was properly disclosed but yeah it’s a type of vulnerability that uh is very i think it’s one of the worst enablers that a car could have right like someone getting access to a fleet of vehicles 

[Paul]
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 attacker’s hands so that wasn’t actually a flaw in the protocol itself it was actually an incorrectly configured part if you like of what you might call the data supply chain

[Gabriel]
Yeah exactly it was on the back end and in qtt the isolation between clients need to be currently configured and the cues that mqtt has you have to you can allow and restrict the write and read access so all those things were not currently currently set up and of course the the actual authentication to the system only authorized system with the right type of authentication should only be the ones that are should access to the to the server not everyone on the internet

[Paul]
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]
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 100 applications. Certainly, 40, 50, 60 is a reasonable number on cars if you consider infotainment and all the digital controls on a vehicle. I think, in the automotive industry, it’s interesting because as the architectures of the vehicles change, there’s a lot of stuff that is still 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 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 people can certainly 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]
So, Gabriel, it’s obvious from that rather terrifying story you just told that an important part of what happened after you’d found these vulnerabilities was the rapid and responsive collaboration between you as 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]
Things have improved a lot, right? Maybe 15 years ago, when you submitted a vulnerability, companies were like, they didn’t even know what we were talking about. Some companies were thinking that we were trying to get money out of them.

[Paul]
So would you get sometimes get threatened with legal action and we’ll sue you if you say a word?

 

[Gabriel]
Yeah. Sometimes that would happen because it was totally new right yes companies most of them didn’t have cyber security teams and maybe not even a security consultant i might sometimes maybe never heard about a cyber security 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 and work with uh with the end companies everything has has improved large companies nowadays most of them they have very well established cyber security teams and when when a vulnerability reaches to them they have a strict process on the times the timelines and how to process that vulnerability internally and also navigate with the consultants with the researchers in this case to let to help them fix their vulnerability and then recently they’ve gained a lot of get the patch out there so everyone can benefit from that. Nowadays, all the other certs and all these entities, they help with the 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]
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]
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 together with their own requirements, and they’re very good. They’re basically integrators. They don’t even own 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 as you said, they produce modems for automotive, for IoT, for whatever.

[Paul]
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 you want to say something about that standard and how it should help to improve security?

[Joe]
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 andrelated functionality, if you will?

[Paul]
So 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]
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 in vehicles today is from BlackBerry. It’s QNX, real-time operating system.

[Paul]
Yes. It’s weird that, 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]
Exactly. And so BlackBerry, obviously a great company. QNX is on 250 million vehicles or more, I think globally the last I checked. You can imagine then the complexity of all this. From one angle, organizations want to know where are these software components 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 been 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

[Paul]
Complying with the safety standard. Joe, you mentioned ASIL 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 or you’re going to roll backwards unexpectedly. All the way to, you 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 autonomous driving?

[Gabriel]
Well, that’s a good question. I think we continue to get similar kinds of vulnerabilities that we’ve been seeing out there now, right? Companies are getting better at securing, as Joe mentioned, buffer overflows. It’s very difficult to get rid of everything. We will still see things here and there. Of course, the autonomous vehicles, they 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]
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. Yeah, exactly. It’s incredible what… …gets left behind, even by people who aren’t trying to do anything bad.

[Gabriel]
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, that’s something that’s going to be very relevant. Bluetooth, NFC, even USBs, right? Indeed. They will probably need to have a very strong physical gap between, whatever the user can touch or attach to, because otherwise it’s going to be a nightmare. So in autonomous vehicles, let me say again, those that are going to be fully autonomous and shared between people, it will be a new research area and probably also a little bit of a headache.

[Paul]
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]
In terms of collaboration, I think nowadays it works well with most of the, or almost all of the auto manufacturers. Cyber security 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. Well, all these things help to increase the security. As everyone knows, there are these events where they put vehicles so everyone can go there and play with them and try to find vulnerabilities.

[Paul]
So that would be something like the car hacking village at DEF CON?

[Gabriel]
Yeah, exactly.

[Paul]
Or cars showing up at the Pwn2Own competition in Vancouver?

[Gabriel]
I don’t know in 10 years how this will look like.

[Paul]
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?

[Gabriel]
Yeah, exactly.

[Paul]
Whereas today, they sort of recognise that that’s a fantastic way of learning about weaknesses that might otherwise get found first by cybercriminals or state-sponsored actors.

[Gabriel]
I think the Jibhag that we did years ago was a good example of the things that researchers can do with a period of time and access to a vehicle. Yeah. That helped the industry realise that there was a problem. I know that everyone knows that companies are much more proactive and they work rapidly to improve the security of their vehicles and all the things that they use.

[Paul]
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 I’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 overhauling?

[Joe]
I mean, there’s a couple of different philosophies people can take, because in the automotive industry, there are ECUs, 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 AutoZar. You look at… 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… 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]
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 or think.

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

[Paul]
Yes. So can you describe a real-world scenario where build-time security prevented a possible exploit, an automotive one?

[Joe]
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]
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 litres 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 on up lane. Gabriel, do you have a thought on that?

[Gabriel]
That’s a good way to put it, right? On the plane you have a limited functionality and in the car they want to have, for example, even a Wi-Fi, they’ve got a USB to connect your phone, you 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 and you can just…

[Paul]
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, it doesn’t control the engine, so I shouldn’t worry about it. But it does control your ability to control the vehicle safely.

[Gabriel]
Yeah, exactly. There are safety-related issues with all the functionality and, as you mentioned, the separation between, let’s say, pure car functions. 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 kind of things that we do, right? Because sometimes the infotainment units allow installing apps. So what 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 currently isolated. In fact, infotainment unit is very complicated and very important in terms of security as well 

[Paul]
And i 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 how 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]
Yeah there’s certainly software systems with wheels as opposed to cars with individual components at this point and integrated systems 

[Paul]
Well put i think that’s a great way to think about it and like you say software defined car.

[Joe]
They are loaded with software if you think about it from the auto manufacturer’s 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 your mercedes or your acura or your ford and you’re trying to compete you’re looking for ways to delight consumers with that overall experience. We have become well trained to bring our own devices connect phones and 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 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 in 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 methodologies.

[Paul]
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]
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 a third party reviews. 

[Paul]
So sdl that’s software development life cycle exactly so that’s where security comes at the beginning the middle and the end of development not just the end of development but all of that is going to be something that you wait till there’s a problem and then say hey let’s paint over it and hope nobody notices

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

[Paul]
Yes. It’s not showing off it’s not trying to rejoice in somebody else’s weakness. 

[Gabriel]
Exactly. 

[Paul]
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 cyber security is always going to be a journey and not a destination.

[Gabriel]
I like it. 

[Paul]

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, hey, I, I own a company that sells something, buy it. I really love that. So that is a wrap — 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 subscribe to our channel and hit the bell icon so you don’t miss any of our new episodes, 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.