Automotive Penetration Testing: Protocol UDS

[Applause] thank you um so hello today we will talk a bit about Automotive again after Martin of course and we will discuss about the specific protocol UDS or unified diagnostic our methodology how we will approach it during our pen testing and how we fast it and how eventually we ended up um uh finding this vulnerability in most of the biggest oems that we were testing uh some stuff about me I&#39;m a senior cyber security consultant for oxygen cyber security by day by night I&#39;m an independent security researcher uh I want to hack everything like especially cars I&#39;m really addicted to Troopers as you can see and for more boring stuff from my CV you can go to crossplace.com um I want to give some props to Nils and Enrico from their talk yesterday they did some really good introduction to UDS but let&#39;s uh give Ultra introduction uh this is a high level overview of many of you from the computer science field and networking you would like you would know the OSI model and this is something similar for the automotive sector and the different interfaces that might exist in the different vehicles that we&#39;re testing basically we will focus on the application layer our Target and more specifically to the UDS on can but everything you will learn on this talk and you can replicate it in all the different interfaces so we will basically attack it through Khan but you can UDS is more or less the same on Flex trade doip Lin and all the other interfaces that you might find in a vehicle and can host UDS or unified Diagnostics let&#39;s talk a bit about the method structure of UDS review this messages first of all we have a couple of a pair of arbitration IDs this can be either 11 bits or 29 bits they are two one for the server which is the vehicle and another one for the client which is usually the tester or the device of the service department that plugs to your OBD to do the Diagnostics or communicate with any cu in your vehicle then we have the protocol protocol control info which states if it&#39;s a single frame If the message that we&#39;re sending is a single frame if it&#39;s more than one frames we state if it&#39;s a first frame or a consecutive frame and it we also State the flow control frame when we need to receive more than one messages but this is more into the isotp protocol and we don&#39;t need to spend a lot of time on it then the most interesting part and the one that we will focus on is the service IDs so under the UDS the unified Diagnostics you can find a lot of services that you can communicate with them you can communicate and perform perform specific actions this service ID is it&#39;s only one byte and there are several standard IDs under the iso but there are the and the rest of them are just manufacturer specific and we have to find them ourselves some of the services have also a sub-function byte and this sub function byte specifies which exact functionality of the service we need to to use in this in the specific scenario this is also one byte and there are also some several standardized sub-function ideas for each service and all of the rest are manufacturer specific that we have to find ourselves the rest is data applicable data to its service and then we have padding on our test cases because we will use a specific tool we will just use the zero zero but padding but you can find many different iterations of that let&#39;s start focusing on the service ID because it will be the one the main topic that we will see today and as you can see in UDS services in a specific service you will have a specific request Sid with the corresponding response ID service ID so for example here you can see that in one of the I have some examples of services one of it is the diagnostic session control for example when you need to send this uh 10 1 0 byte as a service ID in order to request a change in the session that you are into in the specific ECU that you are targeting and the response will be a 50. so you should expect a different byte from your request next we have the negative responses so as you see we have the same services but the response will be always a 7f so if you receive a 7f then you should look at the sub function ID so the sub function ID of the negative response or else a negative Response Code and this will help us enumerate further the ECU and find out why we get a negative response is it actually a service is it not why is it rejecting us is the service supported is the sub function supported or not so this will help us better enumerate the ECU and find out why this service is responding with a negative response next let&#39;s see about some of the requirements that we will need because in order to test an ECU with UDS you will need some prerequisites uh of course you need to have a vehicle and a way to interface with the device and some software we have the vehicle let&#39;s assume that we have it the way to interface with the device usually we try to use some some tools that are widely adopted they have a good Community they&#39;re supported by the Linux kernel and we can communicate with them in an unobstructed way the tools that we usually use basically we&#39;re not developers we are basically basing our development and research on python which is easy and fast to develop something there are some libraries that you can use like isotp python python controls and some widely adopted tools on the industry it&#39;s copy that there was a talk yesterday for this specific part of scapiti Automotive one can utils cutting Caribou which will be the one that we will talk today and can map is basically a security testing tool for automotive the good thing is that it&#39;s modular so you can just develop your module pass it like pull it to the GitHub repo and the community will see will make the changes and they will accept it or not there is zero knowledge needed so you&#39;re you just plug your can adapter to your vehicle and you can start enumerating and passing this is the help page for example you can see the different modules that exist there is the doip module UDS UDS files which is the one that we developed also the doip we developed it there is a fuzzer module and many more in order to communicate with an ECU but let&#39;s start fuzzing this is why you are here uh what is fuzzing first of all uh it&#39;s the supply of unexpected or of expected or unexpected Behavior we analyze the result and that way we understand the Target and we monitor for unexpected Behavior so basically we can find unexpected behavior in many places and believe me in this talk you will see that we can find it in the most unexpected places let&#39;s start but they are with the arbitrary IDE enumeration uh uh first of all we have to find with Target ID is on the specific bus that we&#39;re connected because every CU has a different pair of IDs we have to see if there are 11 bit or 29 bits and if they&#39;re standardized IDs under the iso or manufacturer specific ah for the arbitrary the enumeration basically we are iterating through uh the all the arbitrary IDs this is an example of the 11 bit arbitrary IDs that goes from 0 to 7ff in hexadecimal format of course we send uh basically a diagnostic session control for default session because usually uh every all not usually mainly in all of the issues that we tested you have to find the default session on this ECU and we&#39;re iterating through all the different uh available points to find out if we get a positive or negative response after its iteration and we resend the request to prove the existence of server and client IDs to see it in practice I have a demo here you can see we&#39;re using regarding Caribou UDS Discovery module so that way we can discover on this specific interface and this the specific password that we are connected uh uh how many IDs that we can find we can find so how many ecus this is on a vehicle and all the tests are in a vehicle of 2022 I will not reveal the manufacturer but it&#39;s real life test cases on real vehicles that we found in the wild and as you can see in a couple of seconds we have the results we have the client IDs with the corresponding server IDs this means that we have different ecu&#39;s and we can connect communicate with them uh through or by sending from the client ID messages to the server ID that they cannot be accepted so yeah here you can see client IDs corresponding server IDs in order to communicate you just communicate through this uh to IDs and expect the messages back yep here for example is a specific ECU with these specific IDs we are connected to the OBD Port of the vehicle not something extreme and custom connection through specific buses but just an OBD device connected to the OBD Port under the steering wheel of the vehicle and here you can see the difference in the different results that we have here you can see a positive response from an ECU the in the First Column you have the interface count zero in this example in the second ECU from the enumeration you have you can see that it sends a 10-01 in all the messages ten zero one so default session on the Chain session request and you can see that some of them of course are responding with the 500 one and some of them are responding with a 7f so then you have to replicate your results and see uh slowly with CCU was responding in order to have the appropriate results in the end and not have false positives uh something similar is the service ID enumeration it&#39;s really similar it&#39;s way simpler and way faster because it&#39;s only one byte long it&#39;s ECU has different sets of services and you get an immediate response for existing Services of course we have the UDS request here is the similar you just Supply now because you already know the different arbitrary IDs you specify those arbitrary ideas to the tool and you iterate through the different services from zero to 7f and you monitor for positive or negative responses with the result being the list of the available services here we have another simple demo really fast you can see iterating through all the possible uh services and here we can see a really well defined ECU with no proprietary and not manufacturer specific Services all of them are defined by the iso which is also something that it&#39;s included in caricarbu and you can if if the service is mentioned in the iso you will find it also here we will use some of the services later in order to fuzz and use the the rest of the attacking points and similarly we can also enumerate the sum function byte but it&#39;s a bit tricky there are several different diagnostic sessions and sub functions may only exist under this specific session or ECU modes for example you can switch to a bootloader mode where only a specific sub services will only exist on this mode so you have to thoroughly test it and find all the possible outcomes that you can find in this ECU negative responses can also help us clear things out a bit and that&#39;s why I said that it&#39;s a useful tool to enumerate and find more information about the ECU so now that we have a basic understanding of the UDS and how it works and how all the services are laid down let&#39;s take some fascinating and data use cases that we have throughout our pen tests what we found and how we managed to exploit those issues with really simple to be honest attacking methodologies um there are several security and safety critically so using the vehicles we have to keep that in mind and usually there are no applicable preconditions on those ecu&#39;s in order to execute some functions that can result in not only security issues but also safety issues one of these examples is it&#39;s the ECU reset which does as it says like it resets an ECU in different ways which can directly affect the safety critical components security critical components and even the functionality of other issues on other buses of the vehicle that are interconnected uh uh some the sub functions of a security set can be hard reset key on off reset soft reset and enabler disabled rapid power shutdown but there can be also some manufacturer specific sub functions as discussed before that you have to enumerate through them and see depending on the reaction of the vehicle or the negative responses what you can do with them here it&#39;s an example from the same vehicle this is not an injection of messages into the can bus that presents these methods as Martin said from 2011 it&#39;s something it we basically reset an ECU and it never gets up until a complete power cycle and this means that depending on the criticality of the safety of the CCU it will have the appropriate result so if this result if this ECU is the battery management system you might cut off from the whole battery of the electric vehicle or if it&#39;s the Searing ECU you might lose the control of an electric steering ECU which of course you can understand it&#39;s dangerous and throughout our appendix we found also that there will no requirements on the speed of the vehicle on many of our assessments this is another example you can see here that the blind spot light the blind spot LED it&#39;s blinking when you reset it so you can imagine some scenario when a user is really used to this blind spot that it works properly but after some point after like a couple of years that he is used to it you can potentially Target him and make a really specific scenario that you can drive him to another vehicle in a targeted thing yeah another scenario can be writed by identifier or Android database identifier so there are some predefined memory locations in its ECU that are mounted like the UDS protocol there are two bite size addresses and usually the host vehicle information that you can find like the VIN like some information the mileage and other we will see later and size has to be specified and fixed by the manufacturer um here we request data parameters request that the parameters are passed by the host ECU as you can understand so the data that we send or we request are parsed and have to be passed by the ECU and so as you can understand supplying unexpected amount and type of data can potentially result in classes and memory overflows and we saw that in the wild it&#39;s really difficult to exploit it properly but because we had the ability to plug a debugger a proper debugger from the manufacturers we saw that it was actually concerning and we could find the memory overflows on the ccus maybe someone more focused on it it can potentially exploit it further uh is this the game over that we discussed not yet let&#39;s see some juicy stuff that can be found inside that identifiers first of all we found secret Keys we found passwords we found my leads just yes and commands that can get executed in an underlying OS yes many times you have a Linux systems Android systems especially on the vhu so the head units which are also ecu&#39;s and if you find on the data identifiers some commands maybe you have to enumerate it further because here we have an example from a thesis we did with the university with one of our interns and it&#39;s directly replicating results from a client because we could not reveal actually the results from these pen tests but let me focus on that first of all on the First Column of the result you can see that this is the identifier as I said to byte identifiers and then you have the hexadecimal data that you receive from the ECU if we turn this hexadecimal data to like ASCII you can see that it&#39;s a command it was a software update command in this case it&#39;s a pi that replicates this vulnerability and what we can do with it we can write to this day identifier if there is no prerequisite for a security access to right do this identifier you can write your own command or pipe a new command and then get code execution from the Wi-Fi access point of the vhu or from any other connections like broader it&#39;s Flex Ray or any other connections that you can get a network connection to the specific ECU noteworthy services that you might be interested in following up and doing your own research is communication control right memory by address so you can find also memory addresses inside any cus that you can write and read from with UDS rooting control and request upload and then for the main part of of the talk and the service that we will approach and attack is the UDS security access this is the main solution to restrict UDS functions under security mechanism so you have this security mechanism which is algorithmically secure and like there it has different levels of security access access and manufacturers hide let&#39;s say uh different uh functionality under this security access it&#39;s a CD algorithm implemented and obscured by the manufacturer so the way that the key is derived from the seed should not be revealed and usually there are some leaks online or there are some seeds that get leaked or algorithms or some people reverse those algorithms in order to get access to these ecu&#39;s this is a representation of how the UDS security access works so we have the client and the ECU those two has have to communicate through the arbitrary IDs first of all the client sends the seed request to the ACU the client can be either you as an attacker or the service department devices that usually uh are available on when you go for service to fix your ECU or to update it or anything after the seed request the ECU generates a random seed and calculates the key out of it with the predefined algorithm from the manufacturer the random seed is sent to the client and the client has to also calculate the key and send the calculated key to the ECU so you can understand that the client has to know this algorithm in order to make this pairing between the two different ecu&#39;s and eventually they see you verify the key and Grant access to the client here I have an example and keep this example in your mind it&#39;s requesting seeds to a specific ECU in the vehicle that we targeted before and I want you to keep it in mind because later we will basically do the same and you will find you will see the difference in results as you can see here we are requesting like a lot of seeds every line is a seed and it can be considered a really secure seed because it&#39;s it&#39;s long it cannot be brute forced easily like it will take years or millions of years to fast to Brute Force this seed and find get security access and there are also mechanisms to block you from sending calculated Keys again and again so you can be easily blocked by that here you can see uh some in more detail first of all we have a diagnostic session control so we change the session from the default session which is the default session of the ECU the default State we get a positive response with 50 0 3. now we are already in the extended diagnostic session and after that we request the seed with the service ID 27 and 0 1 because it&#39;s the zero one uh security access that we are trying to get on then you have uh at 10 because we are specifying that this is a bigger a bigger method than it can fit on a single message and then we have uh the flow control methods in order to receive more than one messages and construct the whole seed in order to parse it analyze it calculate the key out of it and send it back together to get security access common attacks in this service can be pre-calculated to fasting as we discussed and brute forcing which is not directly applicable in seeds like this but we also saw two byte seeds that can be easily brute forced fault injection fallback function triggers and algorithm reverse engineering which is the basis for leaks where you can find for many vehicles online to use and understand how these algorithms work but what Randomness means in their way and is this process really random what if we and I will pass this to you what if we could request the same seed more than once this is what we&#39;re trying to approach today and we need to also mention that this is a really common issue in the embedded World due to the limited resources of all these devices so when you have so limited resources your source of Randomness usually is not the most advanced this is where sakar comes to this game and he developed uh basically he started his research as a PhD and he released his research as a revisiting remote that had killed Saints and the candid vulnerability is the one that we are targeting in order to request the same seed more than once because of low Sid entropy and like this is a really interesting research it&#39;s more than the candid vulnerability it&#39;s a whole kill chain if you are interested just go go on to it basically what we analyzed and what we found is that most of the ecu&#39;s that we tested has Randomness based on the processor uptime and the process show up time resets during boot which is an issue and it&#39;s a weak source of Randomness most of the industry is affected like we worked with a lot of oems and tier one suppliers and we found out that like almost 90 percent of the ecu&#39;s that we tested had this vulnerability and this of course States our previous example as like vulnerable the city is not random so if the seed can be guessed we can also pre-calculate the key and get or if we own a pre-calculated key we can grant access we have access to the security access of UDS but let&#39;s find that&#39;s it uh we started by developing custom scripts for Python and Sim customization for its Target ECU was needed so it wasn&#39;t so so good that we customized our tools for every ECU and we needed to automate it somehow to start Gathering more data and faster testing during our assessments this is an explanation of our attack because basically in the research there was no explanation of the attack it was just a theoretical uh and theoretical representation and how they ended up on these results but here I will explain how we will approach it first of all we issue any security set to the Target ECU basic reboots of course this has a separate requested that the ECU reset is unrestricted and under security access we have to have access to the ECU reset in order to do it and usually we need the hard DCU reset because this will reset the system the processor uptime the ACU reboots and then we wait for the predefined amount of time before we received request to the ECU we received the seed if the desired seed is not the one that we want we go again and we request we reiterate through the steps but if this the seed is the one that we need we send the pre-calculated key that we already own as attackers and we Grant security access this is the module that we developed it&#39;s under the current Caribou it&#39;s already available you can download it and play with your car please be careful don&#39;t drive and while testing and don&#39;t break anything they will not fix it there are two sub modules it&#39;s the delay father and the randomness faster it seemed like the proper targets basically because first of all we&#39;re not developers secondly it&#39;s open source it&#39;s modular they were really helpful they helped us fix some of the issues in the implementation and we implemented it both for Khan and deut implementations of the UDS first of all we have we have the seed Randomness faster and this is the tool to evaluate an ECU if it&#39;s uh if it&#39;s actually vulnerable or not to this vulnerability to see weak seed randomness and if you remember the last thing I I told you about this uh the seed request that we shown here we have the evaluation of it with our tool and you can see something strange that every seed is the same this is an extreme scenario it&#39;s actually an actual ECU from an actual vehicle that we had and we are connected to the OBD port and why this happens is that um every time we recite it we get this predefined delay between the ECU reset and the seed request the seed request which in this case is 1.102 and because the chains in seeds like the iteration of the seeds is really slow so it happens every one second or something we can actively find the same seed every time we reset the ECU the thing is that in real world scenarios in other real world scenarios that we had we didn&#39;t manage to get so many same duplicates but you can see in the end that we State the duplicates that were found because in the analysis from he found out that if 20 of the seeds that you receive from the Thousand seeds in total are duplicates then you are pretty sure that the ECU is vulnerable to this two weeks at the randomness here we have the example yes as you see all the seeds are the same because this is he was really vulnerable and it states as the duplicate in the end uh this is an example from the dump that we have at the same time you can see that we send an issue reset which is the 11 service and zero one is the hardest you reset we get a positive response if you get a negative response that you have to find out why is it negative and enumerate it further in case it needs some specific security access or some different diagnostic session in order to execute it then we get into the diagnostic session the extended diagnosis session and then we start requesting the seeds we iterate read with its proposed to do it to replicate it a thousand times as I said and if you found 20 that is duplicate then you can rest assured that it&#39;s vulnerable uh yeah this is as I said like we discussed about this uh but mainly the point that I need to do um to stress is that first of all you need an accurate microcontroller in order to communicate and get accurate results and secondly you will need some kind of more accurate language as discussed with Nils before python has not some so accurate delays so you would need to uh Port it somehow otherwise but for General enumeration and general evaluation of an ECU for this aspect we found out that it&#39;s pretty okay for our pen test that&#39;s pen test assessments and now about our second Tool uh we have the delay fuzzer and we asked ourselves what if we already have a seed and pre-calculated key pair what happens next and these seed and pre-calculated keys can be as discussed leaked through forums uh it can be calculated by someone that have security to access to the security access mechanism and again leaked somewhere or by tampering is used to the service departments and intercepting those seeds those single pairs in order to then inject them and gain security access mechanism security access if the ECU is vulnerable to this uh and this tool helps us find the delay which is needed between basic reset and the seed request in order to get security access with the seed that we already own so basically we fast the delay until we find the successful months for for this specific seed that we own the pre-calculated key this is the tool with the different options we have the session type we have the target which is the seed that we own the pre-calculated key and the source and destination arbitrary IDs and demo time as you see we iterate through different seeds we request seeds these are again different seeds because it&#39;s uh they&#39;re not we change the delay between the ECU reset and the seed request and as you can see we receive different seeds but in the end at some point we found out that the seed that we predefined on our tool that we specified on our tool was found with a specific delay that we can potentially use for a POC to get security access every time so this tool is basically to evaluate and find the delay that is needed between this ECU reset and the seed request find the delay and create the POC out of it in order to further enumerate the device after having a security access with the single predefined key and Seed pair that you obtain somehow and this is our game over this is how we tested all the ecus mainly sometimes we are just ask for a single seed and predefined key in order to prove to them that we can gain security access with a single leak that can happen to to the industry uh here it&#39;s an explanation of the tool again like you can see that we specify our module the UDS fuzz and the sub module which is the delay fuzzer here we specify and this is a really junky way let&#39;s say to specify the different sessions but because of the like of the manufacturer specific implementations uh the normal coverage of cutting cardboard didn&#39;t help us so we had to find another way to specify the different sessions and Seed requests that can be found on an ECU so after enumerating you are specifying the different bytes that you want to be executed on the canvas so here we have 1003 for Diagnostic session control to the extended diagnostic session and 2701 for the seed request for the security access here we have the seed that we can potentially have a seed and pre-calculated key pair already obtained from some League or from some some enumeration that we did and here we have the result after receiving a lot of seeds and by iterating through the delays we saw that in this specific delay our predefined seed that we supply to the options was found and this means that the target seed was found with this delay and we can use it in our POC so we basically don&#39;t need to calculate the key this thing just goes away we don&#39;t have any Randomness and we just attack this device and gained complete Security Access that we can basically rewrite firmwares we can have further access to the unit we can tamper the device which means that we you can also tamper the network the buses the different buses that exist inside the vehicle and of course you can understand that it&#39;s really dangerous when we&#39;re discussing about safety critical ecu&#39;s the pre-calculated key interception can happen in many ways as discussed it can be leak by weak links in the supply chain service shops are the main targets of Tumblr dcu&#39;s malicious issues can also be used to liquid calculated keys and of course online sources and forums that might have somehow obtained these keys mitigations because we also Aspen testers we always have to supply a mitigation strategy and Supply our proposal on how to mitigate those issues basically almost always we suggest that there has to be an HSM and it starts to appear on embedded devices and specifically to use on the latest models many times we found that but the thing is that several modes are still affected and usually we saw that even by not being able to bypass on the normal mode of the V of the ECU if we manage to get into the bootloader mode which is not something really difficult in most of the cases but you need to find out by reversing or by further enumerating the device on how to get into this bootloader mode you can potentially also bypass the security access because the implementation the HSM is only used on the normal mode and not in the bootloader mode this was also a real real pen test finding and yeah it&#39;s basically a way to bypass the mitigation that they applied so they have to start implementing it also in other modes of the acus and yeah of course I don&#39;t have to mention it random seeds I have to always use a proper source of Randomness because otherwise they are not random uh yeah this went too fast I just have to say that um like from my from our experience in the automotive sector uh we saw that many companies don&#39;t care and that&#39;s a really bad thing to do especially when we&#39;re discussing about safety critical components safety critical devices and this is our job that&#39;s why we are here uh we as pen tester Service as researchers and everyone here has to pass this culture and start discussing about safety critical components and safety critical findings that can potentially affect the industry in a different way okay these things might not affect some normal device you might not care about the leak of your private key if you&#39;re not a private Savvy or something else but in these vehicles it&#39;s the culture has to change and we are the ones that will do this change so we&#39;ll start this change yes so thank you for your attention please hackers Make Love Not War and yeah see you next time [Applause] hey yeah thanks for the nice talk and a very inspiring last words um do we have any questions from the audience thank you and at first thank you for your nice talk and also the the layout for you from your slides um I have a question on the authentication method do you see that there is a change in the way the authentication happens like the cdk is not enough that we need to be recruit also um usually it depends on the implementation of the algorithm from what we saw so there are more secure algorithms and less secure also there are many in many cases we found fallback algorithms that you can potentially trigger through some function and they&#39;re way less secure so I can see it as a good enough way to secure the vehicle but you have to implement it properly you have to implement the proper crypto and now there are different services that they&#39;re used you have you have also private keys in the game but you can understand that you have to also implement it correctly you have to have some HSM to store your keys you have to find a way to update the keys if they get leaked or if you&#39;re like certificate Authority gets tampered so it&#39;s all about the implementation in the end yeah and the security access algorithm might be enough but we have other ways to secure it yeah okay thank you very much you&#39;re welcome any other questions so in your first attack when you were able to uh make get one particular seat um derived from that how would you get the particular key because I understand the second example where you have already is seed and key pair and then you are having a particular delay but what I didn&#39;t get at least not from the talk is if you have just a seat without having the algorithm because if you have the algorithm then you do not need to do this then you can just generate a particular key so Molly I think you got the question yeah yeah I got it so basically there are two different tools the first one is to evaluate the seed randomness of the device basically it&#39;s not a continuation of the attack the second tool is not the continuation of the attack with the first one you you run it in order to see if you can find duplicate seeds so as I said the default is to run it thousand times receive thousand seeds and from that if you have 20 which is duplicate then you can consider your ECU vulnerable and you can start searching further to see if you can find the city pair that you can use for the delay Hazard afterwards and get security access so it&#39;s not a way to find the pre-calculated key it&#39;s a way to evaluate if your ECU is vulnerable with the First Tool and with the second tool if you already have the pair then you start fuzzing with your your seed to see the delay in which this seed appears then build your POC and get security access thank you anyone else we do have quite a few minutes left so after you gain security access do you usually go further excuse me I cannot hear you okay after you got the security access do you usually go further and do you also do further expectation steps once you have security access on an ECU uh I I didn&#39;t get it like when I when I get to once you once you have security access what are other things you do afterwards is there any like any other things you do in your usual pen tests um to show the criticality of security access yes so basically uh we try to approach uh the services that are only approachable from the security access this can be uh upload of data right to specific addresses right by that by identifiers that might be restricted under security access so you try to find things that are only only accessible through the security access basically the main target is completely right of the firmware so we request or dump the firmware in order to get it tamper it then upload to it and possibly play with the algorithm or get something inside that identifiers and prove that we can completely rewrite firmware with this security access if it doesn&#39;t allow us we have to find other services that are accessible through this security access that is vulnerable in order to prove it yeah but usually it&#39;s tampering with data inside the ECU that you can only do it through security access and might be really critical so for example you might have temperature thresholds for battery Management systems that this can create huge deals like not explosions but it can completely like destroy the batteries on an electric vehicles after a specific temperature that is only hard-coded in the ECU other examples might be change of the broadcasting through the OBC connector in electric vehicles so that way you can connect to a malicious charger really easily and get access to it through this interface and yeah basically it&#39;s changing of the memory like altering of the memory and tampering with it how many different levels of security access have you encountered like is that a binary thing secure and insecure or no usually there are more than one in a single ECU so and not only a single one but as Nils and Enrico discussed yesterday it&#39;s really difficult to find out the specific path to go through it and get the security seat for example in specific ecu&#39;s so the thing is that not only more than one security access mechanism exists in a single ECU but it&#39;s also a bit tricky to get into them in many cases uh getting to them then gives you different functionality so there might be a simple security access in the programming security access where you can only rewrite firmware on the programming security access so you have to further enumerate when you get the security access to see what are your possibilities and what you can do after it I think you only quickly mentioned about possible memory corruption attacks that you could find with fuzzing did you explore this and if not why not we didn&#39;t exploit it basically like there was a similar discussion yesterday we are not doing security research we are doing pen tests I&#39;m doing the security research on the side and the thing with fantasy is that you have limited time uh usually these devices have different architectures we can be supplied by the manufacturer with a debugger that we can use to see that the actual memory is overflown or some memory corruption is happening but in order to exploit it properly it takes too much time and they don&#39;t know any any real life scenarios when where someone managed to actually exploit it I can see it happening more in Linux based systems with arm processor for example which is more well documented and it will be easier to do because UDS also exists in the as I said in the vehicle head units which run more commonly used architectures and systems but the tool you develop this fuzzle it could be used to find such things and no no you can actually fast like you can even fuzz it with you you can fast this pre-specified space for example in that identifiers by doing some specific configuration in the father module of Karen Caribou but the thing is that even when you overflow it you have to spend significant amount of times to exploit it properly to build the poc in order to get something out of it memory corruption doesn&#39;t directly give you something it&#39;s just a finding that you know it exists if you don&#39;t exploit it it&#39;s not as severe or if you don&#39;t agree with that yeah please let me know no thanks yeah that&#39;s how we write our findings basically okay thank you I think that&#39;s all I I have okay you go first yeah um I have a question did you try or do you know that um because on the list on how you can get student key pairs um I think as Ken is a bus for example you could easily use your regular car built in a sniffer on the canvas like a passive one drive to your workshop and have a maintenance and then they use their diagnostic devices and then you can later more or less analyze all of the stuff that was going on on the canvas and you I&#39;m pretty sure you&#39;ll find some seed and key pairs yeah yeah that&#39;s sort of that&#39;s that&#39;s the main target basically you you have to Target the network inside the different buses that are interconnected uh usually I don&#39;t think that you can easily do it from the OBD but tampering the different interconnections between the ecu&#39;s would be pretty straightforward and you can do it like put your car into the service department and just listen to all the buses to see what you what you got out of of it yeah okay cool I think you had one yeah maybe a bit a different weird kind of question but I was wondering um in your penetration testing work did you do you somehow develop a feeling for which types of easy use are usually more vulnerable than others so if you have to test a specific type of ECU do you sometimes know beforehand that it&#39;s going to be vulnerable just because of the type of ECU it is yeah I will just say that it&#39;s usually depending on the manufacturer and not the type of the ECU yeah we have some idea beforehand when we do the full vehicle penetration test for example because it&#39;s like you have a different ecu&#39;s from different tier one suppliers so we have an idea that vccu might be vulnerable to that so this is a lead to move towards this path of exploitation but the thing is that if you&#39;re doing a penetration test you have to cover some methodology something like what we described today for this specific protocol and you have to cover the whole thing in order to be able to say that this is secure or not you cannot just skip stuff so even while knowing this is just a lead to go faster through this vulnerability and see if it&#39;s vulnerable or not in the end cool thank you for your questions I appreciate it all right then thanks again and let&#39;s thank the speaker again thank you [Applause]

[Applause] thank you um so hello today we will talk a bit about Automotive again after Martin of course and we will discuss about the specific protocol UDS or unified diagnostic our methodology how we will approach it during our pen testing and how we fast it and how eventually we ended up um uh finding this vulnerability in most of the biggest oems that we were testing uh some stuff about me I&amp;#39;m a senior cyber security consultant for oxygen cyber security by day by night I&amp;#39;m an independent security researcher uh I want to hack everything like especially cars I&amp;#39;m really addicted to Troopers as you can see and for more boring stuff from my CV you can go to crossplace.com um I want to give some props to Nils and Enrico from their talk yesterday they did some really good introduction to UDS but let&amp;#39;s uh give Ultra introduction uh this is a high level overview of many of you from the computer science field and networking you would like you would know the OSI model and this is something similar for the automotive sector and the different interfaces that might exist in the different vehicles that we&amp;#39;re testing basically we will focus on the application layer our Target and more specifically to the UDS on can but everything you will learn on this talk and you can replicate it in all the different interfaces so we will basically attack it through Khan but you can UDS is more or less the same on Flex trade doip Lin and all the other interfaces that you might find in a vehicle and can host UDS or unified Diagnostics let&amp;#39;s talk a bit about the method structure of UDS review this messages first of all we have a couple of a pair of arbitration IDs this can be either 11 bits or 29 bits they are two one for the server which is the vehicle and another one for the client which is usually the tester or the device of the service department that plugs to your OBD to do the Diagnostics or communicate with any cu in your vehicle then we have the protocol protocol control info which states if it&amp;#39;s a single frame If the message that we&amp;#39;re sending is a single frame if it&amp;#39;s more than one frames we state if it&amp;#39;s a first frame or a consecutive frame and it we also State the flow control frame when we need to receive more than one messages but this is more into the isotp protocol and we don&amp;#39;t need to spend a lot of time on it then the most interesting part and the one that we will focus on is the service IDs so under the UDS the unified Diagnostics you can find a lot of services that you can communicate with them you can communicate and perform perform specific actions this service ID is it&amp;#39;s only one byte and there are several standard IDs under the iso but there are the and the rest of them are just manufacturer specific and we have to find them ourselves some of the services have also a sub-function byte and this sub function byte specifies which exact functionality of the service we need to to use in this in the specific scenario this is also one byte and there are also some several standardized sub-function ideas for each service and all of the rest are manufacturer specific that we have to find ourselves the rest is data applicable data to its service and then we have padding on our test cases because we will use a specific tool we will just use the zero zero but padding but you can find many different iterations of that let&amp;#39;s start focusing on the service ID because it will be the one the main topic that we will see today and as you can see in UDS services in a specific service you will have a specific request Sid with the corresponding response ID service ID so for example here you can see that in one of the I have some examples of services one of it is the diagnostic session control for example when you need to send this uh 10 1 0 byte as a service ID in order to request a change in the session that you are into in the specific ECU that you are targeting and the response will be a 50. so you should expect a different byte from your request next we have the negative responses so as you see we have the same services but the response will be always a 7f so if you receive a 7f then you should look at the sub function ID so the sub function ID of the negative response or else a negative Response Code and this will help us enumerate further the ECU and find out why we get a negative response is it actually a service is it not why is it rejecting us is the service supported is the sub function supported or not so this will help us better enumerate the ECU and find out why this service is responding with a negative response next let&amp;#39;s see about some of the requirements that we will need because in order to test an ECU with UDS you will need some prerequisites uh of course you need to have a vehicle and a way to interface with the device and some software we have the vehicle let&amp;#39;s assume that we have it the way to interface with the device usually we try to use some some tools that are widely adopted they have a good Community they&amp;#39;re supported by the Linux kernel and we can communicate with them in an unobstructed way the tools that we usually use basically we&amp;#39;re not developers we are basically basing our development and research on python which is easy and fast to develop something there are some libraries that you can use like isotp python python controls and some widely adopted tools on the industry it&amp;#39;s copy that there was a talk yesterday for this specific part of scapiti Automotive one can utils cutting Caribou which will be the one that we will talk today and can map is basically a security testing tool for automotive the good thing is that it&amp;#39;s modular so you can just develop your module pass it like pull it to the GitHub repo and the community will see will make the changes and they will accept it or not there is zero knowledge needed so you&amp;#39;re you just plug your can adapter to your vehicle and you can start enumerating and passing this is the help page for example you can see the different modules that exist there is the doip module UDS UDS files which is the one that we developed also the doip we developed it there is a fuzzer module and many more in order to communicate with an ECU but let&amp;#39;s start fuzzing this is why you are here uh what is fuzzing first of all uh it&amp;#39;s the supply of unexpected or of expected or unexpected Behavior we analyze the result and that way we understand the Target and we monitor for unexpected Behavior so basically we can find unexpected behavior in many places and believe me in this talk you will see that we can find it in the most unexpected places let&amp;#39;s start but they are with the arbitrary IDE enumeration uh uh first of all we have to find with Target ID is on the specific bus that we&amp;#39;re connected because every CU has a different pair of IDs we have to see if there are 11 bit or 29 bits and if they&amp;#39;re standardized IDs under the iso or manufacturer specific ah for the arbitrary the enumeration basically we are iterating through uh the all the arbitrary IDs this is an example of the 11 bit arbitrary IDs that goes from 0 to 7ff in hexadecimal format of course we send uh basically a diagnostic session control for default session because usually uh every all not usually mainly in all of the issues that we tested you have to find the default session on this ECU and we&amp;#39;re iterating through all the different uh available points to find out if we get a positive or negative response after its iteration and we resend the request to prove the existence of server and client IDs to see it in practice I have a demo here you can see we&amp;#39;re using regarding Caribou UDS Discovery module so that way we can discover on this specific interface and this the specific password that we are connected uh uh how many IDs that we can find we can find so how many ecus this is on a vehicle and all the tests are in a vehicle of 2022 I will not reveal the manufacturer but it&amp;#39;s real life test cases on real vehicles that we found in the wild and as you can see in a couple of seconds we have the results we have the client IDs with the corresponding server IDs this means that we have different ecu&amp;#39;s and we can connect communicate with them uh through or by sending from the client ID messages to the server ID that they cannot be accepted so yeah here you can see client IDs corresponding server IDs in order to communicate you just communicate through this uh to IDs and expect the messages back yep here for example is a specific ECU with these specific IDs we are connected to the OBD Port of the vehicle not something extreme and custom connection through specific buses but just an OBD device connected to the OBD Port under the steering wheel of the vehicle and here you can see the difference in the different results that we have here you can see a positive response from an ECU the in the First Column you have the interface count zero in this example in the second ECU from the enumeration you have you can see that it sends a 10-01 in all the messages ten zero one so default session on the Chain session request and you can see that some of them of course are responding with the 500 one and some of them are responding with a 7f so then you have to replicate your results and see uh slowly with CCU was responding in order to have the appropriate results in the end and not have false positives uh something similar is the service ID enumeration it&amp;#39;s really similar it&amp;#39;s way simpler and way faster because it&amp;#39;s only one byte long it&amp;#39;s ECU has different sets of services and you get an immediate response for existing Services of course we have the UDS request here is the similar you just Supply now because you already know the different arbitrary IDs you specify those arbitrary ideas to the tool and you iterate through the different services from zero to 7f and you monitor for positive or negative responses with the result being the list of the available services here we have another simple demo really fast you can see iterating through all the possible uh services and here we can see a really well defined ECU with no proprietary and not manufacturer specific Services all of them are defined by the iso which is also something that it&amp;#39;s included in caricarbu and you can if if the service is mentioned in the iso you will find it also here we will use some of the services later in order to fuzz and use the the rest of the attacking points and similarly we can also enumerate the sum function byte but it&amp;#39;s a bit tricky there are several different diagnostic sessions and sub functions may only exist under this specific session or ECU modes for example you can switch to a bootloader mode where only a specific sub services will only exist on this mode so you have to thoroughly test it and find all the possible outcomes that you can find in this ECU negative responses can also help us clear things out a bit and that&amp;#39;s why I said that it&amp;#39;s a useful tool to enumerate and find more information about the ECU so now that we have a basic understanding of the UDS and how it works and how all the services are laid down let&amp;#39;s take some fascinating and data use cases that we have throughout our pen tests what we found and how we managed to exploit those issues with really simple to be honest attacking methodologies um there are several security and safety critically so using the vehicles we have to keep that in mind and usually there are no applicable preconditions on those ecu&amp;#39;s in order to execute some functions that can result in not only security issues but also safety issues one of these examples is it&amp;#39;s the ECU reset which does as it says like it resets an ECU in different ways which can directly affect the safety critical components security critical components and even the functionality of other issues on other buses of the vehicle that are interconnected uh uh some the sub functions of a security set can be hard reset key on off reset soft reset and enabler disabled rapid power shutdown but there can be also some manufacturer specific sub functions as discussed before that you have to enumerate through them and see depending on the reaction of the vehicle or the negative responses what you can do with them here it&amp;#39;s an example from the same vehicle this is not an injection of messages into the can bus that presents these methods as Martin said from 2011 it&amp;#39;s something it we basically reset an ECU and it never gets up until a complete power cycle and this means that depending on the criticality of the safety of the CCU it will have the appropriate result so if this result if this ECU is the battery management system you might cut off from the whole battery of the electric vehicle or if it&amp;#39;s the Searing ECU you might lose the control of an electric steering ECU which of course you can understand it&amp;#39;s dangerous and throughout our appendix we found also that there will no requirements on the speed of the vehicle on many of our assessments this is another example you can see here that the blind spot light the blind spot LED it&amp;#39;s blinking when you reset it so you can imagine some scenario when a user is really used to this blind spot that it works properly but after some point after like a couple of years that he is used to it you can potentially Target him and make a really specific scenario that you can drive him to another vehicle in a targeted thing yeah another scenario can be writed by identifier or Android database identifier so there are some predefined memory locations in its ECU that are mounted like the UDS protocol there are two bite size addresses and usually the host vehicle information that you can find like the VIN like some information the mileage and other we will see later and size has to be specified and fixed by the manufacturer um here we request data parameters request that the parameters are passed by the host ECU as you can understand so the data that we send or we request are parsed and have to be passed by the ECU and so as you can understand supplying unexpected amount and type of data can potentially result in classes and memory overflows and we saw that in the wild it&amp;#39;s really difficult to exploit it properly but because we had the ability to plug a debugger a proper debugger from the manufacturers we saw that it was actually concerning and we could find the memory overflows on the ccus maybe someone more focused on it it can potentially exploit it further uh is this the game over that we discussed not yet let&amp;#39;s see some juicy stuff that can be found inside that identifiers first of all we found secret Keys we found passwords we found my leads just yes and commands that can get executed in an underlying OS yes many times you have a Linux systems Android systems especially on the vhu so the head units which are also ecu&amp;#39;s and if you find on the data identifiers some commands maybe you have to enumerate it further because here we have an example from a thesis we did with the university with one of our interns and it&amp;#39;s directly replicating results from a client because we could not reveal actually the results from these pen tests but let me focus on that first of all on the First Column of the result you can see that this is the identifier as I said to byte identifiers and then you have the hexadecimal data that you receive from the ECU if we turn this hexadecimal data to like ASCII you can see that it&amp;#39;s a command it was a software update command in this case it&amp;#39;s a pi that replicates this vulnerability and what we can do with it we can write to this day identifier if there is no prerequisite for a security access to right do this identifier you can write your own command or pipe a new command and then get code execution from the Wi-Fi access point of the vhu or from any other connections like broader it&amp;#39;s Flex Ray or any other connections that you can get a network connection to the specific ECU noteworthy services that you might be interested in following up and doing your own research is communication control right memory by address so you can find also memory addresses inside any cus that you can write and read from with UDS rooting control and request upload and then for the main part of of the talk and the service that we will approach and attack is the UDS security access this is the main solution to restrict UDS functions under security mechanism so you have this security mechanism which is algorithmically secure and like there it has different levels of security access access and manufacturers hide let&amp;#39;s say uh different uh functionality under this security access it&amp;#39;s a CD algorithm implemented and obscured by the manufacturer so the way that the key is derived from the seed should not be revealed and usually there are some leaks online or there are some seeds that get leaked or algorithms or some people reverse those algorithms in order to get access to these ecu&amp;#39;s this is a representation of how the UDS security access works so we have the client and the ECU those two has have to communicate through the arbitrary IDs first of all the client sends the seed request to the ACU the client can be either you as an attacker or the service department devices that usually uh are available on when you go for service to fix your ECU or to update it or anything after the seed request the ECU generates a random seed and calculates the key out of it with the predefined algorithm from the manufacturer the random seed is sent to the client and the client has to also calculate the key and send the calculated key to the ECU so you can understand that the client has to know this algorithm in order to make this pairing between the two different ecu&amp;#39;s and eventually they see you verify the key and Grant access to the client here I have an example and keep this example in your mind it&amp;#39;s requesting seeds to a specific ECU in the vehicle that we targeted before and I want you to keep it in mind because later we will basically do the same and you will find you will see the difference in results as you can see here we are requesting like a lot of seeds every line is a seed and it can be considered a really secure seed because it&amp;#39;s it&amp;#39;s long it cannot be brute forced easily like it will take years or millions of years to fast to Brute Force this seed and find get security access and there are also mechanisms to block you from sending calculated Keys again and again so you can be easily blocked by that here you can see uh some in more detail first of all we have a diagnostic session control so we change the session from the default session which is the default session of the ECU the default State we get a positive response with 50 0 3. now we are already in the extended diagnostic session and after that we request the seed with the service ID 27 and 0 1 because it&amp;#39;s the zero one uh security access that we are trying to get on then you have uh at 10 because we are specifying that this is a bigger a bigger method than it can fit on a single message and then we have uh the flow control methods in order to receive more than one messages and construct the whole seed in order to parse it analyze it calculate the key out of it and send it back together to get security access common attacks in this service can be pre-calculated to fasting as we discussed and brute forcing which is not directly applicable in seeds like this but we also saw two byte seeds that can be easily brute forced fault injection fallback function triggers and algorithm reverse engineering which is the basis for leaks where you can find for many vehicles online to use and understand how these algorithms work but what Randomness means in their way and is this process really random what if we and I will pass this to you what if we could request the same seed more than once this is what we&amp;#39;re trying to approach today and we need to also mention that this is a really common issue in the embedded World due to the limited resources of all these devices so when you have so limited resources your source of Randomness usually is not the most advanced this is where sakar comes to this game and he developed uh basically he started his research as a PhD and he released his research as a revisiting remote that had killed Saints and the candid vulnerability is the one that we are targeting in order to request the same seed more than once because of low Sid entropy and like this is a really interesting research it&amp;#39;s more than the candid vulnerability it&amp;#39;s a whole kill chain if you are interested just go go on to it basically what we analyzed and what we found is that most of the ecu&amp;#39;s that we tested has Randomness based on the processor uptime and the process show up time resets during boot which is an issue and it&amp;#39;s a weak source of Randomness most of the industry is affected like we worked with a lot of oems and tier one suppliers and we found out that like almost 90 percent of the ecu&amp;#39;s that we tested had this vulnerability and this of course States our previous example as like vulnerable the city is not random so if the seed can be guessed we can also pre-calculate the key and get or if we own a pre-calculated key we can grant access we have access to the security access of UDS but let&amp;#39;s find that&amp;#39;s it uh we started by developing custom scripts for Python and Sim customization for its Target ECU was needed so it wasn&amp;#39;t so so good that we customized our tools for every ECU and we needed to automate it somehow to start Gathering more data and faster testing during our assessments this is an explanation of our attack because basically in the research there was no explanation of the attack it was just a theoretical uh and theoretical representation and how they ended up on these results but here I will explain how we will approach it first of all we issue any security set to the Target ECU basic reboots of course this has a separate requested that the ECU reset is unrestricted and under security access we have to have access to the ECU reset in order to do it and usually we need the hard DCU reset because this will reset the system the processor uptime the ACU reboots and then we wait for the predefined amount of time before we received request to the ECU we received the seed if the desired seed is not the one that we want we go again and we request we reiterate through the steps but if this the seed is the one that we need we send the pre-calculated key that we already own as attackers and we Grant security access this is the module that we developed it&amp;#39;s under the current Caribou it&amp;#39;s already available you can download it and play with your car please be careful don&amp;#39;t drive and while testing and don&amp;#39;t break anything they will not fix it there are two sub modules it&amp;#39;s the delay father and the randomness faster it seemed like the proper targets basically because first of all we&amp;#39;re not developers secondly it&amp;#39;s open source it&amp;#39;s modular they were really helpful they helped us fix some of the issues in the implementation and we implemented it both for Khan and deut implementations of the UDS first of all we have we have the seed Randomness faster and this is the tool to evaluate an ECU if it&amp;#39;s uh if it&amp;#39;s actually vulnerable or not to this vulnerability to see weak seed randomness and if you remember the last thing I I told you about this uh the seed request that we shown here we have the evaluation of it with our tool and you can see something strange that every seed is the same this is an extreme scenario it&amp;#39;s actually an actual ECU from an actual vehicle that we had and we are connected to the OBD port and why this happens is that um every time we recite it we get this predefined delay between the ECU reset and the seed request the seed request which in this case is 1.102 and because the chains in seeds like the iteration of the seeds is really slow so it happens every one second or something we can actively find the same seed every time we reset the ECU the thing is that in real world scenarios in other real world scenarios that we had we didn&amp;#39;t manage to get so many same duplicates but you can see in the end that we State the duplicates that were found because in the analysis from he found out that if 20 of the seeds that you receive from the Thousand seeds in total are duplicates then you are pretty sure that the ECU is vulnerable to this two weeks at the randomness here we have the example yes as you see all the seeds are the same because this is he was really vulnerable and it states as the duplicate in the end uh this is an example from the dump that we have at the same time you can see that we send an issue reset which is the 11 service and zero one is the hardest you reset we get a positive response if you get a negative response that you have to find out why is it negative and enumerate it further in case it needs some specific security access or some different diagnostic session in order to execute it then we get into the diagnostic session the extended diagnosis session and then we start requesting the seeds we iterate read with its proposed to do it to replicate it a thousand times as I said and if you found 20 that is duplicate then you can rest assured that it&amp;#39;s vulnerable uh yeah this is as I said like we discussed about this uh but mainly the point that I need to do um to stress is that first of all you need an accurate microcontroller in order to communicate and get accurate results and secondly you will need some kind of more accurate language as discussed with Nils before python has not some so accurate delays so you would need to uh Port it somehow otherwise but for General enumeration and general evaluation of an ECU for this aspect we found out that it&amp;#39;s pretty okay for our pen test that&amp;#39;s pen test assessments and now about our second Tool uh we have the delay fuzzer and we asked ourselves what if we already have a seed and pre-calculated key pair what happens next and these seed and pre-calculated keys can be as discussed leaked through forums uh it can be calculated by someone that have security to access to the security access mechanism and again leaked somewhere or by tampering is used to the service departments and intercepting those seeds those single pairs in order to then inject them and gain security access mechanism security access if the ECU is vulnerable to this uh and this tool helps us find the delay which is needed between basic reset and the seed request in order to get security access with the seed that we already own so basically we fast the delay until we find the successful months for for this specific seed that we own the pre-calculated key this is the tool with the different options we have the session type we have the target which is the seed that we own the pre-calculated key and the source and destination arbitrary IDs and demo time as you see we iterate through different seeds we request seeds these are again different seeds because it&amp;#39;s uh they&amp;#39;re not we change the delay between the ECU reset and the seed request and as you can see we receive different seeds but in the end at some point we found out that the seed that we predefined on our tool that we specified on our tool was found with a specific delay that we can potentially use for a POC to get security access every time so this tool is basically to evaluate and find the delay that is needed between this ECU reset and the seed request find the delay and create the POC out of it in order to further enumerate the device after having a security access with the single predefined key and Seed pair that you obtain somehow and this is our game over this is how we tested all the ecus mainly sometimes we are just ask for a single seed and predefined key in order to prove to them that we can gain security access with a single leak that can happen to to the industry uh here it&amp;#39;s an explanation of the tool again like you can see that we specify our module the UDS fuzz and the sub module which is the delay fuzzer here we specify and this is a really junky way let&amp;#39;s say to specify the different sessions but because of the like of the manufacturer specific implementations uh the normal coverage of cutting cardboard didn&amp;#39;t help us so we had to find another way to specify the different sessions and Seed requests that can be found on an ECU so after enumerating you are specifying the different bytes that you want to be executed on the canvas so here we have 1003 for Diagnostic session control to the extended diagnostic session and 2701 for the seed request for the security access here we have the seed that we can potentially have a seed and pre-calculated key pair already obtained from some League or from some some enumeration that we did and here we have the result after receiving a lot of seeds and by iterating through the delays we saw that in this specific delay our predefined seed that we supply to the options was found and this means that the target seed was found with this delay and we can use it in our POC so we basically don&amp;#39;t need to calculate the key this thing just goes away we don&amp;#39;t have any Randomness and we just attack this device and gained complete Security Access that we can basically rewrite firmwares we can have further access to the unit we can tamper the device which means that we you can also tamper the network the buses the different buses that exist inside the vehicle and of course you can understand that it&amp;#39;s really dangerous when we&amp;#39;re discussing about safety critical ecu&amp;#39;s the pre-calculated key interception can happen in many ways as discussed it can be leak by weak links in the supply chain service shops are the main targets of Tumblr dcu&amp;#39;s malicious issues can also be used to liquid calculated keys and of course online sources and forums that might have somehow obtained these keys mitigations because we also Aspen testers we always have to supply a mitigation strategy and Supply our proposal on how to mitigate those issues basically almost always we suggest that there has to be an HSM and it starts to appear on embedded devices and specifically to use on the latest models many times we found that but the thing is that several modes are still affected and usually we saw that even by not being able to bypass on the normal mode of the V of the ECU if we manage to get into the bootloader mode which is not something really difficult in most of the cases but you need to find out by reversing or by further enumerating the device on how to get into this bootloader mode you can potentially also bypass the security access because the implementation the HSM is only used on the normal mode and not in the bootloader mode this was also a real real pen test finding and yeah it&amp;#39;s basically a way to bypass the mitigation that they applied so they have to start implementing it also in other modes of the acus and yeah of course I don&amp;#39;t have to mention it random seeds I have to always use a proper source of Randomness because otherwise they are not random uh yeah this went too fast I just have to say that um like from my from our experience in the automotive sector uh we saw that many companies don&amp;#39;t care and that&amp;#39;s a really bad thing to do especially when we&amp;#39;re discussing about safety critical components safety critical devices and this is our job that&amp;#39;s why we are here uh we as pen tester Service as researchers and everyone here has to pass this culture and start discussing about safety critical components and safety critical findings that can potentially affect the industry in a different way okay these things might not affect some normal device you might not care about the leak of your private key if you&amp;#39;re not a private Savvy or something else but in these vehicles it&amp;#39;s the culture has to change and we are the ones that will do this change so we&amp;#39;ll start this change yes so thank you for your attention please hackers Make Love Not War and yeah see you next time [Applause] hey yeah thanks for the nice talk and a very inspiring last words um do we have any questions from the audience thank you and at first thank you for your nice talk and also the the layout for you from your slides um I have a question on the authentication method do you see that there is a change in the way the authentication happens like the cdk is not enough that we need to be recruit also um usually it depends on the implementation of the algorithm from what we saw so there are more secure algorithms and less secure also there are many in many cases we found fallback algorithms that you can potentially trigger through some function and they&amp;#39;re way less secure so I can see it as a good enough way to secure the vehicle but you have to implement it properly you have to implement the proper crypto and now there are different services that they&amp;#39;re used you have you have also private keys in the game but you can understand that you have to also implement it correctly you have to have some HSM to store your keys you have to find a way to update the keys if they get leaked or if you&amp;#39;re like certificate Authority gets tampered so it&amp;#39;s all about the implementation in the end yeah and the security access algorithm might be enough but we have other ways to secure it yeah okay thank you very much you&amp;#39;re welcome any other questions so in your first attack when you were able to uh make get one particular seat um derived from that how would you get the particular key because I understand the second example where you have already is seed and key pair and then you are having a particular delay but what I didn&amp;#39;t get at least not from the talk is if you have just a seat without having the algorithm because if you have the algorithm then you do not need to do this then you can just generate a particular key so Molly I think you got the question yeah yeah I got it so basically there are two different tools the first one is to evaluate the seed randomness of the device basically it&amp;#39;s not a continuation of the attack the second tool is not the continuation of the attack with the first one you you run it in order to see if you can find duplicate seeds so as I said the default is to run it thousand times receive thousand seeds and from that if you have 20 which is duplicate then you can consider your ECU vulnerable and you can start searching further to see if you can find the city pair that you can use for the delay Hazard afterwards and get security access so it&amp;#39;s not a way to find the pre-calculated key it&amp;#39;s a way to evaluate if your ECU is vulnerable with the First Tool and with the second tool if you already have the pair then you start fuzzing with your your seed to see the delay in which this seed appears then build your POC and get security access thank you anyone else we do have quite a few minutes left so after you gain security access do you usually go further excuse me I cannot hear you okay after you got the security access do you usually go further and do you also do further expectation steps once you have security access on an ECU uh I I didn&amp;#39;t get it like when I when I get to once you once you have security access what are other things you do afterwards is there any like any other things you do in your usual pen tests um to show the criticality of security access yes so basically uh we try to approach uh the services that are only approachable from the security access this can be uh upload of data right to specific addresses right by that by identifiers that might be restricted under security access so you try to find things that are only only accessible through the security access basically the main target is completely right of the firmware so we request or dump the firmware in order to get it tamper it then upload to it and possibly play with the algorithm or get something inside that identifiers and prove that we can completely rewrite firmware with this security access if it doesn&amp;#39;t allow us we have to find other services that are accessible through this security access that is vulnerable in order to prove it yeah but usually it&amp;#39;s tampering with data inside the ECU that you can only do it through security access and might be really critical so for example you might have temperature thresholds for battery Management systems that this can create huge deals like not explosions but it can completely like destroy the batteries on an electric vehicles after a specific temperature that is only hard-coded in the ECU other examples might be change of the broadcasting through the OBC connector in electric vehicles so that way you can connect to a malicious charger really easily and get access to it through this interface and yeah basically it&amp;#39;s changing of the memory like altering of the memory and tampering with it how many different levels of security access have you encountered like is that a binary thing secure and insecure or no usually there are more than one in a single ECU so and not only a single one but as Nils and Enrico discussed yesterday it&amp;#39;s really difficult to find out the specific path to go through it and get the security seat for example in specific ecu&amp;#39;s so the thing is that not only more than one security access mechanism exists in a single ECU but it&amp;#39;s also a bit tricky to get into them in many cases uh getting to them then gives you different functionality so there might be a simple security access in the programming security access where you can only rewrite firmware on the programming security access so you have to further enumerate when you get the security access to see what are your possibilities and what you can do after it I think you only quickly mentioned about possible memory corruption attacks that you could find with fuzzing did you explore this and if not why not we didn&amp;#39;t exploit it basically like there was a similar discussion yesterday we are not doing security research we are doing pen tests I&amp;#39;m doing the security research on the side and the thing with fantasy is that you have limited time uh usually these devices have different architectures we can be supplied by the manufacturer with a debugger that we can use to see that the actual memory is overflown or some memory corruption is happening but in order to exploit it properly it takes too much time and they don&amp;#39;t know any any real life scenarios when where someone managed to actually exploit it I can see it happening more in Linux based systems with arm processor for example which is more well documented and it will be easier to do because UDS also exists in the as I said in the vehicle head units which run more commonly used architectures and systems but the tool you develop this fuzzle it could be used to find such things and no no you can actually fast like you can even fuzz it with you you can fast this pre-specified space for example in that identifiers by doing some specific configuration in the father module of Karen Caribou but the thing is that even when you overflow it you have to spend significant amount of times to exploit it properly to build the poc in order to get something out of it memory corruption doesn&amp;#39;t directly give you something it&amp;#39;s just a finding that you know it exists if you don&amp;#39;t exploit it it&amp;#39;s not as severe or if you don&amp;#39;t agree with that yeah please let me know no thanks yeah that&amp;#39;s how we write our findings basically okay thank you I think that&amp;#39;s all I I have okay you go first yeah um I have a question did you try or do you know that um because on the list on how you can get student key pairs um I think as Ken is a bus for example you could easily use your regular car built in a sniffer on the canvas like a passive one drive to your workshop and have a maintenance and then they use their diagnostic devices and then you can later more or less analyze all of the stuff that was going on on the canvas and you I&amp;#39;m pretty sure you&amp;#39;ll find some seed and key pairs yeah yeah that&amp;#39;s sort of that&amp;#39;s that&amp;#39;s the main target basically you you have to Target the network inside the different buses that are interconnected uh usually I don&amp;#39;t think that you can easily do it from the OBD but tampering the different interconnections between the ecu&amp;#39;s would be pretty straightforward and you can do it like put your car into the service department and just listen to all the buses to see what you what you got out of of it yeah okay cool I think you had one yeah maybe a bit a different weird kind of question but I was wondering um in your penetration testing work did you do you somehow develop a feeling for which types of easy use are usually more vulnerable than others so if you have to test a specific type of ECU do you sometimes know beforehand that it&amp;#39;s going to be vulnerable just because of the type of ECU it is yeah I will just say that it&amp;#39;s usually depending on the manufacturer and not the type of the ECU yeah we have some idea beforehand when we do the full vehicle penetration test for example because it&amp;#39;s like you have a different ecu&amp;#39;s from different tier one suppliers so we have an idea that vccu might be vulnerable to that so this is a lead to move towards this path of exploitation but the thing is that if you&amp;#39;re doing a penetration test you have to cover some methodology something like what we described today for this specific protocol and you have to cover the whole thing in order to be able to say that this is secure or not you cannot just skip stuff so even while knowing this is just a lead to go faster through this vulnerability and see if it&amp;#39;s vulnerable or not in the end cool thank you for your questions I appreciate it all right then thanks again and let&amp;#39;s thank the speaker again thank you [Applause]

Transcript for:Automotive Penetration Testing: Protocol UDS

Transcript for:
Automotive Penetration Testing: Protocol UDS