Vehicle Cyber Security and Innovative Assessment Techniques

everyone hear me okay microphone working yeah cool cool okay afternoon everyone I'm Andy Davis I head up ncc groups Transport Security practice shortly in the talk I'll be joined by Dave player who's our automotive tech lead and the two kind of main thrusts of this presentation the first one is a bunch of tools and techniques and methodologies that we've developed over the years we've been testing vehicles and also a number of different kind of anecdotes war stories about things that we've seen as a result of testing using these tools and techniques so a little bit of an agenda we'll start off with the obligatory attack surface slide that if you've been to any automotive cybersecurity talks you've seen lots of

examples of these but it's really to give you an idea of just how complex and large the attack surfaces in the connected car space will then go through all the different security assessment techniques that are kind of within our arsenal then talk about some of the common themes that we see throughout the automotive space so different elements within that attack surface and then we'll talk about secure development lifecycle so you know how the industry can address these these problems and finish off some Q&A so the attack surface slide probably bigger than a lot of people's attack surface slides and we just get a picture of a car and like you know pointers saying you know USB and

Bluetooth that kind of thing but I wanted to really give a big picture of how connected the connected car infrastructure is these days and it's not just the wired and wireless interfaces on the vehicle itself it's all the onward connectivity as a result of telematics and telematics is a real growing industry at the moment so over the mobile network at the moment and via internet data or specific telematics data to telematics service providers and just to show all these different providers of data and consumers of data around telematics so you know all the way from you know the insurance industry looking at how well you're driving your car so they can work out whether to reduce your

your policy or the cost of your policy through to things like connections through to emergency services so that if your car breaks down or is it in an accident you know that the car can tell the emergency services where you are and yet whether the airbags been deployed that kind of thing the majority of the stuff that we're going to talk about in this presentation is around the vehicle itself and the assessment techniques we have against these different wired and wireless interfaces so we're not going to concentrate too much on the telematics stuff so you know RF interfaces communications via wyd interfaces which is USB that kind of thing diagnostics in fact that the first

chunk of the talk is going to be about diagnostic stuff so we'll kick off with attacks that require you to physically connect to wide interfaces on the car and we'll talk about some diagnostic stuff so I bring Dave up here and hand this over to him he can you keep the handsome one

seamless transition Yeah right sup working right ok so this section thoughts going to be about unified diagnostic services which is a diagnostic protocol that all cars use and the mechanics used to interface with the vehicle when um take your comb for a pair this is the protocol that they're going to use diagnosing faults on the vehicle however we found through testing that you can impair safety critical functions of the vehicle things like disabling the steering killing the engine security issues like adding removing keys and the immobilizer and kind of thing you also have the problem of manufacture IP theft which is a you can download the firmware of the ECU this is how people modify car so modify

the air-fuel maps to increase horsepower that kind of thing and it can also do a lot of tongue gateway assessments which are kind of a lot of manufactures to start to implement gateways in the car to prevent messages transitioning from one bus to another but the problem with that is that the Gateway itself then becomes the point for attack so I created a tool called V map which is basically a call it the Arctic's kind of like nmap vehicles it's a Python tool which enumerates the services that are supported on all these using the vehicle it uses the Linux socket con library so any compatible hardware interface will work so you can have can connect d for

UDS the protocol is actually application application layer protocol so it's data link agnostic so you can swap out for over IP if you wish so at the moment it can do various things like detecting the EC's are in the viet they're in vehicle supported diagnostic functions of the ECU you can authenticate to the ecs which enables you to read and write data in volatile and nonvolatile memory so UDS is basically a data link independent diagnostic service for road to the vehicles and as an example of a few of the surface is there from the ISO standard not all services have to be supported not all services are interesting from a safety or a security perspective

and some of them require authentication which we want to later before you can use them so easy user in a vehicle have a physical address in the range 707 FF hacks if it's 11 bit or a lot large range of its 29 bit and you can detect these ECU's by sending a UDS request a service request to all the values in the range and listening for a response if you get a response you know there's enough live ECU there so the services we use that's a diagnostic session control and test the present because they're kind of benign services which just tell ECU that you want to do some diagnostics and the Seas have to respond with a

positive or negative response for these services so of that

nope so what we're doing here is we're just sending a diagnostic session recall a session control request to all ECU's in the range 702 seven FF and listening back for a positive or negative response we don't care at this stage if it's positive or negative since we just after the address of the ECU so there the arbitration IDs you can see there that we have ones 737 31 down to 70 0 there at the end you can see it gives you a list of the different ones that are available that was just air through the able OPD port oh sorry how did you access your thing I think your mouth

I think the mouse is broken on this I can't go back in okay right sorry about that right so EDS service enumeration the services that we showed previous lied off they can be enumerated in pretty much the same way you're just listening for a positive or negative response you're kind of brute forcing the services so the ones in green they're there in the standard as defined values that unknown so this is an example of diagnostic session control so you have mode to made three mode for there and they are what they are programming session extended session and safety system Diagnostics the ones in red underneath are split into four categories the the sub function so in

UDS you have a service and you have a sub function the sub functions are defined in byte ranges so the first lot of bite range is a vehicle manufacturer specifics of their sub functions the manufacturer can assign to do certain things that the people like Ford GM the second range is the system supply specific used by the tier 1 and tier T providers so that'll be like Bosch continental that people actually make VCU and then the other range ranges are either reserved for future use or undefined and those are the ones that are interesting because as we've seen people seem to be sticking loads of different runs and things in there that caused all kinds of havoc on the car so

how you actually detective a service is active is you're just listening for a positive and negative response so on the on the left they have a positive response where you 70 0 we're telling the ECU requesting service 10 mode 3 now if it's a positive response it responds back by the second bite is just added 40 hex so that becomes 50 and then the sub function is after that so you can tell that to positive response on the right you have a negative response which is a it replaces the service with 7f if it's invalid and then the the 22 those conditions not correct that's likely error code for why it didn't work so conditions not correct can be things

like the car is in motion and you've told it to do something which is unsafe so all you need to do is loop through the bite ranges that are defining the standard until you get a positive response and it's interesting when you do this while the cars running or while you're driving so you can find all kinds of different service services which either way intended to the form a certain function or they just by accident happen to break something which is something called demo no so this is a demo of the attacking the powertrain control module using one of the discovered services plastic over

the data have us killed the engine while the Vegas tensioning version this vehicle is currently accepted wasn't straight to the evening can be killed by attack attack

I

this is a second video attacking a different modulus is that PS CM the power steering control module okay apparently one of our research vehicles in turn straight one of the dangers of packet gaining and upright activists of Cadiz so if they don't race that the steering is spent working by the engine running in the maple and now we send certain specific packets on to the palace see if the steering completely not be very dangerous real driving tonight stop sending packets it's this day one is working fine and it's worth mentioning that this is not a specific von bility with its lethal a widespread issue it again

and why right so that last one there the power steering control module that was pretty interesting because normally if you were to impair the ECU in some way you would still be able to turn the vehicle it would just feel like your power steering belt had snapped and it would just be kind of difficult to turn but on that one the motors actually failed closed so you actually physically couldn't move the wheel because the motors were locked so there's kind of unusual and these these two issues cooling engine in killing the earth or impairing the steering is an issue that we found on pretty much every vehicle in some way there will be a way to do that

by abusing the diagnostic services so there's it yeah so we didn't video but yes you can you can't do that yes so yeah yeah yes is yeah so security access so some of the services require a sort of authentication mechanism and this works by having a symmetric key embedded in each ECU and a corresponding key embedded in the OEM diagnostic software that the manufacturers use to diagnose false it's a challenge-response thing so debate when the diagnostic tool gets plugged in it asks the EC for a seed value and the ECU Center see back to the diagnostic software and the diagnostic software will have a copy of the algorithm for that manufacturer and it will put the seas together with a key

this symmetric key which is also for the ECU together into the algorithm and out comes the response that response is sent back to the ECU and it's then unlocks which means you can use some of the protected services before you give an example of that there's other issues we found with seeds the seed value itself so we found found issues where the entropy is poor and issues where things like the the seed is the same every single time for every ECU sometimes it's the same always sometimes it's the same for the time you have the ignition on and you power cycle the car and you'll get a different one I've seen it where the seeds vary between two bites only

which is easy to brute force over up to 32 bytes so it kind of varies between facture and the use case but in most cases the way easier to just reverse engineer the diagnostic software which I Despres or something like that to get the algorithms out

so what's going on here is we have a list of seeds a list of key sorry and you can see there we're asking for seed and triangle I was going on those we were brute forcing the the key for each ECU so he pulled the seeds out of a dll file sorry the keys out the dll file in the OEM diagnostic software but if you don't know which key is for which ECU but you do have your algorithm because you reverse engineered that as well you can try each key in rapid succession until it authenticates on most cars that won't work because you will get locked out after three and valid temps and the lockout is exponential so you have to

take the ACU out of the vehicle put it on a bench and then find some kind of way of resetting the CPU to try and bypass the timer which if the value is held in RAM which is a bug in itself you can bypass the timing restriction if it's in nvram and accepts potential then you kind of you can't go any further and it's in if you don't know which key is for which ECU you just need to hook into the diagnostic software whilst you're performing a function so there might be a button in a software for adding a key the immobilizer so if you want to find the key for that the password of that

ECU would just hook into the software and do that function pull out the right key so there's no kind of guide to which services are protected and it's down to the manufacturer in the use case and the ones that are typically are protected the ones that you can use to read and write memory and change the ECU in some way or use some kind of proprietary diagnostic function so these include things like the anything where you can read and write by address anything where you can read and write by identify it so a data identifier in UDS it's just a a 2-byte hex value which corresponds to a piece of memory some location in memory

which holds some data in the ECU so for example F 190 is always the VIN number for the car in the ecu's sorry so here what we're going to do is are doing with your fence casing with the ECU and changing the VIN number for the vehicle so you can see that the vin that's the proper vin for the vehicle and then we authenticate with the unknown secret and write our own value into memory and then read it back and you can see there I've changed the VIN number to a cross-site scripting body which is interesting because a lot of the diagnostic software that manufactures uses HTML based so there's potential for attack vectors there and

also as undecided in beginning the telematics the most of the systems always read the VIN number of the vehicle and it gets put back into a report so someone will log into the thing you could get caught by a cross-site scripting bug it's a pretty interesting a tuck vector

alright so this is the bonus video sorry bonus slide something we're playing on recently is ISO to 60 to 1 which is the end of life activation of onboard pyrotechnic devices for vehicles so that sounds cool but as it is is a when a car gets pulled into scrap the airbag systems on seatbelt restraint systems contain a substance called sodium as I days that I de-identify said that right and that's dangerous and one cars go into a big industrial shredder this you can't shred the vehicles with these things in X it's toxic and they're explosive so you have to have something called a pyrotechnic deployment tool which you plug into the vehicle I definitely saw devices and then you can

shred it so this is a standard and deployment / County's supported so you could technically do this but most of the vehicles that I've interrogated with v map report back that a a CL is required an ACR in this case is called an alternative communications line meaning that you would have to plug into the obd or have access to car neither remotely or locally and also plug physically into the restraint control module so unfortunately that's not an attack vector for that particular vehicle however if you can authenticate and then use a particular data identifier a specific bids in this case in that screenshot correspond to the configuration for restraint control module on the supplementary restraint

system so you can see there I've written some data in and rerun the map and it's reported back that the air bugs have been deactivated on all the or the ones that are in the car which is kind of just as bad as than getting off but slightly less spectacular so that concludes the diagnostic portion of the talk so it's worth pointing out that even though this is all physical access stuff where I've been testing here this is used as a post exploitation tool to find out the kind of nasty things you can do on can once you've got remote access an arbiter you can access so if you can if you have access to can you

can do any of the things that bend em out here but not

cool thanks Dave okay so we're not going to go on talk about some of the other tools and techniques that we use for other interfaces other than the onboard diagnostic stuff so first of all USB I've done quite a lot of USB research over the years developing a number of different tools and techniques the picture there shows a face dancer board which some of you may have used at some point or another on pen tests it's open source hardware that allows you to basically emulate USB devices and I write a talk called you map which is open source that allows you to not only go through and in numerate what devices are supported by the host to emulate

those different devices and then based on the different USB specifications for those different device classes fuzz them and identify vulnerabilities in the host but in addition to that some of the other stuff that we've done around us be within vehicles is is pretty interesting I mean we found lots and lots of vulnerabilities in device device drivers but also one one interesting example that we saw we were doing a combination kind of active runtime testing using using tools and also a hardware tear down that resulted in us being able to pull the firmware off the head unit the infotainment system in the car and someone was looking through the the firmware kind of strings of the firmware

and reverse engineering is in ida pro and find something that looked pretty interesting and came up to the group of guys that were doing the testing in the vehicle and said got something that we want you to try we're not quite sure whether it works but this we think that we we've got an attack and it turned out that the authentication mechanism that was being used to determine whether firmware that was going to flash the the head unit on a USB stick the way the authentication was done was it was looking for the presence of a file with a certain file name to also be on that USB stick so that file didn't have to have any

content at all it just had to have a certain file name so if a file with that far name was present and a binary blob file was also present it would flash the firmware of the head unit great authentication so stuff like that with USB is that is always quite interesting video protocols is another interesting area I means we're seeing more and more cameras and sensors in vehicles for you know devices and mechanisms to help parking more more easy for the the occupants lots and lots of cameras and different video protocols and a lot of people aren't aware of the fact that there are that there's lots of bi-directional communication that goes on in these video protocols especially

the likes of hdmi and we've got dedicated test tools that allow us to to emulate those different protocols and fuzz the the video drivers basically again those those tools are open-source they're available and I get a repo we see lots of examples of media protocols that are supported in head units so by head unit I'm talking near these infotainment systems they used to be called car radios and they got bigger and bigger bigger screens typically called head units in the in the automotive industry but they're supporting more and more of these media codecs so videos different audio formats and image formats why anyone would want to put their photo library in their car I'm not quite sure but yeah the

capability is there sir you know fill the the hard disk with with photos so that you can look at them all on your unit but you know as we all know the the parsers for these complex media codecs are often buggy and can result in things like memory corruption vulnerabilities and important to note and this will kind of link into something I talk about a bit later that the the passes that are used for these different codecs you'll often have like one central parser that passes data regardless of what source it comes from so you know when we're testing within the vehicle it's quite easy to use USB as a way of injecting these different images in a kind of

fuzzing context but if you've got some kind of wireless protocol that allows you to send an image or some other kind of media to the vehicle it will be that same parser that's processing that data I've got implications of using open source media passes there because often when we find vulnerabilities as a result of fuzzing with embedded systems it's quite difficult if it's an in-vehicle assessment to actually triage those bugs and you know gain a real kind of understanding of the root cause and how exploitable they are that kind of thing so if you can determine that the parser or any other component within the vehicle that you're fuzzing is actually an open source component you can then do

your fuzzing kind of off board and it's much easier to triage so you know we've had examples in the past again where we've been doing a combination of you know hardware teardown firmware extraction reverse engineering of that alongside fuzzing within a vehicle and the people doing the firmware analysis have seen indicators like strings with version numbers or application names library names that show that it's an open source component so that then makes our job much easier because if we if we're fuzzing it we find a crash we can download the open source implementation of that library and see if it also crashes it when it's running on Linux and that it's far more easy to work out what the real

world impact of that is so you know talk about fuzzing we've got lots of different fuzzing tools got a custom fuzzing framework called first labs that allows us to kind of interface with lots of wired and wireless protocols to test all this stuff so onto the wireless side of things you see Bluetooth in most cars these days primarily used for pairing your mobile phone allowing you to upload your address book to the head unit and we do a lot of testing around Bluetooth both pair with the device paired and unpaired so you know when you pay your device you have to go through this mutual authentication process with pins but of course as part of that process

there is this kind of sub protocol that is working to to perform that pin authentication and if you find a vulnerability in that you can attack Bluetooth without knowing the the pin and without having to pair so we've demonstrated kind of preparing and post pairing attacks against bluetooth with one of our tools this tool isn't currently open source infrared this is an interesting one so we were doing a test a whole vehicle test for client and it had rear seat entertainment so you had LCD screens in the the seat backs so the rear occupants could watch DVDs and the like and they had an infrared remote control handset so that from the back they could control the head unit and we

thought okay what this this looks interesting to have a little play with and the thing that made it more interesting was when we realized that infrared actually works through the car windows when the the door when the doors are closed and the car was locked and the first thing that we did was we wanted to be able to fuzz the infrared pass to see if we could identify if we can put it into some kind of diagnostic mode or demo mode to identify functionality that wasn't supposed to be there and because of the limitations of these consumer infrared protocols you're unlikely to find things like buffer overflows memory corruption vulnerabilities but we did identify some

scenarios whereby it was clearly changing the the refresh rate for example on the screen so the screen would go black but nothing particularly exciting and anyway we kind of moved on to other things in in the assessment and later on we'd identified some exposed canvas wiring on the vehicle so the stuff that dave was talking about you need to plug into the the on-board diagnostics port which is normally underneath the dashboard but if you can find exposed cam wiring outside the vehicle then and you can plug it into there then obviously that's an interesting attack so we had found this at a certain point on the outside of the vehicle but when the car was locked and

alarmed the canvas was asleep so even even though we could connect into it we couldn't actually perform any of the techniques that they was talking about we needed to wake the canvas up and then we remembered this infrared tool that we developed and the fact that worked through car windows so what we were able to do is actually when the car was locked and alarmed send infrared through the car window to the head unit which will actually turn the head unit on which change the overall power level of the vehicle and woke up the canvas so once the canvas is then awake we could then do the attack via the exposed can wiring tire pressure monitoring systems

so in some countries around the world like in the US this is mandatory that you have some form of tire pressure monitoring so that the the driver can tell if the tires are burst or you've got some kind of puncture for safety reasons and obviously with the the wheels rotating the easiest way to do this is actually to put RF transmitters on the the tire pressure valves on each of the tires and they look a bit like that so they've got built-in radio transmitters within them and they then transmit periodically the current tire pressure to a receiver that's within the vehicle and it will then display on the dashboard what your tire pressure is for each of those tires

one of the tests that we did for a vehicle the types of vehicles they had they were very concerned about what they called the VIP hijack scenario where if as an attacker group you could follow a VIPs car and make the chauffeur of that VIPs car think that all the tires at burst because if they think the tires of bursts it's kind of like a social engineering attack really you can convince them to pull over and then you could physically hijack the vehicle and using software-defined radios we demonstrated that it's pretty easy to do replay attacks against these type of protocols reverse engineering the RF protocol that sent from the tire pressure sensor to the the onboard

receiver was reasonably trivial and it was you know easy to demonstrate that using a following vehicle and a directional antenna this is an easy attack to pull off and you know that's that's pretty much across the board with these these tpms sensors we haven't found examples of these radio-based tpms sensors that you can't do replay attacks against because you know they they just hadn't considered the requirement for security within them there is another type of tpms called indirect tpms that instead of using RF transmitters on each tire it actually measures the wheel rotation using the ABS ECU's but not quite so popular certainly not within four by four vehicles actually for number of different reasons Wi-Fi so

we see lots of examples of Wi-Fi clients and Wi-Fi hot spots within vehicles and a range of different potential attacks scenarios against each of those one interesting one that that we came across was although in the vehicle that we were looking at it didn't have a default hotspot enabled it had a a Wi-Fi client that was that would always try and connect to previously associated hotspots that the the owner had configured it to so you could think of a scenario whereby the owner of the vehicle will configure it to their home Wi-Fi so when they drive home and sit on the drive they could sink their music their mp3's with their car and they're there now as a home for example and as

an attacker you could find out what the essay SSID was of the the home network that they were connecting their car to and you could set up a rogue access point and their car would then connect to you but the interesting point here was when you connected to the head unit there are a bunch of exposed services one of which was SSH and there was a default root password on ssh which you can connect to via the Wi-Fi so once you've connected to that because of the lack of segregation between the head unit and the vehicle network so the the can bus that they was talking about although you couldn't send arbitrary cam data there was an API that you could

communicate with and we were able to turn off the safety functions within the car via this Wireless attack so a das features and safety functions that you see on cars one of the ones on this vehicle was advanced emergency braking so if the lonely road enabled that we were able to disable that via Wi-Fi without them realizing which is quite serious remote keyless entry more and more we're seeing vehicles with this as an option so essentially the way that it works is instead of the vehicle owner having to press a button on their key fob as long as they've got their key fob in their pocket the moment they touch the handle the door handle the car sends a signal

525 kilohertz to the key fob to find out if it's in range if it's within a roundabout and meters range of the car then it sends the message back to the car over 433 megahertz saying yes I'm the key key key fob I'm in range unlock the door and the door will unlock now the relay station attack involves two attackers each with a box of tricks and basically the scenario is your two attackers follow the target let's say to a supermarket car park one attacker stands by the car while the the victim goes and does their shopping attacker to make sure that they walk very closely to the victim as they're walking around the supermarket and attacker one who stood

by the car holds the handle of the car it sends the signal of 125 kilohertz to their blue box the blue box proxies the RF bandwidth over long-range comms to the red box and basically the car thinks that the key fob is right next to the car on the door opens that picture there is of some kit that we use as part of assessments of this type of technology and we were doing a test only the other day on a brand new vehicle I won't even tell you what country it came from but it's a brand new vehicle that's still vulnerable to this there are many many vehicles that have remote keyless entry enabled that are vulnerable to this

attack which is why it's the method of choice of organized crime at the moment and when you hear about high-end vehicles being stolen and shipped abroad this is the technique that they're using typically in fact we we even heard the other day because through one of our partner companies that they deal a lot with police forces who you know are involved in trying to track down these these organized crime gangs and apparently the latest technique that they're using is when they when they go and break into a car using this technique that carry a pocket full of broken glass and they'll sprinkle the broken glass on the floor next to where the car was just to hide the fact that

they've used a relay station attack to steal the car and make them make the police officers think that they've smashed the window so longer range attacks I talked about telematics the the primary communications mechanism for telematics is the mobile network so at the telematics normally communicates either via a a tcu component tonight its control unit component within a head unit or a separate tcu box somewhere in the vehicle and we use these RF shielded boxes during our assessments so that so for example that black box there is a usurp software-defined radio we can spin up a rogue mobile base station using that and then we can put the telematics box inside the RF shielded box it will

then connect to our base station rather than the public base station we can try doing things up man in the middle attacks you know intercepting the data between the telematics unit and the telematics service provider we can also fuzz the radio base band on these telematics units GPS is a really interesting one I mean this is not just for cars this is you know all of transport and also you know personal handheld devices GPS is relied upon so much these days but within vehicles you know some of those scenarios that I talked about where services are leveraging the capabilities of telematics they rely on GPS so for example if you've got the the e call

service a European service where yo emergency services are automatically called when your car crashes and the airbags are deployed that uses the GPS information received by your car to tell emergency services where to send the ambulance to so yeah relied upon quite heavily now what kind of things could we do if we could emulate the entire GPS satellite constellation well obviously we could speed for location which yeah it's a bit obvious on a bit dull unless it's an autonomous vehicle in which case is very dangerous more interestingly we can do things like spoofing the date and the time so we've got a virtual time machine which enables us to do things like make the GPS receiver think it's

this specific date at this specific time and we can test for the y-20 38 bug when the 32-bit address space wraps 20 so kind of similar to the y2k bug really and you know we see lots of systems in transport that are relying on very accurate date and time information that we can manipulate of course we can also furs the gps radio stack and we can do some creative attacks such as the center of the earth attack which I'll demonstrate in a minute so there were a few videos of these

so we have here is an example of spoofing the GPS location for the head unit here hex it to a software-defined radio it's a good play RF the way f is emulating the entire GPS couple a constellation and you can see from the screen the roughly and several under the not button button and palace in fact where an artisan channel then this example here we're in the same office as the head units now thinks that our location is in the middle of the Pacific it's up to Easter Island then is final example where air and same office location again and the head unit is now quite confused it's not quite sure where we are because we look past the location

the latitude and longitude are 350 and the altitude is set to minus 6 million thinner than 31,000 meters which is actually in a molten core in the center gear so last year we did some research looking at da be radio as I'm sure you're all aware in the UK all new vehicles or at least the majority of new vehicles are fitted with da be radios these days and it massively increases the attack surface remotely of head units because of the complexity associated with the DA be protocols so not only is the the underlying protocol multiplex data very complex and you can inject potential vulnerabilities into their that when the receiver passes those it triggers memory corruption type

vulnerabilities the DAV protocol allows you to layer other protocols and services over the top so for example you can send in addition to a range of different audio codecs you can send images so JPEGs and pngs so this is typically used for showing that album artwork and also you know if you listen to a radio station maybe a photo of a DJ that's currently on you can in fact send video over da be I've never seen it actually implemented and I think it would be pretty low quality but the the protocol stack allows you to do it it even has support for sending IP and Java so what could possibly go wrong so we've we developed a talk will dabble that

allows us to test all of this and obviously da b is a broadcast medium so if you find a vulnerability that relates to a specific type of vehicle or certain type of head unit you can send one attack and send it to multiple vehicles simultaneously so some of the common themes that we've seen there's definitely inadequate segregation all over the place not just between different can segments so the stuff that they was talking about you tend to see multicam vehicles these days whereas in the olden days you'd have like one flat cam Network and all the ECU is connected to that now you have multicam networks with high speed can and medium speed cam and then you have gateways in between

them but those gateways aren't necessarily security gateways they're just mechanisms for routing between them and when we have seen security gateways as Dave we found quite a lot of vulnerabilities in in cam gateways it's it's interesting because you know can gateways are essentially a firewall for the cam Network and if you think what it was like in the the network infrastructure world in the late 90s when you know Network firewalls were first starting to to be used there was this concept that you put the throw a firewall in and it solves all your security problems there's there's definitely an element of that in the automotive world and not necessarily an appreciation that the security of that security did sorry the

configuration of that security device is extremely important it's not just the presence of a security device lots of what we call the embedded systems mindset so security through obscurity a misunderstanding of you know what needs to be protected and how it needs to be protected and that's basically down to the fact that a lot of these ECU's historically haven't been honorably connected to you know the internet or telematics service providers or you know Wi-Fi networks so they haven't had to think about security in the same way it's always been a box that you need to get physical access to in order to to attack infotainment systems we're starting to see more and more using more

conventional operating systems you know historically five years or more ago you would see more esoteric implementations of operating systems on head units you know kind of more real-time operating systems when you still see those today like qnx for example but we're starting to see a lot more linux on infotainment systems and that there's again with this kind of embedded systems mindset the kind of engineering teams within the automotive space haven't necessarily got the the background knowledge and expertise in cyber security to understand what hardening processes need to be applied to these operating systems so again you know Paul easily guessable administrative passwords we see all the time and we see assumptions about security being been provided by the

mobile networks or the telematics services because it's such a connected ecosystem that like going back to that big picture out at the beginning if you're developing a telematics solution that involves that say a smartphone app that's communicating with a telematics service provider that telematics service providers sending its data for a mobile network operator that's then got to connect to this telematics control unit is developed by somebody else that's embedded in a car that's developed by somebody else there's all kinds of assumptions about who's doing which bits of the security and sometimes those assumptions completely break down which is why when we do for example man-in-the-middle attacks against the mobile network with a telematics unit and we can do a downgrade attack from 3g

two to two and a half g so a 2g sorry so that we can you know intercept the data we in some instances find that the developer of the telematics solution has just made the blanket assumption that the motive is the mobile operators responsibility to encrypt the data so it's all in the clear and now we're man-in-the-middle in it and we can send the data to the telematics control unit to say unlock this vehicle and finally we're seeing integration of functionality in a bid to reduce driver distraction and improve safety that's actually at odds with this segregation requirement to improve cybersecurity so a good example of this is that is a tower safety functions so in the past

you'd have had a button on the dashboard that you depressed to say right I want to turn on advanced emergency braking now it gets to the point where you've got so many buttons on the dashboard is distracting the driver and it's causing a safety problem so what do you do you include that functionality is a tick box in the head unit rather than physical button but then if you manage to compromise that head unit via a Wi-Fi attack you can now just find the function that turns off the advanced emergency braking whereas before it was physically separated and he had a button and that you know that communications path went nowhere near the head unit so that's

quite an interesting one we're seeing more and more of that so how does the industry fix this stuff we're great advocates of secure development lifecycle so basically considering security right from the beginning rather than getting to the end going for the we need a pen test of this solution before we go live and then finding out you've got a fundamental design floor and you've got to go start from scratch again okay five minutes left so yeah I'm sure a lot of you know what I know about the sdl I won't talk about it in great detail but that's it essentially it's considering security right from cradle to grave of a system what can be done

awareness the industry the automotive industry still needs the awareness of what what these risks are to be raised cybersecurity standards needs to be developed there are a number of standards under development and there is a there is a so only because I'm not connected to a network there's the the most mature of those is is actually some guidelines from the Society of Automotive Engineers called J 3061 and it's about guidelines when developing vehicle systems there's an iso standard that's also being developed but that's a long way off at the moment my understanding so as i said they need to a full of school development lifecycle and of course independent security assessment is key so making sure that when they're

developing it they're not Mike in their own homework thank you very much any questions so we are yet that there's been a lot of talk about trying to implement pki within the the cam network so that you know ECU's authenticating with each other but we've not seen any of that in real world implementations yet I don't know David you want to comment on any of that's because as a result of smear it's something that we know some of the OEMs the car manufacturers are discussing and thinking about whether it's applicable to their vehicle networks and the important thing to think about here is the fact that the cam Network this vehicle network that's in most vehicles

is very very old and a lot of the the OEMs have actually started to appreciate that their next-generation vehicle platforms could use a different network that would lend itself more to security mechanisms that aren't really applicable to can there is actually nice a standard a quorum breath is 15 7 64 or something but that is the use of pki over the canvas of Diagnostics but the problem is at the moment is none of the ecu's have a secure storage mechanism for the cryptographic secrets required to securely implement pki so you could have the ecu's that i could you speak either way you're going to store you dear cryptographic secrets unless you've got secure boot telematics the

we've we've certainly seen examples of it in telematics rather than the vehicle network that's then for 4g and 3g isn't it the mutual between the base station and the

some some of the telematics providers are are thinking about how they could implement that yeah it's not something that we've seen yeah real world examples of it it's okay yes Dave in fact we can sit with one of our reference clients is Duff trucks in Eindhoven and Dave's been heavily involved in that so you can talk about yes that's interrupt it's even easier to do exploitation Stefan can because you've got a fine j1939 FMS the fleet management standard which standardizes all the messages in the truck and what they do well not every single one with a large subset so there'll be a message for air breaking they'll be a message for reporting the fuel use of your message for turning on

the changing how the diff works and things like and they're all standardized so you could easily look at those and figure out what they are yes what you how do you miss you it's a very tricky one is why it's still prevalent across you know many many different vehicles there are a number of mechanisms that people have tried to use using timing because especially if you want to proxy it a really long range mean the attack that we've got will work over a kilometre but if you wanted to use it you know between countries via the 3g network for example you're introducing delays in there which can be detected and you can use that as some

kind of mitigation specifications in military hardware but you're not going to get that immigrant in the car due to the expense so yeah there's the that's really really important point actually all of the security features that needs to get implemented in cars need to be as cheap as possible all the car companies just won't adopt them I mean the car industry is known about that relay station attack for eight years and if the current mitigation that's available for it is too expensive they won't put it on the cars because they'll lose competitive advantage in what is very a very competitive market oh the ones the ones that aren't vulnerable are the ones who aren't using remote keyless entry

basically they shouldn't be selling it as a feature when it is an issue hmm exactly you you make the risk decision you yep

yeah so so I mean it's down to again that's a cost issue so the technology that they're using in the key fobs the chipset that they use there is a chip and alternative chipset that they could have changed here a long time ago that would have meant that that attack was impossible but that chipset is more expensive so yeah but the it was down to the capabilities of the chip and the fact that the the chips that they were using were there was an alternative chip that they could use that would have mitigated