1 00:00:03,060 --> 00:00:08,540 Firstly, thank you for giving a chance to talk here. 2 00:00:08,540 --> 00:00:11,510 We are very grateful for this chance. 3 00:00:12,040 --> 00:00:22,330 We will show the presentation titled Realistic Trends in Vulnerability Based on Hacking into Vehicles from Tokyo. 4 00:00:24,220 --> 00:00:30,460 OK, at first, please let us introduce ourselves briefly. 5 00:00:32,080 --> 00:00:34,240 Who am I? 6 00:00:35,720 --> 00:00:37,880 Do you know Denso? 7 00:00:38,160 --> 00:00:44,180 They are one of the top automotive component suppliers in the world. 8 00:00:44,380 --> 00:00:46,960 Do you know NRI? 9 00:00:47,060 --> 00:00:50,520 Is it a very famous company? 10 00:00:51,320 --> 00:00:54,820 Honestly speaking, I really don't know. 11 00:00:54,820 --> 00:01:03,020 But they are famous, at least in Japan, on IT and IoT security. 12 00:01:04,200 --> 00:01:09,180 NIDS is jointly founded by these two companies. 13 00:01:09,300 --> 00:01:10,920 Yeah, so cool. 14 00:01:11,540 --> 00:01:18,600 And I mentioned an important thing that our clients often ask us. 15 00:01:18,600 --> 00:01:28,680 We never ever share the issues and vehicles information with Denso and NRI without your permission. 16 00:01:28,680 --> 00:01:34,180 So please feel free to contact us. 17 00:01:39,400 --> 00:01:43,480 NIDS activities on business. 18 00:01:43,680 --> 00:01:52,380 We provide the cybersecurity assessment and consultation services for 6 OEMs and several suppliers. 19 00:01:53,310 --> 00:02:00,720 On competition, we'd like to mention our activity on the Car Hacking Village. 20 00:02:00,720 --> 00:02:11,650 We are a CTF and we got this position two years ago and fourth in last year. 21 00:02:12,060 --> 00:02:16,900 So we believed to get third this year. 22 00:02:16,900 --> 00:02:24,180 But unfortunately, we got accepted for this presentation. 23 00:02:24,180 --> 00:02:29,200 So we are not ready now for that CTF. 24 00:02:29,600 --> 00:02:32,960 Yeah, that is a bad thing. 25 00:02:36,450 --> 00:02:44,810 On behalf of our company, I'd like to introduce fantastic four providing this presentation. 26 00:02:46,390 --> 00:02:47,790 Ryosuke Uematsu. 27 00:02:47,790 --> 00:02:53,950 He's known as a wireless enthusiast in Japan. 28 00:02:54,550 --> 00:02:57,230 He loves LG so much. 29 00:02:57,230 --> 00:03:05,290 In our company, he is known as living in radio anechoic chamber. 30 00:03:05,650 --> 00:03:12,670 And we believe that he can see the radio waves over the air. 31 00:03:12,670 --> 00:03:14,950 Shogo Nakao. 32 00:03:14,950 --> 00:03:19,030 He used to work for Functional Safety. 33 00:03:19,230 --> 00:03:23,410 But now he is a binary otaku. 34 00:03:24,250 --> 00:03:30,530 We've heard that his friend is only either pro. 35 00:03:31,630 --> 00:03:33,810 Next, Ryoichi Teramura. 36 00:03:34,430 --> 00:03:39,070 He leads our team and he is a cryptographer. 37 00:03:39,070 --> 00:03:44,230 His favorite cryptography is 3D. 38 00:03:45,650 --> 00:03:48,790 And Tatsuya Katsuhara. 39 00:03:48,790 --> 00:03:50,150 It's me. 40 00:03:50,150 --> 00:03:53,810 I'm director of NDS. 41 00:03:55,590 --> 00:03:56,690 Yeah, introduction. 42 00:03:56,690 --> 00:03:58,410 That's all. 43 00:04:03,360 --> 00:04:09,760 These years, a number of car threats have been reported. 44 00:04:09,760 --> 00:04:16,940 You may know the Jeep and recently BMW and Lexus issues are reported by Tencent. 45 00:04:17,320 --> 00:04:20,820 Yeah, they are so cool. 46 00:04:21,280 --> 00:04:26,960 The automotive industry has done a lot on cybersecurity. 47 00:04:27,020 --> 00:04:32,420 The most famous one is WP-29. 48 00:04:33,160 --> 00:04:36,160 It requires really a lot of things. 49 00:04:36,160 --> 00:04:53,600 Software development lifecycle, security operations center, inclusion, detection and prevention system, product security incident response team, PSAT, and so on. 50 00:04:53,600 --> 00:04:59,840 And don't forget ISO SAE-21434. 51 00:05:00,840 --> 00:05:08,160 The important thing is that car developing process takes so long. 52 00:05:08,680 --> 00:05:21,840 So there is a gap between the publication of research about certain vulnerability and actual release of countermeasure. 53 00:05:21,840 --> 00:05:29,320 So I have defined car cybersecurity generation based on these gaps. 54 00:05:29,500 --> 00:05:34,540 First, generation 0 is before Jeep. 55 00:05:34,540 --> 00:05:38,900 Almost no mitigation, no regulation. 56 00:05:39,900 --> 00:05:43,880 Generation 1 is after Jeep. 57 00:05:43,880 --> 00:05:53,160 Some ready-to-go countermeasures like gateway ECU are implemented. 58 00:05:53,160 --> 00:05:58,220 But no electrical platform refurbishment. 59 00:05:59,440 --> 00:06:01,200 Generation 2. 60 00:06:01,520 --> 00:06:13,240 Our presentation focuses on this generation where new security countermeasures are implemented. 61 00:06:14,600 --> 00:06:16,660 Generation 3. 62 00:06:17,300 --> 00:06:29,200 This generation includes security features complied with WP-29 and ISO standard. 63 00:06:33,740 --> 00:06:35,020 Okay. 64 00:06:35,600 --> 00:06:42,320 So, yes, what we are going to talk about in this presentation. 65 00:06:42,320 --> 00:06:47,780 First, we introduce our testing approaches. 66 00:06:48,260 --> 00:06:59,340 Second, we introduce the trends of the vulnerabilities we found for second-generation vehicles and ECUs. 67 00:06:59,340 --> 00:07:07,540 These results are based on more than 40 ECUs and 300 vulnerabilities. 68 00:07:07,540 --> 00:07:11,380 Here are some of the examples. 69 00:07:11,380 --> 00:07:15,680 And then we present effective mitigations. 70 00:07:17,590 --> 00:07:27,150 Of course, we have already reported these vulnerabilities to car manufacturers and suppliers directly. 71 00:07:27,150 --> 00:07:34,150 So it shouldn't be a threat in the actual car. 72 00:07:34,170 --> 00:07:36,470 I think. 73 00:07:37,470 --> 00:07:49,270 I believe that many car manufacturers and ECU suppliers are developing second-generation products just now. 74 00:07:49,270 --> 00:07:58,210 So I hope the results of this analysis will help such a developer. 75 00:07:59,130 --> 00:08:04,150 Okay, I'll turn it over to Teramura. 76 00:08:05,150 --> 00:08:08,470 Okay, hello, nice to meet you. 77 00:08:08,470 --> 00:08:10,630 My name is Yoshi Teramura. 78 00:08:11,390 --> 00:08:18,250 And before getting to the main point, let's talk briefly about our testing methods and approaches. 79 00:08:20,610 --> 00:08:25,190 We think there are two main categories of car testing methods. 80 00:08:25,370 --> 00:08:29,310 The first one is a test for the vehicle itself. 81 00:08:29,450 --> 00:08:32,330 Another is a test for each ECU. 82 00:08:32,330 --> 00:08:36,730 So these tests are different in their purpose. 83 00:08:37,550 --> 00:08:40,010 ECU test is just a unit test. 84 00:08:40,010 --> 00:08:45,090 So it can test a detail but cannot see the entire vehicle. 85 00:08:45,510 --> 00:08:49,790 But vehicle test is like an integration test. 86 00:08:50,250 --> 00:08:53,810 It is difficult to check the detail. 87 00:08:53,910 --> 00:09:01,270 But it's easy to check whether a vehicle can run or not during the test. 88 00:09:02,270 --> 00:09:06,550 So we have experienced both tests. 89 00:09:06,610 --> 00:09:15,490 And we think ECU test is more suitable for finding vulnerabilities than vehicle test. 90 00:09:15,630 --> 00:09:20,630 So this presentation focuses on vulnerability. 91 00:09:20,630 --> 00:09:25,570 So we have an analyzer result of our ECU test results. 92 00:09:30,390 --> 00:09:35,510 First, we explain ECU test methods and approaches from the next page. 93 00:09:40,940 --> 00:09:44,740 ECU test is that it can find vulnerabilities in the ECU. 94 00:09:46,180 --> 00:09:49,100 This slide shows two graphs. 95 00:09:49,160 --> 00:09:52,140 The left graph shows ECU stats. 96 00:09:52,140 --> 00:09:56,640 And the right graph shows our test approaches. 97 00:09:58,080 --> 00:10:02,000 The ECU consists of a lot of components. 98 00:10:02,220 --> 00:10:04,760 It is shown in the left graph. 99 00:10:05,000 --> 00:10:07,100 For example, hardware. 100 00:10:07,180 --> 00:10:09,820 Of course, the interface drivers. 101 00:10:10,080 --> 00:10:11,360 OS kernel. 102 00:10:11,740 --> 00:10:13,100 And the bootstrap. 103 00:10:13,260 --> 00:10:14,740 And the middleware. 104 00:10:14,740 --> 00:10:16,500 And the open-source software. 105 00:10:16,660 --> 00:10:20,420 And of course, applications that run on the OS. 106 00:10:21,960 --> 00:10:25,460 Do you know where is the vulnerability? 107 00:10:26,280 --> 00:10:28,540 Of course, the answer is easy. 108 00:10:28,540 --> 00:10:30,700 The answer is everywhere. 109 00:10:31,860 --> 00:10:38,180 There are vulnerabilities everywhere in the ECU stats. 110 00:10:39,660 --> 00:10:44,240 And to find them, we use a lot of test methods. 111 00:10:47,620 --> 00:10:52,400 The right graph shows our test methods and approaches. 112 00:10:52,400 --> 00:10:56,750 And our test methods are divided into two categories. 113 00:10:57,100 --> 00:10:59,200 One is interface test. 114 00:10:59,200 --> 00:11:02,640 And another is software analysis. 115 00:11:03,680 --> 00:11:07,320 Interface test is one of the black box tests. 116 00:11:09,260 --> 00:11:13,760 Finding vulnerabilities through ECU's interface. 117 00:11:14,180 --> 00:11:20,840 And software analysis is one of the white box or occasionally gray box tests. 118 00:11:20,840 --> 00:11:24,060 Okay, let's take a look at each method. 119 00:11:28,020 --> 00:11:34,400 First, I will introduce interface test and especially remote interface test. 120 00:11:34,400 --> 00:11:35,900 That is Celera. 121 00:11:36,540 --> 00:11:40,980 Do you know this box in this picture? 122 00:11:41,840 --> 00:11:44,580 And this is an unread product. 123 00:11:44,580 --> 00:11:52,860 And this unread product comes as a spoofed base station of LTE or 3G. 124 00:11:52,860 --> 00:11:57,980 And we use it and check the connected services over the Celera network. 125 00:11:58,820 --> 00: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. 126 00:12:16,380 --> 00:12:20,300 But there is one caution point. 127 00:12:20,300 --> 00:12:27,580 In some countries, like Japan, the radio law prevents this type of test. 128 00:12:27,840 --> 00:12:33,560 So you must check your country's law before remote interface testing. 129 00:12:35,300 --> 00:12:37,000 Okay, let's go. 130 00:12:37,000 --> 00:12:38,680 Next, adjacent interfaces. 131 00:12:39,660 --> 00:12:48,580 Adjacent interfaces are like Wi-Fi and Bluetooth, NFC, radio frequency, and more. 132 00:12:50,300 --> 00:12:54,180 This test doesn't need a spoofing base station. 133 00:12:54,280 --> 00: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. 134 00:13:07,020 --> 00:13:12,600 Then we check the vulnerability in the protocol stack and authentication function. 135 00:13:13,380 --> 00:13:17,520 We often use a scanner tool in this test. 136 00:13:17,520 --> 00:13:24,000 And it can find authentication bypasses and some well-known vulnerabilities. 137 00:13:25,220 --> 00:13:28,940 Next, the local interfaces. 138 00:13:29,060 --> 00:13:36,060 We show the local interfaces like a USB or CAN. 139 00:13:36,500 --> 00:13:38,780 Everyone likes CAN. 140 00:13:38,780 --> 00:13:43,680 And inter-ethernet and more. 141 00:13:43,680 --> 00:13:52,360 And in this test, we connect the laptop to the ECU directly via cable or harnesses. 142 00:13:52,480 --> 00:13:55,680 And we often check the security access for UDS and... 143 00:13:58,860 --> 00:14:01,700 occasionally, are internet services remaining? 144 00:14:02,260 --> 00:14:08,140 Okay, and we use a tool like a hotting tool and a scanner tool for this test. 145 00:14:11,200 --> 00:14:12,900 Okay, next one. 146 00:14:13,300 --> 00:14:15,980 Okay, next one is physical interfaces. 147 00:14:17,260 --> 00:14:29,100 Physical interfaces target JTAG, SPI, UART, and more installed in the chip. 148 00:14:29,100 --> 00:14:38,240 The purpose of this test is to check whether we can extract firmware or overwrite the firmware. 149 00:14:41,040 --> 00:14:44,760 The microcontroller or external flash on the chip. 150 00:14:46,560 --> 00:14:51,270 Okay, and in this test, very important skill is soldering. 151 00:14:51,540 --> 00:14:53,800 So our staff is very skillful. 152 00:14:56,160 --> 00:14:57,760 Okay, next. 153 00:14:58,220 --> 00:14:59,880 Dynamic software analysis. 154 00:15:01,640 --> 00:15:09,000 If we can extract the firmware from the ECU, we try the software analysis, static and dynamic. 155 00:15:09,700 --> 00:15:11,960 The dynamic software analysis. 156 00:15:12,000 --> 00:15:25,760 We log in the application on the actual or virtual ECU via SSH and UART and more. 157 00:15:26,420 --> 00:15:34,040 And when we can connect to the ECU, check the internal of them. 158 00:15:34,440 --> 00:15:37,480 Once logged in, we can check a lot of things. 159 00:15:37,480 --> 00:15:46,340 Scanning processes, log files, software version, setting files, credential files, and many data. 160 00:15:49,580 --> 00:15:54,440 And of course, if we can get the firmware, we'll try the static software analysis. 161 00:15:55,240 --> 00:16:05,000 We need a firmware as an assembler or sometimes pre-code using it too, such as AIDA Pro or GDRA. 162 00:16:07,440 --> 00:16:11,800 And we can use it and search the vulnerability. 163 00:16:13,700 --> 00:16:20,480 If the firmware includes an operational system such as Linux, we can run it on a virtual machine. 164 00:16:20,840 --> 00:16:28,080 And if the firmware includes a file system, we can mount the file system and check the files in it. 165 00:16:28,920 --> 00:16:35,420 So we think the firmware is a good alternative of a source code and a debug console. 166 00:16:36,780 --> 00:16:39,140 The software tells us many things. 167 00:16:39,220 --> 00:16:41,600 Many, many things, a lot of things. 168 00:16:42,260 --> 00:16:45,060 There are known vulnerabilities. 169 00:16:45,720 --> 00:16:51,240 And what is open source software and Office 365 product versions? 170 00:16:51,540 --> 00:16:53,740 And is there a debug port? 171 00:16:53,740 --> 00:16:56,160 And is there remaining services? 172 00:16:56,160 --> 00:16:58,440 What is configuration? 173 00:16:58,900 --> 00:17:01,520 Where is the hard-coded credential? 174 00:17:02,360 --> 00:17:05,160 Software analysis tells many things. 175 00:17:07,200 --> 00:17:11,100 Okay, this is a wrap-up, the test result. 176 00:17:11,440 --> 00:17:14,580 But this time we skip it. 177 00:17:15,840 --> 00:17:17,560 Okay, the last. 178 00:17:17,700 --> 00:17:21,520 Here is our matrix to the risk score of the vulnerabilities. 179 00:17:21,920 --> 00:17:25,880 The risk score is determined based on two factors. 180 00:17:26,160 --> 00:17:29,620 One is damage impact and one is attack feasibility. 181 00:17:29,700 --> 00:17:35,640 Damage impact and attack feasibility are evaluated from the view of vehicles. 182 00:17:35,920 --> 00:17:38,880 From the vehicles, it's an important point. 183 00:17:40,400 --> 00:17:46,060 From the view of vehicle users, vehicle users' safety. 184 00:17:47,160 --> 00:17:50,460 So it's from not only ECU. 185 00:17:51,320 --> 00:18:00,620 This means that the risk score related to the vulnerabilities of internal network tends to be decreasing. 186 00:18:01,700 --> 00:18:10,080 Okay, from the next page, we will show our analysis of the vulnerabilities and their risk score from Kyosuke Uematsu. 187 00:18:12,420 --> 00:18:15,720 Okay, I'm Kyosuke Uematsu. 188 00:18:15,720 --> 00:18:19,380 I'm talking about vulnerability trends in vehicles. 189 00:18:21,180 --> 00:18:26,360 First, let me discuss the background data for this analysis. 190 00:18:26,780 --> 00:18:33,380 Our results are derived from over 300 vulnerabilities we have found in the past. 191 00:18:34,000 --> 00:18:40,780 These vulnerabilities are derived from more than 40 issues provided by more than 10 companies. 192 00:18:41,060 --> 00:18:46,620 In this analysis, we will talk about four categories of issues. 193 00:18:46,620 --> 00:18:48,800 First, the IBEX category. 194 00:18:48,800 --> 00:18:51,080 IBEX is in vehicle infotainment. 195 00:18:51,080 --> 00:18:58,900 It has many features, mainly navigation system, play music, and calling with your smartphone, and so on. 196 00:18:58,900 --> 00:19:03,560 It has an adjacent interface such as wireless LAN and Bluetooth. 197 00:19:04,360 --> 00:19:06,680 Second, the TCU category. 198 00:19:06,880 --> 00:19:09,780 TCU is telematics control unit. 199 00:19:09,780 --> 00:19:14,500 It has several interfaces such as 4G, 3G, and 2G. 200 00:19:14,500 --> 00:19:19,520 Some of them have Wi-Fi interface for access point. 201 00:19:20,180 --> 00:19:22,260 Third, the Gateway category. 202 00:19:22,260 --> 00:19:30,800 It has mostly CAN and Ethernet connection, but often OBD2 is connected here. 203 00:19:31,160 --> 00: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. 204 00:19:40,660 --> 00:19:44,020 And then, the other category. 205 00:19:44,020 --> 00:19:48,900 It includes ADAS, smart key, charging, and BTX ECUs. 206 00:19:50,620 --> 00:19:56,940 OK, first, let me talk about where most of the vulnerabilities are found. 207 00:19:57,380 --> 00:20:02,940 The structure of an issue consists of hardware layer and software layer. 208 00:20:02,940 --> 00:20:12,240 Here, the software layer has OS, OSS, off-the-shelf products including interface module, and application. 209 00:20:12,780 --> 00:20:22,300 For this structure, about 70% of vulnerabilities are found in OS, OSS, and off-the-shelf products. 210 00:20:22,500 --> 00:20:30,280 For example, these 70% vulnerabilities have a lack of management for OSS version. 211 00:20:30,280 --> 00:20:38,580 Using an OSS version reported vulnerability in the vulnerability database like a CVE. 212 00:20:38,900 --> 00:20:44,200 Using an inappropriate off-the-shelf products, and so on. 213 00:20:45,400 --> 00:20:51,860 OS, OSS, and off-the-shelf products are developed by a third party. 214 00:20:51,860 --> 00:20:59,480 And in many cases, they have already provided the patches for their vulnerabilities we found. 215 00:20:59,480 --> 00:21:05,820 Pay attention to OS, OSS, and off-the-shelf products is very useful mitigation. 216 00:21:07,420 --> 00:21:11,720 OK, next, focus on the high-risk vulnerabilities. 217 00:21:12,860 --> 00:21:22,840 As a result, the 30% vulnerabilities are in application, and 70% in OS, OSS, and off-the-shelf. 218 00:21:22,840 --> 00:21:28,500 So, almost high-risk vulnerabilities are in software, not hardware. 219 00:21:29,480 --> 00:21:37,520 It means that hardware vulnerabilities hardly affect the threat scenario of vehicle user safety. 220 00:21:38,120 --> 00:21:45,560 Thinking of defense in depth, of course, hardware security is non-negligible. 221 00:21:45,840 --> 00:21:49,860 But, software security may be more important than it. 222 00:21:51,920 --> 00:21:56,360 OK, next, focus on software vulnerabilities. 223 00:21:56,360 --> 00:22:02,680 I've categorized software vulnerabilities into nine major categories. 224 00:22:03,540 --> 00:22:16,360 Insecure OS, OSS settings, insecure authentication, information leakage, use of insecure or outdated components, insecure application layer communication, and so on. 225 00:22:16,400 --> 00:22:23,340 The most often detected vulnerabilities are insecure OS and OSS settings. 226 00:22:23,340 --> 00:22:27,420 As we said, this is a trend in second-gen cars. 227 00:22:27,720 --> 00:22:29,460 We will dig deeper. 228 00:22:31,440 --> 00:22:36,180 We filter vulnerabilities more than medium-risk scores. 229 00:22:36,540 --> 00:22:42,640 It means that we focus on the vulnerabilities that may cause vehicle user safety. 230 00:22:43,500 --> 00:22:51,200 Through this filter, the insecure OS, OSS settings, lags down to third place. 231 00:22:51,200 --> 00:22:58,440 First place is insecure authentication, and second place is lack of secure update mechanism. 232 00:22:59,660 --> 00:23:06,160 These are two top vulnerabilities that could be a threat to the vehicle user safety. 233 00:23:06,540 --> 00:23:13,320 The example of insecure authentication is storing key or password in parentheses. 234 00:23:13,320 --> 00:23:22,700 So it may be good mitigation to keep credentials in secure elements such as trust zone, TPM, and HSM. 235 00:23:23,640 --> 00:23:31,300 The example of lack of secure update mechanism is improper implementation of signature verification. 236 00:23:31,500 --> 00:23:36,460 Thus, it is important to implement the signature verification strictly. 237 00:23:38,400 --> 00:23:42,220 Next, we focus the issue category. 238 00:23:42,220 --> 00:23:47,700 This slide message may be intuitive to you. 239 00:23:48,060 --> 00:23:58,360 That is more complex ECU that have various functions, such as IBOA, has a greater number of vulnerabilities than others. 240 00:23:58,700 --> 00:24:04,660 The left graph shows the average number of vulnerabilities for each ECU. 241 00:24:05,040 --> 00:24:11,360 On average, we find 10.9 vulnerabilities for each IBOA. 242 00:24:12,360 --> 00:24:18,720 5.6 for each TCU, and 3.5 for each gateway. 243 00:24:19,440 --> 00:24:26,440 The right graph shows the proportion of vulnerabilities for each RISC. 244 00:24:27,360 --> 00:24:34,640 It is also the IBOA that is most likely to detect high-risk vulnerabilities. 245 00:24:34,940 --> 00:24:37,620 The reason for that is simple. 246 00:24:37,620 --> 00:24:43,780 It has a lot of applications, OS, OSS, and a lot of interfaces. 247 00:24:46,500 --> 00:24:49,980 OK, next, focus the testing method. 248 00:24:50,660 --> 00:24:54,720 First, let me talk about the remote interface test. 249 00:24:55,580 --> 00:25:07,340 This graph shows the proportion of vulnerabilities we found in remote interface test, including Bluetooth, wireless LAN, server, and so on. 250 00:25:07,620 --> 00:25:12,720 The interface that found the most vulnerabilities is Bluetooth. 251 00:25:13,780 --> 00:25:19,000 Especially, Bluetooth authentication bypass vulnerabilities were most detected. 252 00:25:19,920 --> 00:25:25,940 We think this is because Bluetooth security countermeasures are not yet well known. 253 00:25:26,880 --> 00:25:36,860 On the other hand, wireless LAN and server don't have as many vulnerabilities, but some of them are serious problems. 254 00:25:37,620 --> 00:25:42,740 OK, next, let me introduce the example of Bluetooth and server. 255 00:25:44,720 --> 00:25:50,700 First, talk about the example of vulnerabilities in Bluetooth. 256 00:25:51,440 --> 00:25:56,880 Bluetooth has some vulnerabilities that can bypass authentication. 257 00:25:57,220 --> 00:25:59,500 First, using PIN mode. 258 00:25:59,500 --> 00:26:02,520 Bluetooth has two authentication modes. 259 00:26:02,520 --> 00:26:07,900 One of them is PIN mode, and it is well known to be vulnerable. 260 00:26:08,620 --> 00:26:13,440 Some of issues there are PINs were 0, 0, 0, 0. 261 00:26:13,440 --> 00:26:15,340 It seems vulnerable. 262 00:26:15,940 --> 00:26:21,540 Second, the BDLS spoofing, that is called CAS blues. 263 00:26:21,820 --> 00:26:26,780 And third, the no-input output of IO capability spoofing. 264 00:26:27,820 --> 00: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. 265 00:26:41,660 --> 00: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. 266 00:26:55,900 --> 00:27:06,060 At least, stop using PIN mode and take care of CAS blues and no-input output devices. 267 00:27:07,260 --> 00:27:10,990 Next, let me talk about the server vulnerabilities. 268 00:27:12,200 --> 00:27:17,960 Server vulnerabilities are not so many, but sometimes found. 269 00:27:18,200 --> 00:27:22,210 We introduce one example we have found. 270 00:27:22,930 --> 00:27:29,150 We try the method of relative fuzz that can bypass server authentication. 271 00:27:29,610 --> 00:27:36,630 Of course, a lot of issues don't be exploited, but one issue could be exploited. 272 00:27:36,770 --> 00:27:42,170 When I found it, I really couldn't believe it. 273 00:27:42,230 --> 00:27:51,050 This is really bad because it allows the attacker to spoof the base station and to attack the vehicle remotely. 274 00:27:51,050 --> 00:27:57,380 In addition, the information on the server communication leaks to the attacker. 275 00:27:58,750 --> 00:28:03,890 The cause of this vulnerability is in the server stack provided by JitBender. 276 00:28:03,890 --> 00:28:10,930 Therefore, this mitigation is to get the latest software from JitBender and apply it. 277 00:28:13,250 --> 00:28:18,390 OK, next, talk about trends for the interface in the vehicle. 278 00:28:18,890 --> 00:28:22,110 Take a look at the graph on the left. 279 00:28:22,410 --> 00:28:24,450 Most of them are CAN. 280 00:28:24,450 --> 00:28:27,650 In-vehicle Ethernet is also important recently. 281 00:28:28,630 --> 00:28:37,450 About 80% of the vulnerabilities we found are related to in-vehicle networks, including CAN and Ethernet. 282 00:28:37,750 --> 00:28:44,590 So, let's check what type of high-risk vulnerabilities of the in-vehicle networks. 283 00:28:44,710 --> 00:28:55,310 As shown in the graph on the right, many UDS-related vulnerabilities are found in the in-vehicle networks. 284 00:28:55,410 --> 00:29:00,670 In the next page, let me show you some of the UDS-related vulnerabilities. 285 00:29:03,190 --> 00:29:08,410 Broken security access protection is a typical problem. 286 00:29:08,730 --> 00:29:16,230 Recently, message authentication is started to be implemented to secure messages of in-vehicle networks. 287 00:29:16,230 --> 00:29:19,470 For example, CAN and Ethernet. 288 00:29:19,470 --> 00:29:23,390 This is a pretty powerful countermeasure. 289 00:29:24,170 --> 00:29:34,370 By contrast, for UDS, security access is still a primary countermeasure for security. 290 00:29:34,370 --> 00:29:39,750 Some of the UDS vulnerabilities we found are as follows. 291 00:29:39,750 --> 00:29:40,950 1. 292 00:29:40,950 --> 00:29:44,190 Lack of entropy in seed generation. 293 00:29:44,670 --> 00:29:45,470 2. 294 00:29:45,470 --> 00:29:49,630 Insufficient initializes for random number generator. 295 00:29:49,630 --> 00:29:49,990 3. 296 00:29:49,990 --> 00:29:56,070 Extracting sensitive information using UDS service, such as read by ID. 297 00:29:57,290 --> 00:30:06,730 In addition, there is a problem that the private key is hard-coded and can be identified by software analysis. 298 00:30:06,730 --> 00:30:12,950 This will be explained later in software analysis section with example. 299 00:30:14,470 --> 00: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. 300 00:30:30,810 --> 00:30:38,190 Next, let me talk about trends in vulnerability of physical debug interfaces on the ECU. 301 00:30:38,870 --> 00:30:47,330 This graph shows the proportion of the ECU where physical debug interfaces remain unlocked. 302 00:30:47,650 --> 00:30:53,810 There are three types of vulnerabilities for the physical debug interfaces on ECU. 303 00:30:53,850 --> 00:30:54,530 1. 304 00:30:54,530 --> 00:30:59,210 The debugging access to the CPU via JTAG interface is available. 305 00:30:59,650 --> 00:31:00,990 2. 306 00:31:00,990 --> 00:31:05,610 The shared access to the CPU via UART interface is available. 307 00:31:05,610 --> 00:31:06,870 3. 308 00:31:06,870 --> 00:31:13,970 It is extraction of firmware from external RAM on the ECU, such as eMMC. 309 00:31:14,610 --> 00:31:24,750 As you can see from the left graph, 41% of ECUs can be accessed via JTAG interface. 310 00:31:24,750 --> 00:31:33,350 The next graph shows that 32% of ECUs can be accessed via UART. 311 00:31:33,350 --> 00:31:43,170 As you can see from the right graph, 44% of ECUs can be extracted the firmware from eMMC or others. 312 00:31:44,330 --> 00:31:50,610 The main reason is that the debugging interfaces are not locked in most ECUs. 313 00:31:50,930 --> 00:31:57,530 Even if you have locked the debugging interfaces, they are not properly locked or disabled. 314 00:31:59,610 --> 00:32:07,150 For example, JTAG is locked, but password is default value. 315 00:32:07,150 --> 00:32:10,390 It doesn't mean it's locked. 316 00:32:10,390 --> 00:32:13,930 Thus, of course, you must fix it. 317 00:32:15,410 --> 00:32:18,910 OK, next presenter is Shogunakao. 318 00:32:22,900 --> 00:32:25,080 OK, I'm Shogunakao. 319 00:32:25,080 --> 00:32:27,260 Hello, I'm Shogunakao. 320 00:32:27,260 --> 00:32:38,700 Hereafter, we talk about the trend comparing interface testing and software analysis, and also talk about software analysis with examples. 321 00:32:38,880 --> 00:32:43,200 We have been focusing on interface testing. 322 00:32:43,380 --> 00:32:50,320 However, there is a limit to the amount of vulnerability we found by interface testing. 323 00:32:51,320 --> 00:33:01,220 For example, though we capture and analyze the communication data, we can check the security measures on communication channel. 324 00:33:01,860 --> 00:33:09,480 It is rare that we can find vulnerabilities in the software related to the communication. 325 00:33:10,280 --> 00:33:15,760 So we analyze binary files to find vulnerability in the software. 326 00:33:16,980 --> 00: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. 327 00:33:29,160 --> 00:33:39,040 In addition, high-risk vulnerabilities tend to be found by the software analysis, as you can see from the right graph. 328 00:33:39,040 --> 00:33:52,000 The reason for this is that the vulnerabilities found by the interface testing, like auto-scan, seem to be already fixed. 329 00:33:52,700 --> 00:33:58,640 Of course, the high-risk vulnerabilities also seem to be already fixed. 330 00:33:58,640 --> 00:34:09,740 Therefore, I think it would be significant to analyze software and binary files to find vulnerabilities in the car development. 331 00:34:10,580 --> 00:34:17,030 But we need to obtain binary files in order to analyze the software. 332 00:34:18,120 --> 00:34:27,060 For this reason, I think a good relationship between the car manufacturers, suppliers, and security vendors is essential. 333 00:34:28,060 --> 00:34:35,400 In the following slide, we will explain some specific examples on software analysis. 334 00:34:38,580 --> 00:34:48,460 In software analysis, we identify the code of the target process from the extracted binary files. 335 00:34:48,460 --> 00: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. 336 00:35:00,620 --> 00:35:10,580 After that, we investigate and analyze the data flow and functions from the identified code more deeply. 337 00:35:10,900 --> 00:35:17,300 This is how we gather detailed information about the target ECU. 338 00:35:18,460 --> 00:35:26,850 Of course, we also identify and analyze the security functions by reading the binary code. 339 00:35:27,500 --> 00:35:41,480 For example, we know that the ECU has containers, terrorist communication, signature verification, and cryptographic functions. 340 00:35:41,480 --> 00:35:45,880 Then, we relate the code more deeply. 341 00:35:45,880 --> 00:35:49,460 We find a lot of vulnerabilities in this work. 342 00:35:50,300 --> 00:35:59,320 Next, I'll explain examples of software analysis and vulnerabilities we have found. 343 00:36:02,120 --> 00:36:07,040 The first example is analysis of an IBI code. 344 00:36:07,040 --> 00:36:14,220 First step, we identified the process of encrypting the seed with AES. 345 00:36:14,900 --> 00:36:25,240 Second step, we disassembled the target code in AIDA Pro and read it to find the AES key. 346 00:36:26,180 --> 00:36:29,400 Let's read the assembly code. 347 00:36:30,420 --> 00:36:35,400 We followed the core instruction as shown in the figure. 348 00:36:35,400 --> 00:36:41,670 Then, we can saw that it refers to the data area in the function. 349 00:36:42,880 --> 00:36:50,530 We noticed that the key for AES is in the area as we proceeded with the analysis. 350 00:36:51,740 --> 00:37:01,750 When we looked for other functions that refer this data area, we could see that they initialize the same area. 351 00:37:01,750 --> 00:37:09,770 As a result of analysis, we could find the information about the AES key, maybe, I think. 352 00:37:10,090 --> 00:37:16,020 If this is a real AES key, we may be able to hack the IBI. 353 00:37:18,370 --> 00:37:24,990 To prevent the leakage of the key, you can store it in the HSM. 354 00:37:30,060 --> 00:37:35,440 The second one is about gateway firmware. 355 00:37:36,000 --> 00:37:41,140 This is the same approach as the before slide. 356 00:37:41,140 --> 00:37:47,260 Fortunately, we are able to decompile the code in GitHub. 357 00:37:47,940 --> 00:37:57,480 This is because we identified the security access handlers and found the private key information in them rapidly. 358 00:37:58,200 --> 00:38:09,800 In this analysis, we also identified the security access algorithm, so we were able to bypass the security access. 359 00:38:11,840 --> 00:38:17,720 Binary files tell you a lot of information about the ECU and the vehicle. 360 00:38:18,340 --> 00:38:25,720 It tells you how you can hack into the vehicle or ECU and how you can extract the sensitive data. 361 00:38:27,120 --> 00:38:32,140 These are some of the vulnerabilities we found. 362 00:38:32,640 --> 00:38:52,100 For example, you can see disabling TLS certificate validation, improper signature validation, and buffer overflows and directory traversal. 363 00:38:52,100 --> 00:38:58,240 These lead to severe or high impact for the vehicle, I think. 364 00:39:01,460 --> 00:39:13,120 After checking the trend of vulnerabilities, someone may ask us whether the second-generation cars face cybersecurity threats. 365 00:39:13,880 --> 00:39:19,320 We will say it's secure in most cases. 366 00:39:19,320 --> 00: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. 367 00:39:33,020 --> 00:39:37,320 In rare cases, they are unsecured ones. 368 00:39:37,700 --> 00:39:44,260 But we've reported the vulnerability we found, so it must be already fixed. 369 00:39:48,990 --> 00:39:55,590 We show five solutions against such vulnerability here. 370 00:39:55,950 --> 00:40:04,310 85% of high and medium risk vulnerabilities can be mitigated by these solutions. 371 00:40:04,370 --> 00:40:09,490 So, I sincerely recommend to introduce the solutions. 372 00:40:10,190 --> 00:40:17,570 First of all, store credential and private keys in protected area. 373 00:40:17,570 --> 00:40:26,470 For example, trust zone and TPM, HSM, or something like that. 374 00:40:26,470 --> 00:40:35,730 Second, make sure that the signature verification is done correctly. 375 00:40:36,290 --> 00:40:40,650 I'm not just talking about the verification algorithm. 376 00:40:40,650 --> 00:40:49,930 There are some vulnerabilities that signature verification is bypassed due to verification timing issues. 377 00:40:50,510 --> 00:40:59,130 Third, use appropriate random number generator and cryptosystem. 378 00:40:59,990 --> 00:41:09,810 Fourth, on OS, OSS, and off-the-shelf, pay attention to the following three things. 379 00:41:09,810 --> 00:41:15,210 The first one is use OSS properly. 380 00:41:16,010 --> 00:41:26,910 For example, we often see unproperly settings in TLS connection using OpenSSL, CURL, and so on. 381 00:41:27,250 --> 00:41:35,310 The second one is software version control and managing software composition. 382 00:41:36,310 --> 00:41:41,510 The third one, secure OS and OSS configuration. 383 00:41:42,830 --> 00:41:52,570 There are a wide range of settings, but most of them are firewall permissions and hardening settings for the OS. 384 00:41:54,050 --> 00:41:59,610 Fifth, log the physical debug port on the hardware properly. 385 00:42:00,610 --> 00:42:05,570 Finally, we will say it again. 386 00:42:05,570 --> 00:42:14,890 Just by introducing these solutions, you can mitigate 85% of the high and medium risk. 387 00:42:15,170 --> 00:42:20,190 We strongly recommend that you introduce these solutions. 388 00:42:22,520 --> 00:42:25,900 And we conclude our presentation. 389 00:42:25,900 --> 00:42:28,360 This is our conclusion. 390 00:42:28,360 --> 00:42:32,400 We answer for frequently questions. 391 00:42:32,660 --> 00:42:33,360 That's all. 392 00:42:33,360 --> 00:42:34,140 Thanks.