Firstly, thank you for giving a chance to talk here.
We are very grateful for this chance.
We will show the presentation titled
Realistic Trends in Vulnerability Based on Hacking into Vehicles from Tokyo.
OK, at first, please let us introduce ourselves briefly.
Who am I?
Do you know Denso?
They are one of the top automotive component suppliers in the world.
Do you know NRI?
Is it a very famous company?
Honestly speaking, I really don't know.
But they are famous, at least in Japan, on IT and IoT security.
NIDS is jointly founded by these two companies.
Yeah, so cool.
And I mentioned an important thing that our clients often ask us.
We never ever share the issues and vehicles information with Denso and NRI without your permission.
So please feel free to contact us.
NIDS activities on business.
We provide the cybersecurity assessment and consultation services for 6 OEMs and several suppliers.
On competition, we'd like to mention our activity on the Car Hacking Village.
We are a CTF and we got this position two years ago and fourth in last year.
So we believed to get third this year.
But unfortunately, we got accepted for this presentation.
So we are not ready now for that CTF.
Yeah, that is a bad thing.
On behalf of our company, I'd like to introduce fantastic four providing this presentation.
Ryosuke Uematsu.
He's known as a wireless enthusiast in Japan.
He loves LG so much.
In our company, he is known as living in radio anechoic chamber.
And we believe that he can see the radio waves over the air.
Shogo Nakao. He used to work for Functional Safety.
But now he is a binary otaku.
We've heard that his friend is only either pro.
Next, Ryoichi Teramura.
He leads our team and he is a cryptographer.
His favorite cryptography is 3D.
And Tatsuya Katsuhara. It's me.
I'm director of NDS.
Yeah, introduction. That's all.
These years, a number of car threats have been reported.
You may know the Jeep and recently BMW and Lexus issues are reported by Tencent.
Yeah, they are so cool.
The automotive industry has done a lot on cybersecurity.
The most famous one is WP-29.
It requires really a lot of things.
Software development lifecycle, security operations center, inclusion, detection and prevention system, product security incident response team, PSAT, and so on.
And don't forget ISO SAE-21434.
The important thing is that car developing process takes so long.
So there is a gap between the publication of research about certain vulnerability and actual release of countermeasure.
So I have defined car cybersecurity generation based on these gaps.
First, generation 0 is before Jeep. Almost no mitigation, no regulation.
Generation 1 is after Jeep.
Some ready-to-go countermeasures like gateway ECU are implemented.
But no electrical platform refurbishment.
Generation 2.
Our presentation focuses on this generation where new security countermeasures are implemented.
Generation 3.
This generation includes security features complied with WP-29 and ISO standard.
Okay.
So, yes, what we are going to talk about in this presentation.
First, we introduce our testing approaches.
Second, we introduce the trends of the vulnerabilities we found for second-generation vehicles and ECUs.
These results are based on more than 40 ECUs and 300 vulnerabilities.
Here are some of the examples.
And then we present effective mitigations.
Of course, we have already reported these vulnerabilities to car manufacturers and suppliers directly.
So it shouldn't be a threat in the actual car.
I think.
I believe that many car manufacturers and ECU suppliers are developing second-generation products just now.
So I hope the results of this analysis will help such a developer.
Okay, I'll turn it over to Teramura.
Okay, hello, nice to meet you.
My name is Yoshi Teramura.
And before getting to the main point, let's talk briefly about our testing methods and approaches.
We think there are two main categories of car testing methods.
The first one is a test for the vehicle itself.
Another is a test for each ECU.
So these tests are different in their purpose.
ECU test is just a unit test.
So it can test a detail but cannot see the entire vehicle.
But vehicle test is like an integration test.
It is difficult to check the detail.
But it's easy to check whether a vehicle can run or not during the test.
So we have experienced both tests.
And we think ECU test is more suitable for finding vulnerabilities than vehicle test.
So this presentation focuses on vulnerability.
So we have an analyzer result of our ECU test results.
First, we explain ECU test methods and approaches from the next page.
ECU test is that it can find vulnerabilities in the ECU.
This slide shows two graphs.
The left graph shows ECU stats.
And the right graph shows our test approaches.
The ECU consists of a lot of components.
It is shown in the left graph.
For example, hardware.
Of course, the interface drivers.
OS kernel.
And the bootstrap.
And the middleware.
And the open-source software.
And of course, applications that run on the OS.
Do you know where is the vulnerability?
Of course, the answer is easy.
The answer is everywhere.
There are vulnerabilities everywhere in the ECU stats.
And to find them, we use a lot of test methods.
The right graph shows our test methods and approaches.
And our test methods are divided into two categories.
One is interface test.
And another is software analysis.
Interface test is one of the black box tests.
Finding vulnerabilities through ECU's interface.
And software analysis is one of the white box or occasionally gray box tests.
Okay, let's take a look at each method.
First, I will introduce interface test and especially remote interface test.
That is Celera.
Do you know this box in this picture?
And this is an unread product.
And this unread product comes as a spoofed base station of LTE or 3G.
And we use it and check the connected services over the Celera network.
And by spoofing and monitoring the messages during connection and authentication sequence,
we can check the protocol stack of the Celera interface
and simulate some attacks like authentication bypass and micromodal attacks over the Celera network.
But there is one caution point.
In some countries, like Japan, the radio law prevents this type of test.
So you must check your country's law before remote interface testing.
Okay, let's go. Next, adjacent interfaces.
Adjacent interfaces are like Wi-Fi and Bluetooth, NFC, radio frequency, and more.
This test doesn't need a spoofing base station.
And we connect our laptop to the ECU via the Wi-Fi or Bluetooth
and send a spoofing message and monitor the responses.
Then we check the vulnerability in the protocol stack and authentication function.
We often use a scanner tool in this test.
And it can find authentication bypasses and some well-known vulnerabilities.
Next, the local interfaces.
We show the local interfaces like a USB or CAN.
Everyone likes CAN.
And inter-ethernet and more.
And in this test, we connect the laptop to the ECU directly via cable or harnesses.
And we often check the security access for UDS and...
occasionally, are internet services remaining?
Okay, and we use a tool like a hotting tool and a scanner tool for this test.
Okay, next one.
Okay, next one is physical interfaces.
Physical interfaces target JTAG, SPI, UART, and more installed in the chip.
The purpose of this test is to check whether we can extract firmware or overwrite the firmware.
The microcontroller or external flash on the chip.
Okay, and in this test, very important skill is soldering.
So our staff is very skillful.
Okay, next.
Dynamic software analysis.
If we can extract the firmware from the ECU, we try the software analysis, static and dynamic.
The dynamic software analysis.
We log in the application on the actual or virtual ECU via SSH and UART and more.
And when we can connect to the ECU, check the internal of them.
Once logged in, we can check a lot of things.
Scanning processes, log files, software version, setting files, credential files, and many data.
And of course, if we can get the firmware, we'll try the static software analysis.
We need a firmware as an assembler or sometimes pre-code using it too, such as AIDA Pro or GDRA.
And we can use it and search the vulnerability.
If the firmware includes an operational system such as Linux, we can run it on a virtual machine.
And if the firmware includes a file system, we can mount the file system and check the files in it.
So we think the firmware is a good alternative of a source code and a debug console.
The software tells us many things.
Many, many things, a lot of things.
There are known vulnerabilities.
And what is open source software and Office 365 product versions?
And is there a debug port? And is there remaining services?
What is configuration? Where is the hard-coded credential?
Software analysis tells many things.
Okay, this is a wrap-up, the test result.
But this time we skip it.
Okay, the last. Here is our matrix to the risk score of the vulnerabilities.
The risk score is determined based on two factors.
One is damage impact and one is attack feasibility.
Damage impact and attack feasibility are evaluated from the view of vehicles.
From the vehicles, it's an important point.
From the view of vehicle users, vehicle users' safety.
So it's from not only ECU.
This means that the risk score related to the vulnerabilities of internal network tends to be decreasing.
Okay, from the next page, we will show our analysis of the vulnerabilities and their risk score from Kyosuke Uematsu.
Okay, I'm Kyosuke Uematsu. I'm talking about vulnerability trends in vehicles.
First, let me discuss the background data for this analysis.
Our results are derived from over 300 vulnerabilities we have found in the past.
These vulnerabilities are derived from more than 40 issues provided by more than 10 companies.
In this analysis, we will talk about four categories of issues.
First, the IBEX category. IBEX is in vehicle infotainment.
It has many features, mainly navigation system, play music, and calling with your smartphone, and so on.
It has an adjacent interface such as wireless LAN and Bluetooth.
Second, the TCU category.
TCU is telematics control unit. It has several interfaces such as 4G, 3G, and 2G.
Some of them have Wi-Fi interface for access point.
Third, the Gateway category.
It has mostly CAN and Ethernet connection, but often OBD2 is connected here.
The Gateway has features to separate the communication between the IBEX or TCU and the control system issues such as engine or steering issue.
And then, the other category.
It includes ADAS, smart key, charging, and BTX ECUs.
OK, first, let me talk about where most of the vulnerabilities are found.
The structure of an issue consists of hardware layer and software layer.
Here, the software layer has OS, OSS, off-the-shelf products including interface module, and application.
For this structure, about 70% of vulnerabilities are found in OS, OSS, and off-the-shelf products.
For example, these 70% vulnerabilities have a lack of management for OSS version.
Using an OSS version reported vulnerability in the vulnerability database like a CVE.
Using an inappropriate off-the-shelf products, and so on.
OS, OSS, and off-the-shelf products are developed by a third party.
And in many cases, they have already provided the patches for their vulnerabilities we found.
Pay attention to OS, OSS, and off-the-shelf products is very useful mitigation.
OK, next, focus on the high-risk vulnerabilities.
As a result, the 30% vulnerabilities are in application, and 70% in OS, OSS, and off-the-shelf.
So, almost high-risk vulnerabilities are in software, not hardware.
It means that hardware vulnerabilities hardly affect the threat scenario of vehicle user safety.
Thinking of defense in depth, of course, hardware security is non-negligible.
But, software security may be more important than it.
OK, next, focus on software vulnerabilities.
I've categorized software vulnerabilities into nine major categories.
Insecure OS, OSS settings, insecure authentication, information leakage, use of insecure or outdated components, insecure application layer communication, and so on.
The most often detected vulnerabilities are insecure OS and OSS settings.
As we said, this is a trend in second-gen cars. We will dig deeper.
We filter vulnerabilities more than medium-risk scores.
It means that we focus on the vulnerabilities that may cause vehicle user safety.
Through this filter, the insecure OS, OSS settings, lags down to third place.
First place is insecure authentication, and second place is lack of secure update mechanism.
These are two top vulnerabilities that could be a threat to the vehicle user safety.
The example of insecure authentication is storing key or password in parentheses.
So it may be good mitigation to keep credentials in secure elements such as trust zone, TPM, and HSM.
The example of lack of secure update mechanism is improper implementation of signature verification.
Thus, it is important to implement the signature verification strictly.
Next, we focus the issue category.
This slide message may be intuitive to you.
That is more complex ECU that have various functions, such as IBOA, has a greater number of vulnerabilities than others.
The left graph shows the average number of vulnerabilities for each ECU.
On average, we find 10.9 vulnerabilities for each IBOA.
5.6 for each TCU, and 3.5 for each gateway.
The right graph shows the proportion of vulnerabilities for each RISC.
It is also the IBOA that is most likely to detect high-risk vulnerabilities.
The reason for that is simple.
It has a lot of applications, OS, OSS, and a lot of interfaces.
OK, next, focus the testing method.
First, let me talk about the remote interface test.
This graph shows the proportion of vulnerabilities we found in remote interface test, including Bluetooth, wireless LAN, server, and so on.
The interface that found the most vulnerabilities is Bluetooth.
Especially, Bluetooth authentication bypass vulnerabilities were most detected.
We think this is because Bluetooth security countermeasures are not yet well known.
On the other hand, wireless LAN and server don't have as many vulnerabilities, but some of them are serious problems.
OK, next, let me introduce the example of Bluetooth and server.
First, talk about the example of vulnerabilities in Bluetooth.
Bluetooth has some vulnerabilities that can bypass authentication.
First, using PIN mode.
Bluetooth has two authentication modes.
One of them is PIN mode, and it is well known to be vulnerable.
Some of issues there are PINs were 0, 0, 0, 0. It seems vulnerable.
Second, the BDLS spoofing, that is called CAS blues.
And third, the no-input output of IO capability spoofing.
These vulnerabilities are that an attacker can connect to the vehicle Bluetooth interface without user operations,
and then perform any operation over Bluetooth interfaces.
If a debugged serial service would remain over the Bluetooth interface,
an attacker can connect to the debugged serial service and execute any command by exploiting these vulnerabilities.
At least, stop using PIN mode and take care of CAS blues and no-input output devices.
Next, let me talk about the server vulnerabilities.
Server vulnerabilities are not so many, but sometimes found.
We introduce one example we have found.
We try the method of relative fuzz that can bypass server authentication.
Of course, a lot of issues don't be exploited, but one issue could be exploited.
When I found it, I really couldn't believe it.
This is really bad because it allows the attacker to spoof the base station and to attack the vehicle remotely.
In addition, the information on the server communication leaks to the attacker.
The cause of this vulnerability is in the server stack provided by JitBender.
Therefore, this mitigation is to get the latest software from JitBender and apply it.
OK, next, talk about trends for the interface in the vehicle.
Take a look at the graph on the left.
Most of them are CAN. In-vehicle Ethernet is also important recently.
About 80% of the vulnerabilities we found are related to in-vehicle networks, including CAN and Ethernet.
So, let's check what type of high-risk vulnerabilities of the in-vehicle networks.
As shown in the graph on the right,
many UDS-related vulnerabilities are found in the in-vehicle networks.
In the next page, let me show you some of the UDS-related vulnerabilities.
Broken security access protection is a typical problem.
Recently, message authentication is started to be implemented to secure messages of in-vehicle networks.
For example, CAN and Ethernet.
This is a pretty powerful countermeasure.
By contrast, for UDS, security access is still a primary countermeasure for security.
Some of the UDS vulnerabilities we found are as follows.
1. Lack of entropy in seed generation.
2. Insufficient initializes for random number generator.
3. Extracting sensitive information using UDS service, such as read by ID.
In addition, there is a problem that the private key is hard-coded and can be identified by software analysis.
This will be explained later in software analysis section with example.
Although UDS connection to be an attack surface of ECU, it is becoming more and more difficult to attack UDS due to the effect of domain separation by gateway.
Next, let me talk about trends in vulnerability of physical debug interfaces on the ECU.
This graph shows the proportion of the ECU where physical debug interfaces remain unlocked.
There are three types of vulnerabilities for the physical debug interfaces on ECU.
1. The debugging access to the CPU via JTAG interface is available.
2. The shared access to the CPU via UART interface is available.
3. It is extraction of firmware from external RAM on the ECU, such as eMMC.
As you can see from the left graph, 41% of ECUs can be accessed via JTAG interface.
The next graph shows that 32% of ECUs can be accessed via UART.
As you can see from the right graph, 44% of ECUs can be extracted the firmware from eMMC or others.
The main reason is that the debugging interfaces are not locked in most ECUs.
Even if you have locked the debugging interfaces, they are not properly locked or disabled.
For example, JTAG is locked, but password is default value. It doesn't mean it's locked.
Thus, of course, you must fix it.
OK, next presenter is Shogunakao.
OK, I'm Shogunakao. Hello, I'm Shogunakao.
Hereafter, we talk about the trend comparing interface testing and software analysis, and also talk about software analysis with examples.
We have been focusing on interface testing. However, there is a limit to the amount of vulnerability we found by interface testing.
For example, though we capture and analyze the communication data, we can check the security measures on communication channel.
It is rare that we can find vulnerabilities in the software related to the communication.
So we analyze binary files to find vulnerability in the software.
In fact, as shown in the left graph, we have found twice as many vulnerabilities through the software analysis as through the interface testing.
In addition, high-risk vulnerabilities tend to be found by the software analysis, as you can see from the right graph.
The reason for this is that the vulnerabilities found by the interface testing, like auto-scan, seem to be already fixed.
Of course, the high-risk vulnerabilities also seem to be already fixed.
Therefore, I think it would be significant to analyze software and binary files to find vulnerabilities in the car development.
But we need to obtain binary files in order to analyze the software.
For this reason, I think a good relationship between the car manufacturers, suppliers, and security vendors is essential.
In the following slide, we will explain some specific examples on software analysis.
In software analysis, we identify the code of the target process from the extracted binary files.
Then, we can understand the architecture of software and relate the data flow and functions of the process, as shown in this figure.
After that, we investigate and analyze the data flow and functions from the identified code more deeply.
This is how we gather detailed information about the target ECU.
Of course, we also identify and analyze the security functions by reading the binary code.
For example, we know that the ECU has containers, terrorist communication, signature verification, and cryptographic functions.
Then, we relate the code more deeply. We find a lot of vulnerabilities in this work.
Next, I'll explain examples of software analysis and vulnerabilities we have found.
The first example is analysis of an IBI code.
First step, we identified the process of encrypting the seed with AES.
Second step, we disassembled the target code in AIDA Pro and read it to find the AES key.
Let's read the assembly code.
We followed the core instruction as shown in the figure.
Then, we can saw that it refers to the data area in the function.
We noticed that the key for AES is in the area as we proceeded with the analysis.
When we looked for other functions that refer this data area, we could see that they initialize the same area.
As a result of analysis, we could find the information about the AES key, maybe, I think.
If this is a real AES key, we may be able to hack the IBI.
To prevent the leakage of the key, you can store it in the HSM.
The second one is about gateway firmware.
This is the same approach as the before slide.
Fortunately, we are able to decompile the code in GitHub.
This is because we identified the security access handlers and found the private key information in them rapidly.
In this analysis, we also identified the security access algorithm, so we were able to bypass the security access.
Binary files tell you a lot of information about the ECU and the vehicle.
It tells you how you can hack into the vehicle or ECU and how you can extract the sensitive data.
These are some of the vulnerabilities we found.
For example, you can see disabling TLS certificate validation, improper signature validation, and buffer overflows and directory traversal.
These lead to severe or high impact for the vehicle, I think.
After checking the trend of vulnerabilities, someone may ask us whether the second-generation cars face cybersecurity threats.
We will say it's secure in most cases.
It's difficult to realize a threat scenario for the vehicle in terms of vehicle architecture on both security features and so on.
In rare cases, they are unsecured ones.
But we've reported the vulnerability we found, so it must be already fixed.
We show five solutions against such vulnerability here.
85% of high and medium risk vulnerabilities can be mitigated by these solutions.
So, I sincerely recommend to introduce the solutions.
First of all, store credential and private keys in protected area.
For example, trust zone and TPM, HSM, or something like that.
Second, make sure that the signature verification is done correctly.
I'm not just talking about the verification algorithm.
There are some vulnerabilities that signature verification is bypassed due to verification timing issues.
Third, use appropriate random number generator and cryptosystem.
Fourth, on OS, OSS, and off-the-shelf, pay attention to the following three things.
The first one is use OSS properly.
For example, we often see unproperly settings in TLS connection using OpenSSL, CURL, and so on.
The second one is software version control and managing software composition.
The third one, secure OS and OSS configuration.
There are a wide range of settings, but most of them are firewall permissions and hardening settings for the OS.
Fifth, log the physical debug port on the hardware properly.
Finally, we will say it again.
Just by introducing these solutions, you can mitigate 85% of the high and medium risk.
We strongly recommend that you introduce these solutions.
And we conclude our presentation.
This is our conclusion.
We answer for frequently questions.
That's all. Thanks.