WEBVTT

1
00:00:00.120 --> 00:00:02.680
<v Speaker 1>Welcome to the deep dive. Today. We're jumping into something

2
00:00:02.720 --> 00:00:06.280
<v Speaker 1>that's well, probably all around you right now, the Internet

3
00:00:06.320 --> 00:00:10.199
<v Speaker 1>of things IoT. Think about it, you're smart speaker, your

4
00:00:10.199 --> 00:00:13.560
<v Speaker 1>fitness tracker, maybe even medical devices. They're super convenient, right,

5
00:00:13.720 --> 00:00:15.960
<v Speaker 1>but they also open up a whole new world of

6
00:00:16.679 --> 00:00:22.280
<v Speaker 1>well potential problems vulnerabilities. So our mission today is to

7
00:00:22.559 --> 00:00:26.559
<v Speaker 1>really get into the weeds of IoT security. It's fascinating stuff,

8
00:00:26.600 --> 00:00:30.440
<v Speaker 1>sometimes a bit unsettling. We're using the IoT Hackers Handbook

9
00:00:30.440 --> 00:00:32.880
<v Speaker 1>as our guide here, kind of a shortcut to understanding

10
00:00:33.119 --> 00:00:36.159
<v Speaker 1>why these things are often insecure and how security pros

11
00:00:36.200 --> 00:00:37.880
<v Speaker 1>and yeah, the bad guys too figure out how to

12
00:00:37.920 --> 00:00:39.759
<v Speaker 1>break into them. By the end of this you'll have

13
00:00:39.759 --> 00:00:42.000
<v Speaker 1>a much better handle on the tech behind your smart world,

14
00:00:42.439 --> 00:00:45.000
<v Speaker 1>way more than just a news headline. Ready to dive in.

15
00:00:45.280 --> 00:00:46.799
<v Speaker 1>All right, So where did this all kick off, this

16
00:00:46.840 --> 00:00:48.719
<v Speaker 1>idea of connecting everything, Well, the.

17
00:00:48.799 --> 00:00:51.560
<v Speaker 2>Term internet of things actually goes back to Kevin Ashty.

18
00:00:51.640 --> 00:00:54.600
<v Speaker 2>He was thinking about RFID, you know, tracking physical.

19
00:00:54.159 --> 00:00:57.880
<v Speaker 1>Stuff RFID right, like in inventory tags exactly.

20
00:00:58.000 --> 00:01:03.079
<v Speaker 2>But then fast forward to June two thousand, LG actually

21
00:01:03.200 --> 00:01:07.599
<v Speaker 2>launched an Internet connected fridge, the Internet digital dios maybe

22
00:01:07.680 --> 00:01:09.719
<v Speaker 2>the first real IoT device.

23
00:01:09.400 --> 00:01:10.840
<v Speaker 1>And internet fridge in two thousand.

24
00:01:10.879 --> 00:01:13.599
<v Speaker 2>Wow. Yeah, bit ahead of its time maybe, But the

25
00:01:13.640 --> 00:01:17.680
<v Speaker 2>real sort of tipping point when people really noticed was

26
00:01:17.719 --> 00:01:21.599
<v Speaker 2>probably the nests hrmostat ah nest I remember that right

27
00:01:21.840 --> 00:01:24.719
<v Speaker 2>when Google bought them at twenty eleven for was a

28
00:01:24.760 --> 00:01:28.000
<v Speaker 2>three point two billion dollars That really signaled, wait, this

29
00:01:28.040 --> 00:01:29.359
<v Speaker 2>is happening, this is a revolution.

30
00:01:29.480 --> 00:01:31.680
<v Speaker 1>So the money started flowing and everyone wanted.

31
00:01:31.480 --> 00:01:36.120
<v Speaker 2>In pretty much. And the thing is, policymakers, regulators, they

32
00:01:36.239 --> 00:01:38.040
<v Speaker 2>just couldn't keep up with how fast it was growing.

33
00:01:38.120 --> 00:01:41.319
<v Speaker 2>So you had this massive adoption of devices, but often

34
00:01:41.359 --> 00:01:45.920
<v Speaker 2>without any real strict quality controls or safety rules.

35
00:01:45.799 --> 00:01:49.519
<v Speaker 1>Meaning developers could kind of ignore security largely.

36
00:01:49.599 --> 00:01:51.439
<v Speaker 2>Yeah, the pressure was just to get products out the

37
00:01:51.439 --> 00:01:52.920
<v Speaker 2>door fast. Security was often.

38
00:01:52.760 --> 00:01:55.439
<v Speaker 1>An afterthought until something big happened to us exactly.

39
00:01:55.439 --> 00:01:58.200
<v Speaker 2>The big wake up call was the Maria botnet twenty

40
00:01:58.239 --> 00:02:02.519
<v Speaker 2>sixteen that was genuinely alarming. Maria basically went after internet

41
00:02:02.599 --> 00:02:07.200
<v Speaker 2>connected cameras, cheap ones. Mostly. It was brutally simple, really,

42
00:02:07.400 --> 00:02:10.919
<v Speaker 2>it just tried common default user names and passwords like

43
00:02:11.080 --> 00:02:15.000
<v Speaker 2>admin and pass. They're king defaults on millions of devices.

44
00:02:15.240 --> 00:02:17.800
<v Speaker 2>It was like millions of front doors just left unlocked,

45
00:02:18.000 --> 00:02:21.599
<v Speaker 2>and once it got in, it took over Liberia's entire internet,

46
00:02:21.639 --> 00:02:24.639
<v Speaker 2>the whole country, whole country. Yeah, and then launched this

47
00:02:24.840 --> 00:02:28.759
<v Speaker 2>massive DDoS attack distributed denial of service against DIN, a

48
00:02:28.759 --> 00:02:35.439
<v Speaker 2>big internet infrastructure company that took down huge sites GitHub, Twitter, Reddit, Netflix,

49
00:02:35.919 --> 00:02:38.840
<v Speaker 2>you name it all because of default passwords on cheap cameras.

50
00:02:38.919 --> 00:02:41.639
<v Speaker 1>That's staggering. It shows how interconnected everything is and how

51
00:02:41.719 --> 00:02:43.639
<v Speaker 1>weak links can cause chaos.

52
00:02:43.680 --> 00:02:46.719
<v Speaker 2>Precisely, it was a systemic failure, not just a few

53
00:02:46.759 --> 00:02:47.479
<v Speaker 2>bad devices.

54
00:02:47.560 --> 00:02:49.199
<v Speaker 1>Has security gotten better since.

55
00:02:49.039 --> 00:02:53.800
<v Speaker 2>Then, It's improved definitely slowly, but I wouldn't say devices

56
00:02:53.800 --> 00:02:56.479
<v Speaker 2>are extremely safe even now, not by a long shot.

57
00:02:56.800 --> 00:03:00.479
<v Speaker 2>We've seen researchers do things like takeover Phillips HU smart

58
00:03:00.560 --> 00:03:04.039
<v Speaker 2>lights using drones. Drones how they found encryption keys just

59
00:03:04.120 --> 00:03:07.039
<v Speaker 2>hard coded into the firmware, easy to grab, and they

60
00:03:07.080 --> 00:03:10.639
<v Speaker 2>use zigbie the wireless protocol to spread the infection.

61
00:03:10.560 --> 00:03:12.919
<v Speaker 1>So one light infects the next, YEP.

62
00:03:13.439 --> 00:03:16.840
<v Speaker 2>And even earlier, back in twenty thirteen, Natistan Johnny showed

63
00:03:16.879 --> 00:03:21.800
<v Speaker 2>he could cause permanent blackouts just by replaying old network messages.

64
00:03:22.159 --> 00:03:24.879
<v Speaker 2>He just needed the device's m ASSE address, which isn't

65
00:03:24.919 --> 00:03:28.319
<v Speaker 2>hard to get and could spoof commands. Basic stuff really

66
00:03:28.599 --> 00:03:29.840
<v Speaker 2>but effective, which is.

67
00:03:29.759 --> 00:03:32.520
<v Speaker 1>Worrying because these devices collect so much data about us.

68
00:03:32.479 --> 00:03:36.039
<v Speaker 2>Right, absolutely, really intimate data, sometimes health data, what you

69
00:03:36.080 --> 00:03:38.479
<v Speaker 2>do in your home. It's a huge privacy risk if

70
00:03:38.479 --> 00:03:41.439
<v Speaker 2>they get hacked. But on the flip side, all these

71
00:03:41.439 --> 00:03:45.080
<v Speaker 2>incidents have created a real demand for IoT security experts,

72
00:03:45.400 --> 00:03:47.719
<v Speaker 2>people who know how to build this stuff securely, and

73
00:03:47.759 --> 00:03:49.039
<v Speaker 2>people who know how to break.

74
00:03:48.840 --> 00:03:50.960
<v Speaker 1>It the ethical hackers right, and.

75
00:03:50.960 --> 00:03:53.879
<v Speaker 2>Companies are finally starting to offer bug bounties more often,

76
00:03:54.000 --> 00:03:56.960
<v Speaker 2>paying researchers to find flaws before the criminals do.

77
00:03:57.240 --> 00:03:59.280
<v Speaker 1>Okay, So it sounds like the rapid growth and lack

78
00:03:59.319 --> 00:04:01.639
<v Speaker 1>of early overst so I created a bit of a mess.

79
00:04:01.680 --> 00:04:03.879
<v Speaker 1>Maybe the best way to understand the risks is to

80
00:04:03.919 --> 00:04:07.840
<v Speaker 1>look at some specific example some of those headline grabbing hacks.

81
00:04:08.199 --> 00:04:10.960
<v Speaker 1>Let's start with the Nest thermistat. Again, you mentioned it earlier.

82
00:04:10.759 --> 00:04:14.360
<v Speaker 2>Right, the Nest. So researchers found you could crash it,

83
00:04:14.520 --> 00:04:17.800
<v Speaker 2>make it reboot just by sending specific Bluetooth signals.

84
00:04:17.959 --> 00:04:19.480
<v Speaker 1>Just crash it. What's the big deal?

85
00:04:19.680 --> 00:04:22.720
<v Speaker 2>Well, it created about a ninety second window where the thermistat

86
00:04:22.720 --> 00:04:25.319
<v Speaker 2>was offline. Okay, and if you had a nest security

87
00:04:25.360 --> 00:04:28.160
<v Speaker 2>camera link to it. That camera might also be affected

88
00:04:28.240 --> 00:04:31.199
<v Speaker 2>or delayed. Ninety seconds could be enough for a burglar

89
00:04:31.279 --> 00:04:32.639
<v Speaker 2>to slip past undetected.

90
00:04:33.000 --> 00:04:35.879
<v Speaker 1>Ah. I see, so a security device actually created an

91
00:04:35.879 --> 00:04:37.240
<v Speaker 1>insecurity exactly.

92
00:04:37.480 --> 00:04:40.079
<v Speaker 2>Then there were those Phillips Hugh lights. We mentioned the

93
00:04:40.160 --> 00:04:42.920
<v Speaker 2>drone attack exploiting the hard coded Zigbie.

94
00:04:42.600 --> 00:04:44.560
<v Speaker 1>Keys right, the self spreading worm.

95
00:04:44.560 --> 00:04:48.399
<v Speaker 2>Yep, and also that replay attack causing permanent blackouts that

96
00:04:48.519 --> 00:04:52.839
<v Speaker 2>was also targeting Phillips gear exploiting easily guessable device IDs.

97
00:04:53.079 --> 00:04:56.680
<v Speaker 1>It seems like basic communications security was often missing often.

98
00:04:56.839 --> 00:05:00.000
<v Speaker 2>Yes, look at the lift at smart Bold. Another research

99
00:05:00.319 --> 00:05:03.560
<v Speaker 2>Alex Chapman found he could inject malicious packets. He could

100
00:05:03.560 --> 00:05:06.160
<v Speaker 2>actually decrypt the owner's Wi Fi password from the.

101
00:05:06.079 --> 00:05:08.680
<v Speaker 1>Bulb get the Wi Fi password from a light bulb.

102
00:05:09.000 --> 00:05:12.000
<v Speaker 2>Yeah, the key was he dumped the firmware, the bulb

103
00:05:12.079 --> 00:05:15.639
<v Speaker 2>software using a hardware technique called JTAG, and right there

104
00:05:15.680 --> 00:05:19.279
<v Speaker 2>in the code the AES encryption key, the initialization vector,

105
00:05:19.759 --> 00:05:22.040
<v Speaker 2>everything needed to break the security. Wow.

106
00:05:22.199 --> 00:05:25.759
<v Speaker 1>Okay, that's bad, but maybe not as viscerally scary as

107
00:05:25.759 --> 00:05:26.360
<v Speaker 1>the GP pack.

108
00:05:26.560 --> 00:05:29.439
<v Speaker 2>Ah. The jeep pack twenty fifteen, That one really got

109
00:05:29.439 --> 00:05:32.639
<v Speaker 2>people's attention. Doctor Charlie Miller and Chris Vallisek.

110
00:05:32.560 --> 00:05:34.959
<v Speaker 1>Legends what did they do exactly? I remember the headlines,

111
00:05:34.959 --> 00:05:35.839
<v Speaker 1>but the details.

112
00:05:36.079 --> 00:05:39.160
<v Speaker 2>They remotely took control of a Jeep Cherokee while it

113
00:05:39.199 --> 00:05:43.040
<v Speaker 2>was driving miles away. They found a vulnerability in the

114
00:05:43.120 --> 00:05:47.800
<v Speaker 2>U Connect infotainment system, specifically an open network port Port

115
00:05:47.839 --> 00:05:50.720
<v Speaker 2>six six sixty seven running something called DBUS over IP,

116
00:05:51.160 --> 00:05:53.079
<v Speaker 2>and through that they found a service that let them

117
00:05:53.160 --> 00:05:55.319
<v Speaker 2>run their own code on the car's system, giving them

118
00:05:55.319 --> 00:06:01.399
<v Speaker 2>control of the steering, brakes, headlights, transmission, wipers, radio, everything

119
00:06:01.560 --> 00:06:03.040
<v Speaker 2>while someone was driving out on the highway.

120
00:06:03.120 --> 00:06:07.480
<v Speaker 1>That is terrifying, actual physical danger from a software flaw.

121
00:06:07.639 --> 00:06:10.360
<v Speaker 2>Absolutely. It led to a recall of one point four

122
00:06:10.399 --> 00:06:13.519
<v Speaker 2>million vehicles. It showed that IoT security wasn't just about

123
00:06:13.600 --> 00:06:15.680
<v Speaker 2>data theft. It could be about physical safety.

124
00:06:15.879 --> 00:06:18.160
<v Speaker 1>And it's not just cars or light bulbs. You mentioned

125
00:06:18.240 --> 00:06:19.680
<v Speaker 1>medical devices, right.

126
00:06:19.839 --> 00:06:23.040
<v Speaker 2>Jay Radcliffe found a major issue with a Johnson and

127
00:06:23.120 --> 00:06:27.560
<v Speaker 2>Johnson insulin pump, the Anima's one Touch pain. It communicated

128
00:06:27.600 --> 00:06:29.800
<v Speaker 2>wirelessly but in clear text.

129
00:06:30.120 --> 00:06:32.560
<v Speaker 1>No encryption for an insulin pump.

130
00:06:32.600 --> 00:06:37.279
<v Speaker 2>That sounds critically extremely It meant someone nearby could capture

131
00:06:37.319 --> 00:06:40.800
<v Speaker 2>the commands, maybe modify them and replay them. They could

132
00:06:40.800 --> 00:06:43.800
<v Speaker 2>potentially change the insulin dosage delivered to a patient that

133
00:06:43.839 --> 00:06:47.639
<v Speaker 2>could be lethal. Potentially. Yes. Thankfully, the vendor did patch

134
00:06:47.680 --> 00:06:51.600
<v Speaker 2>it relatively quickly, within about five months, but it highlighted

135
00:06:51.600 --> 00:06:53.439
<v Speaker 2>the risks in critical health devices.

136
00:06:53.680 --> 00:06:56.120
<v Speaker 1>Even things like smart door locks have had problems.

137
00:06:56.160 --> 00:06:59.839
<v Speaker 2>Oh yeah, tons of issues. One researcher, Jay Max, looked

138
00:06:59.839 --> 00:07:02.199
<v Speaker 2>at the August smart lock. He found a way for

139
00:07:02.279 --> 00:07:05.439
<v Speaker 2>someone with guest access to become an administrator. Oh just

140
00:07:05.480 --> 00:07:08.279
<v Speaker 2>by intercepting the network traffic and changing a value from

141
00:07:08.399 --> 00:07:12.120
<v Speaker 2>user to super user. Simple as that. Plus the firmware

142
00:07:12.199 --> 00:07:15.000
<v Speaker 2>wasn't signed, meaning you could modify it and to bypassed

143
00:07:15.000 --> 00:07:18.240
<v Speaker 2>some standard security check to other locks. Other researchers found

144
00:07:18.319 --> 00:07:22.600
<v Speaker 2>locks sending passwords and plaintext over the network yep, or

145
00:07:22.759 --> 00:07:27.639
<v Speaker 2>vulnerable to replay attacks, or using ridiculously weak hard coded

146
00:07:27.720 --> 00:07:32.879
<v Speaker 2>encryption keys. One Dana loock model literally used the key

147
00:07:33.000 --> 00:07:35.120
<v Speaker 2>this this secret, this the secret.

148
00:07:35.399 --> 00:07:36.920
<v Speaker 1>You can't make this stuff.

149
00:07:36.680 --> 00:07:40.120
<v Speaker 2>Up, you really can't. The pattern is just surprisingly weak

150
00:07:40.160 --> 00:07:41.720
<v Speaker 2>security practices in many.

151
00:07:41.560 --> 00:07:43.879
<v Speaker 1>Cases, even smart guns. That sounds like something from a.

152
00:07:43.839 --> 00:07:47.680
<v Speaker 2>Movie, It does, but it's real. Tracking point makes smart rifles,

153
00:07:47.800 --> 00:07:51.079
<v Speaker 2>you know, with computer raided targeting. Researchers Runas Sandvik and

154
00:07:51.160 --> 00:07:54.079
<v Speaker 2>Michael Auger found they could get admin access through a

155
00:07:54.079 --> 00:07:56.279
<v Speaker 2>physical port called art okay.

156
00:07:56.519 --> 00:07:58.160
<v Speaker 1>And what could they do from there?

157
00:07:58.240 --> 00:08:01.439
<v Speaker 2>They could launch network attacks to mess with the rifle's calculations.

158
00:08:01.879 --> 00:08:05.079
<v Speaker 2>Change the wind velocity value or the bulletweight parameter.

159
00:08:04.879 --> 00:08:07.079
<v Speaker 1>So the rifle would calculate the wrong shot.

160
00:08:07.040 --> 00:08:10.040
<v Speaker 2>Exactly, making the shoot or miss without them even knowing.

161
00:08:10.079 --> 00:08:11.839
<v Speaker 2>Why imagine the implications.

162
00:08:11.920 --> 00:08:13.879
<v Speaker 1>Yeah, and you mentioned another one with magnets.

163
00:08:14.240 --> 00:08:18.279
<v Speaker 2>Ah, right, the Armatix IP one smart gun. It had

164
00:08:18.279 --> 00:08:21.839
<v Speaker 2>a safety feature linked to a special watch. Another researcher

165
00:08:21.959 --> 00:08:26.000
<v Speaker 2>poor bypassed it using yes, just strong magnets. He could

166
00:08:26.040 --> 00:08:29.600
<v Speaker 2>manipulate the firing mechanism directly, proving that sometimes a really

167
00:08:29.680 --> 00:08:33.480
<v Speaker 2>low tech attack works just fine against poorly designed high

168
00:08:33.480 --> 00:08:34.159
<v Speaker 2>tech security.

169
00:08:34.279 --> 00:08:36.960
<v Speaker 1>So, looking at all these different examples, what's the common thread?

170
00:08:37.320 --> 00:08:39.919
<v Speaker 2>I think what's fascinating and worrying is how it shows

171
00:08:39.960 --> 00:08:41.919
<v Speaker 2>every part of an IoT device can be a weak

172
00:08:41.960 --> 00:08:45.679
<v Speaker 2>point if it's not secured properly. The hardware itself, the firmware,

173
00:08:45.759 --> 00:08:47.919
<v Speaker 2>the mobile app, the cloud service it talks to, the

174
00:08:48.000 --> 00:08:51.840
<v Speaker 2>radio signals, any single component can be the point of failure.

175
00:08:52.039 --> 00:08:52.879
<v Speaker 2>It's the whole chain.

176
00:08:53.159 --> 00:08:56.159
<v Speaker 1>Okay, so we've seen what goes wrong, But why why

177
00:08:56.200 --> 00:08:59.000
<v Speaker 1>are these vulnerabilities so common? What are the root causes?

178
00:08:59.120 --> 00:09:01.440
<v Speaker 2>That's the crucial quest if we actually want to fix things,

179
00:09:01.480 --> 00:09:03.960
<v Speaker 2>And there's several big reasons. One huge one is fragmentation.

180
00:09:04.200 --> 00:09:07.639
<v Speaker 2>Fragmentation means the sheer number of different ways these devices

181
00:09:07.639 --> 00:09:11.000
<v Speaker 2>talk to each other ZIGB Bluetooth, low energy, z wave,

182
00:09:11.600 --> 00:09:15.960
<v Speaker 2>Wi Fi, Laura six to low PAN, dozens of protocols

183
00:09:15.960 --> 00:09:16.879
<v Speaker 2>and software.

184
00:09:16.480 --> 00:09:18.639
<v Speaker 1>Frameworks like a tower of Babbel for devices.

185
00:09:18.960 --> 00:09:22.720
<v Speaker 2>Kinda yeah, it creates enormous complexity. There's no single standard

186
00:09:22.759 --> 00:09:27.200
<v Speaker 2>everyone follows, and this lack of standardization makes it way

187
00:09:27.240 --> 00:09:30.240
<v Speaker 2>easier for flaws to creep in. Plus, a lot of

188
00:09:30.320 --> 00:09:32.679
<v Speaker 2>developers just grab a popular framework and kind of assume

189
00:09:32.720 --> 00:09:36.000
<v Speaker 2>it's secure out of the box, which is often a

190
00:09:36.000 --> 00:09:37.159
<v Speaker 2>really dangerous assumption.

191
00:09:37.399 --> 00:09:39.279
<v Speaker 1>So the variety itself is a problem.

192
00:09:39.360 --> 00:09:41.600
<v Speaker 2>What else, A big one is simply a lack of

193
00:09:41.679 --> 00:09:44.480
<v Speaker 2>security awareness among developers. You mean they don't care. Not

194
00:09:44.480 --> 00:09:47.679
<v Speaker 2>necessarily that they don't care, but they're often under immense

195
00:09:47.720 --> 00:09:52.240
<v Speaker 2>pressure to ship products quickly. Deadlines are tight, and they

196
00:09:52.320 --> 00:09:55.200
<v Speaker 2>might just not be trained or aware of the specific

197
00:09:55.320 --> 00:09:59.639
<v Speaker 2>security pitfalls and IoT how hardware interacts with software, how

198
00:09:59.720 --> 00:10:03.440
<v Speaker 2>RADI protocols can be abused. It's a specialized field.

199
00:10:03.200 --> 00:10:05.879
<v Speaker 1>So they need better training and maybe stricter guidelines.

200
00:10:05.960 --> 00:10:10.759
<v Speaker 2>Definitely regular security training, clear coding rules, security checklists baked

201
00:10:10.799 --> 00:10:13.080
<v Speaker 2>into the development cycle. That's essential.

202
00:10:13.159 --> 00:10:14.440
<v Speaker 1>Okay, what other factors?

203
00:10:14.600 --> 00:10:16.960
<v Speaker 2>Another issue is what you might call a lack of

204
00:10:17.000 --> 00:10:21.320
<v Speaker 2>a macro perspective. A macro perspective, yeah, meaning teams often

205
00:10:21.360 --> 00:10:24.919
<v Speaker 2>focus too much on securing just one piece of the puzzle,

206
00:10:25.440 --> 00:10:28.200
<v Speaker 2>Like they'll pentis the mobile app, but they won't look

207
00:10:28.240 --> 00:10:30.639
<v Speaker 2>closely at how the app, the device, and the cloud

208
00:10:30.720 --> 00:10:31.440
<v Speaker 2>all interact.

209
00:10:31.679 --> 00:10:35.480
<v Speaker 1>Ah, so they miss the vulnerabilities that emerge from the

210
00:10:35.480 --> 00:10:37.559
<v Speaker 1>connections between components exactly.

211
00:10:37.720 --> 00:10:40.039
<v Speaker 2>They miss the forest for the trees. You need to

212
00:10:40.039 --> 00:10:42.639
<v Speaker 2>look at the entire system architecture end to end and

213
00:10:42.720 --> 00:10:45.159
<v Speaker 2>do proper threat modeling to see how everything connects and

214
00:10:45.159 --> 00:10:46.440
<v Speaker 2>where the real risks lie.

215
00:10:46.679 --> 00:10:49.120
<v Speaker 1>That makes sense. It's the Internet of things, after all,

216
00:10:49.360 --> 00:10:50.440
<v Speaker 1>the connections matter.

217
00:10:50.639 --> 00:10:52.679
<v Speaker 2>Right. Then there are supply chain issues.

218
00:10:52.720 --> 00:10:55.480
<v Speaker 1>Supply chain like where the parts come from precisely.

219
00:10:55.799 --> 00:10:58.440
<v Speaker 2>Think about how a complex device gets made. You might

220
00:10:58.480 --> 00:11:01.279
<v Speaker 2>have one company making the process or another. The Wi

221
00:11:01.279 --> 00:11:05.600
<v Speaker 2>Fi chip another, assembling it, another distributing it. Every step

222
00:11:05.639 --> 00:11:08.840
<v Speaker 2>in that chain, every vendor involved, is an opportunity for

223
00:11:08.879 --> 00:11:13.120
<v Speaker 2>a vulnerability to be introduced, either accidentally or maybe even deliberately.

224
00:11:13.799 --> 00:11:16.000
<v Speaker 2>A backdoor could be slipped in at any point.

225
00:11:16.240 --> 00:11:18.879
<v Speaker 1>Wow, that's complex. How do you even secure that?

226
00:11:19.080 --> 00:11:22.279
<v Speaker 2>It's incredibly difficult. It requires a lot of trust and verification,

227
00:11:22.480 --> 00:11:24.240
<v Speaker 2>which is hard to achieve globally.

228
00:11:24.519 --> 00:11:26.480
<v Speaker 1>Okay, any other major causes.

229
00:11:26.600 --> 00:11:30.080
<v Speaker 2>One last big one is the use of insecure frameworks

230
00:11:30.120 --> 00:11:31.600
<v Speaker 2>and third party libraries.

231
00:11:31.960 --> 00:11:35.799
<v Speaker 1>So developers using pre written code that's already flawed exactly.

232
00:11:36.559 --> 00:11:40.039
<v Speaker 2>It's very common to grab existing code samples or libraries

233
00:11:40.080 --> 00:11:43.000
<v Speaker 2>to speed up development. But if that code you're importing

234
00:11:43.039 --> 00:11:46.840
<v Speaker 2>has vulnerabilities, well, now your product has those vulnerabilities too.

235
00:11:47.519 --> 00:11:50.240
<v Speaker 2>And again, the business pressure to launch quickly often means

236
00:11:50.559 --> 00:11:54.000
<v Speaker 2>proper security vetting of these third party components gets pushed.

237
00:11:53.799 --> 00:11:55.519
<v Speaker 1>To the back burner until there's a breach.

238
00:11:55.639 --> 00:11:59.080
<v Speaker 2>Until there's a breach. Sadly, that's often the trigger for

239
00:11:59.120 --> 00:11:59.960
<v Speaker 2>taking it seriously.

240
00:12:00.159 --> 00:12:03.240
<v Speaker 1>So putting it all together, it's a mix of complexities,

241
00:12:03.360 --> 00:12:07.039
<v Speaker 1>speed to market pressure, lack of awareness, and issues baked

242
00:12:07.039 --> 00:12:09.240
<v Speaker 1>into the whole process of building these things that.

243
00:12:09.200 --> 00:12:11.519
<v Speaker 2>Sums it up pretty well. It's a complex ecosystem with

244
00:12:11.600 --> 00:12:14.200
<v Speaker 2>security challenges at almost every level.

245
00:12:14.000 --> 00:12:17.159
<v Speaker 1>Which, as you said, creates a huge demand for people

246
00:12:17.360 --> 00:12:20.399
<v Speaker 1>who can find these flaws. The security professionals, the pen testers.

247
00:12:20.919 --> 00:12:22.600
<v Speaker 1>How did they actually do it? What's their process?

248
00:12:22.840 --> 00:12:25.480
<v Speaker 2>Right? So, an IoT penetration test or pentest is different

249
00:12:25.519 --> 00:12:28.120
<v Speaker 2>from just testing a website or a regular application. It's

250
00:12:28.159 --> 00:12:32.360
<v Speaker 2>about assessing everything the physical device, the firmware inside it,

251
00:12:32.559 --> 00:12:36.440
<v Speaker 2>the radio communications, the mobile app, the cloud back end.

252
00:12:37.240 --> 00:12:38.039
<v Speaker 2>The whole solution.

253
00:12:38.200 --> 00:12:39.879
<v Speaker 1>Sounds comprehensive, it has to.

254
00:12:39.840 --> 00:12:43.519
<v Speaker 2>Be, And interestingly, you often need multiple physical devices for

255
00:12:43.639 --> 00:12:47.600
<v Speaker 2>testing because some techniques like physically taking chips off the

256
00:12:47.600 --> 00:12:51.919
<v Speaker 2>board are well destructive. You might break a device or

257
00:12:51.919 --> 00:12:53.399
<v Speaker 2>two finding vulnerabilities.

258
00:12:53.519 --> 00:12:54.799
<v Speaker 1>Okay, so where do they start?

259
00:12:54.960 --> 00:12:58.000
<v Speaker 2>The absolute foundation is a tax surface mapping. This is

260
00:12:58.039 --> 00:13:00.759
<v Speaker 2>the recon phase. You gather as much in from possible

261
00:13:00.840 --> 00:13:03.799
<v Speaker 2>before you even touch the device. Read the manuals, check

262
00:13:03.799 --> 00:13:07.039
<v Speaker 2>the vendor's website, look for patents, search for previous research

263
00:13:07.080 --> 00:13:09.559
<v Speaker 2>on similar devices, anything you can find.

264
00:13:09.679 --> 00:13:11.120
<v Speaker 1>What kind of info are you looking for?

265
00:13:11.279 --> 00:13:15.600
<v Speaker 2>Q details like what processor, cpu architectures it use, what

266
00:13:15.639 --> 00:13:19.720
<v Speaker 2>communication protocols, Wi Fi, bl zigbie, Is there a mobile app.

267
00:13:19.960 --> 00:13:22.720
<v Speaker 2>How does it get firmware updates? Does it have USB ports,

268
00:13:22.919 --> 00:13:25.600
<v Speaker 2>FD card slots, any hardware ports? Visible?

269
00:13:25.600 --> 00:13:27.840
<v Speaker 1>Building a complete picture, yes exactly.

270
00:13:28.000 --> 00:13:30.240
<v Speaker 2>You can generally break down the attack surface into three

271
00:13:30.279 --> 00:13:33.759
<v Speaker 2>big areas. First, the embedded device itself the thing. Can

272
00:13:33.799 --> 00:13:36.600
<v Speaker 2>you open it? Are the debug ports inside like art

273
00:13:36.679 --> 00:13:39.519
<v Speaker 2>or jtag? Can you dump the firmware directly from a

274
00:13:39.600 --> 00:13:44.240
<v Speaker 2>chip is authentication week? Second the firmware software and applications.

275
00:13:44.559 --> 00:13:46.960
<v Speaker 2>This is where traditional pen testing skills come in more

276
00:13:47.440 --> 00:13:50.320
<v Speaker 2>analyzing the mobile app, the web dashboard if there is one,

277
00:13:50.480 --> 00:13:53.360
<v Speaker 2>checking network services like SSH or FDP that might be

278
00:13:53.399 --> 00:13:57.440
<v Speaker 2>running on the device, looking for hard coded passwords, weak authentication,

279
00:13:57.919 --> 00:14:02.480
<v Speaker 2>logic flaws. And Third the radio communications. This is often

280
00:14:02.519 --> 00:14:06.080
<v Speaker 2>overlooked by developers. Wi Fi security yes, but also ble

281
00:14:06.519 --> 00:14:09.759
<v Speaker 2>zigb Z wave Laura. Can you sniff the traffic as

282
00:14:09.799 --> 00:14:12.120
<v Speaker 2>it encrypted? Can you jam the signal? Can you perform

283
00:14:12.159 --> 00:14:12.919
<v Speaker 2>replay attacks?

284
00:14:12.960 --> 00:14:15.120
<v Speaker 1>So you map out all these potential entry points right.

285
00:14:15.159 --> 00:14:17.919
<v Speaker 2>The goal is to create an architectural diagram, show all

286
00:14:17.960 --> 00:14:20.000
<v Speaker 2>the components how they talk to each other, and then

287
00:14:20.039 --> 00:14:22.279
<v Speaker 2>list every potential way an attacker might try to get

288
00:14:22.279 --> 00:14:23.480
<v Speaker 2>in every attack vector.

289
00:14:23.960 --> 00:14:26.200
<v Speaker 1>You mentioned something earlier about sec IDs.

290
00:14:26.559 --> 00:14:30.519
<v Speaker 2>Ah Yes, a really practical tip. Almost every device that

291
00:14:30.559 --> 00:14:33.799
<v Speaker 2>transmits radio waves has to have an SECID never printed

292
00:14:33.840 --> 00:14:36.679
<v Speaker 2>on it somewhere. If you take that ID and search

293
00:14:36.720 --> 00:14:40.360
<v Speaker 2>for it on the FCC website, specifically sites like sccside

294
00:14:40.360 --> 00:14:42.679
<v Speaker 2>dot io, it's often a gold mine.

295
00:14:42.840 --> 00:14:43.879
<v Speaker 1>Why what's there?

296
00:14:44.000 --> 00:14:46.440
<v Speaker 2>You can find internal photos of the device before it's

297
00:14:46.480 --> 00:14:51.120
<v Speaker 2>even released, sometimes detailed documents test reports. For example, looking

298
00:14:51.200 --> 00:14:55.039
<v Speaker 2>up the FCCID for an edmax IP camera revealed internal

299
00:14:55.080 --> 00:14:58.000
<v Speaker 2>photos clearly showing four little pads on the circuit board

300
00:14:58.519 --> 00:15:01.879
<v Speaker 2>that strongly suggested a u AT interface, a key debug port,

301
00:15:02.120 --> 00:15:04.600
<v Speaker 2>public information giving you a clue for hardware hacking.

302
00:15:04.799 --> 00:15:07.480
<v Speaker 1>That's clever, using public data to find hidden doors.

303
00:15:07.679 --> 00:15:10.000
<v Speaker 2>Okay, so once you've mapped the attack surface, what's next?

304
00:15:10.039 --> 00:15:12.799
<v Speaker 2>You mentioned getting physical to tear down exactly?

305
00:15:12.840 --> 00:15:15.360
<v Speaker 1>This is often where the real fun begins for hardware hackers,

306
00:15:15.399 --> 00:15:17.600
<v Speaker 1>getting physical with the device, trying it open.

307
00:15:17.840 --> 00:15:21.679
<v Speaker 2>Pretty much, the main goals here are things like extracting

308
00:15:21.720 --> 00:15:25.120
<v Speaker 2>the firmware directly from memory chips, maybe getting a rootshell

309
00:15:25.200 --> 00:15:27.399
<v Speaker 2>or command prompt on the device through a hidden port,

310
00:15:27.840 --> 00:15:30.159
<v Speaker 2>connecting debuggers to see what the code is doing live,

311
00:15:30.799 --> 00:15:35.440
<v Speaker 2>sometimes even modifying the hardware or writing custom firmware. And yeah,

312
00:15:35.440 --> 00:15:37.320
<v Speaker 2>as I said, you need spare devices because you might

313
00:15:37.360 --> 00:15:37.919
<v Speaker 2>break things.

314
00:15:38.360 --> 00:15:41.559
<v Speaker 1>So how do you start the physical analysis? First?

315
00:15:41.720 --> 00:15:45.279
<v Speaker 2>Is just external inspection. Look closely at the outside, what

316
00:15:45.320 --> 00:15:49.559
<v Speaker 2>buttons are there, any obvious ports, ethernet, USBSD card, what

317
00:15:49.679 --> 00:15:52.759
<v Speaker 2>kind of display does it have? Power requirements? And critically

318
00:15:53.000 --> 00:15:56.519
<v Speaker 2>look for those certification labels like the STCID. Even note

319
00:15:56.519 --> 00:15:59.120
<v Speaker 2>the type of screws holding it together. Sometimes you need

320
00:15:59.159 --> 00:16:01.720
<v Speaker 2>special screwdriver just to get inside.

321
00:16:01.279 --> 00:16:02.879
<v Speaker 1>Like on Apple devices.

322
00:16:02.600 --> 00:16:07.120
<v Speaker 2>Exactly ped loavescrews, torques. Knowing that tells you something. For instance,

323
00:16:07.200 --> 00:16:09.240
<v Speaker 2>looking at an old Navman GPS, you might note it

324
00:16:09.320 --> 00:16:12.720
<v Speaker 2>runs Windows, CE has a Samsung ARM processor and see

325
00:16:12.720 --> 00:16:15.360
<v Speaker 2>the USB, port, SD slot, et cetera. All clues.

326
00:16:15.480 --> 00:16:16.559
<v Speaker 1>Then you actually open it up.

327
00:16:16.759 --> 00:16:19.919
<v Speaker 2>Yeah, carefully. This is the internal inspection. You're looking at

328
00:16:19.960 --> 00:16:24.679
<v Speaker 2>the printed circuit board PCB, identifying the main chips, the CPU, RAM,

329
00:16:24.759 --> 00:16:28.519
<v Speaker 2>flash memory, where the firmware lives. You're also hunting for connectors, antennas,

330
00:16:28.519 --> 00:16:31.240
<v Speaker 2>and especially those debug interfaces. We talked about pins or

331
00:16:31.600 --> 00:16:35.600
<v Speaker 2>pads for your JTAG SPI. These are often the keys

332
00:16:35.639 --> 00:16:36.960
<v Speaker 2>to unlocking the device.

333
00:16:36.720 --> 00:16:40.080
<v Speaker 1>And those fcc ID lookups help here too massively.

334
00:16:40.440 --> 00:16:44.799
<v Speaker 2>Again, that FCC database SCCI dot io is amazing. You

335
00:16:44.879 --> 00:16:47.519
<v Speaker 2>might see internal photos there that clearly label the CPU

336
00:16:47.600 --> 00:16:50.559
<v Speaker 2>model or show exactly where the ur pads are, saving

337
00:16:50.639 --> 00:16:52.120
<v Speaker 2>you a ton of guesswork, like.

338
00:16:52.039 --> 00:16:53.679
<v Speaker 1>Finding the blueprint before you pick the lock.

339
00:16:53.840 --> 00:16:57.720
<v Speaker 2>Precisely that edmax camera example. Again, the SEC filing basically

340
00:16:57.720 --> 00:17:00.200
<v Speaker 2>pointed right to the r pads, a huge headstar for

341
00:17:00.240 --> 00:17:01.399
<v Speaker 2>anyone wanting to connect to it.

342
00:17:01.480 --> 00:17:04.359
<v Speaker 1>Okay, so you've found these internal ports like u ART,

343
00:17:04.599 --> 00:17:06.319
<v Speaker 1>how do you actually use them? How do you talk

344
00:17:06.400 --> 00:17:07.559
<v Speaker 1>to the device's insights?

345
00:17:07.680 --> 00:17:10.920
<v Speaker 2>Right? That's where understanding these low level communication protocols is key.

346
00:17:11.240 --> 00:17:14.680
<v Speaker 2>Let's start with u ART Universal Asynchronous Receival Transmitter.

347
00:17:14.759 --> 00:17:15.920
<v Speaker 1>Okay, what is it?

348
00:17:16.000 --> 00:17:19.039
<v Speaker 2>Simply, it's a really common, simple way for chips to

349
00:17:19.039 --> 00:17:21.880
<v Speaker 2>talk serially one bit after another. It doesn't need a

350
00:17:21.920 --> 00:17:24.640
<v Speaker 2>shared clock signal, which makes it easy to implement. Think

351
00:17:24.640 --> 00:17:28.240
<v Speaker 2>of it like a basic direct serial chat line between components.

352
00:17:28.279 --> 00:17:29.319
<v Speaker 1>And how do you exploit it?

353
00:17:29.440 --> 00:17:31.759
<v Speaker 2>First, you need to identify the pins on the circuit

354
00:17:31.759 --> 00:17:36.440
<v Speaker 2>board ground G and D, transmit TX, receive RX and

355
00:17:36.519 --> 00:17:40.359
<v Speaker 2>sometimes power VCC. You can often find these using.

356
00:17:40.160 --> 00:17:43.319
<v Speaker 1>A multimeter testing voltages and continuity exactly.

357
00:17:43.400 --> 00:17:45.519
<v Speaker 2>Yeah, Then you need a tool to connect your computer

358
00:17:45.720 --> 00:17:49.200
<v Speaker 2>to these pins, something like an FTDI adapter or a

359
00:17:49.200 --> 00:17:52.279
<v Speaker 2>specialized tool like the Adify badge works well. You connect

360
00:17:52.319 --> 00:17:56.400
<v Speaker 2>your tools TX to the devices RX, RX to TX

361
00:17:56.640 --> 00:17:59.200
<v Speaker 2>and ground to ground. You usually leave the VCC power

362
00:17:59.240 --> 00:18:02.440
<v Speaker 2>pin disconnected. Why because the device is usually already powered on.

363
00:18:02.480 --> 00:18:04.960
<v Speaker 2>You don't want to feed it extra voltage. Then you

364
00:18:05.000 --> 00:18:07.039
<v Speaker 2>need to figure out the speed the bod rate they're

365
00:18:07.079 --> 00:18:09.720
<v Speaker 2>talking at. There are tools like bodrate dot PI that

366
00:18:09.759 --> 00:18:10.960
<v Speaker 2>can automatically detect this.

367
00:18:11.119 --> 00:18:14.200
<v Speaker 1>Okay, you've got the pins, the speed, then what Then?

368
00:18:14.279 --> 00:18:17.079
<v Speaker 2>You just use a simple terminal program on your computer

369
00:18:17.279 --> 00:18:19.799
<v Speaker 2>like screen or Mini coom, connect to the serial port

370
00:18:19.799 --> 00:18:22.759
<v Speaker 2>provided by your tool, and very often, especially on cheaper

371
00:18:22.880 --> 00:18:25.640
<v Speaker 2>or older devices, you'll just get dropped straight into a

372
00:18:25.640 --> 00:18:27.799
<v Speaker 2>command prompt, often a rootshell.

373
00:18:27.720 --> 00:18:30.839
<v Speaker 1>Meaning full administrative control, no password needed.

374
00:18:30.920 --> 00:18:35.920
<v Speaker 2>Yep, an unauthenticated root shell over art. It's a surprisingly

375
00:18:36.079 --> 00:18:39.559
<v Speaker 2>common and critical vulnerability. We found this on that Atmax

376
00:18:39.599 --> 00:18:43.599
<v Speaker 2>camera for example, instant root access just by soldering three wires.

377
00:18:43.759 --> 00:18:46.359
<v Speaker 1>Wow, okay, what about other protocols you mentioned I two

378
00:18:46.400 --> 00:18:47.559
<v Speaker 1>C right, IT two.

379
00:18:47.359 --> 00:18:50.519
<v Speaker 2>C integrated circuit. There is another common one, but it's

380
00:18:50.519 --> 00:18:53.880
<v Speaker 2>a bus protocol, meaning multiple chips can share the same

381
00:18:53.920 --> 00:18:57.880
<v Speaker 2>two wires SDA for data and SEL for the clock signal.

382
00:18:58.119 --> 00:19:00.480
<v Speaker 1>So it's like a little internal network kind of.

383
00:19:00.559 --> 00:19:03.960
<v Speaker 2>Yeah. It's used for slower communication between components like e

384
00:19:04.079 --> 00:19:08.839
<v Speaker 2>proms small memory chips that store configuration data, real time clocks, sensors,

385
00:19:08.880 --> 00:19:09.400
<v Speaker 2>things like that.

386
00:19:09.440 --> 00:19:10.920
<v Speaker 1>And how is that useful for hacking?

387
00:19:11.240 --> 00:19:14.720
<v Speaker 2>Well, if important data like settings or maybe even keys

388
00:19:15.079 --> 00:19:17.200
<v Speaker 2>are stored in an e PROM chip that uses IT

389
00:19:17.359 --> 00:19:20.000
<v Speaker 2>two C, you can often read or write directly to

390
00:19:20.119 --> 00:19:22.279
<v Speaker 2>that chip. You'd find that chip on the board, look

391
00:19:22.359 --> 00:19:24.480
<v Speaker 2>up its data sheet to understand how to talk to it.

392
00:19:24.799 --> 00:19:27.559
<v Speaker 2>Connect your tool against something like the adify badge using

393
00:19:27.599 --> 00:19:28.200
<v Speaker 2>clips or an.

394
00:19:28.119 --> 00:19:30.440
<v Speaker 1>Adapter directly onto the chip yep, clip.

395
00:19:30.279 --> 00:19:33.079
<v Speaker 2>Right onto the legs. If possible, then you use software

396
00:19:33.319 --> 00:19:35.680
<v Speaker 2>like scripts often called I two C PROM dot PI

397
00:19:35.880 --> 00:19:38.640
<v Speaker 2>or similar to communicate over I two C and dump

398
00:19:38.680 --> 00:19:41.279
<v Speaker 2>the contents of the memory or even write new data

399
00:19:41.279 --> 00:19:41.680
<v Speaker 2>back to.

400
00:19:41.640 --> 00:19:44.240
<v Speaker 1>It, so you could potentially change device settings stored in

401
00:19:44.279 --> 00:19:45.839
<v Speaker 1>that memory exactly.

402
00:19:45.440 --> 00:19:49.640
<v Speaker 2>Maybe disable a security feature, or extract some sensitive configuration data.

403
00:19:49.720 --> 00:19:51.480
<v Speaker 1>Okay, one more SPI.

404
00:19:51.319 --> 00:19:55.799
<v Speaker 2>SPI Serial Peripheral interface another bus protocol generally faster than

405
00:19:55.839 --> 00:19:58.640
<v Speaker 2>I two C. It uses separate lines for data going

406
00:19:58.640 --> 00:20:02.079
<v Speaker 2>in OSI master out, slave in and data coming out

407
00:20:02.119 --> 00:20:06.000
<v Speaker 2>misomaster enslave out, plus a clock SK and a chip

408
00:20:06.039 --> 00:20:09.119
<v Speaker 2>select line SS to choose which device you're talking to.

409
00:20:09.400 --> 00:20:12.480
<v Speaker 1>Faster, more wires. What's his main use case in hacking?

410
00:20:12.759 --> 00:20:15.079
<v Speaker 2>The big one for SPI is often dumping the entire

411
00:20:15.119 --> 00:20:17.039
<v Speaker 2>firmware directly from the main flash.

412
00:20:16.880 --> 00:20:20.759
<v Speaker 1>Memory chip AH getting the device's brain out precisely.

413
00:20:21.119 --> 00:20:23.960
<v Speaker 2>Many devices store their operating system and all their software

414
00:20:24.000 --> 00:20:28.319
<v Speaker 2>on a flash chip that communicates using SPI, so similar

415
00:20:28.359 --> 00:20:33.960
<v Speaker 2>process find the chip, identify the SPI pins, mobiles, MISO, skcs,

416
00:20:34.160 --> 00:20:37.440
<v Speaker 2>VCCG and D connect your tool, and then use a

417
00:20:37.559 --> 00:20:41.319
<v Speaker 2>utility like spyflash dot PI. I often use with tools

418
00:20:41.359 --> 00:20:44.039
<v Speaker 2>like the ATIFI badge or flashroom to read the entire

419
00:20:44.119 --> 00:20:44.720
<v Speaker 2>contents of.

420
00:20:44.680 --> 00:20:47.359
<v Speaker 1>That chip, and that gives you the firmware file exactly.

421
00:20:47.359 --> 00:20:50.240
<v Speaker 2>You get a binary file containing everything. For example, on

422
00:20:50.279 --> 00:20:53.000
<v Speaker 2>a device like the WRT node router, you can use

423
00:20:53.079 --> 00:20:56.279
<v Speaker 2>SPI to pull the full OpenWrt firmware off its flash chip.

424
00:20:56.680 --> 00:20:58.920
<v Speaker 2>Then you can start analyzing that firmware offline.

425
00:20:59.039 --> 00:21:01.920
<v Speaker 1>So these low level portocols r at I two ce SPI.

426
00:21:02.000 --> 00:21:04.880
<v Speaker 1>They're like the secret back doors into the device's hardware,

427
00:21:05.079 --> 00:21:07.240
<v Speaker 1>letting you get shells or extract the firmware.

428
00:21:07.279 --> 00:21:08.960
<v Speaker 2>That's a good way to put it. They bypass a

429
00:21:08.960 --> 00:21:11.680
<v Speaker 2>lot of the normal software security because you're talking directly

430
00:21:11.720 --> 00:21:13.160
<v Speaker 2>to the hardware components.

431
00:21:12.720 --> 00:21:15.039
<v Speaker 1>Which leads perfectly into the next stage. You got the

432
00:21:15.039 --> 00:21:17.680
<v Speaker 1>firmware file, Now, what how do you crack that open?

433
00:21:17.920 --> 00:21:19.920
<v Speaker 2>Right? So you've managed to get the firmware, either by

434
00:21:19.960 --> 00:21:22.480
<v Speaker 2>downloading it, sniffing it during an update, or dumping it

435
00:21:22.559 --> 00:21:27.039
<v Speaker 2>via hardware like SBI. Now the real analysis begins, and

436
00:21:27.119 --> 00:21:30.920
<v Speaker 2>having that firmware file is huge for a security researcher.

437
00:21:31.400 --> 00:21:33.880
<v Speaker 2>It's arguably the most critical component because it lets you

438
00:21:33.960 --> 00:21:38.880
<v Speaker 2>understand the device's logic, find vulnerabilities, look for secrets, all

439
00:21:38.920 --> 00:21:41.759
<v Speaker 2>without needing the physical device anymore potentially.

440
00:21:41.400 --> 00:21:43.680
<v Speaker 1>So first step is usually unpacking it. You mentioned it's

441
00:21:43.720 --> 00:21:45.160
<v Speaker 1>often compressed exactly.

442
00:21:45.279 --> 00:21:48.799
<v Speaker 2>Firmware files are often archives containing a file system, bootloaders,

443
00:21:48.839 --> 00:21:52.039
<v Speaker 2>maybe a kernel. You can try manually analyzing it first,

444
00:21:52.240 --> 00:21:54.000
<v Speaker 2>use tools like file to see what type of file

445
00:21:54.000 --> 00:21:56.559
<v Speaker 2>it is, strings to look for readable text, hex dump

446
00:21:56.720 --> 00:21:59.240
<v Speaker 2>to look at the raw bytes. Sometimes you can spot

447
00:21:59.279 --> 00:22:02.400
<v Speaker 2>signatures of and filesystems like squash fs. Just by looking

448
00:22:02.400 --> 00:22:05.039
<v Speaker 2>at the hex you might see the magic bytes.

449
00:22:04.839 --> 00:22:06.640
<v Speaker 1>H excludes in the raw data.

450
00:22:06.880 --> 00:22:09.200
<v Speaker 2>Yeah, and if you find something like squash fs, you

451
00:22:09.240 --> 00:22:12.160
<v Speaker 2>can use tools like dd to carve out that section

452
00:22:12.200 --> 00:22:15.680
<v Speaker 2>of the firmware file and then use unsquash to extract

453
00:22:15.720 --> 00:22:17.440
<v Speaker 2>the actual filesystem.

454
00:22:16.960 --> 00:22:18.920
<v Speaker 1>Sounds a bit involved? Is there an easier way?

455
00:22:19.000 --> 00:22:22.279
<v Speaker 2>Oh? Yeah? The go to tool here is binwalk. It's fantastic.

456
00:22:22.480 --> 00:22:23.640
<v Speaker 1>Binwalk. What does it do?

457
00:22:23.880 --> 00:22:27.920
<v Speaker 2>It automatically scans firmware files for known file signatures, compression types,

458
00:22:28.039 --> 00:22:32.559
<v Speaker 2>executable code, everything. You just run binwalk on the firmware file,

459
00:22:32.759 --> 00:22:35.279
<v Speaker 2>it'll tell you okay, at this offset there's a header.

460
00:22:35.519 --> 00:22:38.640
<v Speaker 2>At this offset, there's a squash fs filesystem. At this

461
00:22:38.720 --> 00:22:41.160
<v Speaker 2>offset maybe some GFFS two data.

462
00:22:41.400 --> 00:22:43.240
<v Speaker 1>It maps out the structure exactly.

463
00:22:43.640 --> 00:22:47.599
<v Speaker 2>And even better, you can run binwalk de for extract

464
00:22:47.920 --> 00:22:50.440
<v Speaker 2>and it will try to automatically carve out and extract

465
00:22:50.519 --> 00:22:53.279
<v Speaker 2>everything it finds into a folder. Usually gives you a

466
00:22:53.279 --> 00:22:58.400
<v Speaker 2>firmware dot extracted directory containing the filesystem like squashroot. Super convenient.

467
00:22:58.480 --> 00:23:00.680
<v Speaker 1>Okay, so now you have the filesystem laid out, what

468
00:23:00.720 --> 00:23:01.480
<v Speaker 1>are you looking for.

469
00:23:01.400 --> 00:23:05.519
<v Speaker 2>Inside one of The first things is hard coded secrets, passwords,

470
00:23:05.640 --> 00:23:11.000
<v Speaker 2>API keys, private encryption keys. Developers sometimes mistakenly embed these

471
00:23:11.039 --> 00:23:13.279
<v Speaker 2>directly into scripts or configuration files.

472
00:23:13.480 --> 00:23:15.000
<v Speaker 1>You just search for them pretty much.

473
00:23:15.559 --> 00:23:18.200
<v Speaker 2>You'd use rep to search recursively through the entire extract

474
00:23:18.240 --> 00:23:22.480
<v Speaker 2>and file system for keywords like password, key, secret, admin token,

475
00:23:23.119 --> 00:23:26.920
<v Speaker 2>or maybe specific service names like Telnet FDP, and.

476
00:23:26.880 --> 00:23:28.359
<v Speaker 1>You might find default credentials.

477
00:23:28.640 --> 00:23:32.599
<v Speaker 2>Absolutely, you might find a script like telnetdat dot ashesh

478
00:23:33.000 --> 00:23:36.039
<v Speaker 2>that starts the Telnet service with a default login like

479
00:23:36.119 --> 00:23:38.160
<v Speaker 2>root and password happens all the time.

480
00:23:38.240 --> 00:23:41.039
<v Speaker 1>Okay, but what if bin walk can't extract anything? What

481
00:23:41.119 --> 00:23:43.279
<v Speaker 1>if the firmware just looks like random data.

482
00:23:43.599 --> 00:23:47.400
<v Speaker 2>Ah, that's a strong sign it might be encrypted or

483
00:23:47.440 --> 00:23:52.519
<v Speaker 2>maybe heavily obfuscated, So gameover not necessarily. First step is

484
00:23:52.559 --> 00:23:55.480
<v Speaker 2>often to look at the entropy. How random the data looks.

485
00:23:56.039 --> 00:23:59.640
<v Speaker 2>Tools can measure this. High entropy suggests encryption or compression.

486
00:24:00.160 --> 00:24:02.400
<v Speaker 2>Then you might use hext se again to look at

487
00:24:02.400 --> 00:24:05.359
<v Speaker 2>the raw bytes. Even with encryption, sometimes you can spot.

488
00:24:05.200 --> 00:24:07.119
<v Speaker 1>Patterns, patterns and encrypted data.

489
00:24:07.400 --> 00:24:11.119
<v Speaker 2>How especially with simpler encryption methods like xor if the

490
00:24:11.160 --> 00:24:13.960
<v Speaker 2>same key is used repeatedly, you might see repeating byte

491
00:24:13.960 --> 00:24:16.400
<v Speaker 2>patterns in the ciphertext. You might even be able to

492
00:24:16.400 --> 00:24:18.839
<v Speaker 2>guess the key length, or if you're lucky and have

493
00:24:18.920 --> 00:24:21.519
<v Speaker 2>some known plaintext like a standard file header that should

494
00:24:21.559 --> 00:24:24.279
<v Speaker 2>be there, you could potentially deduce the xor key itself.

495
00:24:24.440 --> 00:24:25.599
<v Speaker 1>So you figure out the key.

496
00:24:25.480 --> 00:24:27.640
<v Speaker 2>Then you can write a simple script, maybe in Python,

497
00:24:27.920 --> 00:24:30.759
<v Speaker 2>to apply the xor operation with that key to the

498
00:24:30.880 --> 00:24:35.200
<v Speaker 2>entire encrypted firmware file and hopefully out pops the decrypted.

499
00:24:34.759 --> 00:24:37.079
<v Speaker 1>Firmware and then binwok can work on it exactly.

500
00:24:37.119 --> 00:24:40.599
<v Speaker 2>Once it's decrypted, you run binwalk again, extract the file

501
00:24:40.680 --> 00:24:44.720
<v Speaker 2>system and continue your analysis, maybe dive deeper into specific

502
00:24:44.799 --> 00:24:48.680
<v Speaker 2>executable files using reverse engineering tools like guedro or radar

503
00:24:48.759 --> 00:24:50.319
<v Speaker 2>two to understand their logic.

504
00:24:50.400 --> 00:24:52.640
<v Speaker 1>Okay, this is getting deep. What about actually running the

505
00:24:52.680 --> 00:24:53.920
<v Speaker 1>code you find? Can you do that?

506
00:24:54.119 --> 00:24:58.759
<v Speaker 2>Yes? But it's tricky because IoT devices use different process

507
00:24:58.839 --> 00:25:03.160
<v Speaker 2>or architectures. Arm mips are common, not the by eighty

508
00:25:03.200 --> 00:25:04.440
<v Speaker 2>six your laptop.

509
00:25:04.079 --> 00:25:06.920
<v Speaker 1>Uses, so the code won't run directly on your computer.

510
00:25:07.279 --> 00:25:10.960
<v Speaker 2>Correct, But we can use emulation. The most common tool

511
00:25:11.000 --> 00:25:15.039
<v Speaker 2>for this is keemu U. Yeah, keemu provides userspace emulation.

512
00:25:15.279 --> 00:25:17.920
<v Speaker 2>You can take say a memo binary from the firmware

513
00:25:18.079 --> 00:25:20.680
<v Speaker 2>and run it on your by eighty six Linux machine

514
00:25:20.960 --> 00:25:24.799
<v Speaker 2>using Chemo mipsel static. You copy the right chemostatic binary

515
00:25:24.799 --> 00:25:28.319
<v Speaker 2>into the extracted firmware's filesystem, then use a command called

516
00:25:28.359 --> 00:25:31.200
<v Speaker 2>troot to make that extracted directory act like the root

517
00:25:31.200 --> 00:25:34.599
<v Speaker 2>file system. Now, inside that trute environment, you can run

518
00:25:34.599 --> 00:25:37.559
<v Speaker 2>the firmware's own programs like it's BusyBox shell or other

519
00:25:37.640 --> 00:25:39.400
<v Speaker 2>utilities using chemu behind.

520
00:25:39.200 --> 00:25:41.480
<v Speaker 1>The scenes, so you can interact with the device's software

521
00:25:41.559 --> 00:25:43.799
<v Speaker 1>environment without the device exactly.

522
00:25:43.960 --> 00:25:46.839
<v Speaker 2>Yeah, but that's just running individual programs. What's even more

523
00:25:46.880 --> 00:25:51.559
<v Speaker 2>powerful is full system emulation. There are specialized toolkits, like

524
00:25:51.599 --> 00:25:56.160
<v Speaker 2>the Firmware Analysis Toolkit FAT or Fermidine designed to emulate

525
00:25:56.200 --> 00:25:59.599
<v Speaker 2>the entire firmware image. What's the advantage of that It

526
00:25:59.640 --> 00:26:02.720
<v Speaker 2>tries to boot the whole emulated device, It sets up

527
00:26:02.920 --> 00:26:06.640
<v Speaker 2>networking start services. It means you can often access the

528
00:26:06.640 --> 00:26:09.960
<v Speaker 2>device's web interface through your browser, interact with its network

529
00:26:10.000 --> 00:26:13.480
<v Speaker 2>services attached debuggers. It's like having a virtual version of

530
00:26:13.519 --> 00:26:14.680
<v Speaker 2>the physical device running.

531
00:26:14.799 --> 00:26:19.039
<v Speaker 1>That sounds incredibly useful for testing find web vulnerabilities network flaws.

532
00:26:19.119 --> 00:26:23.160
<v Speaker 2>Absolutely, you could test a netgear firmware, for example, emulate

533
00:26:23.200 --> 00:26:26.559
<v Speaker 2>it with FAT and then access its weblogin page. Maybe

534
00:26:26.599 --> 00:26:28.640
<v Speaker 2>try default credentials like admin passwork.

535
00:26:28.720 --> 00:26:31.839
<v Speaker 1>Okay, one more thing here, backdooring firmware. Can you actually

536
00:26:31.920 --> 00:26:34.519
<v Speaker 1>modify the firmware to ad malicious stuff?

537
00:26:34.720 --> 00:26:38.200
<v Speaker 2>Yes, if the device doesn't have proper security checks in place,

538
00:26:38.640 --> 00:26:41.720
<v Speaker 2>specifically if it doesn't verify the digital signature of the

539
00:26:41.720 --> 00:26:43.200
<v Speaker 2>firmware before installing it.

540
00:26:43.519 --> 00:26:45.680
<v Speaker 1>So if there's no signature check, then.

541
00:26:45.559 --> 00:26:48.759
<v Speaker 2>You can unpack the firmware, modify it, and repack it.

542
00:26:49.079 --> 00:26:52.519
<v Speaker 2>There are tools like the Firmware Modkit FMK that help

543
00:26:52.559 --> 00:26:55.480
<v Speaker 2>with this. You could, for instance, compile a small program

544
00:26:55.519 --> 00:26:58.400
<v Speaker 2>that opens a bindshell basically listens on a network port

545
00:26:58.440 --> 00:27:02.319
<v Speaker 2>for incoming connections backdoor exactly. You'd need to cross compile

546
00:27:02.400 --> 00:27:06.039
<v Speaker 2>it for the device's architecture, say metpass. Tools like build

547
00:27:06.119 --> 00:27:08.599
<v Speaker 2>root can help with that. Then you inject your compiled

548
00:27:08.640 --> 00:27:12.559
<v Speaker 2>backdoor program into the firmware's file system, maybe modify a

549
00:27:12.599 --> 00:27:15.880
<v Speaker 2>startup script system dot SHA or some so your backdoor

550
00:27:15.920 --> 00:27:19.119
<v Speaker 2>runs automatically when the device boots. Then you use fnk's

551
00:27:19.200 --> 00:27:22.480
<v Speaker 2>build firmware dosh script to repack it all into a

552
00:27:22.480 --> 00:27:23.640
<v Speaker 2>new firmware file.

553
00:27:23.440 --> 00:27:26.319
<v Speaker 1>And then flash that malicious firmware onto the device yep.

554
00:27:26.400 --> 00:27:29.039
<v Speaker 2>If it accepts it because it's not checking signatures, the

555
00:27:29.079 --> 00:27:32.000
<v Speaker 2>device reboots and your back door starts listening. You can

556
00:27:32.039 --> 00:27:34.599
<v Speaker 2>then connect to it over the network, maybe using maps

557
00:27:34.720 --> 00:27:37.599
<v Speaker 2>netcat and get a remote shell full control.

558
00:27:37.720 --> 00:27:41.720
<v Speaker 1>That's quite powerful both for finding flaws and for creating

559
00:27:41.799 --> 00:27:42.880
<v Speaker 1>compromised devices.

560
00:27:42.960 --> 00:27:45.960
<v Speaker 2>Definitely, and there are even automated tools like firm walker

561
00:27:46.319 --> 00:27:50.000
<v Speaker 2>that can scan an extracted firmware file system and automatically

562
00:27:50.039 --> 00:27:55.119
<v Speaker 2>flagged potential issues hard coded keys, weak permissions, known vulnerable scripts,

563
00:27:55.559 --> 00:27:56.720
<v Speaker 2>generates a quick report.

564
00:27:56.920 --> 00:28:00.440
<v Speaker 1>So firmware analysis is really about dissecting the devices brain,

565
00:28:00.680 --> 00:28:04.680
<v Speaker 1>finding secrets, understanding its logic, and sometimes even modifying it.

566
00:28:04.799 --> 00:28:07.000
<v Speaker 2>That's the essence of it. It's a critical part of

567
00:28:07.039 --> 00:28:08.440
<v Speaker 2>IoT security assessment.

568
00:28:08.480 --> 00:28:12.079
<v Speaker 1>Okay, we've covered the hardware, the firmware. What about the

569
00:28:12.160 --> 00:28:17.359
<v Speaker 1>invisible part the radio waves? How do devices talk wirelessly

570
00:28:17.519 --> 00:28:18.720
<v Speaker 1>and how is that exploited?

571
00:28:18.960 --> 00:28:21.319
<v Speaker 2>Ah? The radio communications? Yeah, this is often a really

572
00:28:21.359 --> 00:28:24.839
<v Speaker 2>fruitful area for finding vulnerabilities, partly because it's less understood

573
00:28:24.880 --> 00:28:27.200
<v Speaker 2>by many developers and it's literally invisible.

574
00:28:27.359 --> 00:28:30.720
<v Speaker 1>So how do security researchers see these invisible signals?

575
00:28:30.839 --> 00:28:34.559
<v Speaker 2>The key technology here is software defined radio or SDR.

576
00:28:34.880 --> 00:28:36.559
<v Speaker 1>SDR. What's the basic idea?

577
00:28:36.680 --> 00:28:40.359
<v Speaker 2>Instead of needing dedicated physical hardware for every different type

578
00:28:40.359 --> 00:28:43.599
<v Speaker 2>of radio signal like an FM radio, a Wi Fi card,

579
00:28:43.640 --> 00:28:48.319
<v Speaker 2>a Bluetooth chip, SDR lets you do most of the processing, receiving, transmitting,

580
00:28:48.359 --> 00:28:53.200
<v Speaker 2>demodulating in software used relatively cheap, flexible radio hardware connected

581
00:28:53.200 --> 00:28:57.119
<v Speaker 2>to your computer, and then powerful software handles the specifics

582
00:28:57.160 --> 00:28:58.799
<v Speaker 2>of the radio protocol you're interested in.

583
00:28:59.000 --> 00:29:01.240
<v Speaker 1>So one piece of hardware can act like many different

584
00:29:01.319 --> 00:29:02.440
<v Speaker 1>radios exactly.

585
00:29:02.680 --> 00:29:05.480
<v Speaker 2>It gives you incredible flexibility. For a basic lab, you

586
00:29:05.559 --> 00:29:08.519
<v Speaker 2>might use Ubuntu Linux hardware. Why is something like the

587
00:29:08.640 --> 00:29:12.240
<v Speaker 2>RTL SDR dongle is super cheap maybe twenty dollars great

588
00:29:12.319 --> 00:29:16.519
<v Speaker 2>for receiving signals. For transmitting and receiving over a wider range,

589
00:29:16.759 --> 00:29:20.079
<v Speaker 2>the hack RF is popular, though more expensive. Then you

590
00:29:20.160 --> 00:29:24.359
<v Speaker 2>use software like GQRX for visualizing signals, GNU Radio for

591
00:29:24.400 --> 00:29:28.359
<v Speaker 2>complex processing, and various command line tools specific to your hardware.

592
00:29:28.400 --> 00:29:30.200
<v Speaker 1>Okay, so you have the gear, how do you figure

593
00:29:30.200 --> 00:29:32.160
<v Speaker 1>out what frequency a target device is?

594
00:29:32.240 --> 00:29:35.920
<v Speaker 2>Even using good question? Sometimes it's easy. Open up a

595
00:29:35.960 --> 00:29:38.599
<v Speaker 2>simple device like a garage door keyfob, and you might

596
00:29:38.680 --> 00:29:41.519
<v Speaker 2>literally see the frequency like four hundred and thirty three megahertz,

597
00:29:41.680 --> 00:29:43.039
<v Speaker 2>print it on a component called.

598
00:29:42.880 --> 00:29:45.200
<v Speaker 1>An oscillator, look inside the hardware right.

599
00:29:45.359 --> 00:29:48.640
<v Speaker 2>Or as we discussed, use the SCCID. Look up a

600
00:29:48.680 --> 00:29:51.799
<v Speaker 2>device like a wireless weather station on SECSID dot io

601
00:29:52.400 --> 00:29:54.799
<v Speaker 2>using its ID, and the public filings will often tell

602
00:29:54.799 --> 00:29:57.400
<v Speaker 2>you the exact operating frequency, say four hundred and thirty

603
00:29:57.440 --> 00:30:00.480
<v Speaker 2>three point nine two mable hertz using public infogas YEP,

604
00:30:00.759 --> 00:30:03.480
<v Speaker 2>and then you use your SDR software like GQRX to

605
00:30:03.559 --> 00:30:06.119
<v Speaker 2>confirm it. You tune near that frequency and look for

606
00:30:06.200 --> 00:30:09.279
<v Speaker 2>spikes in the spectrum display or signals in the waterfall

607
00:30:09.359 --> 00:30:12.119
<v Speaker 2>view that appear when the device transmits. That lets you

608
00:30:12.160 --> 00:30:14.759
<v Speaker 2>pinpoint the exact frequency like maybe four hundred and thirty

609
00:30:14.799 --> 00:30:17.680
<v Speaker 2>three point eighty nine seven mitlhertz for that keyfob.

610
00:30:17.880 --> 00:30:20.279
<v Speaker 1>So you've found the frequency, you can see the signal.

611
00:30:21.079 --> 00:30:22.759
<v Speaker 1>How do you understand what it's saying? How do you

612
00:30:22.799 --> 00:30:23.599
<v Speaker 1>decode the data?

613
00:30:23.920 --> 00:30:27.240
<v Speaker 2>It depends on the complexity For many simple devices keyfobs,

614
00:30:27.240 --> 00:30:30.240
<v Speaker 2>weather sensors, high pressure monitors. There's an amazing tool called

615
00:30:30.319 --> 00:30:33.119
<v Speaker 2>ARDL four three three. It has built in decoders for

616
00:30:33.240 --> 00:30:35.799
<v Speaker 2>hundreds of common devices. You just run it and when

617
00:30:35.839 --> 00:30:38.039
<v Speaker 2>your keyfob transmits eard L four three three. You might

618
00:30:38.079 --> 00:30:40.519
<v Speaker 2>recognize the signal and just print out the decoded data

619
00:30:40.640 --> 00:30:42.640
<v Speaker 2>like the button code being sent. That sounds easy for

620
00:30:42.680 --> 00:30:44.960
<v Speaker 2>simple things it often is, but for more complex or

621
00:30:45.000 --> 00:30:47.559
<v Speaker 2>unknown signals you need to do more work, often using G.

622
00:30:47.559 --> 00:30:50.160
<v Speaker 1>In your radio, the complex processing software.

623
00:30:50.319 --> 00:30:52.680
<v Speaker 2>Right, you build a flow graph in G in your radio.

624
00:30:53.039 --> 00:30:55.839
<v Speaker 2>You start with an SDR source block to capture the signal.

625
00:30:56.279 --> 00:30:58.480
<v Speaker 2>Then you might add blocks to filter it, convert it,

626
00:30:58.680 --> 00:31:01.759
<v Speaker 2>amplify it. You save into a file. You can then

627
00:31:01.839 --> 00:31:04.720
<v Speaker 2>open that save signal file, maybe a dot wave file

628
00:31:05.119 --> 00:31:06.880
<v Speaker 2>in an audio editor like Audacity.

629
00:31:07.000 --> 00:31:09.880
<v Speaker 1>Audacity for radio signals.

630
00:31:09.960 --> 00:31:12.240
<v Speaker 2>Yes, If you record the signal's amplitude, you can often

631
00:31:12.319 --> 00:31:16.720
<v Speaker 2>visually analyze the waveform Inaudacity. You look for patterns is

632
00:31:16.720 --> 00:31:20.119
<v Speaker 2>it on off keying okay, where pulses represent data or

633
00:31:20.240 --> 00:31:23.880
<v Speaker 2>frequency shift king FSK for simple okay, like from that

634
00:31:23.920 --> 00:31:26.880
<v Speaker 2>weather station. You might see short pulses for digital zeros

635
00:31:26.920 --> 00:31:29.759
<v Speaker 2>and longer pulses for ones. You can literally just measure

636
00:31:29.799 --> 00:31:33.039
<v Speaker 2>the pulse widths and manually decode the binary data packet.

637
00:31:33.119 --> 00:31:36.880
<v Speaker 1>Wow. Manual decoding that reveals the actual data.

638
00:31:36.960 --> 00:31:39.680
<v Speaker 2>Yep. You might decode a packet containing the station's ID

639
00:31:39.880 --> 00:31:42.160
<v Speaker 2>the temperature, humidity, maybe a checksum.

640
00:31:42.240 --> 00:31:44.880
<v Speaker 1>Okay, decoding is one thing. What about replaying those signals

641
00:31:44.960 --> 00:31:45.880
<v Speaker 1>you mentioned that earlier.

642
00:31:46.000 --> 00:31:49.079
<v Speaker 2>Replay attacks are very powerful, especially if the target device

643
00:31:49.119 --> 00:31:52.279
<v Speaker 2>doesn't have good protection against them, like sequence numbers or

644
00:31:52.319 --> 00:31:54.359
<v Speaker 2>proper checks them CRCs.

645
00:31:53.920 --> 00:31:57.000
<v Speaker 1>Meaning it just accepts any valid looking command A hears.

646
00:31:57.359 --> 00:32:01.200
<v Speaker 2>Pretty much. So you use SDR hardware capable of transmitting

647
00:32:01.279 --> 00:32:03.720
<v Speaker 2>like the hacker F. You first use it to capture

648
00:32:03.759 --> 00:32:06.319
<v Speaker 2>a legitimate radio packet, say the signal scent when you

649
00:32:06.319 --> 00:32:08.839
<v Speaker 2>press the unlocked button on a car FIP, save that

650
00:32:08.880 --> 00:32:11.599
<v Speaker 2>captured signal to a file. Then you just use the

651
00:32:11.640 --> 00:32:14.200
<v Speaker 2>hack RF again to transmit the contents of that file.

652
00:32:14.640 --> 00:32:16.920
<v Speaker 2>If the car doesn't have replay protection, and many older

653
00:32:16.960 --> 00:32:20.160
<v Speaker 2>ones didn't, it will hear that replayed unlocked signal.

654
00:32:19.880 --> 00:32:21.799
<v Speaker 1>And unlocked simple but effective.

655
00:32:22.200 --> 00:32:25.160
<v Speaker 2>Very You can even use simpler hardware like an Arduino

656
00:32:25.240 --> 00:32:27.920
<v Speaker 2>micro controller connected to a cheap four hundred thirty three

657
00:32:27.920 --> 00:32:31.359
<v Speaker 2>milihertz transmitter module for basic replay attacks on some systems.

658
00:32:31.480 --> 00:32:35.400
<v Speaker 1>Okay, let's talk about specific protocols. ZIGB common in smart homes.

659
00:32:35.200 --> 00:32:38.319
<v Speaker 2>Right, very common. It's based on the IEEO two point

660
00:32:38.359 --> 00:32:41.799
<v Speaker 2>one five point four standard operates usually around two point

661
00:32:41.839 --> 00:32:45.400
<v Speaker 2>four gigger heerts globally and forms mesh networks where devices

662
00:32:45.400 --> 00:32:47.640
<v Speaker 2>can relay messages for each other mesh network.

663
00:32:47.720 --> 00:32:49.480
<v Speaker 1>Okay, and how do you attack sigby?

664
00:32:49.839 --> 00:32:53.079
<v Speaker 2>First? You need hardware that can sniff zigby traffic, things

665
00:32:53.119 --> 00:32:56.200
<v Speaker 2>like specially flashed at mil ars, raven USB sticks, or

666
00:32:56.279 --> 00:32:59.279
<v Speaker 2>dedicated devices like the API mode often used with the

667
00:32:59.359 --> 00:33:02.039
<v Speaker 2>killer B frame. Killer be cool name, Yeah, it's a

668
00:33:02.079 --> 00:33:05.200
<v Speaker 2>popular Python framework. You start by using a tool like

669
00:33:05.559 --> 00:33:09.559
<v Speaker 2>zib stumbler from killerb to scan the sixteen possible Zigbee

670
00:33:09.640 --> 00:33:12.799
<v Speaker 2>channels and find which channel your target network is using.

671
00:33:13.039 --> 00:33:14.720
<v Speaker 1>Find the right frequency right.

672
00:33:14.960 --> 00:33:17.400
<v Speaker 2>Once you know the channel, say channel twenty, you use

673
00:33:17.400 --> 00:33:20.160
<v Speaker 2>an tool like zibi dump or zib wire shark which

674
00:33:20.160 --> 00:33:22.839
<v Speaker 2>integrates with wire shark, to just capture all the packets

675
00:33:22.839 --> 00:33:23.559
<v Speaker 2>flying around on that.

676
00:33:23.559 --> 00:33:25.880
<v Speaker 1>Channel and what might you see?

677
00:33:25.920 --> 00:33:29.359
<v Speaker 2>If the communication isn't properly encrypted, which sometimes happens during

678
00:33:29.359 --> 00:33:33.799
<v Speaker 2>initial device pairing or with poorly implemented systems, you might

679
00:33:33.839 --> 00:33:37.599
<v Speaker 2>see sensitive data in clear text. We've seen examples where

680
00:33:37.839 --> 00:33:42.039
<v Speaker 2>sniffing the pairing process of a vulnerable zigbi lock revealed the.

681
00:33:41.960 --> 00:33:44.440
<v Speaker 1>Network key, the master key for that whole network.

682
00:33:44.519 --> 00:33:46.519
<v Speaker 2>Yep, just by passively listening.

683
00:33:46.200 --> 00:33:47.839
<v Speaker 1>And replay attacks. Do they work? On Zigbe?

684
00:33:48.240 --> 00:33:51.359
<v Speaker 2>They can take the Phillips Hughes smart hub example. Again,

685
00:33:52.640 --> 00:33:55.720
<v Speaker 2>using specialized Zigbie tools, researchers were able to capture the

686
00:33:55.759 --> 00:33:57.960
<v Speaker 2>commands sent from the mobile app to change a light

687
00:33:57.960 --> 00:34:01.240
<v Speaker 2>bulb's color. Because the system it didn't properly check if

688
00:34:01.240 --> 00:34:04.039
<v Speaker 2>the command was fresh or unique. They could simply replay

689
00:34:04.039 --> 00:34:06.720
<v Speaker 2>that captured packet later and the bulb would change color

690
00:34:06.759 --> 00:34:09.519
<v Speaker 2>again without any reauthentication needed from the app.

691
00:34:09.679 --> 00:34:13.519
<v Speaker 1>Control without credentials, just by replaying old messages exactly. Okay,

692
00:34:13.599 --> 00:34:18.559
<v Speaker 1>last Radio one Bluetooth Low Energy or BLE that's everywhere now,

693
00:34:18.679 --> 00:34:20.920
<v Speaker 1>fitness trackers, headphones, everywhere.

694
00:34:21.280 --> 00:34:24.639
<v Speaker 2>Its big advantages are low power use and simplicity, making

695
00:34:24.639 --> 00:34:27.920
<v Speaker 2>it ideal for battery powered gadgets. It's used in healthcare,

696
00:34:28.000 --> 00:34:30.840
<v Speaker 2>smart homes, wearables, tons of applications.

697
00:34:30.920 --> 00:34:31.960
<v Speaker 1>How does it work? Briefly?

698
00:34:32.320 --> 00:34:35.679
<v Speaker 2>BLE devices advertise their presence when you connect. They expose

699
00:34:35.719 --> 00:34:39.559
<v Speaker 2>things called services and characteristics. Think of services as categories

700
00:34:39.559 --> 00:34:42.639
<v Speaker 2>of function like heart rate or battery level, and characteristics

701
00:34:42.679 --> 00:34:45.519
<v Speaker 2>as the actual data points or controls within those services,

702
00:34:45.840 --> 00:34:48.480
<v Speaker 2>like the heart rate value or a command to turn

703
00:34:48.559 --> 00:34:53.320
<v Speaker 2>something on off. These are identified by unis numbers called UUIDs.

704
00:34:53.519 --> 00:34:56.679
<v Speaker 1>So interacting with the BLE device means reading or writing

705
00:34:56.719 --> 00:34:58.519
<v Speaker 1>these characteristics pretty much.

706
00:34:59.159 --> 00:35:02.440
<v Speaker 2>First, you need a BLE dongle on your computer. Then

707
00:35:02.480 --> 00:35:05.280
<v Speaker 2>you use tools like h tool s scan on Linux

708
00:35:05.599 --> 00:35:09.039
<v Speaker 2>to scan for nearby BLE devices. You'll see their names

709
00:35:09.079 --> 00:35:13.280
<v Speaker 2>and MTh addresses BDA d DR find your target right.

710
00:35:13.960 --> 00:35:15.880
<v Speaker 2>Then you use a tool like gad tool to connect

711
00:35:15.880 --> 00:35:18.880
<v Speaker 2>to the device using its address. Once connected, you can

712
00:35:18.960 --> 00:35:21.840
<v Speaker 2>use commands like primary to list its services and char

713
00:35:21.960 --> 00:35:25.440
<v Speaker 2>desk to list the characteristics within those services along with

714
00:35:25.480 --> 00:35:27.840
<v Speaker 2>their unique handles short addresses.

715
00:35:27.360 --> 00:35:28.519
<v Speaker 1>And then you manipulate them.

716
00:35:28.639 --> 00:35:31.000
<v Speaker 2>Yep, you can read the current value of a characteristic

717
00:35:31.079 --> 00:35:34.519
<v Speaker 2>using shar red and and its handle number, or more interestingly,

718
00:35:34.559 --> 00:35:36.719
<v Speaker 2>you can write a new value using char rate rec

719
00:35:37.159 --> 00:35:39.920
<v Speaker 2>the handle number and the new value in hexdesimal.

720
00:35:40.079 --> 00:35:40.960
<v Speaker 1>Give me an example.

721
00:35:41.079 --> 00:35:44.719
<v Speaker 2>Okay, say you have a simple BLEI tag tracker that

722
00:35:44.880 --> 00:35:47.519
<v Speaker 2>beeps if you get too far from your phone. Maybe

723
00:35:47.519 --> 00:35:51.440
<v Speaker 2>it disconnects too easily. You might find a characteristic related

724
00:35:51.480 --> 00:35:54.760
<v Speaker 2>to connection parameters. You read its current value, then write

725
00:35:54.760 --> 00:35:57.199
<v Speaker 2>a new value to try and keep it connected longer.

726
00:35:57.760 --> 00:36:01.079
<v Speaker 2>Or on a proximity beacon might be an alert level

727
00:36:01.159 --> 00:36:04.599
<v Speaker 2>characteristic standard ui D zero by two AO six six.

728
00:36:05.159 --> 00:36:07.760
<v Speaker 2>You could write the value ero one to its handle

729
00:36:07.880 --> 00:36:10.719
<v Speaker 2>to make the beacon start buzzing, or two to make

730
00:36:10.719 --> 00:36:14.079
<v Speaker 2>it buzz louder. You're directly controlling the device by writing

731
00:36:14.079 --> 00:36:15.159
<v Speaker 2>to these characteristics.

732
00:36:15.199 --> 00:36:18.639
<v Speaker 1>That seems quite powerful. What about sniffing and replaying.

733
00:36:18.280 --> 00:36:21.880
<v Speaker 2>BLE also possible? You need specialized hardware for reliable sniffing,

734
00:36:22.039 --> 00:36:23.239
<v Speaker 2>like the ubertooth.

735
00:36:22.800 --> 00:36:24.880
<v Speaker 1>One ubertooth another cool name.

736
00:36:25.000 --> 00:36:28.119
<v Speaker 2>Yeah, you run uberto buttlef to follow connections from a

737
00:36:28.119 --> 00:36:31.880
<v Speaker 2>specific device address and dump the captured packets to a PCC.

738
00:36:31.679 --> 00:36:33.599
<v Speaker 1>File and analyze that file exactly.

739
00:36:33.639 --> 00:36:36.119
<v Speaker 2>Open it. In wire shark, you can filter for BLE

740
00:36:36.360 --> 00:36:40.280
<v Speaker 2>attribute protocol att packets which contain the read write requests

741
00:36:40.280 --> 00:36:42.840
<v Speaker 2>for characteristics. You can see the handles being accessed and

742
00:36:42.880 --> 00:36:44.840
<v Speaker 2>the data values being exchanged.

743
00:36:44.400 --> 00:36:46.639
<v Speaker 1>So you could see the exact hex value sent to

744
00:36:46.679 --> 00:36:48.679
<v Speaker 1>turn a smart light red precisely.

745
00:36:49.360 --> 00:36:52.280
<v Speaker 2>Wider shark would show you the right request packet, the

746
00:36:52.320 --> 00:36:55.400
<v Speaker 2>handle for the color characteristic, and the RGB values being

747
00:36:55.480 --> 00:36:58.119
<v Speaker 2>sent oug fs zero zero zero for.

748
00:36:58.079 --> 00:37:00.719
<v Speaker 1>Red, and then you could just replay that value yourself.

749
00:37:00.840 --> 00:37:03.280
<v Speaker 2>Yep, go back to gat tool, connect to the light

750
00:37:03.559 --> 00:37:06.519
<v Speaker 2>and use charwright rec with the correct handle and that

751
00:37:06.719 --> 00:37:09.760
<v Speaker 2>ff zero zero zero value and the light should turn red.

752
00:37:10.480 --> 00:37:13.760
<v Speaker 2>You've replicated the command without needing the original app. There

753
00:37:13.760 --> 00:37:16.679
<v Speaker 2>are even guy tools like BTL Juice that try to

754
00:37:16.760 --> 00:37:19.360
<v Speaker 2>automate this sniffing and replaying in real time.

755
00:37:19.639 --> 00:37:22.639
<v Speaker 1>So across all these radio protocols, the themes seem to

756
00:37:22.639 --> 00:37:27.519
<v Speaker 1>be sniffing unencrypted data, finding wheak keys, and exploiting replay vulnerabilities.

757
00:37:27.559 --> 00:37:29.760
<v Speaker 2>Those are definitely some of the most common attack vectors

758
00:37:29.760 --> 00:37:30.599
<v Speaker 2>in the radio space.

759
00:37:30.639 --> 00:37:33.960
<v Speaker 1>For IoT Wow, we've covered a lot of ground from

760
00:37:34.000 --> 00:37:37.400
<v Speaker 1>the very beginnings of IoT and why it grew so insecurely.

761
00:37:37.119 --> 00:37:40.360
<v Speaker 2>Right the wild West phase and the lack of initial oversight.

762
00:37:40.039 --> 00:37:43.239
<v Speaker 1>To looking at specific sometimes scary hacks like the jeep

763
00:37:43.480 --> 00:37:44.440
<v Speaker 1>or the insulin pump.

764
00:37:44.519 --> 00:37:46.400
<v Speaker 2>Learning from those past mistakes is crucial.

765
00:37:46.599 --> 00:37:50.840
<v Speaker 1>Then digging into the root causes fragmentation, developer awareness, supply.

766
00:37:50.599 --> 00:37:54.079
<v Speaker 2>Chains, understanding the why behind the vulnerabilities, and.

767
00:37:54.039 --> 00:37:57.159
<v Speaker 1>Then we got into the actual techniques, the pentester's process,

768
00:37:57.360 --> 00:37:59.079
<v Speaker 1>mapping the attack surface.

769
00:37:58.880 --> 00:38:01.360
<v Speaker 2>The importance of that in reconnaissance.

770
00:38:00.960 --> 00:38:04.920
<v Speaker 1>The hardware tear downs, finding those secret ports like yort.

771
00:38:04.760 --> 00:38:08.639
<v Speaker 2>Getting physical with the device often the first step to deep.

772
00:38:08.400 --> 00:38:12.280
<v Speaker 1>Access, exploiting it two C and SPI to grab data

773
00:38:12.400 --> 00:38:14.639
<v Speaker 1>or even the entire firmware.

774
00:38:14.280 --> 00:38:16.440
<v Speaker 2>Speaking of those low level hardware languages.

775
00:38:16.519 --> 00:38:19.800
<v Speaker 1>Then diving deep into that firmware, extracting it, finding secrets,

776
00:38:19.840 --> 00:38:21.920
<v Speaker 1>emulating it, even backdooring.

777
00:38:21.480 --> 00:38:23.559
<v Speaker 2>It, analyzing the device's brain.

778
00:38:23.599 --> 00:38:27.199
<v Speaker 1>And finally exploring the invisible world of radio waves with

779
00:38:27.480 --> 00:38:32.440
<v Speaker 1>SDR decoding signals, replaying commands over zigbie and ble.

780
00:38:32.599 --> 00:38:35.880
<v Speaker 2>Listening to the airwaves often a treasure trove of flaws.

781
00:38:36.119 --> 00:38:38.840
<v Speaker 2>It's been quite a journey through the layers of IoT security,

782
00:38:39.159 --> 00:38:41.239
<v Speaker 2>and hopefully this deep dive gives you a much more

783
00:38:41.280 --> 00:38:44.239
<v Speaker 2>solid grasp of why these devices can be risky and

784
00:38:44.320 --> 00:38:48.000
<v Speaker 2>the clever, sometimes complex ways these risks are uncovered and exploited.

785
00:38:48.159 --> 00:38:50.519
<v Speaker 2>We wanted to make this complex field feel a bit

786
00:38:50.559 --> 00:38:51.280
<v Speaker 2>more accessible.

787
00:38:51.519 --> 00:38:55.119
<v Speaker 1>Absolutely, you now have a much clearer picture of what's

788
00:38:55.119 --> 00:38:57.840
<v Speaker 1>going on under the hood of all those smart devices

789
00:38:57.880 --> 00:39:01.119
<v Speaker 1>you interact with every single day. And this knowledge isn't

790
00:39:01.119 --> 00:39:03.679
<v Speaker 1>just for the tech experts, right, It's really about being

791
00:39:03.719 --> 00:39:07.840
<v Speaker 1>a smarter, more critical consumer in this super connected world we.

792
00:39:07.880 --> 00:39:10.559
<v Speaker 2>Live in now, exactly, and maybe it leads you with

793
00:39:10.599 --> 00:39:13.800
<v Speaker 2>the final thought to consider what other devices in your life.

794
00:39:13.880 --> 00:39:17.480
<v Speaker 2>Things that seem totally ordinary or harmless might have surprising

795
00:39:17.599 --> 00:39:20.679
<v Speaker 2>hidden layers or vulnerabilities, just waiting for someone to take

796
00:39:20.679 --> 00:39:23.280
<v Speaker 2>a deep dive, or for a flaw to be found.