So uh apologies this will be a first for us. We are going to do a presentation without slides.
The the projector doesn't seem to like neither our Linux or our Windows laptop. Uh so uh first
uh let me tell you that uh we are really releasing uh a paper with this presentation so uh
obviously we are going to uh to miss the detail without the slide. Uh we have already lost
some time so we won't also miss more details so uh go read the paper. There's a lot of
information there. So uh basically what was this talk about? Um basically we are releasing a
tool. A tool to audit the CAN devices. And uh we were presenting we were about to present
why we need this such tool and um what we you could do with this tool.
Okay okay. Um the very idea of uh of this tool is uh to um to come up with uh uh one
particular fact. When you want to edit a protocol uh you have two options. Uh either you
reverse the whole protocol from scratch. You have to understand that you have to
understand everything. Or you let for example uh legitimate clients do most of the the
communications. But because you are able to set uh a man in the middle configuration you
listen to these legitimate clients doing the communication and at the right moment you
start um you don't um blocking packets, modifying packets, replaying packets. Uh the very idea
of this approach the man in the middle approach is really to let uh legitimate clients
do the heavy work. Uh this way you don't have the need to reverse everything and you start uh
playing with data trying to find trying to exploit vulnerabilities at the right moment.
The very problem with the CAN network is that it is a serial bus network. Meaning that you
cannot do this. Uh for example if you do this for a web application you simply set up a web suite.
it or that proxy that kind of tool and you are in fact
intercepting every information. You can modify them also. With
a CAN serial bus you cannot unless you physically cut the
bus and insert yourself in between or you plug out one
particular device, the one device wants to audit and you
again you build a CAN bus just for this device and you put
yourself in the middle of these two bus and you start forwarding
from the packets from these two buses and when you're ready,
when you think it's the right moment you start modifying or
replaying packets. So what was the objective of our tools? So
there was already other tools to work with CAN. They were mostly
based on UART over USB. It's a very simple way to work with
CAN. It's quite slow. It can't handle the full speed of CAN
which is one megabyte and nevertheless two CAN
interfaces. So we cannot just use two serial over USB connected to
a computer and in the computer to use the man in the middle.
We had to bring new tools which is CAN spy. So about CAN spy,
what we need, we need two CAN interfaces to do the man in the middle.
either also to sniff and inject, you can also do that.
We need to be able to forward frame from can one to can two
and from can two to can one.
And we want also to be able to filter,
to trigger a frame and change the value
because we want to paint test.
And what we want to is Ethernet
because we want to use standard tools
such as SCAPI or Wireshark and Ethernet's quite convenient.
And also it has the required speed for two or even more can interface.
So our tools is based on Ethernet.
We also have a serial port.
You can still get the frame from on a serial port,
but this is more for debug purpose.
We can also store the settings of the tools in an SD card
in order to be autonomous to put the tools in the car
without connecting a computer and logging the packet, for example.
About CanSpy hardware,
we want to avoid any complex soldering for people
in order that everyone can use these tools.
So the main board is a demo board
you can find on the internet.
So it's on the slide,
so you will need the paper to find the reference.
And we use a shield that provides Ethernet connector,
SD card.
You can also find it on the internet,
on Mouser, DGK,
and both are less than 60 bucks, I think.
But you will still need to solder a small shield
because we did not find any shield with CAN interface,
so we have to make it.
But it's really simple.
It's mostly jumper to set up serial settings,
either if you are working on the real car
or you are working on a bench.
So you have to set up resistors,
power supply, etc.
And everyone can solder it.
And it's also cheap, less than 30 bucks.
So the complete tools is less than 100 bucks.
It depends on where you will read everything.
Okay.
Actually, if you don't want to solder the CAN shield,
we have some spare shields
for people who want to try it more quickly.
Come at the end of the presentation
and you can see actually the tool.
We have two tools running there.
We're going to talk about them.
But for example, we have one that is emulating a car
and the other one that is doing the man-in-the-middle setup.
That is basically what you need to do the CAN device
without auditing the whole car.
You need either the capability to emulate the whole car
to make the device think it's at home
or you need to have a tool doing the man-in-the-middle attack
so you can modify,
make the package on the fly.
So we have here a bench with one CAN spy doing the emulation,
emulating the car,
and one doing the man-in-the-middle attack.
For example, I have my phone here with a diagnostic tool,
thinking we are currently driving at 15 kilometers per hour.
And that is the first CAN spy doing the emulation.
And at any moment at the end,
we are going to set up the man-in-the-middle
and to activate the internal filtering engine
to ask him to modify the speed
so that the tool thinks we are driving at 255 kilometers,
which is the maximum according to the one byte.
It's a cheaper ability to dongle connected to Bluetooth
than a free application you can find on the store.
The idea is for,
I guess we missed a bit of introduction.
Actually, we are working with car manufacturer
to help them find vulnerabilities
before their embedded computers that they want to put in car
are put in the market.
That's why we built this tool.
Like I said, doing the man-in-the-middle,
you need to physically cut the bus or extract the device.
If you are doing this at home,
that means you have to take apart your car.
But we are helping car manufacturers.
So they give us access to integration data
where it's easy to plug in or plug out the devices.
They can give us specifications
so we can build the car emulation software quite easily.
But the reason we choose for today to use the OBD2 case
is that it's easy for everyone to do the same as we do,
but at home.
You don't need to cut anything
or to unplug anything with the OBD2 case.
You just need your car, an OBD2 device,
a cheap diagnostic device,
or a diagnostic tool, for example.
You can set up the CanSpy tool
in between your car and the diagnostic tool,
and then you can start playing with the device.
A little tip,
if you want to turn around a security issue
that is usually considered,
people try to attack car,
why not attack tools that are connecting to the car?
This tool can be pretty sensitive.
For example, if you manage to compromise a diagnostic tool,
the other car that will be connected to this diagnostic tool
will be at risk also.
One easy way to do this
is to play with diagnostic requests
which answers are fragmented over multiple CAN frames.
Because the diagnostic tool usually
defragments those frames
to extract the payload
that was initially sent by the car.
And it's quite easy to induce buffer overflows
at this point.
Tools always expect the car
to be compliant with the norm,
which is true.
I've never found a car
that was not compliant with the norm.
But if you put a man in the middle device
at this point,
and force, for example,
the vehicle identification number,
which is 17 ASCII characters long,
to be up to 40,000 characters,
you will induce a buffer overflow
that can be exploited
pretty much like any buffer overflow.
Yeah, just an obvious information,
but everything is open source and open hardware.
You can find it on our Bitbucket.
You will have to search on Google.
The firmware has been designed
in order to simplify adding new function,
new functionality,
because maybe you want to add new function
on the shell, for example.
We have a serial shell
which is used to change and manage settings,
but you can want to add new functionality.
So when designing the firmware,
we really think of how we can add new function.
A little word about this firmware.
As you may have understood from the slides,
we have two kind of devices.
Did we talk about the internet?
Okay.
We have two kind of devices,
one internet device,
one UART device,
one SD card driver.
In order to never miss a frame,
that's really our goal,
we want to forward the full data rate,
that means up to one megabit per second
from the two canvases.
We want to forward frames between the two
without dropping a frame.
So we had to design the firmware
using real-time techniques
to achieve this goal.
If you add new functionalities to the tool
while complying with our abstraction layer,
you can add functionalities
and be sure that you will not impair
the real-time properties of our tool.
We skipped a large part of the talk
where we were talking about
CAN architecture,
but with that slide,
it will not be possible to explain, I think.
We can try.
Yeah.
Let's try.
Yeah, let's try.
So a few words about CAN architecture.
So what you can find in a car.
So the most basic one is one single bus
with every EQ.
So EQ is an electronic control unit.
So in your car,
you have up to 70 control units
for controlling the dashboard,
the brakes, the engine, etc.
They are all connected.
And if we think of the most basic architecture,
this is just one bus
and everything connected.
So as you can imagine,
you will have congestion issue
because if everyone is talking at the same time,
no one, someone cannot talk.
So the mechanism is based on ID priority
to select which farm will be sent
if two EQ are talking at the same time.
The lowest ID is the most priority.
It's the highest priority, sorry.
But as you can imagine,
an EQ that have a really low priority
will never talk.
So it's in the most advanced architecture
and recent car,
you have several bus.
So another point of having separate bus
is to try to segment,
for example,
with one bus for the entertainment,
the navigation,
and one bus for the engine and the brake.
So this was more thinking for safety
than for security,
but it's still good for security.
You can have, again, two possibilities.
There are two bus with EQ on each bus
and EQs that are connected to two buses.
For example, for the navigation system,
it is related to the entertainment,
but it also needs the speed
and information from the car.
And what we can think
as a state-of-the-art architecture
on modern car
is with several buses and gateway
between these buses,
so like an internet network.
And this gateway will filter the message
based on their ID.
But they can be a little bit smarter
and use the state of the vehicle.
If the vehicle is stopped,
if it's running,
which speed it is running,
if the engine is off, etc.
And they will allow different ID
in function of the state of the car.
So we can see that this is something
which we can play.
The idea is that for an attacker,
you have first the exposed ECU,
for example, navigation system
or telematic functionalities,
you know, using broadband,
mobile broadband communications.
And once you compromise
either of these two type of ECUs,
in order to really impact safety,
you have to compromise more ECUs.
But usually these ECUs
will not be on the same bus
as the ECU you just compromised.
So you need to move from one bus
to one of the NGIDs
to compromise an ECU
that is either on multiple buses,
like the first case Arnaud presented,
or if you are in the situation
where you have a central gateway,
to compromise this gateway.
And that is essentially the goal
behind our tool.
It's not about auditing navigation system,
you know, compromising Bluetooth,
Wi-Fi, USB, mobile broadband,
it's really for the second line of defense,
to audit ECU from the canvas.
The idea is to craft attack from the canvas,
not compromise an ECU from Bluetooth,
for example, and reach the canvas.
That is the first step.
It's an important step.
We do that step two when we audit ECUs.
But really there's nothing to add here.
I mean, if you want information
about Bluetooth penetration testing
or Wi-Fi penetration testing,
there's already plenty of tools,
plenty of literature to expand everything.
On the broadband tool,
you can find a lot of data
about broadband pen testing.
It's not specific to automotive.
Usually you just end up
building an easy catcher
to force the ECU
to use your own mobile broadband
and again you set up
a man-in-the-middle attack
so you can try to modify
the information coming from
the car manufacturer infrastructure
and see what happens on the car.
Man-in-the-middle
is basically the way
when you want to find and exploit
vulnerabilities very quickly
without the need to really understand
everything.
This is something that was lacking to us
from the CAN perspective
doing CAN attacks from the canvas
and that's why we ended up
building this tool.
I'm just working on the time.
Is there anyone that has questions?
We have the demonstration running here
so since we have time
I guess we have.
You can come and see
the demonstration running.
We have no camera to show this
and the screen of the phone
is not loud enough
for everyone to see.
And if you have questions
of course you can answer.
And again we apologize for this issue
we tried on two computers
a Linux and a Windows
and it was working on the speaker room
so that's happened.