WEBVTT 00:00.000 --> 00:02.580 My name is Jong Hyuk Song. 00:02.580 --> 00:05.400 I'm the third author of this talk. 00:05.600 --> 00:10.760 Actually, first and second authors are playing CTF now, including me. 00:10.760 --> 00:17.700 So if you want to see first and second authors or me, you can see there. 00:18.340 --> 00:30.080 Anyway, today's talk's title is Automotive USB Forging, How to Forge USB in Vehicles to Discover the Real-World Vulnerabilities. 00:30.820 --> 00:38.140 In this talk, we propose a way to conduct USB forging on a real car. 00:39.340 --> 00:45.220 We tried USB forging to real cars and found some vulnerabilities. 00:45.220 --> 00:48.540 Today, I'm going to show how we did it. 00:49.720 --> 00:53.160 First, I'm going to introduce my team. 00:53.460 --> 01:00.680 Actually, we are all Red Team members and we are all offensive security researchers at Autocrypt. 01:00.680 --> 01:06.640 Autocrypt is a mobility security company, especially focusing on automotive security. 01:07.320 --> 01:15.040 So we have been conducting penetration tests and forging tests with OEMs and tier companies. 01:15.900 --> 01:22.200 We are actually doing security tests to the real cars with car companies. 01:22.380 --> 01:27.320 So , of course, among the tests, we are doing USB forging. 01:27.320 --> 01:33.380 So I'm going to tell you how we are doing USB forging in the field. 01:33.380 --> 01:37.360 And also, I will explain the limitations of the current method. 01:37.740 --> 01:41.760 And I will describe how we have improved it. 01:44.190 --> 01:49.300 So let's talk about the current USB forging in the automotive industry. 01:51.500 --> 01:58.980 There are three characteristics in USB forging to real cars. 01:59.120 --> 02:02.240 First, it's a black box forging. 02:03.520 --> 02:11.180 OEMs usually don't have a source code of the car because tier suppliers don't provide a source code to the OEMs. 02:11.180 --> 02:18.640 So we also don't have a source code, and so we cannot rebuild the source code for forging. 02:19.300 --> 02:26.820 And in most cases, our target is completed vehicles with a production version of ECUs. 02:26.820 --> 02:34.040 It means that there are no debugger ports, so we cannot monitor inside of the car. 02:34.880 --> 02:42.220 Because of these reasons, most security tests to the cars are usually done in the black box. 02:42.620 --> 02:48.600 So we have to find a way to test well even in the black box testing. 02:49.780 --> 02:57.580 Second, there is no commercial USB forger that can be directly connected to the car with a USB cable. 02:57.580 --> 03:06.120 There are some research about USB forging, but they are not useful forgers for car forging. 03:06.120 --> 03:11.980 In particular, there is no USB forger that can be used in a black box environment. 03:12.540 --> 03:16.780 We were able to test USB on the completed car. 03:17.340 --> 03:22.440 To do that, we needed to connect a test PC to the car by USB. 03:22.440 --> 03:29.560 But there is no commercial USB forger which can connect to the car directly. 03:30.760 --> 03:36.420 Because of the first and second reason, there is a third reason, third characteristic. 03:36.680 --> 03:54.780 To test the attack over USB, automotive OEM began to test the media players in the infotainment system by inserting USB stick containing malformed media files. 03:55.680 --> 04:07.260 I don't know how all automakers do USB forging, but as far as I know, many USB forging tests are usually done in this way for the completed car. 04:08.080 --> 04:20.400 So, this slide shows the current USB forging methods, forging procedures that are performed in the field. 04:20.400 --> 04:26.400 First, the pointer is so small, sorry. 04:26.500 --> 04:33.580 First, testers generate the malformed media files by forger in the PC. 04:33.580 --> 04:38.040 Second, testers copy the malformed files to the USB stick. 04:38.520 --> 04:42.300 And third, testers insert the USB stick into the car. 04:43.660 --> 04:51.040 This USB stick actually inserted into the USB port of the head unit issue, infotainment issue. 04:51.860 --> 04:59.760 Fourth, most media players in the car automatically browse the file in the USB stick and play the files. 04:59.760 --> 05:10.220 Fifth, when media player plays the files, the media player could be freezed or issue could be rebooted. 05:10.380 --> 05:17.960 So, testers should keep an eye on the media player while forging to check the failures. 05:19.040 --> 05:26.020 And if all files are played, testers go back to step one and repeat all these steps again. 05:29.120 --> 05:31.980 Most cases, head unit issue. 05:32.160 --> 05:33.350 Head unit. 05:38.020 --> 05:44.330 In this procedure, we usually play hundreds or thousands files at a time. 05:44.940 --> 05:50.760 It depends on the maximum number of files that media player can load at one time. 05:51.480 --> 05:55.720 Of course, the files are abnormal files, malformed files. 05:55.720 --> 06:02.040 The media player does not play most files and just move on to the next file. 06:02.300 --> 06:09.640 So, usually it takes about 10 minutes or 5 minutes to play a few hundred files. 06:10.020 --> 06:15.620 It means that tester has to repeat this process every 10 minutes. 06:15.940 --> 06:20.560 This is quite a burden and annoying task to the testers. 06:21.680 --> 06:24.520 And there is one more important thing. 06:24.520 --> 06:28.240 We are testing the completed car. 06:28.800 --> 06:33.680 It means that testers should do this in the car, sitting on the car seat. 06:33.680 --> 06:37.620 It could be also very uncomfortable to the testers. 06:39.260 --> 06:42.980 Okay, so let me summarize the limitation again. 06:42.980 --> 06:48.400 First, each step requires many manual efforts to testers. 06:49.760 --> 06:53.620 There are many steps in the test procedure. 06:53.620 --> 06:57.580 Testers should generate the files, copy files, and insert sticks. 06:59.180 --> 07:05.780 And every test cycle, testers should repeat that action again and again. 07:05.780 --> 07:08.540 It's very burden to testers. 07:08.820 --> 07:13.720 Second, there is a limited number of files that can be tested at a time. 07:14.920 --> 07:21.800 This is the main reason that testers should repeat these steps several times. 07:22.600 --> 07:27.740 Each media player in the car has the maximum number of files that can be played at one time. 07:28.000 --> 07:38.120 Even if you can put millions of files into a USB stick, the media player only takes the hundreds or thousands of files and plays only them. 07:38.680 --> 07:50.320 So, when all files on the USB sticks are played, the tester must generate new files again, and put them into the USB stick again, and insert it into the car again. 07:50.320 --> 07:58.660 As you know, it's a fuzzing test, so we need to test as many files as possible to find vulnerabilities. 07:59.040 --> 08:05.680 So, testers should repeat those actions several times to test enough files. 08:07.800 --> 08:17.560 And third, to detect failures by fuzzing, testers must keep an eye on the car while it's being fuzzed. 08:18.920 --> 08:22.900 So, in this test, testers use 08:26.840 --> 08:28.740 a media file fuzzer. 08:28.740 --> 08:30.980 It's not connected to the car. 08:30.980 --> 08:34.720 It just generates malformed files in the PC. 08:34.720 --> 08:41.040 So, the fuzzer cannot detect the failures caused by fuzzing. 08:41.040 --> 08:47.540 Therefore, testers should observe the media player while fuzzing is performed. 08:47.540 --> 08:55.020 As you know, as I said before, to find vulnerability, testers should test a large number of files. 08:55.020 --> 09:00.580 It means that he stays and watches the media player for a long time in the car. 09:00.800 --> 09:02.300 It's not that good. 09:03.520 --> 09:07.620 Fourth, it's application fuzzing. 09:07.960 --> 09:10.620 This method cannot do kernel fuzzing. 09:11.260 --> 09:14.420 So, it's obvious because it's media player fuzzing. 09:15.760 --> 09:22.120 But testing only media player is not enough to check all USB attacks. 09:26.150 --> 09:32.650 So, in this talk, we suggest a new automotive USB fuzzing method, which is practically effective. 09:33.090 --> 09:37.610 We try to remove the current limitations that I mentioned just before. 09:38.470 --> 09:43.150 So, what is the requirement of the new fuzzing method? 09:43.150 --> 09:50.290 First, fuzzer should transmit malicious files to the car directly. 09:51.330 --> 09:57.950 Second, fuzzer should monitor the car to detect failures caused by fuzzing. 09:58.250 --> 10:02.290 Third, fuzzer should be able to test the kernel area. 10:03.690 --> 10:13.190 So, therefore, in this talk, I would like to introduce automotive USB fuzzing method that satisfies these three requirements. 10:13.490 --> 10:16.450 Actually, I will explain later. 10:16.450 --> 10:20.550 Second requirement is difficult to completely satisfy. 10:21.170 --> 10:27.770 In some cases, we cannot satisfy the second requirement yet. 10:28.030 --> 10:32.090 Because it's black box fuzzing, we cannot monitor the inside of the car. 10:32.830 --> 10:39.110 But we try to suggest the best ways to detect failures in black box fuzzing. 10:39.610 --> 10:48.810 So, main contribution of the talk is that we did not develop new fancy fuzzing techniques. 10:48.810 --> 10:56.910 There are already great USB research, and we show how to apply them for fuzzing cars. 10:57.710 --> 11:03.050 And finally, we found some vulnerabilities in several cars. 11:03.050 --> 11:05.750 I'm going to show how to do that. 11:06.730 --> 11:11.830 So, how do we solve the challenges? 11:12.350 --> 11:17.670 First, let's connect fuzzer to the car directly by USB cable. 11:18.210 --> 11:23.830 If fuzzing is possible in this way, fuzzing process becomes very simple. 11:23.830 --> 11:31.270 There are only two steps, connect fuzzer and car, and just start fuzzing. 11:31.530 --> 11:41.170 If it's possible, fuzzer can automatically transmit malformed files to the car, and fuzzer can monitor the car to detect failures. 11:41.690 --> 11:49.110 It means that testers don't have to move the files and don't have to monitor the car during fuzzing. 11:51.570 --> 11:56.490 So, let's talk about the advantages first. 11:57.070 --> 12:02.850 First, it reduces the workload of testers by removing the test steps. 12:03.470 --> 12:15.510 Because in the previous method, it requires five steps, and more of the steps should be repeated several times to test enough number of files. 12:15.510 --> 12:25.370 But if fuzzer can transmit the files to the car by itself, fuzzing process becomes very simple. 12:25.790 --> 12:35.730 Second, in this test, fuzzer can detect your failures, so testers don't need to monitor all the time. 12:37.390 --> 12:44.310 And third, fuzzer can automatically generate malformed files and send them to the car. 12:44.310 --> 12:47.550 I don't know why it moved to the next page. 12:50.210 --> 12:51.570 Sorry. 12:59.390 --> 13:06.850 Fuzzer automatically generates malformed files and sends them to the vehicle, so fuzzing can continue without human interaction. 13:07.730 --> 13:09.950 And now we can do corner fuzzing. 13:11.930 --> 13:15.650 So how can we do these things? 13:15.650 --> 13:20.110 Because of these two things, we can do that. 13:20.630 --> 13:23.550 First is Linux USB Gadget. 13:25.370 --> 13:32.000 We need to make the car recognize our device as USB storage. 13:32.510 --> 13:35.790 To do that, we need to use Linux USB Gadget. 13:35.970 --> 13:42.000 Linux USB Gadget makes Linux system appear to be a USB device to a host. 13:42.000 --> 13:46.840 So it's a kind of way to emulate a storage device. 13:46.980 --> 13:53.160 As I know, it's only available in Linux, so we need to prepare Linux device. 13:53.600 --> 13:57.460 So in our test, we use Raspberry Pi. 13:58.400 --> 14:03.040 So it means that we emulate the USB storage using the Raspberry Pi. 14:03.800 --> 14:12.360 So car recognizes a specific folder in the Raspberry Pi as USB storage. 14:13.180 --> 14:20.280 So if we put some files in that folder, the media player will get the files and play them. 14:21.280 --> 14:24.640 Second thing is the USB RAW Gadget. 14:24.640 --> 14:28.200 We also use USB RAW Gadget for corner fuzzing. 14:28.460 --> 14:33.020 It's a Linux corner module that implements a low-level interface. 14:33.040 --> 14:38.260 For the Linux USB Gadget subsystem. 14:38.840 --> 14:47.480 Using the USB RAW Gadget, we can transmit arbitrary USB requests to the USB host. 14:49.360 --> 14:54.120 SysCaller already supports the USB fuzzing using this RAW Gadget. 14:54.200 --> 15:01.940 So we can just use the SysCaller to fuzz USB corner stacks in the car. 15:01.940 --> 15:08.840 So we use these two things to conduct USB fuzzing to the real cars. 15:16.420 --> 15:18.340 So let's summarize. 15:18.340 --> 15:23.970 To USB Gadget mode and RAW Gadget, we need a Linux device. 15:24.680 --> 15:28.420 In this research, we use the Raspberry Pi 4. 15:28.420 --> 15:33.640 And then connect the Raspberry Pi to the car by a USB cable. 15:34.480 --> 15:40.840 To transmit data, you should use a USB cable that supports data transmission. 15:40.840 --> 15:44.020 Some USB cables, you know, only support charging. 15:44.220 --> 15:47.840 That kind of USB cable cannot be used in this fuzzing. 15:48.540 --> 15:53.060 And we set up Raspberry Pi for USB fuzzing. 15:53.660 --> 16:00.080 To do media player fuzzing, we emulate Raspberry Pi as a USB storage using USB Gadget. 16:00.080 --> 16:03.180 And to do corner fuzzing, we use RAW Gadget. 16:05.700 --> 16:10.860 First, I'm going to tell you about how to do media player fuzzing. 16:11.020 --> 16:13.860 This figure shows the overview. 16:14.540 --> 16:20.100 All these processes are automatically done by fuzzer without human interaction. 16:20.220 --> 16:22.140 Except the start command. 16:22.920 --> 16:27.440 First, we need to set up Raspberry Pi as a USB Gadget. 16:27.900 --> 16:32.080 And second, the fuzzer generates malformed media files into the fuzzer. 16:32.080 --> 16:36.240 And third, the fuzzer mounts the folder as a USB storage. 16:36.740 --> 16:44.260 And fourth, if the folder is mounted, the media player automatically recognizes it. 16:45.360 --> 16:50.300 Then media player gets all files in the folder and plays them. 16:50.620 --> 17:02.580 During the files are playing, fuzzer monitors Raspberry Pi's corner log, which is de-message raw for detecting failures caused by fuzzing. 17:03.560 --> 17:14.440 After all files are played, fuzzer mounts the folder and removes all files in the folder and go back to the step two and repeat the step. 17:15.500 --> 17:20.480 This is how to do USB fuzzing by directly connecting the fuzzer and the car. 17:22.020 --> 17:27.160 We can do this without the USB stick and without human interaction. 17:28.580 --> 17:32.860 So the whole process can be done without human interaction. 17:35.750 --> 17:41.170 So this is the initial setup for USB Gadget mode. 17:41.170 --> 17:45.130 We do this first step in the previous slide. 17:46.510 --> 17:50.540 Because of time limit, I can't explain details in each line. 17:50.540 --> 17:54.380 But if you want more, you can find the details on the internet. 17:54.380 --> 18:02.560 There are already many good articles, papers, explaining how to make a Raspberry Pi USB storage. 18:06.300 --> 18:10.900 And let's talk about how to generate malformed media files. 18:12.680 --> 18:20.080 To generate the media files, we collect normal media files to use them as seed files. 18:20.890 --> 18:25.580 Then we manipulate the seed files using bit flipping techniques. 18:25.900 --> 18:34.380 We just randomly choose 1% of bits of the seed files and flip the selected bits. 18:34.400 --> 18:34.960 That's all. 18:34.960 --> 18:37.120 It's very simple. 18:39.560 --> 18:43.320 Actually, you know, there are already several file fuzzers. 18:43.320 --> 18:53.680 But in our test, in our experience, they are not very useful to the media player fuzzing in the car. 18:54.900 --> 18:56.780 We cannot figure out why. 18:56.780 --> 18:59.000 We cannot figure out the exact reason. 18:59.000 --> 19:07.440 But we just guessed that most existing file fuzzers mutate the file signature part. 19:07.440 --> 19:16.300 It means that if file signature is mutated, the media player does not play the file. 19:17.720 --> 19:23.380 Most media players do not play the files which have incorrect file signature. 19:23.620 --> 19:31.520 So when we generate the malformed files, we do not mutate the file signature part. 19:32.880 --> 19:36.320 That is our first tip in the car fuzzing. 19:37.440 --> 19:39.660 For the automotive media players. 19:39.920 --> 19:47.920 Next tip is, if the file content is mutated too much, some media players don't play the media file also. 19:47.920 --> 19:52.300 Even if the media file has correct file signature. 19:53.220 --> 19:57.660 So this is why we just mutate only 1% of the file. 19:58.300 --> 20:05.220 I cannot say that 1% is the magic value for all cars, all cases. 20:05.220 --> 20:12.780 But maybe each car has different media players. 20:12.780 --> 20:15.700 So you should find your values. 20:17.780 --> 20:19.560 And there is one more. 20:21.860 --> 20:26.400 Each automotive media player supports different media file types. 20:26.400 --> 20:36.900 So before you generate the malformed media files, you should check the supported file types and generate only those files. 20:37.560 --> 20:42.940 Because the media players will only play the files that they support. 20:42.940 --> 20:48.880 So you don't need to generate the files that are not supported by the media player. 20:49.780 --> 20:53.860 Usually media players support many file types. 20:54.300 --> 20:57.340 It's just some example of them. 21:00.490 --> 21:03.210 Now let's talk about how to detect failures. 21:04.210 --> 21:12.890 To detect failures caused by fuzzing, as you can see, our fuzzer monitors the corner log, which is de-message. 21:14.310 --> 21:22.350 But I think you probably noticed that it is not perfect to detect failures. 21:22.350 --> 21:31.150 Because the Raspberry Pi de-message log cannot show the exact state of the target media player or exact state of the car. 21:31.150 --> 21:34.650 It's just the Raspberry Pi's corner log. 21:34.970 --> 21:37.530 But you know, this is black box fuzzing. 21:37.610 --> 21:42.250 The only thing we can use is Raspberry Pi de-message log. 21:42.250 --> 21:45.830 That is currently our best option. 21:45.890 --> 21:52.410 So we have to identify the target state by only using this log. 21:53.910 --> 22:00.370 So let me explain in more detail about how our fuzzer detects failures by the de-message log. 22:00.370 --> 22:02.830 There are two cases. 22:03.590 --> 22:11.170 First, we found out that some issues are rebooted if the media player is crashed. 22:11.270 --> 22:20.550 In that case, USB connection between Raspberry Pi and issue is of course disconnected because issue is rebooted. 22:21.370 --> 22:27.730 After issue is rebooted, Raspberry Pi and issue are connected by USB again. 22:27.730 --> 22:32.050 At that time, USB connection log is created at de-message. 22:32.050 --> 22:34.010 So fuzzer can detect failure. 22:34.010 --> 22:37.990 Fuzzer can know there is something wrong using the de-message log. 22:39.530 --> 22:41.230 And there is a second case. 22:41.230 --> 22:45.470 Some issue is just shut down and not rebooted again. 22:47.230 --> 22:55.150 In this case, there is no USB reconnection log in the de-message because issue is not rebooted. 22:55.150 --> 22:57.990 So fuzzer cannot know the failures. 22:58.030 --> 23:04.570 So the fuzzer just tries to mount the next folder that contains new files. 23:04.910 --> 23:11.250 But the mount will be failed because issue is shut down. 23:11.290 --> 23:14.470 So at that time, fuzzer can detect failures. 23:16.290 --> 23:21.830 Of course, it's not real-time detection, but it's the best option we can do now. 23:24.110 --> 23:27.210 Let's look at these figures. 23:28.310 --> 23:33.730 Left figure shows the fuzzer's log and right figure shows the de-message log. 23:34.110 --> 23:39.850 At this time, we conducted fuzzing using 100 files at each trial. 23:40.070 --> 23:48.670 As I mentioned before, our fuzzer repeats mount and unmount folder several times. 23:48.670 --> 23:54.110 So there will be USB reconnection log as many as the number of mounts. 23:54.510 --> 24:03.550 In this figure, we mount a test folder three times, but there are four USB connection logs in de-message. 24:04.670 --> 24:08.770 And the last log is a little bit different from other logs. 24:08.770 --> 24:14.810 So fuzzer can notice that there is something wrong in the media player or issue. 24:14.810 --> 24:20.750 So in this way, the fuzzer can detect failures. 24:23.510 --> 24:26.630 Actually, of course, there is a limitation of our method. 24:27.790 --> 24:30.610 We are doing black-box fuzzing. 24:30.990 --> 24:38.470 Fuzzer in Raspberry Pi cannot know exactly which file is currently playing in the media player. 24:38.470 --> 24:44.410 Fuzzer generates hundreds or thousands files in the folder and mounts the folder. 24:44.450 --> 24:47.670 Then media player gets all files and plays them. 24:48.290 --> 24:53.790 So when a crash is detected, fuzzer cannot know which file caused the crash. 24:54.730 --> 25:03.710 Fuzzer should find the file causing the crash by replaying the files again one by one. 25:04.600 --> 25:08.470 To solve this limitation, we tried two things. 25:08.790 --> 25:16.000 First, we can just put only one file in the folder and mount the folder and play just only one file. 25:16.850 --> 25:27.410 If we do fuzzing like this, when a crash occurs, we can exactly know which file is causing the crash because there is only one file. 25:28.010 --> 25:33.650 But in this case, mount and unmount is required for the number of files. 25:34.670 --> 25:41.950 Mount and unmount is a very slow operation, but we have to test a large number of files. 25:41.950 --> 25:45.610 So we need to reduce the number of mount and unmount. 25:46.310 --> 25:51.790 So in our experience, playing only one file at once is not a good idea. 25:52.590 --> 25:57.890 So we need to find the appropriate number of files each one cycle. 25:57.890 --> 26:05.990 This is why we generated and played only 100 files at each trial in the previous slide. 26:06.250 --> 26:10.790 We can play more files, but we don't. 26:11.030 --> 26:20.140 Because if there are too many files played at once, it's difficult to find the file that caused the crash. 26:21.030 --> 26:26.850 I cannot say 100 is the ideal number for all fuzzing. 26:26.850 --> 26:29.950 It's very different for each cases. 26:29.950 --> 26:33.970 So you should find the basic number of files for your own test. 26:36.580 --> 26:38.740 And actually, there is one more limitation. 26:38.740 --> 26:44.600 In some cases, some issue is not rebooted and shut down, even if the media player is crashed. 26:44.840 --> 26:52.400 In this case, USB is not disconnected, even if the media player is crashed and stopped. 26:52.800 --> 26:56.440 So fuzzer cannot detect failures. 26:56.440 --> 26:59.540 Test habit monitor car again. 27:00.000 --> 27:05.300 It's one of our limitations and it's one of our future work to solve this one. 27:06.260 --> 27:10.140 We found these cases in GM Volvo cars. 27:10.180 --> 27:15.240 What they have in common is that they use Android Automotive OS. 27:15.240 --> 27:22.060 So we just guessed Android Automotive OS is not good case for our fuzzing. 27:24.960 --> 27:29.680 So until now, I talked about how to fuzz automotive media player by USB. 27:29.960 --> 27:36.100 But to test attacks over USB port, media player fuzzing is not enough. 27:36.740 --> 27:39.700 Let's test automotive kernel by USB. 27:40.880 --> 27:46.220 You know, there is already great research project about fuzzing USB kernel stack. 27:47.000 --> 27:52.840 In this project, this also implements raw gadget for USB kernel fuzzing. 27:52.840 --> 27:57.640 And he also implements USB fuzzer using the raw gadget. 27:57.640 --> 28:02.520 And this fuzzer integrated into Shizkalo. 28:02.780 --> 28:07.020 You know, Shizkalo is the best fuzzer for kernel fuzzing. 28:07.020 --> 28:12.080 So we just use Shizkalo to fuzz USB kernel stack in the car. 28:14.060 --> 28:15.660 But let's think about it. 28:15.660 --> 28:22.480 Shizkalo is the coverage guided fuzzer and it requires kernel build for fuzzing. 28:22.840 --> 28:25.460 But we are doing black box fuzzing now. 28:25.460 --> 28:29.680 We don't have source code of the car. 28:30.120 --> 28:34.200 So it's difficult to use Shizkalo as it is. 28:34.400 --> 28:38.840 So how can you generate the fuzzing inputs for USB kernel stack in the car? 28:42.820 --> 28:45.960 But we can do fuzzing using Shizkalo. 28:45.960 --> 28:55.660 Actually, Shizkalo for USB already found about 300 or more bugs in kernel USB stack. 28:55.820 --> 29:00.300 That bugs are reported to the Shizkalo appspot.com. 29:00.480 --> 29:06.280 In that reports, there are codes to reproduce the bug. 29:06.280 --> 29:10.680 So we can use the reproduction codes for our fuzzing input. 29:13.050 --> 29:20.360 We just collect the reproduction codes and just execute the code by using Shizkalo programs. 29:20.880 --> 29:25.470 Shizkalo provides a way to reproduce the bug with a specific input. 29:25.880 --> 29:35.080 So you can reproduce the bug founded by Shizkalo using those two programs. 29:35.660 --> 29:40.410 I think many of you guys in here already know how to use Shizkalo. 29:41.320 --> 29:51.090 Anyway, this is the example code, example command to reproduce the bug founded by Shizkalo. 29:51.910 --> 29:58.670 In this case, the name of the reproduction code is crash01.log. 29:59.710 --> 30:07.720 And the figure in the bottom shows one of the reproduction codes in the Shizkalo appspot.com. 30:10.470 --> 30:17.890 This figure shows that the bug list reported in the Shizkalo appspot.com. 30:18.170 --> 30:24.730 Actually, there is a lot of bugs on this site except the USB bugs. 30:24.730 --> 30:28.270 So you should filter only the USB bugs. 30:28.950 --> 30:34.750 The link in the bottom will show the only USB bugs. 30:35.770 --> 30:37.510 And there is one more thing. 30:37.510 --> 30:42.210 Actually, all reported bugs don't contain the reproduction code. 30:42.210 --> 30:51.010 So you can only find the reproduction code in the articles if Shiz or Shiz is written in repro field. 30:51.010 --> 30:54.630 So you don't need to collect all the bugs. 30:56.330 --> 31:00.790 So this is the overview of the fuzzing USB kernel stack in the car. 31:00.790 --> 31:02.490 It's very simple. 31:02.490 --> 31:06.950 First, just collect the reproduction code from the Shizkalo appspot.com. 31:06.950 --> 31:09.950 And then just reply the codes. 31:09.970 --> 31:14.130 Of course, we can also mutate the reproduction code. 31:14.170 --> 31:17.510 Mutate the data part of the reproduction code. 31:17.810 --> 31:22.910 But actually, we can find the vulnerability using just the original code. 31:23.270 --> 31:31.590 So in kernel fuzzing, we also monitor the message log to detect failures caused by fuzzing. 31:32.710 --> 31:38.050 All cars we tested were rebooted if kernel crashed. 31:38.110 --> 31:43.690 So fuzzer can detect all failures by using this method. 31:45.270 --> 31:48.980 So now let's talk about testing with real cars. 31:49.730 --> 31:53.990 Actually, this is the most challenging part in the car hacking. 31:54.430 --> 31:58.030 Because we don't have enough test cars. 31:58.030 --> 32:05.330 So even if we have a very good idea, it's very difficult to prove using the real cars. 32:06.110 --> 32:13.410 Luckily, our fuzzing test can be performed without disassembling the car. 32:13.410 --> 32:16.710 And it does not cause serious damage to the car. 32:16.790 --> 32:20.170 So we can test using the rental car. 32:20.290 --> 32:25.570 So we rented cars for a day or just a few hours and tested them. 32:26.310 --> 32:31.030 There were not many different types of cars that we could rent. 32:31.030 --> 32:34.770 But we rented as many as possible and tested them. 32:37.210 --> 32:41.430 These are the summary of the vulnerabilities we found. 32:41.450 --> 32:46.910 We found vulnerabilities from Renaults and Chevrolet and Volkswagen. 32:47.470 --> 32:50.930 And we also found a vulnerability in AGL. 32:51.090 --> 32:54.530 Actually, AGL is tested on the Raspberry Pi. 32:57.390 --> 33:01.230 And actually number 7 vulnerability is not reported. 33:01.230 --> 33:06.070 Because we found number 6 and 7 vulnerability in the same version. 33:06.090 --> 33:09.610 And we just only reported number 6 first. 33:09.930 --> 33:13.330 And Volkswagen patched the vulnerability very quickly. 33:13.570 --> 33:15.970 Before we reported number 7. 33:16.170 --> 33:19.850 And number 7 vulnerability is not working on the patched version. 33:19.850 --> 33:21.770 So we cannot report that. 33:21.790 --> 33:24.890 We should report number 6 and 7 at the same time. 33:25.570 --> 33:26.130 But we made a mistake. 33:26.230 --> 33:28.770 Because we were quite busy at that time. 33:28.770 --> 33:31.550 We just forgot to report number 7. 33:32.070 --> 33:35.690 Anyway, I'm going to show our demo video. 33:54.580 --> 33:58.400 So media player lost the play again. 33:58.960 --> 34:01.940 There is a Raspberry Pi here. 34:02.340 --> 34:04.480 PC just controlled Raspberry Pi. 34:05.980 --> 34:08.400 And it just shut down. 34:08.400 --> 34:11.400 This is the media player fuzzing case. 34:11.400 --> 34:15.580 And this issue is shut down and not rebooted again. 34:15.580 --> 34:20.340 So tester tried to turn off the car and turn on the car again. 34:23.270 --> 34:28.770 Interestingly, car is back working on normally. 34:28.770 --> 34:33.110 But the head unit issue is still not working on. 34:33.390 --> 34:38.750 So we have to hard reset the head unit issue. 34:53.020 --> 34:55.600 Yes, this is the first demo. 34:56.460 --> 35:03.660 So we can crash the head unit issue by the media player crash. 35:13.520 --> 35:17.280 In this test, we tested while driving. 35:17.720 --> 35:20.580 You can see the head unit issue is rebooted. 35:20.580 --> 35:24.920 This is the rebooted case and it's also media player fuzzing. 35:24.920 --> 35:27.440 There is a Raspberry Pi over there. 35:28.300 --> 35:34.600 So you can see that issue is rebooted by crash even if the car is moving. 35:44.750 --> 35:48.450 Third video shows the corner fuzzing demo. 35:49.290 --> 35:51.450 It's also moving. 35:57.320 --> 36:07.700 There is a Raspberry Pi and issue is rebooted even if the car is moving. 36:12.910 --> 36:15.670 The last demo is also corner fuzzing. 36:33.620 --> 36:36.740 Okay, these are our demo video. 36:37.120 --> 36:39.180 So let's conclude my talk. 36:41.180 --> 36:48.300 The current USB fuzzing used in the automotive industry has many limitations. 36:48.300 --> 36:50.060 It's complicated. 36:50.060 --> 36:53.600 It requires huge workload to testers. 36:54.360 --> 37:02.840 These limitations can be addressed by directly connecting fuzzer and car via USB cable. 37:03.360 --> 37:08.400 And USB gadget and low gadget makes it possible. 37:08.400 --> 37:15.060 So we can significantly reduce the workload of the testers. 37:15.180 --> 37:19.220 And also we can test the USB corner stack. 37:20.320 --> 37:24.040 And also we can find the real world vulnerabilities. 37:24.900 --> 37:27.640 Okay, it's end of my talk. 37:27.640 --> 37:28.580 Thank you.