WEBVTT 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:22.330 We will show the presentation titled 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:14.950 Shogo Nakao. 03:14.950 --> 03:19.030 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:48.790 And Tatsuya Katsuhara. 03:48.790 --> 03:50.150 It's me. 03:50.150 --> 03:53.810 I'm director of NDS. 03:55.590 --> 03:56.690 Yeah, introduction. 03:56.690 --> 03:58.410 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:34.540 First, generation 0 is before Jeep. 05:34.540 --> 05:38.900 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:15.220 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. 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:37.000 Okay, let's go. 12:37.000 --> 12:38.680 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 --> 13:04.440 And we connect our laptop to the ECU via the Wi-Fi or Bluetooth 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:53.740 And is there a debug port? 16:53.740 --> 16:56.160 And is there remaining services? 16:56.160 --> 16:58.440 What is configuration? 16:58.900 --> 17:01.520 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:17.560 Okay, the last. 17:17.700 --> 17:21.520 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:15.720 Okay, I'm Kyosuke Uematsu. 18:15.720 --> 18:19.380 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:48.800 First, the IBEX category. 18:48.800 --> 18:51.080 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:09.780 TCU is telematics control unit. 19:09.780 --> 19:14.500 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:27.420 As we said, this is a trend in second-gen cars. 22:27.720 --> 22:29.460 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:13.440 Some of issues there are PINs were 0, 0, 0, 0. 26:13.440 --> 26:15.340 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:41.640 These vulnerabilities are that an attacker can connect to the vehicle Bluetooth interface without user operations, and then perform any operation over Bluetooth interfaces. 26:41.660 --> 26:54.900 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. 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:24.450 Most of them are CAN. 28:24.450 --> 28:27.650 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:55.310 As shown in the graph on the right, 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:40.950 1. 29:40.950 --> 29:44.190 Lack of entropy in seed generation. 29:44.670 --> 29:45.470 2. 29:45.470 --> 29:49.630 Insufficient initializes for random number generator. 29:49.630 --> 29:49.990 3. 29:49.990 --> 29:56.070 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:54.530 1. 30:54.530 --> 30:59.210 The debugging access to the CPU via JTAG interface is available. 30:59.650 --> 31:00.990 2. 31:00.990 --> 31:05.610 The shared access to the CPU via UART interface is available. 31:05.610 --> 31:06.870 3. 31:06.870 --> 31:13.970 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:07.150 For example, JTAG is locked, but password is default value. 32:07.150 --> 32:10.390 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:25.080 OK, I'm Shogunakao. 32:25.080 --> 32:27.260 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:43.200 We have been focusing on interface testing. 32:43.380 --> 32:50.320 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:45.880 Then, we relate the code more deeply. 35:45.880 --> 35:49.460 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:33.360 That's all. 42:33.360 --> 42:34.140 Thanks.