camp2023-57024-eng-Horror_Stories_from_the_Automotive_Industry_opus.srt

1
00:00:00,000 --> 00:00:10,000
 [MUSIC]

2
00:00:10,000 --> 00:00:20,000
 [MUSIC]

3
00:00:20,000 --> 00:00:33,200
 And we will have a five minute Q&A in the end of the talk.

4
00:00:33,200 --> 00:00:39,760
 And the talk is about nightmares in the automotive security.

5
00:00:39,760 --> 00:00:46,720
 And we have Thomas Sampini here, who is a pen tester with automotive.

6
00:00:46,720 --> 00:00:50,160
 And he will talk about the nightmares.

7
00:00:50,160 --> 00:00:52,420
 Welcome.

8
00:00:52,420 --> 00:01:00,100
 >> [APPLAUSE]

9
00:01:00,100 --> 00:01:01,360
 >> Thank you.

10
00:01:01,360 --> 00:01:04,920
 So hello everyone, I hope you're not drunk or sleepy.

11
00:01:04,920 --> 00:01:08,080
 I'm sleepy, but we will go through it.

12
00:01:08,080 --> 00:01:11,480
 So today we will talk about horror stories in the automotive industry.

13
00:01:11,480 --> 00:01:15,320
 I'm Thomas Sampinis, otherwise you might know me as Crow Tom.

14
00:01:15,320 --> 00:01:17,600
 This is the CCC edition.

15
00:01:17,600 --> 00:01:20,880
 It's been already once presented.

16
00:01:20,880 --> 00:01:25,600
 I'm Thomas Sampinis, as I said, I'm automotive pen tester lead by day.

17
00:01:25,600 --> 00:01:29,320
 In auxiliary cybersecurity and thanks a lot to this team for

18
00:01:29,320 --> 00:01:31,520
 the support and the help for this research.

19
00:01:31,520 --> 00:01:34,160
 And the security researcher by night.

20
00:01:34,160 --> 00:01:36,080
 I like to hack everything everywhere.

21
00:01:36,080 --> 00:01:37,000
 I don't really care.

22
00:01:37,000 --> 00:01:40,640
 I just like to hack everything that gets into my hands and

23
00:01:40,640 --> 00:01:42,560
 I really love security conferences.

24
00:01:42,560 --> 00:01:44,200
 For more, you can go to my website.

25
00:01:44,200 --> 00:01:48,200
 There are some specific goals for this talk.

26
00:01:48,200 --> 00:01:51,600
 First of all, I want to analyze the state of cybersecurity in

27
00:01:51,600 --> 00:01:53,160
 the automotive industry.

28
00:01:53,160 --> 00:01:56,000
 I want to present some unique and hopefully interesting for

29
00:01:56,000 --> 00:01:59,040
 you use cases, result of around 100 pen tests and

30
00:01:59,040 --> 00:02:02,000
 research projects in this industry.

31
00:02:02,000 --> 00:02:05,680
 Endorse and push more hackers to the automotive industry and

32
00:02:05,680 --> 00:02:11,000
 educate the new, the old and the bold of this industry.

33
00:02:11,000 --> 00:02:12,280
 And of course raise and

34
00:02:12,280 --> 00:02:15,920
 highlight the significance of security related devices.

35
00:02:15,920 --> 00:02:21,320
 Let's start with an overview of the state of cybersecurity in

36
00:02:21,320 --> 00:02:24,520
 the automotive industry and discuss where we currently are,

37
00:02:24,520 --> 00:02:27,280
 what is planned and where we're currently heading.

38
00:02:27,280 --> 00:02:31,200
 And there are several incidents throughout the years, but

39
00:02:31,200 --> 00:02:35,200
 I still get fascinated by the quality of the findings that

40
00:02:35,200 --> 00:02:40,720
 get discovered on the automotive industry into 2023 still.

41
00:02:40,720 --> 00:02:44,720
 Some examples from the last years are some fixed code

42
00:02:44,720 --> 00:02:47,800
 vulnerabilities in Nissan, for example, which is one of many

43
00:02:47,800 --> 00:02:50,480
 examples of this vulnerability in the wild.

44
00:02:50,480 --> 00:02:53,760
 Stealing keys with just USB cables, I mean, okay.

45
00:02:53,760 --> 00:02:56,960
 Key for vulnerabilities again and again.

46
00:02:56,960 --> 00:03:01,320
 Remote unlocks of whole vehicle fleets due to flaws in

47
00:03:01,320 --> 00:03:06,200
 series XM, unlocking and stealing vehicles due to easily

48
00:03:06,200 --> 00:03:09,840
 accessible campuses and really bad internal architecture,

49
00:03:09,840 --> 00:03:12,560
 something that we will also talk in this, speak about in

50
00:03:12,560 --> 00:03:14,000
 this talk.

51
00:03:14,000 --> 00:03:17,960
 And that's only a sample out of a huge list of similar

52
00:03:17,960 --> 00:03:19,040
 incidents in this sector.

53
00:03:19,040 --> 00:03:23,280
 I don't know if there is a light in the end of the tunnel, but

54
00:03:23,280 --> 00:03:26,760
 the automotive industry cannot be considered new.

55
00:03:26,760 --> 00:03:30,440
 The connectivity and technological aspect of it,

56
00:03:30,440 --> 00:03:32,920
 though, is not so old.

57
00:03:32,920 --> 00:03:37,560
 Entertainment and constant need for connectivity are the main

58
00:03:37,560 --> 00:03:40,840
 reasons for the technological advancements and integration

59
00:03:40,840 --> 00:03:42,640
 in this industry.

60
00:03:42,640 --> 00:03:47,480
 And usually we're talking about 100 plus year old industries

61
00:03:47,480 --> 00:03:50,400
 trying to catch up with some young startups.

62
00:03:50,400 --> 00:03:53,400
 And this is an example for you to understand what is the

63
00:03:53,400 --> 00:03:55,000
 current state of cybersecurity.

64
00:03:55,000 --> 00:03:57,160
 This is the BMW i7.

65
00:03:57,160 --> 00:03:59,880
 And outside of the common things that you usually see in

66
00:03:59,880 --> 00:04:02,400
 a vehicle, you see my whole living room.

67
00:04:02,400 --> 00:04:05,240
 Basically, all these things are interconnected.

68
00:04:05,240 --> 00:04:08,120
 All these services are connected to the internet and

69
00:04:08,120 --> 00:04:12,080
 exposed to some interfaces that are approachable by

70
00:04:12,080 --> 00:04:15,240
 attackers eventually.

71
00:04:15,240 --> 00:04:19,160
 In order to fight this, there are some regulations that get

72
00:04:19,160 --> 00:04:19,840
 introduced.

73
00:04:19,840 --> 00:04:20,960
 I don't want to bore you.

74
00:04:20,960 --> 00:04:21,680
 It's really late.

75
00:04:21,680 --> 00:04:23,640
 I don't want you to sleep.

76
00:04:23,640 --> 00:04:26,560
 Basically, to go through it really fast, it provides a set

77
00:04:26,560 --> 00:04:29,760
 of standards that must be met in order to ensure the

78
00:04:29,760 --> 00:04:32,280
 safety of road vehicles.

79
00:04:32,280 --> 00:04:34,960
 It requires operation of certified cybersecurity

80
00:04:34,960 --> 00:04:36,640
 management systems.

81
00:04:36,640 --> 00:04:41,320
 And in any case, in summary, it tries to shape the completely

82
00:04:41,320 --> 00:04:45,000
 unregulated mess that exists until now.

83
00:04:45,000 --> 00:04:49,160
 And the big caveat is that penetration testing is solely

84
00:04:49,160 --> 00:04:52,320
 based on the risk assessment of the target vehicle or the

85
00:04:52,320 --> 00:04:55,120
 target ECU.

86
00:04:55,120 --> 00:04:58,440
 Going into the first part, I want to have a discussion

87
00:04:58,440 --> 00:05:01,360
 about the tier one suppliers, which of course play a huge

88
00:05:01,360 --> 00:05:04,960
 role in the automotive industry, with cars being

89
00:05:04,960 --> 00:05:09,280
 literally like LEGOs, pieces of LEGOs that you construct from

90
00:05:09,280 --> 00:05:11,880
 different tier one suppliers in order to build the whole

91
00:05:11,880 --> 00:05:13,840
 vehicle.

92
00:05:13,840 --> 00:05:17,160
 To start talking about it, we need to talk about

93
00:05:17,160 --> 00:05:20,120
 cybersecurity requirements, which are developed and

94
00:05:20,120 --> 00:05:21,720
 distributed by OEMs.

95
00:05:21,720 --> 00:05:25,800
 And it's usually the engineering requirements for

96
00:05:25,800 --> 00:05:27,920
 cybersecurity risk management.

97
00:05:27,920 --> 00:05:32,240
 And the tier one suppliers should ideally comply to those

98
00:05:32,240 --> 00:05:34,640
 for correct and secure functionality of the supplied

99
00:05:34,640 --> 00:05:37,160
 components.

100
00:05:37,160 --> 00:05:39,240
 If those requirements are followed, though, it's a

101
00:05:39,240 --> 00:05:40,200
 different discussion.

102
00:05:40,200 --> 00:05:43,680
 So let's go through some real life examples that lead to

103
00:05:43,680 --> 00:05:46,960
 complete compromise of a vehicle in the most dumb way

104
00:05:46,960 --> 00:05:48,240
 possible.

105
00:05:48,240 --> 00:05:52,200
 And the reason for this, from my perspective, is that

106
00:05:52,200 --> 00:05:55,440
 several tier ones are based in countries with low

107
00:05:55,440 --> 00:05:57,760
 transparency and weak governance.

108
00:05:57,760 --> 00:06:00,120
 If you know what I mean.

109
00:06:00,120 --> 00:06:05,360
 And secondly, we don't know how clear are these cybersecurity

110
00:06:05,360 --> 00:06:08,720
 requirements in order to be followed by these tier one

111
00:06:08,720 --> 00:06:10,000
 suppliers.

112
00:06:10,000 --> 00:06:16,240
 And then if not only the OEM, but also the appendices

113
00:06:16,240 --> 00:06:20,040
 suppliers usually have a reactive approach to security

114
00:06:20,040 --> 00:06:23,600
 testing, which assumes that everything described on those

115
00:06:23,600 --> 00:06:27,040
 requirements is followed, which leads to shaping weak

116
00:06:27,040 --> 00:06:30,520
 penetration testing methodology and test cases

117
00:06:30,520 --> 00:06:33,400
 with high probability of losing important parts of

118
00:06:33,400 --> 00:06:36,480
 the attack surface.

119
00:06:36,480 --> 00:06:40,080
 To start with our first use case and the path to Game

120
00:06:40,080 --> 00:06:43,960
 Over, we need to understand a bit what is UDS.

121
00:06:43,960 --> 00:06:48,080
 Basically, it's one of the application layer protocols

122
00:06:48,080 --> 00:06:51,880
 that run on these electronic control units, the computers

123
00:06:51,880 --> 00:06:56,400
 inside the vehicle, for communication between them in

124
00:06:56,400 --> 00:06:58,720
 automotive electronics.

125
00:06:58,720 --> 00:07:02,560
 It allows diagnostic functionality, such as reading

126
00:07:02,560 --> 00:07:05,840
 and erasing fault codes, programming and reprogramming

127
00:07:05,840 --> 00:07:09,000
 ECUs, testing and monitoring of them.

128
00:07:09,000 --> 00:07:12,360
 It consists of several services, which can be used to

129
00:07:12,360 --> 00:07:14,160
 perform specific actions.

130
00:07:14,160 --> 00:07:18,520
 And the really common authentication schema in UDS is

131
00:07:18,520 --> 00:07:23,280
 the Security Access Service, or 0x27, which allows elevated

132
00:07:23,280 --> 00:07:27,880
 access to authenticated users.

133
00:07:27,880 --> 00:07:30,880
 And talking about this service, we need to understand

134
00:07:30,880 --> 00:07:36,720
 how it works in order to go on how we eventually bypass it.

135
00:07:36,720 --> 00:07:42,640
 And basically, there is a client, which is us as a

136
00:07:42,640 --> 00:07:47,040
 tester or some reprogramming tool, and the ECU.

137
00:07:47,040 --> 00:07:49,920
 The client that wants to be authenticated into the ECU

138
00:07:49,920 --> 00:07:53,160
 sends a seed request to the ECU.

139
00:07:53,160 --> 00:07:56,840
 The ECU generates a random seed and calculates the key by

140
00:07:56,840 --> 00:08:03,800
 using an algorithm for this calculation and the secret key.

141
00:08:03,800 --> 00:08:07,240
 It sends the random seed to the client, and the client,

142
00:08:07,240 --> 00:08:10,720
 using the same algorithm, the same secret key, has to

143
00:08:10,720 --> 00:08:15,320
 calculate the calculated key where the ECU verifies it and

144
00:08:15,320 --> 00:08:18,320
 grants access to the client if they are matching from both

145
00:08:18,320 --> 00:08:21,560
 calculations on each side.

146
00:08:21,560 --> 00:08:25,360
 Regarding this service and considering the trend of

147
00:08:25,360 --> 00:08:27,560
 loosely developed requirements, we have observed

148
00:08:27,560 --> 00:08:32,040
 several types of outcomes, including sloppy authentication

149
00:08:32,040 --> 00:08:36,000
 implementations, weak sources of randomness, something that

150
00:08:36,000 --> 00:08:40,320
 I talked last year in Troopers conference, and my talk UDS

151
00:08:40,320 --> 00:08:43,160
 fuzzing in the path to Game Over, and backdoors

152
00:08:43,160 --> 00:08:46,520
 implemented outside of the scope of the cyber security

153
00:08:46,520 --> 00:08:48,080
 requirements.

154
00:08:48,080 --> 00:08:52,560
 As an example, we have an extra security access sub-service

155
00:08:52,560 --> 00:08:57,720
 which is with extremely weak security for some reason.

156
00:08:57,720 --> 00:08:59,520
 And actually, that's the case here.

157
00:08:59,520 --> 00:09:02,200
 Here we have a real life example on the

158
00:09:02,200 --> 00:09:03,480
 screenshot on the right.

159
00:09:03,480 --> 00:09:06,560
 And the same process as we saw previously.

160
00:09:06,560 --> 00:09:10,200
 So we send a seed request to the ECU.

161
00:09:10,200 --> 00:09:10,880
 We are the client.

162
00:09:10,880 --> 00:09:13,880
 We send the seed request to the ECU.

163
00:09:13,880 --> 00:09:19,600
 We receive a random seed despite being four bytes.

164
00:09:19,600 --> 00:09:22,320
 It's debatable on if we can crack it and how long.

165
00:09:22,320 --> 00:09:24,560
 If there is a proper implementation, there should

166
00:09:24,560 --> 00:09:28,520
 be a new randomly generated seed every time.

167
00:09:28,520 --> 00:09:31,400
 In this case, this seed is always the same.

168
00:09:31,400 --> 00:09:34,040
 Every time we request it, we have the same seed.

169
00:09:34,040 --> 00:09:39,480
 And by testing the first key that we send, which is only

170
00:09:39,480 --> 00:09:42,200
 zeros, we manage to get a positive response.

171
00:09:42,200 --> 00:09:45,800
 The positive response here is the 6773.

172
00:09:45,800 --> 00:09:47,840
 And the ECU grants access to us.

173
00:09:47,840 --> 00:09:52,360
 And this eventually is a backdoor from our perspective.

174
00:09:52,360 --> 00:09:55,520
 Of course, there is no security in this case.

175
00:09:55,520 --> 00:10:00,720
 And while the tier one supplier, supply components

176
00:10:00,720 --> 00:10:04,160
 might follow the OEM cyber security requirement, that

177
00:10:04,160 --> 00:10:07,280
 doesn't mean that we only need to test by the book.

178
00:10:07,280 --> 00:10:12,080
 As you saw, by enumerating and finding an extra security

179
00:10:12,080 --> 00:10:14,840
 access subservice, we found out that we can bypass it

180
00:10:14,840 --> 00:10:19,840
 easily without any calculation, any secret algorithm, or any

181
00:10:19,840 --> 00:10:20,800
 secret key.

182
00:10:20,800 --> 00:10:25,840
 And we can get direct access to it by only supplying zeros.

183
00:10:25,840 --> 00:10:29,520
 In most cases, several misconfigurations exist

184
00:10:29,520 --> 00:10:32,120
 outside of the cyber security requirements.

185
00:10:32,120 --> 00:10:36,520
 The OEM doesn't know or doesn't want us to know.

186
00:10:36,520 --> 00:10:38,560
 So they don't communicate it.

187
00:10:38,560 --> 00:10:43,600
 And the tier ones did not inform the OEM in the end,

188
00:10:43,600 --> 00:10:46,680
 which is the backdoor use case that we had now.

189
00:10:46,680 --> 00:10:47,960
 Why?

190
00:10:47,960 --> 00:10:49,880
 I don't know.

191
00:10:49,880 --> 00:10:52,240
 The solution, from my perspective, from our

192
00:10:52,240 --> 00:10:57,360
 perspective, for the OEM is to build more strict cyber

193
00:10:57,360 --> 00:10:59,040
 security requirements.

194
00:10:59,040 --> 00:11:02,520
 For the pen-less suppliers like us and the researchers is

195
00:11:02,520 --> 00:11:06,720
 to build more robust methodology, which will cover

196
00:11:06,720 --> 00:11:09,920
 a realistic amount of test cases.

197
00:11:09,920 --> 00:11:13,520
 Don't build it solely based on the requirements.

198
00:11:13,520 --> 00:11:15,480
 Stop thinking only about the requirements.

199
00:11:15,480 --> 00:11:19,200
 Build it on the experience and the attack surface that you

200
00:11:19,200 --> 00:11:21,440
 have in front of you.

201
00:11:21,440 --> 00:11:24,720
 And of course, educate the client, OEM, tier one, or

202
00:11:24,720 --> 00:11:25,400
 anyone else.

203
00:11:25,400 --> 00:11:28,040
 Education is the biggest part here.

204
00:11:28,040 --> 00:11:32,200
 We need the client to understand what we found and

205
00:11:32,200 --> 00:11:36,840
 what can be the severity and the impact of it.

206
00:11:36,840 --> 00:11:40,080
 Moving forward, everything will be changed in the end.

207
00:11:40,080 --> 00:11:43,400
 But moving forward now, we need to talk about the main

208
00:11:43,400 --> 00:11:47,480
 bridge of connectivity of a vehicle to the real world

209
00:11:47,480 --> 00:11:50,360
 lately, which is the telematics unit, and how many

210
00:11:50,360 --> 00:11:54,840
 vehicles get connected in the network that eventually they

211
00:11:54,840 --> 00:11:56,080
 should not actually be.

212
00:11:58,600 --> 00:12:03,440
 First of all, almost no vehicles ship anymore without a

213
00:12:03,440 --> 00:12:06,120
 telematics unit.

214
00:12:06,120 --> 00:12:08,640
 Main purpose of a telematics unit is the secure update

215
00:12:08,640 --> 00:12:12,240
 procedures, which became a necessity.

216
00:12:12,240 --> 00:12:15,360
 There are some regulations also.

217
00:12:15,360 --> 00:12:17,840
 There are several running services, including a remote

218
00:12:17,840 --> 00:12:20,120
 vehicle management in most cases.

219
00:12:20,120 --> 00:12:21,200
 You can unlock doors.

220
00:12:21,200 --> 00:12:25,080
 You can start vehicle conditioning and many other

221
00:12:25,080 --> 00:12:27,800
 use cases that a user might need.

222
00:12:27,800 --> 00:12:28,520
 Might not.

223
00:12:28,520 --> 00:12:29,440
 I don't know.

224
00:12:29,440 --> 00:12:32,640
 And the TLDR is that please consider the applicable

225
00:12:32,640 --> 00:12:36,920
 connectivity while designing the architecture.

226
00:12:36,920 --> 00:12:39,680
 So now that we got a first taste of how things are

227
00:12:39,680 --> 00:12:43,400
 getting connected, let's dive into a real world scenario of

228
00:12:43,400 --> 00:12:46,520
 a supercar manufacturer in this case that pushed the

229
00:12:46,520 --> 00:12:49,640
 connectivity of their pre-production vehicle in

230
00:12:49,640 --> 00:12:53,080
 order to perform secure updates and remote management

231
00:12:53,080 --> 00:12:58,120
 of the fleet for personalized support of their clients.

232
00:12:58,120 --> 00:13:01,280
 In this case, and as a first part, we have a telematics

233
00:13:01,280 --> 00:13:04,640
 unit, an ECU handling the cellular connectivity and the

234
00:13:04,640 --> 00:13:06,720
 connection to the internet.

235
00:13:06,720 --> 00:13:09,760
 And this telematics unit is connected to the main head

236
00:13:09,760 --> 00:13:13,560
 unit over some kind of interface.

237
00:13:13,560 --> 00:13:17,320
 It can be an RS485, serial, Broadridge, which is

238
00:13:17,320 --> 00:13:20,360
 automotive ethernet, or anything else that is

239
00:13:20,360 --> 00:13:23,200
 applicable in automotive.

240
00:13:23,200 --> 00:13:26,240
 At this point, one ECU is already connected.

241
00:13:26,240 --> 00:13:29,800
 And considering that this kind of ECUs usually come with

242
00:13:29,800 --> 00:13:32,840
 several publicly available services, in many cases,

243
00:13:32,840 --> 00:13:37,120
 including SSAs, you can understand that this kind of

244
00:13:37,120 --> 00:13:40,040
 risk is not implemented properly.

245
00:13:40,040 --> 00:13:43,960
 But there are proper implementations limiting the

246
00:13:43,960 --> 00:13:46,920
 exposure at the minimum using hypervisors, for example, on

247
00:13:46,920 --> 00:13:50,520
 the head unit to isolate the exposed system from the rest

248
00:13:50,520 --> 00:13:53,520
 of the ECUs and the connectivity in the vehicle,

249
00:13:53,520 --> 00:13:57,440
 and gateways that filter all requests coming from the

250
00:13:57,440 --> 00:13:59,560
 exposed unit.

251
00:13:59,560 --> 00:14:05,120
 But I don't know if this is the reality, because what we

252
00:14:05,120 --> 00:14:08,280
 can see in the complete hypothetical, in this case,

253
00:14:08,280 --> 00:14:12,120
 architecture of this vehicle, because we're under NDA, of

254
00:14:12,120 --> 00:14:19,480
 course, the different domains of this architecture are

255
00:14:19,480 --> 00:14:21,080
 interconnected between them.

256
00:14:21,080 --> 00:14:25,400
 But the biggest problem here is that there are several

257
00:14:25,400 --> 00:14:29,200
 components directly connected to the head unit, as we can

258
00:14:29,200 --> 00:14:35,840
 see on the red lines, instead of passing through the gateway

259
00:14:35,840 --> 00:14:38,360
 for proper routing and filtering of the

260
00:14:38,360 --> 00:14:40,320
 target messages.

261
00:14:40,320 --> 00:14:42,520
 Is that really an issue?

262
00:14:42,520 --> 00:14:46,160
 Interconnected buses can act as a stepping stone in safety

263
00:14:46,160 --> 00:14:51,040
 critical attacks, and gateways are commonly used for message

264
00:14:51,040 --> 00:14:52,960
 filtering and routing, as we said.

265
00:14:52,960 --> 00:14:55,520
 By passing the gateway, as we saw in the previous

266
00:14:55,520 --> 00:14:58,200
 architecture, it results in direct interception and

267
00:14:58,200 --> 00:15:01,120
 communication of CAN messages.

268
00:15:01,120 --> 00:15:05,320
 And at this point, the target ECUs existing on those buses

269
00:15:05,320 --> 00:15:09,920
 can be analyzed, enumerated, and exploited without the

270
00:15:09,920 --> 00:15:14,680
 assumed restrictions from the protections that we mentioned.

271
00:15:14,680 --> 00:15:17,200
 And getting deeper into our attack scenario, let's

272
00:15:17,200 --> 00:15:18,840
 remember the UDS.

273
00:15:18,840 --> 00:15:23,000
 And this time, we will use the service 11, which is ECU

274
00:15:23,000 --> 00:15:26,440
 reset, which does exactly what the name implies.

275
00:15:26,440 --> 00:15:29,480
 It resets the target ECU in different ways, with most

276
00:15:29,480 --> 00:15:33,040
 important one being the hard ECU reset, which technically

277
00:15:33,040 --> 00:15:36,800
 performs a complete power cycle of the target unit.

278
00:15:36,800 --> 00:15:40,720
 In our experience, almost 90% of the target ECUs come with

279
00:15:40,720 --> 00:15:43,280
 no authentication or precondition for hard ECU

280
00:15:43,280 --> 00:15:45,600
 resets, which can lead to several

281
00:15:45,600 --> 00:15:48,280
 issues described later.

282
00:15:48,280 --> 00:15:52,000
 What is the outcome of this EV supercar?

283
00:15:52,000 --> 00:15:54,840
 As we can see, there are several ECUs that are

284
00:15:54,840 --> 00:15:56,800
 connected--

285
00:15:56,800 --> 00:15:57,400
 no.

286
00:15:57,400 --> 00:15:57,800
 Yes.

287
00:15:57,800 --> 00:16:04,600
 So basically here, we have a specific domain of ECUs that

288
00:16:04,600 --> 00:16:09,640
 are directly connected to the gateway and to the head unit.

289
00:16:09,640 --> 00:16:12,080
 And if we manage to compromise the publicly

290
00:16:12,080 --> 00:16:17,600
 accessible head unit, we will be able to access directly a

291
00:16:17,600 --> 00:16:20,440
 BMS, which is a battery management system, an

292
00:16:20,440 --> 00:16:24,120
 inverter, and the whole batteries that are connected as

293
00:16:24,120 --> 00:16:26,120
 ECUs to the head unit.

294
00:16:26,120 --> 00:16:30,760
 In this case, by supplying either an ECU reset to the BMS,

295
00:16:30,760 --> 00:16:33,040
 which is the battery management system, or a

296
00:16:33,040 --> 00:16:37,760
 combined ECU reset to all the batteries, one, two, or three,

297
00:16:37,760 --> 00:16:42,960
 or whatever is the number of it, we can stop the

298
00:16:42,960 --> 00:16:46,320
 communication between the batteries and the rest of the

299
00:16:46,320 --> 00:16:49,400
 vehicle and completely stop the vehicle, which was the

300
00:16:49,400 --> 00:16:52,000
 case as imagined.

301
00:16:52,000 --> 00:16:53,960
 Of course, there are NDAs.

302
00:16:53,960 --> 00:16:57,960
 We cannot show exactly what we did with this supercar.

303
00:16:57,960 --> 00:17:01,200
 And also, when we test these components, we don't test them

304
00:17:01,200 --> 00:17:03,920
 on the actual vehicle most of the time-- sorry, in a running

305
00:17:03,920 --> 00:17:06,920
 vehicle, but we test it in a controlled environment.

306
00:17:06,920 --> 00:17:13,440
 But I have another example where the same POC is running

307
00:17:13,440 --> 00:17:17,560
 on a blind spot detection sensor in one of my rentals,

308
00:17:17,560 --> 00:17:21,320
 which blinks when issuing ECU reset, because you perform a

309
00:17:21,320 --> 00:17:24,800
 complete power cycle, so the ECU just blinks.

310
00:17:24,800 --> 00:17:28,240
 And while not critical, not as critical as resetting the

311
00:17:28,240 --> 00:17:32,960
 batteries, it can potentially confuse the driver that there

312
00:17:32,960 --> 00:17:36,000
 is something on the blind spot, or even create issues

313
00:17:36,000 --> 00:17:39,200
 with the adaptive cruise control when relying on the

314
00:17:39,200 --> 00:17:41,600
 system for turns or lane changes.

315
00:17:42,600 --> 00:17:46,720
 To conclude, while it was a simple example, we were able to

316
00:17:46,720 --> 00:17:49,320
 see how bad architectures can lead to some

317
00:17:49,320 --> 00:17:50,800
 devastating results.

318
00:17:50,800 --> 00:17:53,120
 Automotive architecture, understandably, gets more

319
00:17:53,120 --> 00:17:55,800
 complicated due to the need for connectivity.

320
00:17:55,800 --> 00:17:58,720
 But architecture needs to be revised in a secure way

321
00:17:58,720 --> 00:18:02,400
 throughout the different iterations and not really in

322
00:18:02,400 --> 00:18:05,840
 old and outdated architectures used in vehicle iterations

323
00:18:05,840 --> 00:18:08,200
 with half the ECUs.

324
00:18:08,200 --> 00:18:11,800
 For this, I would suggest more internal buses to be

325
00:18:11,800 --> 00:18:15,920
 introduced when needed for proper segmentation and safety

326
00:18:15,920 --> 00:18:18,480
 critical and non-critical components.

327
00:18:18,480 --> 00:18:21,800
 And better designs should be considered from the first step

328
00:18:21,800 --> 00:18:23,320
 of production.

329
00:18:23,320 --> 00:18:25,720
 When the actual vehicle starts to be implemented and

330
00:18:25,720 --> 00:18:28,960
 developed, it's already really late to change such

331
00:18:28,960 --> 00:18:32,400
 significant parts of the architecture.

332
00:18:32,400 --> 00:18:36,520
 Moving forward, we need to have a talk about design choices.

333
00:18:36,520 --> 00:18:39,600
 We already briefly mentioned some of the pitfalls that the

334
00:18:39,600 --> 00:18:43,160
 industry fell into because of bad design choices in the

335
00:18:43,160 --> 00:18:43,520
 start.

336
00:18:43,520 --> 00:18:48,720
 But let me also give you some juicy insights that you will

337
00:18:48,720 --> 00:18:51,960
 hopefully appreciate.

338
00:18:51,960 --> 00:18:55,480
 Understandably, vehicle development is way more

339
00:18:55,480 --> 00:18:58,480
 complicated than simply designing and architecting a

340
00:18:58,480 --> 00:19:02,520
 vehicle network with several decisions that need to be made

341
00:19:02,520 --> 00:19:07,200
 under highly constrained budget and time.

342
00:19:07,200 --> 00:19:10,040
 One of the issues that need to be resolved is the physical

343
00:19:10,040 --> 00:19:13,280
 space of the components, the actual space that we will fit

344
00:19:13,280 --> 00:19:14,840
 everything inside.

345
00:19:14,840 --> 00:19:18,520
 And where these components will be placed, how they will

346
00:19:18,520 --> 00:19:20,640
 fit, are they light enough?

347
00:19:20,640 --> 00:19:23,000
 Also, weight is a big factor in this.

348
00:19:23,000 --> 00:19:26,440
 And other such questions that need to be answered in order to

349
00:19:26,440 --> 00:19:29,960
 create an efficient and working vehicle which doesn't

350
00:19:29,960 --> 00:19:34,000
 spend 30 liters per kilometer or has an efficiency of 50

351
00:19:34,000 --> 00:19:35,560
 kilometers per charge.

352
00:19:35,560 --> 00:19:38,680
 At this point, manufacturers need to make sure that

353
00:19:38,680 --> 00:19:42,480
 everything is secure, isolated, and inaccessible to

354
00:19:42,480 --> 00:19:45,080
 external buses.

355
00:19:45,080 --> 00:19:48,800
 But what happens if it's not?

356
00:19:48,800 --> 00:19:53,880
 In the car theft incident that we saw previously, we saw that

357
00:19:53,880 --> 00:19:57,920
 a vehicle getting stolen due to internal buses which were

358
00:19:57,920 --> 00:20:03,640
 accessible behind the front headlight of the vehicle.

359
00:20:03,640 --> 00:20:06,160
 That is a really accessible place, as you can imagine.

360
00:20:06,160 --> 00:20:09,520
 As an attacker, it can simply create a small hole behind the

361
00:20:09,520 --> 00:20:11,880
 wheel of the vehicle to access the bus.

362
00:20:11,880 --> 00:20:14,520
 And if the architecture is something similar to what we

363
00:20:14,520 --> 00:20:17,640
 saw in the previous section, potentially unlock the whole

364
00:20:17,640 --> 00:20:21,520
 vehicle and issue an ignition signal which will start the

365
00:20:21,520 --> 00:20:25,120
 vehicle and help the attacker start a road trip, which is

366
00:20:25,120 --> 00:20:29,080
 the case with this finding here from Ian.

367
00:20:29,080 --> 00:20:32,720
 During a full vehicle pentest, though, we really often stumble

368
00:20:32,720 --> 00:20:37,080
 upon some such issues with the radar, sliders, and lights being

369
00:20:37,080 --> 00:20:39,320
 the most vulnerable ones.

370
00:20:39,320 --> 00:20:41,720
 As most of the times, manufacturers connect these

371
00:20:41,720 --> 00:20:43,320
 components with internal buses.

372
00:20:43,320 --> 00:20:46,280
 And by combining bad architecture that we saw

373
00:20:46,280 --> 00:20:50,040
 previously with bad design choices, we can have some

374
00:20:50,040 --> 00:20:52,800
 really interesting results.

375
00:20:52,800 --> 00:20:55,240
 Taking as an example our previous diagram, we can see

376
00:20:55,240 --> 00:20:59,120
 that there are several cameras and radars in one of the buses

377
00:20:59,120 --> 00:21:01,240
 of the vehicle.

378
00:21:01,240 --> 00:21:04,840
 This would not be an issue considering that the bus is

379
00:21:04,840 --> 00:21:06,920
 isolated from other buses.

380
00:21:06,920 --> 00:21:12,600
 But because on the same domain we have the EBS, the

381
00:21:12,600 --> 00:21:15,880
 electronic braking system, it means that it needs access to

382
00:21:15,880 --> 00:21:19,920
 the braking and steering ECUs, which that's why we see the

383
00:21:19,920 --> 00:21:24,480
 interconnected bus inside the network.

384
00:21:24,480 --> 00:21:28,440
 Considering that all previous use cases are applicable, we

385
00:21:28,440 --> 00:21:31,960
 can see the scenario where due to bad design, an attacker

386
00:21:31,960 --> 00:21:35,760
 managed to get internal bus access through the front radar.

387
00:21:35,760 --> 00:21:38,960
 Due to bad architecture, he can access the braking system.

388
00:21:38,960 --> 00:21:45,280
 And by issuing an ECU reset to the EBS system, trigger an

389
00:21:45,280 --> 00:21:48,440
 emergency braking of the vehicle, he can start a

390
00:21:48,440 --> 00:21:51,280
 emergency braking of the vehicle with potentially

391
00:21:51,280 --> 00:21:53,280
 devastating results, as you understand.

392
00:21:53,280 --> 00:21:55,760
 If applied in a highway, for example, we can see

393
00:21:55,760 --> 00:21:58,800
 something like this.

394
00:21:58,800 --> 00:22:02,360
 And now let's watch a cute video from a truck

395
00:22:02,360 --> 00:22:06,000
 manufacturer, which will give us some insights on the current

396
00:22:06,000 --> 00:22:09,280
 topic and how we will move forward in the talk.

397
00:22:09,280 --> 00:22:13,000
 So on the near side, we have a battery isolator switch.

398
00:22:13,000 --> 00:22:16,040
 As with everything with computers on board, before we

399
00:22:16,040 --> 00:22:20,320
 call action service out, it's always worth just isolating the

400
00:22:20,320 --> 00:22:24,360
 vehicle, counting to 10, and let everything reset itself,

401
00:22:24,360 --> 00:22:30,160
 re-energize the truck, and see if that's corrected your fault.

402
00:22:30,160 --> 00:22:32,480
 No relation.

403
00:22:32,480 --> 00:22:35,760
 So completely unrelated on OEM.

404
00:22:35,760 --> 00:22:39,560
 I just need to emphasize the battery isolator and grab your

405
00:22:39,560 --> 00:22:42,200
 attention a bit with the video.

406
00:22:42,200 --> 00:22:45,640
 The battery isolator is included in many EVs, in many

407
00:22:45,640 --> 00:22:49,840
 fuel cell cars, and other heavy duty vehicles.

408
00:22:49,840 --> 00:22:53,920
 And it's mainly used for isolation of batteries, for

409
00:22:53,920 --> 00:22:57,560
 safety concerning incidents, isolation of

410
00:22:57,560 --> 00:22:59,840
 inverters and converters.

411
00:22:59,840 --> 00:23:03,820
 hard reset of ECUs and clearance of faults.

412
00:23:03,820 --> 00:23:11,820
 What this isolation does, like the name implies, it separates the direct current into the underlying components.

413
00:23:11,820 --> 00:23:21,820
 And it actually, we actually encountered it several times in our pentest and mainly in heavy duty vehicles like

414
00:23:21,820 --> 00:23:30,820
 trucks, buses, some boats and other devices like this that have applicable ECUs.

415
00:23:30,820 --> 00:23:38,820
 The main question here is if should they be accessible in an unauthenticated manner as we saw in the video

416
00:23:38,820 --> 00:23:41,820
 or if they should be restricted.

417
00:23:41,820 --> 00:23:47,820
 And to answer this question we are moving to the next chapter which is the bootloaders

418
00:23:47,820 --> 00:23:54,820
 and we need to talk a bit about it and how some really old vulnerabilities are becoming new again

419
00:23:54,820 --> 00:23:58,820
 and we can use them to bypass several restrictions.

420
00:23:58,820 --> 00:24:05,820
 The bootloader usually in electronic control units is architecture specific

421
00:24:05,820 --> 00:24:14,820
 but it can be accessed through the application layer protocols which is common alongside all the different architectures that are applicable.

422
00:24:14,820 --> 00:24:21,820
 The bootloader usually is used for reprogramming purposes in initialization of application section of the memory,

423
00:24:21,820 --> 00:24:25,820
 read and write from and to sensitive parts of the memory

424
00:24:25,820 --> 00:24:33,820
 and understandably security measures must be taken to restrict unauthenticated access to these bootloaders.

425
00:24:33,820 --> 00:24:40,820
 The hard truth is that most of the manufacturers do not restrict access to this part of the memory

426
00:24:40,820 --> 00:24:47,820
 which as you understand can supply access to some really critical functionality on the underlying systems.

427
00:24:47,820 --> 00:24:56,820
 Usually even if we get access to the bootloader some of the sensitive services are restricted to unauthenticated users

428
00:24:56,820 --> 00:25:03,820
 and most of the times these services are the ones responsible for secure update of the unit

429
00:25:03,820 --> 00:25:09,820
 as an example request download and upload, transfer data and other services are the ones that are usually restricted

430
00:25:09,820 --> 00:25:13,820
 under some security access implementation.

431
00:25:13,820 --> 00:25:22,820
 But most of the ECUs use this bootloader section to perform secure update of the target

432
00:25:22,820 --> 00:25:31,820
 and authentication subservices for reprogramming is different from the subservices used in application mode and other restricted tasks.

433
00:25:31,820 --> 00:25:38,820
 In this diagram we see a really simple representation of the application bootloader parts of the system.

434
00:25:38,820 --> 00:25:44,820
 The normal boot process starts from the bootloader and then ends up on the application part

435
00:25:44,820 --> 00:25:52,820
 where our implemented applications live and manage the tasks which the ECU is programmed to perform.

436
00:25:52,820 --> 00:25:58,820
 In some of the cases though we can use the application layer UDS, protocol UDS

437
00:25:58,820 --> 00:26:07,820
 and issue session change to the programming session which will technically redirect us directly to the bootloader

438
00:26:07,820 --> 00:26:17,820
 and usually this session is unrestricted and we can directly supply it and switch to the bootloader.

439
00:26:17,820 --> 00:26:28,820
 In our experience this UDS session control programming session is most of the times accessible as I said by unauthenticated users

440
00:26:28,820 --> 00:26:33,820
 but what happens if it's not? How do we bypass it?

441
00:26:33,820 --> 00:26:41,820
 I don't know if you remember the service ECU reset but in this case by supplying an ECU reset, a hard ECU reset

442
00:26:41,820 --> 00:26:48,820
 we technically issue a complete power cycle to the unit and the boot process starts from the start.

443
00:26:48,820 --> 00:26:56,820
 What we can do now is issue another service which is a tester present which does exactly what the service implies, the name implies

444
00:26:56,820 --> 00:27:05,820
 which is state that we are there so we don't have to supply again and again the same command, the same session change

445
00:27:05,820 --> 00:27:16,820
 so by issuing the ECU reset and then issuing a tester present we can stay to the bootloader mode even if the switch to programming session is restricted.

446
00:27:16,820 --> 00:27:23,820
 So what if even the ECU reset is restricted? What are we doing now?

447
00:27:23,820 --> 00:27:30,820
 Basically on a test bench scenario where we have the ECU on our test bench and we can directly supply power to it

448
00:27:30,820 --> 00:27:39,820
 if we have restrictions on supplying the service ECU reset we can directly supply power to the unit which will act as the same thing

449
00:27:39,820 --> 00:27:47,820
 we can just use a really simple switch, we can turn off the power, we can resupply it and then we will have the same boot process

450
00:27:47,820 --> 00:27:56,820
 we send again the tester present, we stay in the bootloader and we have access to all the unauthenticated, to all the services that are applicable there

451
00:27:56,820 --> 00:28:00,820
 and to everything that opens when we get access to the bootloader.

452
00:28:00,820 --> 00:28:08,820
 And I don't know if you remember this but this comes again into the game because what happens if we have a full vehicle pen test?

453
00:28:08,820 --> 00:28:14,820
 This is really common and with the current regulations we need to have full vehicle pen tests

454
00:28:14,820 --> 00:28:22,820
 and in this case we don't have the ability to supply power from a power supply because we don't have the ECU

455
00:28:22,820 --> 00:28:27,820
 the vehicle is constructed, it is full so we need to find another way.

456
00:28:27,820 --> 00:28:35,820
 And these battery isolators is one of the things that we use to bypass these bootloader restrictions, the ECU reset restrictions

457
00:28:35,820 --> 00:28:38,820
 and the switch to programming session restrictions.

458
00:28:38,820 --> 00:28:45,820
 So basically the OEM give us an option, give us a switch outside of the vehicle

459
00:28:45,820 --> 00:28:52,820
 which we can use to stop the power supply and supply it again in order to get access to the bootloader

460
00:28:52,820 --> 00:28:55,820
 and bypass all the applicable restrictions in this case.

461
00:28:55,820 --> 00:29:03,820
 And yeah, here is a summary of what was explained, let's go through it, we don't have a lot of time

462
00:29:03,820 --> 00:29:10,820
 and now switching to something that will lead us to the final and complete compromise of the vehicle.

463
00:29:10,820 --> 00:29:16,820
 Combining on knowledge till now, we need to mention my talk from last year as we said before

464
00:29:16,820 --> 00:29:23,820
 where I evaluated security access seed randomness which is based in many cases on system clock

465
00:29:23,820 --> 00:29:29,820
 and how all the vulnerabilities because this is something that we see 20-30 years now are becoming new again

466
00:29:29,820 --> 00:29:32,820
 and it's really common in the automotive sector.

467
00:29:32,820 --> 00:29:40,820
 Manufacturers this year after my previous talk started realizing and mitigating this issue in most of the components

468
00:29:40,820 --> 00:29:45,820
 and especially big OEM and tier 1 suppliers. Did they though?

469
00:29:45,820 --> 00:29:54,820
 Here you can see that we have the normal boot process and we have one security access service

470
00:29:54,820 --> 00:30:01,820
 in order to give us on the application layer some execution of restricted routines in this case

471
00:30:01,820 --> 00:30:06,820
 and the subservice is the 03, we find it with enumeration of the unit

472
00:30:06,820 --> 00:30:12,820
 and in this case while enumerating the unit we find out that the source of randomness is the HSM.

473
00:30:12,820 --> 00:30:21,820
 There is no way to basically predict the seed that we will receive so there is no way to bypass it in this case.

474
00:30:21,820 --> 00:30:29,820
 But performing a bit more of enumeration and applying everything that we saw before by hard resetting the ECU

475
00:30:29,820 --> 00:30:36,820
 and supplying power to get access to the bootloader by bypassing anything even the battery isolator.

476
00:30:36,820 --> 00:30:44,820
 In this case enumerating the bootloader gives us again the security access service but with a different subservice 01

477
00:30:44,820 --> 00:30:51,820
 which is used for reprogramming and enumerating further we see that here we have a seed randomness of a system clock.

478
00:30:51,820 --> 00:31:03,820
 So basically by enumerating different sessions of the unit and by applying the different bypasses that we explained in the previous sections

479
00:31:03,820 --> 00:31:09,820
 we managed to find a hidden session which basically supplies us with weak source of randomness

480
00:31:09,820 --> 00:31:13,820
 and we can eventually bypass and get access to it.

481
00:31:13,820 --> 00:31:22,820
 Things which are protected on the application layer can be usually unprotected in the bootloader.

482
00:31:22,820 --> 00:31:29,820
 Many times it's forgotten, I don't know if it's a separate development team that developed the bootloader

483
00:31:29,820 --> 00:31:33,820
 and a separate one that developed the application layer so they didn't communicate

484
00:31:33,820 --> 00:31:40,820
 or they didn't follow the cyber security requirements or it's externally sourced so a different code base.

485
00:31:40,820 --> 00:31:49,820
 I cannot be sure but the outcome is that it's worth testing all the available services and subservices under all available layers on the ECU.

486
00:31:49,820 --> 00:31:54,820
 And finally we have the story of the duplicates.

487
00:31:54,820 --> 00:32:02,820
 What I presented last year and what I extend this year is the seed randomness phaser module for cutting Caribou

488
00:32:02,820 --> 00:32:10,820
 which is a tool for automating security analysis of ECUs.

489
00:32:10,820 --> 00:32:16,820
 It's mostly modular with several developed modules and the main advantage of it is the ease of use.

490
00:32:16,820 --> 00:32:22,820
 Main disadvantage is the inability to easily alter the low level layers of the protocol in this case.

491
00:32:22,820 --> 00:32:33,820
 As our last use case, let's target the hydrogen ATV which for safety critical reasons needs to be easily isolated from the batteries.

492
00:32:33,820 --> 00:32:38,820
 After enumerating we find out that ECU reset is not available in any diagnostic session,

493
00:32:38,820 --> 00:32:45,820
 that the available security access is not backed or vulnerable to weak seed randomness

494
00:32:45,820 --> 00:32:50,820
 and that no other misconfigurations discovered during the initial enumeration.

495
00:32:50,820 --> 00:32:59,820
 And in this case we go back, we have our favorite battery isolator alongside a really nice relay

496
00:32:59,820 --> 00:33:14,820
 and by combining them we can control when we can stop supplying power and start again by using this externally accessible battery isolator.

497
00:33:14,820 --> 00:33:22,820
 What we are looking here is a heavily edited version of the module that I described which instead of using ECU resets

498
00:33:22,820 --> 00:33:31,820
 it uses complete power cycles from this battery isolator and fixed delays between the power supply and the random seed request

499
00:33:31,820 --> 00:33:35,820
 in order to prove that the seed is based on the system clock.

500
00:33:35,820 --> 00:33:40,820
 And despite having all our preconditions restricted as we discussed,

501
00:33:40,820 --> 00:33:47,820
 we get fixed seeds and basically as you can see because of the configuration all the seeds received are the same

502
00:33:47,820 --> 00:33:55,820
 and based on the system clock and it's not a small seed, it's not something that we can actually predict or manipulate.

503
00:33:55,820 --> 00:33:59,820
 It's like a really big string that cannot be cracked.

504
00:33:59,820 --> 00:34:06,820
 In our example having a relay as the source of the power cycle can result in even more accurate results

505
00:34:06,820 --> 00:34:10,820
 than by using the ECU reset service that we discussed previously.

506
00:34:10,820 --> 00:34:19,820
 With around 20% of duplicate seeds of our 1K samples we can be relatively confident

507
00:34:19,820 --> 00:34:23,820
 that the target is sourcing the randomness from the system clock but even with less.

508
00:34:23,820 --> 00:34:31,820
 If you see a single duplicate in such a big string I don't think that you should think twice.

509
00:34:31,820 --> 00:34:38,820
 And in most cases it's easier to intercept the seed and precalculated key pair from the bootloader accessible sub-session

510
00:34:38,820 --> 00:34:42,820
 than from the application layer because it's used for reprogramming sessions.

511
00:34:42,820 --> 00:34:48,820
 So if you send the car to the testing center or to the service center and they will reprogram the ECU

512
00:34:48,820 --> 00:35:03,820
 it's more applicable that you will be able to intercept this seed in order to reapply the key to the applicable security access sub-service.

513
00:35:03,820 --> 00:35:12,820
 And to conclude, while Car in Caribou might not be the best tool out there, it can help newcomers start

514
00:35:12,820 --> 00:35:14,820
 and this is how we also started.

515
00:35:14,820 --> 00:35:22,820
 Several new automations from my side helped the project move forward that you can check online on the GitHub project.

516
00:35:22,820 --> 00:35:29,820
 I developed some modules for write data by identifier, FASER and other really important services.

517
00:35:29,820 --> 00:35:37,820
 Automated module for complete automation of UDS enumeration, support for new CAN interfaces with provider drivers

518
00:35:37,820 --> 00:35:41,820
 and different padding or no padding support.

519
00:35:41,820 --> 00:35:47,820
 And as we reach the end I would like to briefly mention the differences between what we perform as pen testers

520
00:35:47,820 --> 00:35:50,820
 and what security research on the automotive industry is.

521
00:35:50,820 --> 00:35:58,820
 And while reversing firmware and getting hardware access is fun, scope is usually extremely limited by the client.

522
00:35:58,820 --> 00:36:05,820
 For this reason we are tasked to find efficient ways to perform more testing in a result driven environment

523
00:36:05,820 --> 00:36:09,820
 and automation of tasks is usually our main priority.

524
00:36:09,820 --> 00:36:19,820
 We directly result the extension of our methodology and test cases and sometimes the investment of our time in automotive research.

525
00:36:19,820 --> 00:36:25,820
 And for the client side of the things, automotive clients need to understand our methodology and test cases

526
00:36:25,820 --> 00:36:30,820
 and we are the ones that need to properly explain it.

527
00:36:30,820 --> 00:36:42,820
 Alstreg results are not always a good way forward and education is the key for a better collaboration with developers as there is no clear standard and methodology available online

528
00:36:42,820 --> 00:36:47,820
 in contrast with mature industries like web, infra, API and others.

529
00:36:47,820 --> 00:36:56,820
 And here comes the serious finale and for some food for thought, I have some food for thought for you.

530
00:36:56,820 --> 00:37:02,820
 I think that my approach in the industry is a bit more romantic in this case.

531
00:37:02,820 --> 00:37:09,820
 I care about making the world a safer place and my way of achieving it is by doing the best to secure vehicles out there

532
00:37:09,820 --> 00:37:16,820
 and by closely working with manufacturers and by trying to spread the culture like what we are doing here.

533
00:37:16,820 --> 00:37:22,820
 The thing is that most of them, especially the OG ones, don't really care about this vision

534
00:37:22,820 --> 00:37:26,820
 and try to undermine issues like the ones we discussed today.

535
00:37:26,820 --> 00:37:30,820
 We live in a capitalistic world in the end and that's what we have to do.

536
00:37:30,820 --> 00:37:34,820
 We have to build the product, we have to ship it, we have to make it run.

537
00:37:34,820 --> 00:37:46,820
 So what I have to say is that the weight is basically on us, the researchers, the pen testers, the car hackers and everyone in this field, in this audience, in this camp

538
00:37:46,820 --> 00:37:54,820
 to share the culture and make sure issues like this are not undermined by the manufacturers and are not considered ways of modding

539
00:37:54,820 --> 00:38:02,820
 but things that can directly affect the safety and security of passengers, of drivers and of people in the streets.

540
00:38:02,820 --> 00:38:05,820
 That's it. Thank you.

541
00:38:14,820 --> 00:38:18,820
 Thank you very much. We have some time for some questions.

542
00:38:18,820 --> 00:38:21,820
 Are there... Yes.

543
00:38:21,820 --> 00:38:27,820
 Thank you. Thank you for your talk.

544
00:38:27,820 --> 00:38:40,820
 I totally get the idea of having a secret broker for the security services because they do that when you have your simple car, they just unplug the battery.

545
00:38:40,820 --> 00:38:48,820
 Why don't they just put a fucking fuse rather than something that can be reset?

546
00:38:48,820 --> 00:38:55,820
 It has no real acceptable purpose except what you do.

547
00:38:55,820 --> 00:39:00,820
 Yeah, look, unfortunately I don't work for an automotive.

548
00:39:00,820 --> 00:39:06,820
 Yes, I'm just the supplier and the researcher. I do both things also on my free time.

549
00:39:06,820 --> 00:39:10,820
 And in this case, I don't have a concrete answer.

550
00:39:10,820 --> 00:39:16,820
 Usually it's because these vehicles, the heavy duty vehicles, are not directly accessible.

551
00:39:16,820 --> 00:39:21,820
 It's not a car that you will find on the parking lot in the corner of the street.

552
00:39:21,820 --> 00:39:26,820
 It's something that is contained in an environment, in a fleet that you cannot easily access.

553
00:39:26,820 --> 00:39:32,820
 It's probably secured by some company, so you cannot go there and directly do it.

554
00:39:32,820 --> 00:39:37,820
 But what if you can? What if you can bypass these physical restrictions?

555
00:39:37,820 --> 00:39:42,820
 So, yeah, that's the answer. I don't know if I covered you, but yeah.

556
00:39:42,820 --> 00:39:48,820
 Do I see any other... Yeah, over there.

557
00:39:48,820 --> 00:39:54,820
 Yeah, thanks for the talk. It was great.

558
00:39:54,820 --> 00:40:03,820
 One question, so how do we prevent the car manufacturers using these security measures, which I hope will get better and better every time,

559
00:40:03,820 --> 00:40:11,820
 to use them to hide secrets in the firmware, like we've seen with emission scandals or these days with driving automations?

560
00:40:11,820 --> 00:40:17,820
 How do we ensure we still get transparency about decisions that are implemented in the firmware

561
00:40:17,820 --> 00:40:22,820
 while still keeping the car secure against intruders, I guess?

562
00:40:23,820 --> 00:40:27,820
 To be honest, I don't know if I have this answer.

563
00:40:27,820 --> 00:40:35,820
 I think this is more of a political discussion in general in the IT sector, not only in the vehicles, if I'm right.

564
00:40:35,820 --> 00:40:40,820
 I think that the reason we are here in this camp is exactly this.

565
00:40:40,820 --> 00:40:47,820
 It's also partially privacy and partially openness, and be sure that what we are using is what we are using

566
00:40:47,820 --> 00:40:50,820
 and manufacturers don't hide anything from us.

567
00:40:50,820 --> 00:40:53,820
 In this case, I don't have a concrete answer.

568
00:40:53,820 --> 00:40:59,820
 What I have to say is that these components are also safety critical components.

569
00:40:59,820 --> 00:41:02,820
 If something goes wrong with it, people can die.

570
00:41:02,820 --> 00:41:05,820
 And it's not only about privacy.

571
00:41:05,820 --> 00:41:13,820
 We also have to think twice when we do something, because if we don't develop it properly or if we don't secure it properly,

572
00:41:13,820 --> 00:41:16,820
 then it's human lives at stake.

573
00:41:16,820 --> 00:41:25,820
 So I don't have a concrete answer for the privacy issues, because unfortunately it's an issue that we are trying to fix here,

574
00:41:25,820 --> 00:41:28,820
 but I cannot fix it by myself.

575
00:41:28,820 --> 00:41:32,820
 Thank you.

576
00:41:32,820 --> 00:41:40,820
 So I don't see any other hands.

577
00:41:41,820 --> 00:41:47,820
 Oh no, we don't have. We have some time. We are quite good on time.

578
00:41:47,820 --> 00:41:53,820
 Can you? Yeah. Sorry.

579
00:41:53,820 --> 00:41:59,820
 I have a question about your test cases or your free time.

580
00:41:59,820 --> 00:42:06,820
 Maybe did you get the idea to get a little more creative and maybe use all the sensors of the vehicles

581
00:42:06,820 --> 00:42:13,820
 to try to get artificial inputs that might trigger ECU reset in another way,

582
00:42:13,820 --> 00:42:20,820
 for example, get a lighter sensor and shine a bright light on it or any other kind of these kind of things.

583
00:42:20,820 --> 00:42:23,820
 So apart from the requirements that you're testing against.

584
00:42:23,820 --> 00:42:32,820
 Yeah, like the test cases that we described here was mainly focused on UDS, which is this Application Layer Protocol.

585
00:42:32,820 --> 00:42:39,820
 But other than that, there are these messages that are flowing between this ECU and in the networks that we described.

586
00:42:39,820 --> 00:42:46,820
 So what you can usually do and what was really easy to do until a couple of years ago was that you could easily inject messages inside.

587
00:42:46,820 --> 00:42:52,820
 So and as you said, you can basically trick the vehicle on, for example, if you have a lighter sensor

588
00:42:52,820 --> 00:43:01,820
 and the adaptive cruise control is like focusing all the actions, all the braking actions, the steering actions on this lighter sensor,

589
00:43:01,820 --> 00:43:06,820
 and you manage to inject messages, then you can trick it into doing some action.

590
00:43:06,820 --> 00:43:12,820
 And that's partially what happened in the video with the blinking light.

591
00:43:12,820 --> 00:43:23,820
 Now there are several technologies that are used like Secocity to handle the two entities and the authentication between the two

592
00:43:23,820 --> 00:43:28,820
 and which ECU communicates with which to avoid these attacks.

593
00:43:28,820 --> 00:43:38,820
 But it's still not obsolete. You can still do it. I'm sure that in many vehicles you can still do it and you can inject messages.

594
00:43:38,820 --> 00:43:41,820
 You're welcome. Thank you.

595
00:43:41,820 --> 00:43:45,820
 And OK, so one last question.

596
00:43:45,820 --> 00:44:01,820
 Just a quick question. Did you look into the diagnostic tester from the OEM as an actual attack surface of like the security access algorithms usually having to be there for the workshop to do service?

597
00:44:01,820 --> 00:44:06,820
 You mean which are the security access algorithms if they are secure?

598
00:44:06,820 --> 00:44:18,820
 So the diagnostic tester usually has to have the algorithm somewhere on the diagnostic tester which makes this an attack surface for the vehicle,

599
00:44:18,820 --> 00:44:22,820
 which is not actually inside the vehicle, but on a computer in a workshop.

600
00:44:22,820 --> 00:44:31,820
 Yeah, like usually these testers are only going to certified service points, so we cannot obtain them.

601
00:44:31,820 --> 00:44:39,820
 Usually we evaluate the security access algorithms, which is something that it can be weak, it can be not.

602
00:44:39,820 --> 00:44:46,820
 Sometimes it's only a byte addition to the key, which is really dumb and you can reverse it in like a couple of minutes.

603
00:44:46,820 --> 00:44:50,820
 And sometimes it's a yes that you cannot bypass.

604
00:44:50,820 --> 00:44:55,820
 But for these testers, no, usually they don't come to our hands.

605
00:44:55,820 --> 00:45:05,820
 It's developed by someone else most of the times, not the OEM specifically, and they just supply the cybersecurity requirements and they develop it.

606
00:45:05,820 --> 00:45:10,820
 So thank you very much.

607
00:45:10,820 --> 00:45:16,820
 I have another organizer like auger announcements.

608
00:45:16,820 --> 00:45:23,820
 I've been asked to remind you that you should bring back your bottles that you bought to the place where you bought them if they're empty.

609
00:45:23,820 --> 00:45:32,820
 And you might also want to bring some like bottles that are not belonging to anyone.

610
00:45:32,820 --> 00:45:41,820
 Just pick them up and bring them back because we have a lot of empty crates that we're waiting to be filled to exchange them with full ones.

611
00:45:41,820 --> 00:45:43,820
 Thank you very much.

612
00:45:43,820 --> 00:45:49,820
 The next talk will be here in 15 minutes.

613
00:45:49,820 --> 00:45:59,820
 Thanks.