[00:03.060 --> 00:08.540]  Firstly, thank you for giving a chance to talk here.
[00:08.540 --> 00:11.510]  We are very grateful for this chance.
[00:12.040 --> 00:14.620]  We will show the presentation titled
[00:14.620 --> 00:22.330]  Realistic Trends in Vulnerability Based on Hacking into Vehicles from Tokyo.
[00:24.220 --> 00:30.460]  OK, at first, please let us introduce ourselves briefly.
[00:32.080 --> 00:34.240]  Who am I?
[00:35.720 --> 00:37.880]  Do you know Denso?
[00:38.160 --> 00:44.180]  They are one of the top automotive component suppliers in the world.
[00:44.380 --> 00:46.960]  Do you know NRI?
[00:47.060 --> 00:50.520]  Is it a very famous company?
[00:51.320 --> 00:54.820]  Honestly speaking, I really don't know.
[00:54.820 --> 01:03.020]  But they are famous, at least in Japan, on IT and IoT security.
[01:04.200 --> 01:09.180]  NIDS is jointly founded by these two companies.
[01:09.300 --> 01:10.920]  Yeah, so cool.
[01:11.540 --> 01:18.600]  And I mentioned an important thing that our clients often ask us.
[01:18.600 --> 01:28.680]  We never ever share the issues and vehicles information with Denso and NRI without your permission.
[01:28.680 --> 01:34.180]  So please feel free to contact us.
[01:39.400 --> 01:43.480]  NIDS activities on business.
[01:43.680 --> 01:52.380]  We provide the cybersecurity assessment and consultation services for 6 OEMs and several suppliers.
[01:53.310 --> 02:00.720]  On competition, we'd like to mention our activity on the Car Hacking Village.
[02:00.720 --> 02:11.650]  We are a CTF and we got this position two years ago and fourth in last year.
[02:12.060 --> 02:16.900]  So we believed to get third this year.
[02:16.900 --> 02:24.180]  But unfortunately, we got accepted for this presentation.
[02:24.180 --> 02:29.200]  So we are not ready now for that CTF.
[02:29.600 --> 02:32.960]  Yeah, that is a bad thing.
[02:36.450 --> 02:44.810]  On behalf of our company, I'd like to introduce fantastic four providing this presentation.
[02:46.390 --> 02:47.790]  Ryosuke Uematsu.
[02:47.790 --> 02:53.950]  He's known as a wireless enthusiast in Japan.
[02:54.550 --> 02:57.230]  He loves LG so much.
[02:57.230 --> 03:05.290]  In our company, he is known as living in radio anechoic chamber.
[03:05.650 --> 03:12.670]  And we believe that he can see the radio waves over the air.
[03:12.670 --> 03:19.030]  Shogo Nakao. He used to work for Functional Safety.
[03:19.230 --> 03:23.410]  But now he is a binary otaku.
[03:24.250 --> 03:30.530]  We've heard that his friend is only either pro.
[03:31.630 --> 03:33.810]  Next, Ryoichi Teramura.
[03:34.430 --> 03:39.070]  He leads our team and he is a cryptographer.
[03:39.070 --> 03:44.230]  His favorite cryptography is 3D.
[03:45.650 --> 03:50.150]  And Tatsuya Katsuhara. It's me.
[03:50.150 --> 03:53.810]  I'm director of NDS.
[03:55.590 --> 03:58.410]  Yeah, introduction. That's all.
[04:03.360 --> 04:09.760]  These years, a number of car threats have been reported.
[04:09.760 --> 04:16.940]  You may know the Jeep and recently BMW and Lexus issues are reported by Tencent.
[04:17.320 --> 04:20.820]  Yeah, they are so cool.
[04:21.280 --> 04:26.960]  The automotive industry has done a lot on cybersecurity.
[04:27.020 --> 04:32.420]  The most famous one is WP-29.
[04:33.160 --> 04:36.160]  It requires really a lot of things.
[04:36.160 --> 04:53.600]  Software development lifecycle, security operations center, inclusion, detection and prevention system, product security incident response team, PSAT, and so on.
[04:53.600 --> 04:59.840]  And don't forget ISO SAE-21434.
[05:00.840 --> 05:08.160]  The important thing is that car developing process takes so long.
[05:08.680 --> 05:21.840]  So there is a gap between the publication of research about certain vulnerability and actual release of countermeasure.
[05:21.840 --> 05:29.320]  So I have defined car cybersecurity generation based on these gaps.
[05:29.500 --> 05:38.900]  First, generation 0 is before Jeep. Almost no mitigation, no regulation.
[05:39.900 --> 05:43.880]  Generation 1 is after Jeep.
[05:43.880 --> 05:53.160]  Some ready-to-go countermeasures like gateway ECU are implemented.
[05:53.160 --> 05:58.220]  But no electrical platform refurbishment.
[05:59.440 --> 06:01.200]  Generation 2.
[06:01.520 --> 06:13.240]  Our presentation focuses on this generation where new security countermeasures are implemented.
[06:14.600 --> 06:16.660]  Generation 3.
[06:17.300 --> 06:29.200]  This generation includes security features complied with WP-29 and ISO standard.
[06:33.740 --> 06:35.020]  Okay.
[06:35.600 --> 06:42.320]  So, yes, what we are going to talk about in this presentation.
[06:42.320 --> 06:47.780]  First, we introduce our testing approaches.
[06:48.260 --> 06:59.340]  Second, we introduce the trends of the vulnerabilities we found for second-generation vehicles and ECUs.
[06:59.340 --> 07:07.540]  These results are based on more than 40 ECUs and 300 vulnerabilities.
[07:07.540 --> 07:11.380]  Here are some of the examples.
[07:11.380 --> 07:15.680]  And then we present effective mitigations.
[07:17.590 --> 07:27.150]  Of course, we have already reported these vulnerabilities to car manufacturers and suppliers directly.
[07:27.150 --> 07:34.150]  So it shouldn't be a threat in the actual car.
[07:34.170 --> 07:36.470]  I think.
[07:37.470 --> 07:49.270]  I believe that many car manufacturers and ECU suppliers are developing second-generation products just now.
[07:49.270 --> 07:58.210]  So I hope the results of this analysis will help such a developer.
[07:59.130 --> 08:04.150]  Okay, I'll turn it over to Teramura.
[08:05.150 --> 08:08.470]  Okay, hello, nice to meet you.
[08:08.470 --> 08:10.630]  My name is Yoshi Teramura.
[08:11.390 --> 08:18.250]  And before getting to the main point, let's talk briefly about our testing methods and approaches.
[08:20.610 --> 08:25.190]  We think there are two main categories of car testing methods.
[08:25.370 --> 08:29.310]  The first one is a test for the vehicle itself.
[08:29.450 --> 08:32.330]  Another is a test for each ECU.
[08:32.330 --> 08:36.730]  So these tests are different in their purpose.
[08:37.550 --> 08:40.010]  ECU test is just a unit test.
[08:40.010 --> 08:45.090]  So it can test a detail but cannot see the entire vehicle.
[08:45.510 --> 08:49.790]  But vehicle test is like an integration test.
[08:50.250 --> 08:53.810]  It is difficult to check the detail.
[08:53.910 --> 09:01.270]  But it's easy to check whether a vehicle can run or not during the test.
[09:02.270 --> 09:06.550]  So we have experienced both tests.
[09:06.610 --> 09:15.490]  And we think ECU test is more suitable for finding vulnerabilities than vehicle test.
[09:15.630 --> 09:20.630]  So this presentation focuses on vulnerability.
[09:20.630 --> 09:25.570]  So we have an analyzer result of our ECU test results.
[09:30.390 --> 09:35.510]  First, we explain ECU test methods and approaches from the next page.
[09:40.940 --> 09:44.740]  ECU test is that it can find vulnerabilities in the ECU.
[09:46.180 --> 09:49.100]  This slide shows two graphs.
[09:49.160 --> 09:52.140]  The left graph shows ECU stats.
[09:52.140 --> 09:56.640]  And the right graph shows our test approaches.
[09:58.080 --> 10:02.000]  The ECU consists of a lot of components.
[10:02.220 --> 10:04.760]  It is shown in the left graph.
[10:05.000 --> 10:07.100]  For example, hardware.
[10:07.180 --> 10:09.820]  Of course, the interface drivers.
[10:10.080 --> 10:11.360]  OS kernel.
[10:11.740 --> 10:13.100]  And the bootstrap.
[10:13.260 --> 10:14.740]  And the middleware.
[10:14.740 --> 10:16.500]  And the open-source software.
[10:16.660 --> 10:20.420]  And of course, applications that run on the OS.
[10:21.960 --> 10:25.460]  Do you know where is the vulnerability?
[10:26.280 --> 10:28.540]  Of course, the answer is easy.
[10:28.540 --> 10:30.700]  The answer is everywhere.
[10:31.860 --> 10:38.180]  There are vulnerabilities everywhere in the ECU stats.
[10:39.660 --> 10:44.240]  And to find them, we use a lot of test methods.
[10:47.620 --> 10:52.400]  The right graph shows our test methods and approaches.
[10:52.400 --> 10:56.750]  And our test methods are divided into two categories.
[10:57.100 --> 10:59.200]  One is interface test.
[10:59.200 --> 11:02.640]  And another is software analysis.
[11:03.680 --> 11:07.320]  Interface test is one of the black box tests.
[11:09.260 --> 11:13.760]  Finding vulnerabilities through ECU's interface.
[11:14.180 --> 11:20.840]  And software analysis is one of the white box or occasionally gray box tests.
[11:20.840 --> 11:24.060]  Okay, let's take a look at each method.
[11:28.020 --> 11:34.400]  First, I will introduce interface test and especially remote interface test.
[11:34.400 --> 11:35.900]  That is Celera.
[11:36.540 --> 11:40.980]  Do you know this box in this picture?
[11:41.840 --> 11:44.580]  And this is an unread product.
[11:44.580 --> 11:52.860]  And this unread product comes as a spoofed base station of LTE or 3G.
[11:52.860 --> 11:57.980]  And we use it and check the connected services over the Celera network.
[11:58.820 --> 12:04.120]  And by spoofing and monitoring the messages during connection and authentication sequence,
[12:04.460 --> 12:07.600]  we can check the protocol stack of the Celera interface
[12:07.600 --> 12:15.220]  and simulate some attacks like authentication bypass and micromodal attacks over the Celera network.
[12:16.380 --> 12:20.300]  But there is one caution point.
[12:20.300 --> 12:27.580]  In some countries, like Japan, the radio law prevents this type of test.
[12:27.840 --> 12:33.560]  So you must check your country's law before remote interface testing.
[12:35.300 --> 12:38.680]  Okay, let's go. Next, adjacent interfaces.
[12:39.660 --> 12:48.580]  Adjacent interfaces are like Wi-Fi and Bluetooth, NFC, radio frequency, and more.
[12:50.300 --> 12:54.180]  This test doesn't need a spoofing base station.
[12:54.280 --> 12:59.180]  And we connect our laptop to the ECU via the Wi-Fi or Bluetooth
[12:59.180 --> 13:04.440]  and send a spoofing message and monitor the responses.
[13:07.020 --> 13:12.600]  Then we check the vulnerability in the protocol stack and authentication function.
[13:13.380 --> 13:17.520]  We often use a scanner tool in this test.
[13:17.520 --> 13:24.000]  And it can find authentication bypasses and some well-known vulnerabilities.
[13:25.220 --> 13:28.940]  Next, the local interfaces.
[13:29.060 --> 13:36.060]  We show the local interfaces like a USB or CAN.
[13:36.500 --> 13:38.780]  Everyone likes CAN.
[13:38.780 --> 13:43.680]  And inter-ethernet and more.
[13:43.680 --> 13:52.360]  And in this test, we connect the laptop to the ECU directly via cable or harnesses.
[13:52.480 --> 13:55.680]  And we often check the security access for UDS and...
[13:58.860 --> 14:01.700]  occasionally, are internet services remaining?
[14:02.260 --> 14:08.140]  Okay, and we use a tool like a hotting tool and a scanner tool for this test.
[14:11.200 --> 14:12.900]  Okay, next one.
[14:13.300 --> 14:15.980]  Okay, next one is physical interfaces.
[14:17.260 --> 14:29.100]  Physical interfaces target JTAG, SPI, UART, and more installed in the chip.
[14:29.100 --> 14:38.240]  The purpose of this test is to check whether we can extract firmware or overwrite the firmware.
[14:41.040 --> 14:44.760]  The microcontroller or external flash on the chip.
[14:46.560 --> 14:51.270]  Okay, and in this test, very important skill is soldering.
[14:51.540 --> 14:53.800]  So our staff is very skillful.
[14:56.160 --> 14:57.760]  Okay, next.
[14:58.220 --> 14:59.880]  Dynamic software analysis.
[15:01.640 --> 15:09.000]  If we can extract the firmware from the ECU, we try the software analysis, static and dynamic.
[15:09.700 --> 15:11.960]  The dynamic software analysis.
[15:12.000 --> 15:25.760]  We log in the application on the actual or virtual ECU via SSH and UART and more.
[15:26.420 --> 15:34.040]  And when we can connect to the ECU, check the internal of them.
[15:34.440 --> 15:37.480]  Once logged in, we can check a lot of things.
[15:37.480 --> 15:46.340]  Scanning processes, log files, software version, setting files, credential files, and many data.
[15:49.580 --> 15:54.440]  And of course, if we can get the firmware, we'll try the static software analysis.
[15:55.240 --> 16:05.000]  We need a firmware as an assembler or sometimes pre-code using it too, such as AIDA Pro or GDRA.
[16:07.440 --> 16:11.800]  And we can use it and search the vulnerability.
[16:13.700 --> 16:20.480]  If the firmware includes an operational system such as Linux, we can run it on a virtual machine.
[16:20.840 --> 16:28.080]  And if the firmware includes a file system, we can mount the file system and check the files in it.
[16:28.920 --> 16:35.420]  So we think the firmware is a good alternative of a source code and a debug console.
[16:36.780 --> 16:39.140]  The software tells us many things.
[16:39.220 --> 16:41.600]  Many, many things, a lot of things.
[16:42.260 --> 16:45.060]  There are known vulnerabilities.
[16:45.720 --> 16:51.240]  And what is open source software and Office 365 product versions?
[16:51.540 --> 16:56.160]  And is there a debug port? And is there remaining services?
[16:56.160 --> 17:01.520]  What is configuration? Where is the hard-coded credential?
[17:02.360 --> 17:05.160]  Software analysis tells many things.
[17:07.200 --> 17:11.100]  Okay, this is a wrap-up, the test result.
[17:11.440 --> 17:14.580]  But this time we skip it.
[17:15.840 --> 17:21.520]  Okay, the last. Here is our matrix to the risk score of the vulnerabilities.
[17:21.920 --> 17:25.880]  The risk score is determined based on two factors.
[17:26.160 --> 17:29.620]  One is damage impact and one is attack feasibility.
[17:29.700 --> 17:35.640]  Damage impact and attack feasibility are evaluated from the view of vehicles.
[17:35.920 --> 17:38.880]  From the vehicles, it's an important point.
[17:40.400 --> 17:46.060]  From the view of vehicle users, vehicle users' safety.
[17:47.160 --> 17:50.460]  So it's from not only ECU.
[17:51.320 --> 18:00.620]  This means that the risk score related to the vulnerabilities of internal network tends to be decreasing.
[18:01.700 --> 18:10.080]  Okay, from the next page, we will show our analysis of the vulnerabilities and their risk score from Kyosuke Uematsu.
[18:12.420 --> 18:19.380]  Okay, I'm Kyosuke Uematsu. I'm talking about vulnerability trends in vehicles.
[18:21.180 --> 18:26.360]  First, let me discuss the background data for this analysis.
[18:26.780 --> 18:33.380]  Our results are derived from over 300 vulnerabilities we have found in the past.
[18:34.000 --> 18:40.780]  These vulnerabilities are derived from more than 40 issues provided by more than 10 companies.
[18:41.060 --> 18:46.620]  In this analysis, we will talk about four categories of issues.
[18:46.620 --> 18:51.080]  First, the IBEX category. IBEX is in vehicle infotainment.
[18:51.080 --> 18:58.900]  It has many features, mainly navigation system, play music, and calling with your smartphone, and so on.
[18:58.900 --> 19:03.560]  It has an adjacent interface such as wireless LAN and Bluetooth.
[19:04.360 --> 19:06.680]  Second, the TCU category.
[19:06.880 --> 19:14.500]  TCU is telematics control unit. It has several interfaces such as 4G, 3G, and 2G.
[19:14.500 --> 19:19.520]  Some of them have Wi-Fi interface for access point.
[19:20.180 --> 19:22.260]  Third, the Gateway category.
[19:22.260 --> 19:30.800]  It has mostly CAN and Ethernet connection, but often OBD2 is connected here.
[19:31.160 --> 19:40.660]  The Gateway has features to separate the communication between the IBEX or TCU and the control system issues such as engine or steering issue.
[19:40.660 --> 19:44.020]  And then, the other category.
[19:44.020 --> 19:48.900]  It includes ADAS, smart key, charging, and BTX ECUs.
[19:50.620 --> 19:56.940]  OK, first, let me talk about where most of the vulnerabilities are found.
[19:57.380 --> 20:02.940]  The structure of an issue consists of hardware layer and software layer.
[20:02.940 --> 20:12.240]  Here, the software layer has OS, OSS, off-the-shelf products including interface module, and application.
[20:12.780 --> 20:22.300]  For this structure, about 70% of vulnerabilities are found in OS, OSS, and off-the-shelf products.
[20:22.500 --> 20:30.280]  For example, these 70% vulnerabilities have a lack of management for OSS version.
[20:30.280 --> 20:38.580]  Using an OSS version reported vulnerability in the vulnerability database like a CVE.
[20:38.900 --> 20:44.200]  Using an inappropriate off-the-shelf products, and so on.
[20:45.400 --> 20:51.860]  OS, OSS, and off-the-shelf products are developed by a third party.
[20:51.860 --> 20:59.480]  And in many cases, they have already provided the patches for their vulnerabilities we found.
[20:59.480 --> 21:05.820]  Pay attention to OS, OSS, and off-the-shelf products is very useful mitigation.
[21:07.420 --> 21:11.720]  OK, next, focus on the high-risk vulnerabilities.
[21:12.860 --> 21:22.840]  As a result, the 30% vulnerabilities are in application, and 70% in OS, OSS, and off-the-shelf.
[21:22.840 --> 21:28.500]  So, almost high-risk vulnerabilities are in software, not hardware.
[21:29.480 --> 21:37.520]  It means that hardware vulnerabilities hardly affect the threat scenario of vehicle user safety.
[21:38.120 --> 21:45.560]  Thinking of defense in depth, of course, hardware security is non-negligible.
[21:45.840 --> 21:49.860]  But, software security may be more important than it.
[21:51.920 --> 21:56.360]  OK, next, focus on software vulnerabilities.
[21:56.360 --> 22:02.680]  I've categorized software vulnerabilities into nine major categories.
[22:03.540 --> 22:16.360]  Insecure OS, OSS settings, insecure authentication, information leakage, use of insecure or outdated components, insecure application layer communication, and so on.
[22:16.400 --> 22:23.340]  The most often detected vulnerabilities are insecure OS and OSS settings.
[22:23.340 --> 22:29.460]  As we said, this is a trend in second-gen cars. We will dig deeper.
[22:31.440 --> 22:36.180]  We filter vulnerabilities more than medium-risk scores.
[22:36.540 --> 22:42.640]  It means that we focus on the vulnerabilities that may cause vehicle user safety.
[22:43.500 --> 22:51.200]  Through this filter, the insecure OS, OSS settings, lags down to third place.
[22:51.200 --> 22:58.440]  First place is insecure authentication, and second place is lack of secure update mechanism.
[22:59.660 --> 23:06.160]  These are two top vulnerabilities that could be a threat to the vehicle user safety.
[23:06.540 --> 23:13.320]  The example of insecure authentication is storing key or password in parentheses.
[23:13.320 --> 23:22.700]  So it may be good mitigation to keep credentials in secure elements such as trust zone, TPM, and HSM.
[23:23.640 --> 23:31.300]  The example of lack of secure update mechanism is improper implementation of signature verification.
[23:31.500 --> 23:36.460]  Thus, it is important to implement the signature verification strictly.
[23:38.400 --> 23:42.220]  Next, we focus the issue category.
[23:42.220 --> 23:47.700]  This slide message may be intuitive to you.
[23:48.060 --> 23:58.360]  That is more complex ECU that have various functions, such as IBOA, has a greater number of vulnerabilities than others.
[23:58.700 --> 24:04.660]  The left graph shows the average number of vulnerabilities for each ECU.
[24:05.040 --> 24:11.360]  On average, we find 10.9 vulnerabilities for each IBOA.
[24:12.360 --> 24:18.720]  5.6 for each TCU, and 3.5 for each gateway.
[24:19.440 --> 24:26.440]  The right graph shows the proportion of vulnerabilities for each RISC.
[24:27.360 --> 24:34.640]  It is also the IBOA that is most likely to detect high-risk vulnerabilities.
[24:34.940 --> 24:37.620]  The reason for that is simple.
[24:37.620 --> 24:43.780]  It has a lot of applications, OS, OSS, and a lot of interfaces.
[24:46.500 --> 24:49.980]  OK, next, focus the testing method.
[24:50.660 --> 24:54.720]  First, let me talk about the remote interface test.
[24:55.580 --> 25:07.340]  This graph shows the proportion of vulnerabilities we found in remote interface test, including Bluetooth, wireless LAN, server, and so on.
[25:07.620 --> 25:12.720]  The interface that found the most vulnerabilities is Bluetooth.
[25:13.780 --> 25:19.000]  Especially, Bluetooth authentication bypass vulnerabilities were most detected.
[25:19.920 --> 25:25.940]  We think this is because Bluetooth security countermeasures are not yet well known.
[25:26.880 --> 25:36.860]  On the other hand, wireless LAN and server don't have as many vulnerabilities, but some of them are serious problems.
[25:37.620 --> 25:42.740]  OK, next, let me introduce the example of Bluetooth and server.
[25:44.720 --> 25:50.700]  First, talk about the example of vulnerabilities in Bluetooth.
[25:51.440 --> 25:56.880]  Bluetooth has some vulnerabilities that can bypass authentication.
[25:57.220 --> 25:59.500]  First, using PIN mode.
[25:59.500 --> 26:02.520]  Bluetooth has two authentication modes.
[26:02.520 --> 26:07.900]  One of them is PIN mode, and it is well known to be vulnerable.
[26:08.620 --> 26:15.340]  Some of issues there are PINs were 0, 0, 0, 0. It seems vulnerable.
[26:15.940 --> 26:21.540]  Second, the BDLS spoofing, that is called CAS blues.
[26:21.820 --> 26:26.780]  And third, the no-input output of IO capability spoofing.
[26:27.820 --> 26:36.980]  These vulnerabilities are that an attacker can connect to the vehicle Bluetooth interface without user operations,
[26:36.980 --> 26:41.640]  and then perform any operation over Bluetooth interfaces.
[26:41.660 --> 26:47.120]  If a debugged serial service would remain over the Bluetooth interface,
[26:47.120 --> 26:54.900]  an attacker can connect to the debugged serial service and execute any command by exploiting these vulnerabilities.
[26:55.900 --> 27:06.060]  At least, stop using PIN mode and take care of CAS blues and no-input output devices.
[27:07.260 --> 27:10.990]  Next, let me talk about the server vulnerabilities.
[27:12.200 --> 27:17.960]  Server vulnerabilities are not so many, but sometimes found.
[27:18.200 --> 27:22.210]  We introduce one example we have found.
[27:22.930 --> 27:29.150]  We try the method of relative fuzz that can bypass server authentication.
[27:29.610 --> 27:36.630]  Of course, a lot of issues don't be exploited, but one issue could be exploited.
[27:36.770 --> 27:42.170]  When I found it, I really couldn't believe it.
[27:42.230 --> 27:51.050]  This is really bad because it allows the attacker to spoof the base station and to attack the vehicle remotely.
[27:51.050 --> 27:57.380]  In addition, the information on the server communication leaks to the attacker.
[27:58.750 --> 28:03.890]  The cause of this vulnerability is in the server stack provided by JitBender.
[28:03.890 --> 28:10.930]  Therefore, this mitigation is to get the latest software from JitBender and apply it.
[28:13.250 --> 28:18.390]  OK, next, talk about trends for the interface in the vehicle.
[28:18.890 --> 28:22.110]  Take a look at the graph on the left.
[28:22.410 --> 28:27.650]  Most of them are CAN. In-vehicle Ethernet is also important recently.
[28:28.630 --> 28:37.450]  About 80% of the vulnerabilities we found are related to in-vehicle networks, including CAN and Ethernet.
[28:37.750 --> 28:44.590]  So, let's check what type of high-risk vulnerabilities of the in-vehicle networks.
[28:44.710 --> 28:48.430]  As shown in the graph on the right,
[28:48.430 --> 28:55.310]  many UDS-related vulnerabilities are found in the in-vehicle networks.
[28:55.410 --> 29:00.670]  In the next page, let me show you some of the UDS-related vulnerabilities.
[29:03.190 --> 29:08.410]  Broken security access protection is a typical problem.
[29:08.730 --> 29:16.230]  Recently, message authentication is started to be implemented to secure messages of in-vehicle networks.
[29:16.230 --> 29:19.470]  For example, CAN and Ethernet.
[29:19.470 --> 29:23.390]  This is a pretty powerful countermeasure.
[29:24.170 --> 29:34.370]  By contrast, for UDS, security access is still a primary countermeasure for security.
[29:34.370 --> 29:39.750]  Some of the UDS vulnerabilities we found are as follows.
[29:39.750 --> 29:44.190]  1. Lack of entropy in seed generation.
[29:44.670 --> 29:49.630]  2. Insufficient initializes for random number generator.
[29:49.630 --> 29:56.070]  3. Extracting sensitive information using UDS service, such as read by ID.
[29:57.290 --> 30:06.730]  In addition, there is a problem that the private key is hard-coded and can be identified by software analysis.
[30:06.730 --> 30:12.950]  This will be explained later in software analysis section with example.
[30:14.470 --> 30:27.730]  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.
[30:30.810 --> 30:38.190]  Next, let me talk about trends in vulnerability of physical debug interfaces on the ECU.
[30:38.870 --> 30:47.330]  This graph shows the proportion of the ECU where physical debug interfaces remain unlocked.
[30:47.650 --> 30:53.810]  There are three types of vulnerabilities for the physical debug interfaces on ECU.
[30:53.850 --> 30:59.210]  1. The debugging access to the CPU via JTAG interface is available.
[30:59.650 --> 31:05.610]  2. The shared access to the CPU via UART interface is available.
[31:05.610 --> 31:13.970]  3. It is extraction of firmware from external RAM on the ECU, such as eMMC.
[31:14.610 --> 31:24.750]  As you can see from the left graph, 41% of ECUs can be accessed via JTAG interface.
[31:24.750 --> 31:33.350]  The next graph shows that 32% of ECUs can be accessed via UART.
[31:33.350 --> 31:43.170]  As you can see from the right graph, 44% of ECUs can be extracted the firmware from eMMC or others.
[31:44.330 --> 31:50.610]  The main reason is that the debugging interfaces are not locked in most ECUs.
[31:50.930 --> 31:57.530]  Even if you have locked the debugging interfaces, they are not properly locked or disabled.
[31:59.610 --> 32:10.390]  For example, JTAG is locked, but password is default value. It doesn't mean it's locked.
[32:10.390 --> 32:13.930]  Thus, of course, you must fix it.
[32:15.410 --> 32:18.910]  OK, next presenter is Shogunakao.
[32:22.900 --> 32:27.260]  OK, I'm Shogunakao. Hello, I'm Shogunakao.
[32:27.260 --> 32:38.700]  Hereafter, we talk about the trend comparing interface testing and software analysis, and also talk about software analysis with examples.
[32:38.880 --> 32:50.320]  We have been focusing on interface testing. However, there is a limit to the amount of vulnerability we found by interface testing.
[32:51.320 --> 33:01.220]  For example, though we capture and analyze the communication data, we can check the security measures on communication channel.
[33:01.860 --> 33:09.480]  It is rare that we can find vulnerabilities in the software related to the communication.
[33:10.280 --> 33:15.760]  So we analyze binary files to find vulnerability in the software.
[33:16.980 --> 33:28.620]  In fact, as shown in the left graph, we have found twice as many vulnerabilities through the software analysis as through the interface testing.
[33:29.160 --> 33:39.040]  In addition, high-risk vulnerabilities tend to be found by the software analysis, as you can see from the right graph.
[33:39.040 --> 33:52.000]  The reason for this is that the vulnerabilities found by the interface testing, like auto-scan, seem to be already fixed.
[33:52.700 --> 33:58.640]  Of course, the high-risk vulnerabilities also seem to be already fixed.
[33:58.640 --> 34:09.740]  Therefore, I think it would be significant to analyze software and binary files to find vulnerabilities in the car development.
[34:10.580 --> 34:17.030]  But we need to obtain binary files in order to analyze the software.
[34:18.120 --> 34:27.060]  For this reason, I think a good relationship between the car manufacturers, suppliers, and security vendors is essential.
[34:28.060 --> 34:35.400]  In the following slide, we will explain some specific examples on software analysis.
[34:38.580 --> 34:48.460]  In software analysis, we identify the code of the target process from the extracted binary files.
[34:48.460 --> 34:59.960]  Then, we can understand the architecture of software and relate the data flow and functions of the process, as shown in this figure.
[35:00.620 --> 35:10.580]  After that, we investigate and analyze the data flow and functions from the identified code more deeply.
[35:10.900 --> 35:17.300]  This is how we gather detailed information about the target ECU.
[35:18.460 --> 35:26.850]  Of course, we also identify and analyze the security functions by reading the binary code.
[35:27.500 --> 35:41.480]  For example, we know that the ECU has containers, terrorist communication, signature verification, and cryptographic functions.
[35:41.480 --> 35:49.460]  Then, we relate the code more deeply. We find a lot of vulnerabilities in this work.
[35:50.300 --> 35:59.320]  Next, I'll explain examples of software analysis and vulnerabilities we have found.
[36:02.120 --> 36:07.040]  The first example is analysis of an IBI code.
[36:07.040 --> 36:14.220]  First step, we identified the process of encrypting the seed with AES.
[36:14.900 --> 36:25.240]  Second step, we disassembled the target code in AIDA Pro and read it to find the AES key.
[36:26.180 --> 36:29.400]  Let's read the assembly code.
[36:30.420 --> 36:35.400]  We followed the core instruction as shown in the figure.
[36:35.400 --> 36:41.670]  Then, we can saw that it refers to the data area in the function.
[36:42.880 --> 36:50.530]  We noticed that the key for AES is in the area as we proceeded with the analysis.
[36:51.740 --> 37:01.750]  When we looked for other functions that refer this data area, we could see that they initialize the same area.
[37:01.750 --> 37:09.770]  As a result of analysis, we could find the information about the AES key, maybe, I think.
[37:10.090 --> 37:16.020]  If this is a real AES key, we may be able to hack the IBI.
[37:18.370 --> 37:24.990]  To prevent the leakage of the key, you can store it in the HSM.
[37:30.060 --> 37:35.440]  The second one is about gateway firmware.
[37:36.000 --> 37:41.140]  This is the same approach as the before slide.
[37:41.140 --> 37:47.260]  Fortunately, we are able to decompile the code in GitHub.
[37:47.940 --> 37:57.480]  This is because we identified the security access handlers and found the private key information in them rapidly.
[37:58.200 --> 38:09.800]  In this analysis, we also identified the security access algorithm, so we were able to bypass the security access.
[38:11.840 --> 38:17.720]  Binary files tell you a lot of information about the ECU and the vehicle.
[38:18.340 --> 38:25.720]  It tells you how you can hack into the vehicle or ECU and how you can extract the sensitive data.
[38:27.120 --> 38:32.140]  These are some of the vulnerabilities we found.
[38:32.640 --> 38:52.100]  For example, you can see disabling TLS certificate validation, improper signature validation, and buffer overflows and directory traversal.
[38:52.100 --> 38:58.240]  These lead to severe or high impact for the vehicle, I think.
[39:01.460 --> 39:13.120]  After checking the trend of vulnerabilities, someone may ask us whether the second-generation cars face cybersecurity threats.
[39:13.880 --> 39:19.320]  We will say it's secure in most cases.
[39:19.320 --> 39:32.260]  It's difficult to realize a threat scenario for the vehicle in terms of vehicle architecture on both security features and so on.
[39:33.020 --> 39:37.320]  In rare cases, they are unsecured ones.
[39:37.700 --> 39:44.260]  But we've reported the vulnerability we found, so it must be already fixed.
[39:48.990 --> 39:55.590]  We show five solutions against such vulnerability here.
[39:55.950 --> 40:04.310]  85% of high and medium risk vulnerabilities can be mitigated by these solutions.
[40:04.370 --> 40:09.490]  So, I sincerely recommend to introduce the solutions.
[40:10.190 --> 40:17.570]  First of all, store credential and private keys in protected area.
[40:17.570 --> 40:26.470]  For example, trust zone and TPM, HSM, or something like that.
[40:26.470 --> 40:35.730]  Second, make sure that the signature verification is done correctly.
[40:36.290 --> 40:40.650]  I'm not just talking about the verification algorithm.
[40:40.650 --> 40:49.930]  There are some vulnerabilities that signature verification is bypassed due to verification timing issues.
[40:50.510 --> 40:59.130]  Third, use appropriate random number generator and cryptosystem.
[40:59.990 --> 41:09.810]  Fourth, on OS, OSS, and off-the-shelf, pay attention to the following three things.
[41:09.810 --> 41:15.210]  The first one is use OSS properly.
[41:16.010 --> 41:26.910]  For example, we often see unproperly settings in TLS connection using OpenSSL, CURL, and so on.
[41:27.250 --> 41:35.310]  The second one is software version control and managing software composition.
[41:36.310 --> 41:41.510]  The third one, secure OS and OSS configuration.
[41:42.830 --> 41:52.570]  There are a wide range of settings, but most of them are firewall permissions and hardening settings for the OS.
[41:54.050 --> 41:59.610]  Fifth, log the physical debug port on the hardware properly.
[42:00.610 --> 42:05.570]  Finally, we will say it again.
[42:05.570 --> 42:14.890]  Just by introducing these solutions, you can mitigate 85% of the high and medium risk.
[42:15.170 --> 42:20.190]  We strongly recommend that you introduce these solutions.
[42:22.520 --> 42:25.900]  And we conclude our presentation.
[42:25.900 --> 42:28.360]  This is our conclusion.
[42:28.360 --> 42:32.400]  We answer for frequently questions.
[42:32.660 --> 42:34.140]  That's all. Thanks.