[MUSIC]
And we will have a five minute Q&A in the end of the talk.
And the talk is about nightmares in the automotive security.
And we have Thomas Sampini here, who is a pen tester with automotive.
And he will talk about the nightmares.
Welcome.
>> [APPLAUSE]
>> Thank you.
So hello everyone, I hope you're not drunk or sleepy.
I'm sleepy, but we will go through it.
So today we will talk about horror stories in the automotive industry.
I'm Thomas Sampinis, otherwise you might know me as Crow Tom.
This is the CCC edition.
It's been already once presented.
I'm Thomas Sampinis, as I said, I'm automotive pen tester lead by day.
In auxiliary cybersecurity and thanks a lot to this team for
the support and the help for this research.
And the security researcher by night.
I like to hack everything everywhere.
I don't really care.
I just like to hack everything that gets into my hands and
I really love security conferences.
For more, you can go to my website.
There are some specific goals for this talk.
First of all, I want to analyze the state of cybersecurity in
the automotive industry.
I want to present some unique and hopefully interesting for
you use cases, result of around 100 pen tests and
research projects in this industry.
Endorse and push more hackers to the automotive industry and
educate the new, the old and the bold of this industry.
And of course raise and
highlight the significance of security related devices.
Let's start with an overview of the state of cybersecurity in
the automotive industry and discuss where we currently are,
what is planned and where we're currently heading.
And there are several incidents throughout the years, but
I still get fascinated by the quality of the findings that
get discovered on the automotive industry into 2023 still.
Some examples from the last years are some fixed code
vulnerabilities in Nissan, for example, which is one of many
examples of this vulnerability in the wild.
Stealing keys with just USB cables, I mean, okay.
Key for vulnerabilities again and again.
Remote unlocks of whole vehicle fleets due to flaws in
series XM, unlocking and stealing vehicles due to easily
accessible campuses and really bad internal architecture,
something that we will also talk in this, speak about in
this talk.
And that's only a sample out of a huge list of similar
incidents in this sector.
I don't know if there is a light in the end of the tunnel, but
the automotive industry cannot be considered new.
The connectivity and technological aspect of it,
though, is not so old.
Entertainment and constant need for connectivity are the main
reasons for the technological advancements and integration
in this industry.
And usually we're talking about 100 plus year old industries
trying to catch up with some young startups.
And this is an example for you to understand what is the
current state of cybersecurity.
This is the BMW i7.
And outside of the common things that you usually see in
a vehicle, you see my whole living room.
Basically, all these things are interconnected.
All these services are connected to the internet and
exposed to some interfaces that are approachable by
attackers eventually.
In order to fight this, there are some regulations that get
introduced.
I don't want to bore you.
It's really late.
I don't want you to sleep.
Basically, to go through it really fast, it provides a set
of standards that must be met in order to ensure the
safety of road vehicles.
It requires operation of certified cybersecurity
management systems.
And in any case, in summary, it tries to shape the completely
unregulated mess that exists until now.
And the big caveat is that penetration testing is solely
based on the risk assessment of the target vehicle or the
target ECU.
Going into the first part, I want to have a discussion
about the tier one suppliers, which of course play a huge
role in the automotive industry, with cars being
literally like LEGOs, pieces of LEGOs that you construct from
different tier one suppliers in order to build the whole
vehicle.
To start talking about it, we need to talk about
cybersecurity requirements, which are developed and
distributed by OEMs.
And it's usually the engineering requirements for
cybersecurity risk management.
And the tier one suppliers should ideally comply to those
for correct and secure functionality of the supplied
components.
If those requirements are followed, though, it's a
different discussion.
So let's go through some real life examples that lead to
complete compromise of a vehicle in the most dumb way
possible.
And the reason for this, from my perspective, is that
several tier ones are based in countries with low
transparency and weak governance.
If you know what I mean.
And secondly, we don't know how clear are these cybersecurity
requirements in order to be followed by these tier one
suppliers.
And then if not only the OEM, but also the appendices
suppliers usually have a reactive approach to security
testing, which assumes that everything described on those
requirements is followed, which leads to shaping weak
penetration testing methodology and test cases
with high probability of losing important parts of
the attack surface.
To start with our first use case and the path to Game
Over, we need to understand a bit what is UDS.
Basically, it's one of the application layer protocols
that run on these electronic control units, the computers
inside the vehicle, for communication between them in
automotive electronics.
It allows diagnostic functionality, such as reading
and erasing fault codes, programming and reprogramming
ECUs, testing and monitoring of them.
It consists of several services, which can be used to
perform specific actions.
And the really common authentication schema in UDS is
the Security Access Service, or 0x27, which allows elevated
access to authenticated users.
And talking about this service, we need to understand
how it works in order to go on how we eventually bypass it.
And basically, there is a client, which is us as a
tester or some reprogramming tool, and the ECU.
The client that wants to be authenticated into the ECU
sends a seed request to the ECU.
The ECU generates a random seed and calculates the key by
using an algorithm for this calculation and the secret key.
It sends the random seed to the client, and the client,
using the same algorithm, the same secret key, has to
calculate the calculated key where the ECU verifies it and
grants access to the client if they are matching from both
calculations on each side.
Regarding this service and considering the trend of
loosely developed requirements, we have observed
several types of outcomes, including sloppy authentication
implementations, weak sources of randomness, something that
I talked last year in Troopers conference, and my talk UDS
fuzzing in the path to Game Over, and backdoors
implemented outside of the scope of the cyber security
requirements.
As an example, we have an extra security access sub-service
which is with extremely weak security for some reason.
And actually, that's the case here.
Here we have a real life example on the
screenshot on the right.
And the same process as we saw previously.
So we send a seed request to the ECU.
We are the client.
We send the seed request to the ECU.
We receive a random seed despite being four bytes.
It's debatable on if we can crack it and how long.
If there is a proper implementation, there should
be a new randomly generated seed every time.
In this case, this seed is always the same.
Every time we request it, we have the same seed.
And by testing the first key that we send, which is only
zeros, we manage to get a positive response.
The positive response here is the 6773.
And the ECU grants access to us.
And this eventually is a backdoor from our perspective.
Of course, there is no security in this case.
And while the tier one supplier, supply components
might follow the OEM cyber security requirement, that
doesn't mean that we only need to test by the book.
As you saw, by enumerating and finding an extra security
access subservice, we found out that we can bypass it
easily without any calculation, any secret algorithm, or any
secret key.
And we can get direct access to it by only supplying zeros.
In most cases, several misconfigurations exist
outside of the cyber security requirements.
The OEM doesn't know or doesn't want us to know.
So they don't communicate it.
And the tier ones did not inform the OEM in the end,
which is the backdoor use case that we had now.
Why?
I don't know.
The solution, from my perspective, from our
perspective, for the OEM is to build more strict cyber
security requirements.
For the pen-less suppliers like us and the researchers is
to build more robust methodology, which will cover
a realistic amount of test cases.
Don't build it solely based on the requirements.
Stop thinking only about the requirements.
Build it on the experience and the attack surface that you
have in front of you.
And of course, educate the client, OEM, tier one, or
anyone else.
Education is the biggest part here.
We need the client to understand what we found and
what can be the severity and the impact of it.
Moving forward, everything will be changed in the end.
But moving forward now, we need to talk about the main
bridge of connectivity of a vehicle to the real world
lately, which is the telematics unit, and how many
vehicles get connected in the network that eventually they
should not actually be.
First of all, almost no vehicles ship anymore without a
telematics unit.
Main purpose of a telematics unit is the secure update
procedures, which became a necessity.
There are some regulations also.
There are several running services, including a remote
vehicle management in most cases.
You can unlock doors.
You can start vehicle conditioning and many other
use cases that a user might need.
Might not.
I don't know.
And the TLDR is that please consider the applicable
connectivity while designing the architecture.
So now that we got a first taste of how things are
getting connected, let's dive into a real world scenario of
a supercar manufacturer in this case that pushed the
connectivity of their pre-production vehicle in
order to perform secure updates and remote management
of the fleet for personalized support of their clients.
In this case, and as a first part, we have a telematics
unit, an ECU handling the cellular connectivity and the
connection to the internet.
And this telematics unit is connected to the main head
unit over some kind of interface.
It can be an RS485, serial, Broadridge, which is
automotive ethernet, or anything else that is
applicable in automotive.
At this point, one ECU is already connected.
And considering that this kind of ECUs usually come with
several publicly available services, in many cases,
including SSAs, you can understand that this kind of
risk is not implemented properly.
But there are proper implementations limiting the
exposure at the minimum using hypervisors, for example, on
the head unit to isolate the exposed system from the rest
of the ECUs and the connectivity in the vehicle,
and gateways that filter all requests coming from the
exposed unit.
But I don't know if this is the reality, because what we
can see in the complete hypothetical, in this case,
architecture of this vehicle, because we're under NDA, of
course, the different domains of this architecture are
interconnected between them.
But the biggest problem here is that there are several
components directly connected to the head unit, as we can
see on the red lines, instead of passing through the gateway
for proper routing and filtering of the
target messages.
Is that really an issue?
Interconnected buses can act as a stepping stone in safety
critical attacks, and gateways are commonly used for message
filtering and routing, as we said.
By passing the gateway, as we saw in the previous
architecture, it results in direct interception and
communication of CAN messages.
And at this point, the target ECUs existing on those buses
can be analyzed, enumerated, and exploited without the
assumed restrictions from the protections that we mentioned.
And getting deeper into our attack scenario, let's
remember the UDS.
And this time, we will use the service 11, which is ECU
reset, which does exactly what the name implies.
It resets the target ECU in different ways, with most
important one being the hard ECU reset, which technically
performs a complete power cycle of the target unit.
In our experience, almost 90% of the target ECUs come with
no authentication or precondition for hard ECU
resets, which can lead to several
issues described later.
What is the outcome of this EV supercar?
As we can see, there are several ECUs that are
connected--
no.
Yes.
So basically here, we have a specific domain of ECUs that
are directly connected to the gateway and to the head unit.
And if we manage to compromise the publicly
accessible head unit, we will be able to access directly a
BMS, which is a battery management system, an
inverter, and the whole batteries that are connected as
ECUs to the head unit.
In this case, by supplying either an ECU reset to the BMS,
which is the battery management system, or a
combined ECU reset to all the batteries, one, two, or three,
or whatever is the number of it, we can stop the
communication between the batteries and the rest of the
vehicle and completely stop the vehicle, which was the
case as imagined.
Of course, there are NDAs.
We cannot show exactly what we did with this supercar.
And also, when we test these components, we don't test them
on the actual vehicle most of the time-- sorry, in a running
vehicle, but we test it in a controlled environment.
But I have another example where the same POC is running
on a blind spot detection sensor in one of my rentals,
which blinks when issuing ECU reset, because you perform a
complete power cycle, so the ECU just blinks.
And while not critical, not as critical as resetting the
batteries, it can potentially confuse the driver that there
is something on the blind spot, or even create issues
with the adaptive cruise control when relying on the
system for turns or lane changes.
To conclude, while it was a simple example, we were able to
see how bad architectures can lead to some
devastating results.
Automotive architecture, understandably, gets more
complicated due to the need for connectivity.
But architecture needs to be revised in a secure way
throughout the different iterations and not really in
old and outdated architectures used in vehicle iterations
with half the ECUs.
For this, I would suggest more internal buses to be
introduced when needed for proper segmentation and safety
critical and non-critical components.
And better designs should be considered from the first step
of production.
When the actual vehicle starts to be implemented and
developed, it's already really late to change such
significant parts of the architecture.
Moving forward, we need to have a talk about design choices.
We already briefly mentioned some of the pitfalls that the
industry fell into because of bad design choices in the
start.
But let me also give you some juicy insights that you will
hopefully appreciate.
Understandably, vehicle development is way more
complicated than simply designing and architecting a
vehicle network with several decisions that need to be made
under highly constrained budget and time.
One of the issues that need to be resolved is the physical
space of the components, the actual space that we will fit
everything inside.
And where these components will be placed, how they will
fit, are they light enough?
Also, weight is a big factor in this.
And other such questions that need to be answered in order to
create an efficient and working vehicle which doesn't
spend 30 liters per kilometer or has an efficiency of 50
kilometers per charge.
At this point, manufacturers need to make sure that
everything is secure, isolated, and inaccessible to
external buses.
But what happens if it's not?
In the car theft incident that we saw previously, we saw that
a vehicle getting stolen due to internal buses which were
accessible behind the front headlight of the vehicle.
That is a really accessible place, as you can imagine.
As an attacker, it can simply create a small hole behind the
wheel of the vehicle to access the bus.
And if the architecture is something similar to what we
saw in the previous section, potentially unlock the whole
vehicle and issue an ignition signal which will start the
vehicle and help the attacker start a road trip, which is
the case with this finding here from Ian.
During a full vehicle pentest, though, we really often stumble
upon some such issues with the radar, sliders, and lights being
the most vulnerable ones.
As most of the times, manufacturers connect these
components with internal buses.
And by combining bad architecture that we saw
previously with bad design choices, we can have some
really interesting results.
Taking as an example our previous diagram, we can see
that there are several cameras and radars in one of the buses
of the vehicle.
This would not be an issue considering that the bus is
isolated from other buses.
But because on the same domain we have the EBS, the
electronic braking system, it means that it needs access to
the braking and steering ECUs, which that's why we see the
interconnected bus inside the network.
Considering that all previous use cases are applicable, we
can see the scenario where due to bad design, an attacker
managed to get internal bus access through the front radar.
Due to bad architecture, he can access the braking system.
And by issuing an ECU reset to the EBS system, trigger an
emergency braking of the vehicle, he can start a
emergency braking of the vehicle with potentially
devastating results, as you understand.
If applied in a highway, for example, we can see
something like this.
And now let's watch a cute video from a truck
manufacturer, which will give us some insights on the current
topic and how we will move forward in the talk.
So on the near side, we have a battery isolator switch.
As with everything with computers on board, before we
call action service out, it's always worth just isolating the
vehicle, counting to 10, and let everything reset itself,
re-energize the truck, and see if that's corrected your fault.
No relation.
So completely unrelated on OEM.
I just need to emphasize the battery isolator and grab your
attention a bit with the video.
The battery isolator is included in many EVs, in many
fuel cell cars, and other heavy duty vehicles.
And it's mainly used for isolation of batteries, for
safety concerning incidents, isolation of
inverters and converters.
hard reset of ECUs and clearance of faults.
What this isolation does, like the name implies, it separates the direct current into the underlying components.
And it actually, we actually encountered it several times in our pentest and mainly in heavy duty vehicles like
trucks, buses, some boats and other devices like this that have applicable ECUs.
The main question here is if should they be accessible in an unauthenticated manner as we saw in the video
or if they should be restricted.
And to answer this question we are moving to the next chapter which is the bootloaders
and we need to talk a bit about it and how some really old vulnerabilities are becoming new again
and we can use them to bypass several restrictions.
The bootloader usually in electronic control units is architecture specific
but it can be accessed through the application layer protocols which is common alongside all the different architectures that are applicable.
The bootloader usually is used for reprogramming purposes in initialization of application section of the memory,
read and write from and to sensitive parts of the memory
and understandably security measures must be taken to restrict unauthenticated access to these bootloaders.
The hard truth is that most of the manufacturers do not restrict access to this part of the memory
which as you understand can supply access to some really critical functionality on the underlying systems.
Usually even if we get access to the bootloader some of the sensitive services are restricted to unauthenticated users
and most of the times these services are the ones responsible for secure update of the unit
as an example request download and upload, transfer data and other services are the ones that are usually restricted
under some security access implementation.
But most of the ECUs use this bootloader section to perform secure update of the target
and authentication subservices for reprogramming is different from the subservices used in application mode and other restricted tasks.
In this diagram we see a really simple representation of the application bootloader parts of the system.
The normal boot process starts from the bootloader and then ends up on the application part
where our implemented applications live and manage the tasks which the ECU is programmed to perform.
In some of the cases though we can use the application layer UDS, protocol UDS
and issue session change to the programming session which will technically redirect us directly to the bootloader
and usually this session is unrestricted and we can directly supply it and switch to the bootloader.
In our experience this UDS session control programming session is most of the times accessible as I said by unauthenticated users
but what happens if it's not? How do we bypass it?
I don't know if you remember the service ECU reset but in this case by supplying an ECU reset, a hard ECU reset
we technically issue a complete power cycle to the unit and the boot process starts from the start.
What we can do now is issue another service which is a tester present which does exactly what the service implies, the name implies
which is state that we are there so we don't have to supply again and again the same command, the same session change
so by issuing the ECU reset and then issuing a tester present we can stay to the bootloader mode even if the switch to programming session is restricted.
So what if even the ECU reset is restricted? What are we doing now?
Basically on a test bench scenario where we have the ECU on our test bench and we can directly supply power to it
if we have restrictions on supplying the service ECU reset we can directly supply power to the unit which will act as the same thing
we can just use a really simple switch, we can turn off the power, we can resupply it and then we will have the same boot process
we send again the tester present, we stay in the bootloader and we have access to all the unauthenticated, to all the services that are applicable there
and to everything that opens when we get access to the bootloader.
And I don't know if you remember this but this comes again into the game because what happens if we have a full vehicle pen test?
This is really common and with the current regulations we need to have full vehicle pen tests
and in this case we don't have the ability to supply power from a power supply because we don't have the ECU
the vehicle is constructed, it is full so we need to find another way.
And these battery isolators is one of the things that we use to bypass these bootloader restrictions, the ECU reset restrictions
and the switch to programming session restrictions.
So basically the OEM give us an option, give us a switch outside of the vehicle
which we can use to stop the power supply and supply it again in order to get access to the bootloader
and bypass all the applicable restrictions in this case.
And yeah, here is a summary of what was explained, let's go through it, we don't have a lot of time
and now switching to something that will lead us to the final and complete compromise of the vehicle.
Combining on knowledge till now, we need to mention my talk from last year as we said before
where I evaluated security access seed randomness which is based in many cases on system clock
and how all the vulnerabilities because this is something that we see 20-30 years now are becoming new again
and it's really common in the automotive sector.
Manufacturers this year after my previous talk started realizing and mitigating this issue in most of the components
and especially big OEM and tier 1 suppliers. Did they though?
Here you can see that we have the normal boot process and we have one security access service
in order to give us on the application layer some execution of restricted routines in this case
and the subservice is the 03, we find it with enumeration of the unit
and in this case while enumerating the unit we find out that the source of randomness is the HSM.
There is no way to basically predict the seed that we will receive so there is no way to bypass it in this case.
But performing a bit more of enumeration and applying everything that we saw before by hard resetting the ECU
and supplying power to get access to the bootloader by bypassing anything even the battery isolator.
In this case enumerating the bootloader gives us again the security access service but with a different subservice 01
which is used for reprogramming and enumerating further we see that here we have a seed randomness of a system clock.
So basically by enumerating different sessions of the unit and by applying the different bypasses that we explained in the previous sections
we managed to find a hidden session which basically supplies us with weak source of randomness
and we can eventually bypass and get access to it.
Things which are protected on the application layer can be usually unprotected in the bootloader.
Many times it's forgotten, I don't know if it's a separate development team that developed the bootloader
and a separate one that developed the application layer so they didn't communicate
or they didn't follow the cyber security requirements or it's externally sourced so a different code base.
I cannot be sure but the outcome is that it's worth testing all the available services and subservices under all available layers on the ECU.
And finally we have the story of the duplicates.
What I presented last year and what I extend this year is the seed randomness phaser module for cutting Caribou
which is a tool for automating security analysis of ECUs.
It's mostly modular with several developed modules and the main advantage of it is the ease of use.
Main disadvantage is the inability to easily alter the low level layers of the protocol in this case.
As our last use case, let's target the hydrogen ATV which for safety critical reasons needs to be easily isolated from the batteries.
After enumerating we find out that ECU reset is not available in any diagnostic session,
that the available security access is not backed or vulnerable to weak seed randomness
and that no other misconfigurations discovered during the initial enumeration.
And in this case we go back, we have our favorite battery isolator alongside a really nice relay
and by combining them we can control when we can stop supplying power and start again by using this externally accessible battery isolator.
What we are looking here is a heavily edited version of the module that I described which instead of using ECU resets
it uses complete power cycles from this battery isolator and fixed delays between the power supply and the random seed request
in order to prove that the seed is based on the system clock.
And despite having all our preconditions restricted as we discussed,
we get fixed seeds and basically as you can see because of the configuration all the seeds received are the same
and based on the system clock and it's not a small seed, it's not something that we can actually predict or manipulate.
It's like a really big string that cannot be cracked.
In our example having a relay as the source of the power cycle can result in even more accurate results
than by using the ECU reset service that we discussed previously.
With around 20% of duplicate seeds of our 1K samples we can be relatively confident
that the target is sourcing the randomness from the system clock but even with less.
If you see a single duplicate in such a big string I don't think that you should think twice.
And in most cases it's easier to intercept the seed and precalculated key pair from the bootloader accessible sub-session
than from the application layer because it's used for reprogramming sessions.
So if you send the car to the testing center or to the service center and they will reprogram the ECU
it's more applicable that you will be able to intercept this seed in order to reapply the key to the applicable security access sub-service.
And to conclude, while Car in Caribou might not be the best tool out there, it can help newcomers start
and this is how we also started.
Several new automations from my side helped the project move forward that you can check online on the GitHub project.
I developed some modules for write data by identifier, FASER and other really important services.
Automated module for complete automation of UDS enumeration, support for new CAN interfaces with provider drivers
and different padding or no padding support.
And as we reach the end I would like to briefly mention the differences between what we perform as pen testers
and what security research on the automotive industry is.
And while reversing firmware and getting hardware access is fun, scope is usually extremely limited by the client.
For this reason we are tasked to find efficient ways to perform more testing in a result driven environment
and automation of tasks is usually our main priority.
We directly result the extension of our methodology and test cases and sometimes the investment of our time in automotive research.
And for the client side of the things, automotive clients need to understand our methodology and test cases
and we are the ones that need to properly explain it.
Alstreg results are not always a good way forward and education is the key for a better collaboration with developers as there is no clear standard and methodology available online
in contrast with mature industries like web, infra, API and others.
And here comes the serious finale and for some food for thought, I have some food for thought for you.
I think that my approach in the industry is a bit more romantic in this case.
I care about making the world a safer place and my way of achieving it is by doing the best to secure vehicles out there
and by closely working with manufacturers and by trying to spread the culture like what we are doing here.
The thing is that most of them, especially the OG ones, don't really care about this vision
and try to undermine issues like the ones we discussed today.
We live in a capitalistic world in the end and that's what we have to do.
We have to build the product, we have to ship it, we have to make it run.
So what I have to say is that the weight is basically on us, the researchers, the pen testers, the car hackers and everyone in this field, in this audience, in this camp
to share the culture and make sure issues like this are not undermined by the manufacturers and are not considered ways of modding
but things that can directly affect the safety and security of passengers, of drivers and of people in the streets.
That's it. Thank you.
Thank you very much. We have some time for some questions.
Are there... Yes.
Thank you. Thank you for your talk.
I totally get the idea of having a secret broker for the security services because they do that when you have your simple car, they just unplug the battery.
Why don't they just put a fucking fuse rather than something that can be reset?
It has no real acceptable purpose except what you do.
Yeah, look, unfortunately I don't work for an automotive.
Yes, I'm just the supplier and the researcher. I do both things also on my free time.
And in this case, I don't have a concrete answer.
Usually it's because these vehicles, the heavy duty vehicles, are not directly accessible.
It's not a car that you will find on the parking lot in the corner of the street.
It's something that is contained in an environment, in a fleet that you cannot easily access.
It's probably secured by some company, so you cannot go there and directly do it.
But what if you can? What if you can bypass these physical restrictions?
So, yeah, that's the answer. I don't know if I covered you, but yeah.
Do I see any other... Yeah, over there.
Yeah, thanks for the talk. It was great.
One question, so how do we prevent the car manufacturers using these security measures, which I hope will get better and better every time,
to use them to hide secrets in the firmware, like we've seen with emission scandals or these days with driving automations?
How do we ensure we still get transparency about decisions that are implemented in the firmware
while still keeping the car secure against intruders, I guess?
To be honest, I don't know if I have this answer.
I think this is more of a political discussion in general in the IT sector, not only in the vehicles, if I'm right.
I think that the reason we are here in this camp is exactly this.
It's also partially privacy and partially openness, and be sure that what we are using is what we are using
and manufacturers don't hide anything from us.
In this case, I don't have a concrete answer.
What I have to say is that these components are also safety critical components.
If something goes wrong with it, people can die.
And it's not only about privacy.
We also have to think twice when we do something, because if we don't develop it properly or if we don't secure it properly,
then it's human lives at stake.
So I don't have a concrete answer for the privacy issues, because unfortunately it's an issue that we are trying to fix here,
but I cannot fix it by myself.
Thank you.
So I don't see any other hands.
Oh no, we don't have. We have some time. We are quite good on time.
Can you? Yeah. Sorry.
I have a question about your test cases or your free time.
Maybe did you get the idea to get a little more creative and maybe use all the sensors of the vehicles
to try to get artificial inputs that might trigger ECU reset in another way,
for example, get a lighter sensor and shine a bright light on it or any other kind of these kind of things.
So apart from the requirements that you're testing against.
Yeah, like the test cases that we described here was mainly focused on UDS, which is this Application Layer Protocol.
But other than that, there are these messages that are flowing between this ECU and in the networks that we described.
So what you can usually do and what was really easy to do until a couple of years ago was that you could easily inject messages inside.
So and as you said, you can basically trick the vehicle on, for example, if you have a lighter sensor
and the adaptive cruise control is like focusing all the actions, all the braking actions, the steering actions on this lighter sensor,
and you manage to inject messages, then you can trick it into doing some action.
And that's partially what happened in the video with the blinking light.
Now there are several technologies that are used like Secocity to handle the two entities and the authentication between the two
and which ECU communicates with which to avoid these attacks.
But it's still not obsolete. You can still do it. I'm sure that in many vehicles you can still do it and you can inject messages.
You're welcome. Thank you.
And OK, so one last question.
Just a quick question. Did you look into the diagnostic tester from the OEM as an actual attack surface of like the security access algorithms usually having to be there for the workshop to do service?
You mean which are the security access algorithms if they are secure?
So the diagnostic tester usually has to have the algorithm somewhere on the diagnostic tester which makes this an attack surface for the vehicle,
which is not actually inside the vehicle, but on a computer in a workshop.
Yeah, like usually these testers are only going to certified service points, so we cannot obtain them.
Usually we evaluate the security access algorithms, which is something that it can be weak, it can be not.
Sometimes it's only a byte addition to the key, which is really dumb and you can reverse it in like a couple of minutes.
And sometimes it's a yes that you cannot bypass.
But for these testers, no, usually they don't come to our hands.
It's developed by someone else most of the times, not the OEM specifically, and they just supply the cybersecurity requirements and they develop it.
So thank you very much.
I have another organizer like auger announcements.
I've been asked to remind you that you should bring back your bottles that you bought to the place where you bought them if they're empty.
And you might also want to bring some like bottles that are not belonging to anyone.
Just pick them up and bring them back because we have a lot of empty crates that we're waiting to be filled to exchange them with full ones.
Thank you very much.
The next talk will be here in 15 minutes.
Thanks.