1
00:00:17,820 --> 00:00:21,280
All right, and welcome back, everybody.

2
00:00:21,280 --> 00:00:24,360
We have another great speaker here today.

3
00:00:24,360 --> 00:00:28,300
We've got Eyal Iqin here to talk about light bulb security.

4
00:00:28,300 --> 00:00:29,400
How's it going, Eyal?

5
00:00:30,120 --> 00:00:31,260
Fine, how are you?

6
00:00:31,260 --> 00:00:32,340
I'm doing okay.

7
00:00:32,340 --> 00:00:35,380
We also have my co-goon here, Siget.

8
00:00:35,380 --> 00:00:36,700
Hey, Siget, how's it going?

9
00:00:40,740 --> 00:00:51,880
So, Eyal, can you kind of just take a minute and maybe give like a brief introduction of yourself and the presentation that you gave that people can go watch on DEF CON?

10
00:00:53,620 --> 00:00:54,640
Yes.

11
00:00:54,640 --> 00:00:57,200
So, hi, I'm Eyal.

12
00:00:57,200 --> 00:00:59,360
I'm a vulnerability researcher.

13
00:00:59,360 --> 00:01:04,900
I usually focus on embedded devices and network protocols.

14
00:01:05,060 --> 00:01:13,740
And this is a classic research in which I combine them both together to hack some, in this case, smart device.

15
00:01:14,800 --> 00:01:32,700
Essentially, in our research, we continued the previous research by two great researchers, Eyal Ronen and Colin O'Flynn, and they showed how they can take over a smart light bulb and propagate from one light bulb to the other.

16
00:01:33,060 --> 00:01:37,680
And our goal in this research was to take it one step further.

17
00:01:37,740 --> 00:01:44,140
We wanted to take over a light bulb and then from the light bulb take over the smart controller.

18
00:01:44,400 --> 00:01:51,420
And the controller is connected to both the radio network, the ZigBee network, and to the regular computer network.

19
00:01:51,460 --> 00:01:57,400
So, we could manage our smart light bulbs from our mobile app, for example.

20
00:01:57,980 --> 00:02:11,100
This basically means that using a malicious light bulb or an antenna, we could take over the controller and then infiltrate the network and attack computers inside it.

21
00:02:11,100 --> 00:02:18,720
So, we only need a radio antenna and we can infiltrate your home or your office network.

22
00:02:18,780 --> 00:02:22,540
So, that was the goal and this is what we demonstrated.

23
00:02:22,680 --> 00:02:24,300
That's excellent.

24
00:02:24,320 --> 00:02:25,620
All right.

25
00:02:26,200 --> 00:02:36,440
So, I know in your presentation, you kind of mentioned a whole bunch of the people's research that you based yours off of.

26
00:02:36,520 --> 00:02:39,240
What got you interested in this kind of thing?

27
00:02:39,240 --> 00:02:47,900
What made you want to look into trying to take things one step further from what the other research that previous people did?

28
00:02:48,960 --> 00:02:49,580
Okay.

29
00:02:49,580 --> 00:02:51,240
So, it was quite simple.

30
00:02:51,340 --> 00:02:54,760
One of the researchers, Eyal Ronen, is an old colleague of mine.

31
00:02:54,760 --> 00:03:03,800
And when he started working on his initial research roughly four years ago, it was the first time I actually heard of smart light bulbs.

32
00:03:04,000 --> 00:03:14,760
And I really didn't know why people need smart light bulbs because I really only need the light when I'm physically in the room and I'm physically capable of toggling on and off the switch.

33
00:03:14,940 --> 00:03:20,640
So, I don't really know why I need an app in order to control the light in the room that I'm currently in.

34
00:03:21,300 --> 00:03:26,660
And I figured out that smart light bulbs won't be a real thing.

35
00:03:26,660 --> 00:03:31,720
People won't buy it and forgot about it and continued on with my life.

36
00:03:32,120 --> 00:03:36,240
But it turns out that people actually buy smart lighting solutions.

37
00:03:36,240 --> 00:03:41,240
It turns out a lot of people specifically in the UK use it.

38
00:03:41,240 --> 00:03:44,340
It's not so popular here in Israel.

39
00:03:45,080 --> 00:04:00,100
So, Eyal Ronen talked with me again and he said, we have an opportunity to continue on our research because we had an additional task that we couldn't complete in our research.

40
00:04:00,260 --> 00:04:14,900
And since it turns out that people actually use smart light bulbs and in previous DEF CON talks, we infiltrated the network using a fax machine, it turns out that it could be interesting to do that over the radio as well, over ZigBee.

41
00:04:14,900 --> 00:04:16,740
So, this was the goal.

42
00:04:16,740 --> 00:04:24,400
We collaborated with the previous research team to get their equipment and knowledge from their results.

43
00:04:24,640 --> 00:04:26,700
And then we started on our way.

44
00:04:26,900 --> 00:04:27,840
Awesome.

45
00:04:27,840 --> 00:04:30,020
That's all great stuff.

46
00:04:30,120 --> 00:04:34,000
So, again, do we have any questions coming in yet or did you have any?

47
00:04:36,710 --> 00:04:39,590
Not sure if he's hearing me at all over there.

48
00:04:39,590 --> 00:04:40,250
Okay.

49
00:04:40,790 --> 00:04:42,370
Go for it.

50
00:04:43,070 --> 00:04:50,510
No, there's a comment that says, I hope you got a bounty for showing that the weren't completely implemented.

51
00:04:52,130 --> 00:05:00,210
The second part of the patch that you tested, right?

52
00:05:00,210 --> 00:05:01,230
Yeah.

53
00:05:01,290 --> 00:05:04,030
We didn't get any bounty.

54
00:05:04,030 --> 00:05:06,910
We usually don't get any bounty.

55
00:05:07,310 --> 00:05:16,210
I never worked on an embedded research which we received any bounty on any vulnerability whatsoever.

56
00:05:17,190 --> 00:05:28,870
Usually even when we report the vulnerabilities, they are only partially fixed or only the crucial vulnerabilities are actually patched.

57
00:05:28,870 --> 00:05:40,730
So, for example, our vulnerability was that we were able to show that in previous versions there were arrays which weren't parsed correctly.

58
00:05:40,730 --> 00:05:43,470
And in newer versions, they migrated the strings.

59
00:05:43,470 --> 00:05:48,350
But behind the scenes, we're still using them as arrays with the same vulnerability.

60
00:05:48,590 --> 00:06:04,930
So, the patch was to check the sizes of the arrays and handle them correctly instead of treating them as strings because strings are handled correctly and we only can send strings over the radio.

61
00:06:04,930 --> 00:06:11,750
So, there's no reason to treat them internally as arrays just because someone did it three years ago and that's the code.

62
00:06:11,750 --> 00:06:21,650
But it's harder to fix it on a big design issue than just adding an if in the code and that's it.

63
00:06:21,790 --> 00:06:26,590
So, one of the questions that we see coming in from looks like Jiska.

64
00:06:26,630 --> 00:06:30,430
Did you get any further with the ZigBee modem itself?

65
00:06:30,430 --> 00:06:32,990
Like, were you able to extract its firmware?

66
00:06:35,690 --> 00:06:37,250
It's a good question.

67
00:06:37,250 --> 00:06:42,250
The problem we had with the ZigBee modem is that the firmware update is encrypted.

68
00:06:43,110 --> 00:06:55,230
And in a previous research, what they did was they had a power analysis attack and they extracted a key and decrypted a firmware update and signed their own firmware update.

69
00:06:55,730 --> 00:07:00,950
But it was only applicable for the firmware to the light bulbs themselves.

70
00:07:00,950 --> 00:07:06,910
It turns out that the modem uses a bit different cryptographic scheme.

71
00:07:06,910 --> 00:07:18,130
So, we had to, if we wished to get the firmware of the modem, we had to reiterate all of the research that the previous research team did.

72
00:07:18,130 --> 00:07:21,650
And we didn't have the resources for that at the time.

73
00:07:21,650 --> 00:07:27,470
So, we tried to live with it as a black box and we managed.

74
00:07:28,290 --> 00:07:33,450
It could be interesting to look on it because it's more advanced than the light bulb itself.

75
00:07:33,450 --> 00:07:36,870
It does more functionality.

76
00:07:37,250 --> 00:07:40,750
But no, we don't have the firmware, sadly.

77
00:07:41,030 --> 00:07:41,830
Okay.

78
00:07:41,850 --> 00:07:55,710
Yeah, I think in your presentation, you mentioned that previously, before your research, it was kind of thought the worst things that you could do was turn all the light bulbs on or turn all the light bulbs off or flicker them or anything like that.

79
00:07:55,710 --> 00:08:04,750
So now, based on the research that you did, what do you see as kind of a worst case scenario if somebody wanted to do bad things with your research?

80
00:08:05,850 --> 00:08:17,590
The classic scenario we thought about is either a neighbor attacking your network or someone parking a large van across the street and deploying an attack.

81
00:08:17,730 --> 00:08:25,650
And then we can easily hijack a given light bulb and convince it to connect to our network.

82
00:08:25,710 --> 00:08:34,170
And then, as you saw in the demo, if we turn off the light bulb, you think that it's broken and you just toss it away.

83
00:08:34,510 --> 00:08:41,110
And instead, we change the color so you'll know that something is wrong with your light bulb and try to reset it.

84
00:08:41,110 --> 00:08:43,210
But there's no reset button.

85
00:08:43,410 --> 00:08:45,670
There's no buttons at all to the light bulb.

86
00:08:45,670 --> 00:08:52,450
So the only way to reset the light bulb is to delete it from the app and then search for new light bulbs.

87
00:08:52,630 --> 00:08:57,950
And when you search for new light bulbs, we can actually attack your controller and infiltrate the network.

88
00:08:57,950 --> 00:09:04,330
So once we take over the controller, we are inside your home network or your office network.

89
00:09:04,330 --> 00:09:09,410
We can attack whichever computer we wish.

90
00:09:09,410 --> 00:09:11,350
We can sniff the traffic.

91
00:09:11,350 --> 00:09:20,350
And if inside your own network you use HTTP instead of HTTPS, we can sniff all of your traffic.

92
00:09:20,350 --> 00:09:25,450
And essentially, no one will notice an intruder on the bridge.

93
00:09:25,450 --> 00:09:28,610
You don't have an antivirus on your bridge.

94
00:09:28,610 --> 00:09:30,650
You don't have any security solution on it.

95
00:09:30,650 --> 00:09:37,010
So we can have a persistent foothold inside your network and attack additional computers.

96
00:09:37,010 --> 00:09:41,850
And just from being near your network with an antenna for five minutes.

97
00:09:41,850 --> 00:09:42,310
Wow.

98
00:09:42,310 --> 00:09:50,190
So knowing what you know now from this exploit, what would you suggest to the makers of IoT devices?

99
00:09:52,550 --> 00:10:00,190
Specifically in this case, there were some security mitigations in place, which is sadly quite rare.

100
00:10:00,190 --> 00:10:02,110
Usually we get none.

101
00:10:02,850 --> 00:10:13,750
And still, although there were some security mitigations, we're still able to exploit the vulnerability because there weren't enough mitigations.

102
00:10:13,750 --> 00:10:22,790
And actually, after our research, we looked again on the heap implementation that was used.

103
00:10:22,930 --> 00:10:36,470
And it was really weird for us that there were some security mitigations, but because the vendors didn't compile their own binary correctly, we were able to bypass the mitigations.

104
00:10:36,470 --> 00:10:44,190
Because it turns out that if you don't have security on by default, the vendor won't compile correctly their firmware.

105
00:10:44,190 --> 00:10:49,630
And they won't get anything because on their compiler, it's off by default.

106
00:10:49,630 --> 00:10:56,130
So in our team, we designed a new security mitigation called Safe Linking.

107
00:10:56,130 --> 00:11:09,470
And we integrated that into both glibc and uclibc-ng so that it will be a new security mitigation in popular malloc implementations.

108
00:11:09,890 --> 00:11:12,070
And it's on by default.

109
00:11:12,130 --> 00:11:19,050
So just this week, glibc introduced a new version that includes Safe Linking.

110
00:11:19,050 --> 00:11:23,830
And uclibc already have versions with Safe Linking.

111
00:11:23,830 --> 00:11:27,490
And this security mitigation would have blocked our attack.

112
00:11:27,490 --> 00:11:33,170
It would have demanded us to have an additional infleek vulnerability, which we couldn't find.

113
00:11:33,830 --> 00:11:42,750
So nowadays, vendors just need to use the most updated versions of libraries that they use.

114
00:11:42,750 --> 00:11:55,890
The most updated Linux version, glibc or uclibc version, and preferably even a good compiler with a good toolchain to actually compile with security mitigation.

115
00:11:55,890 --> 00:12:02,250
But just updating your libc implementation will be a huge step forward.

116
00:12:02,350 --> 00:12:03,170
Excellent.

117
00:12:03,630 --> 00:12:11,370
Segev, are you seeing any other questions for him coming through the Discord channel at track one live QA?

118
00:12:11,810 --> 00:12:13,150
So we have one.

119
00:12:13,370 --> 00:12:18,510
So your discovery was a modern firmware security problem, or just a ZigBee protocol issue?

120
00:12:20,710 --> 00:12:27,490
It turns out that ZigBee is complex, which wasn't a big surprise.

121
00:12:27,490 --> 00:12:33,630
But the vulnerability itself was an implementation vulnerability specific to that product.

122
00:12:33,630 --> 00:12:39,770
So Philips, now Signify, had an implementation vulnerability over the years.

123
00:12:39,770 --> 00:12:42,850
It changed a bit over the firmware versions.

124
00:12:42,850 --> 00:12:47,050
But essentially, it was an implementation vulnerability on their side.

125
00:12:47,050 --> 00:12:49,970
It wasn't a vulnerability on ZigBee.

126
00:12:51,230 --> 00:13:00,010
That said, ZigBee defines data types with variable lengths that should be received over the network.

127
00:13:00,010 --> 00:13:09,310
And usually, embedded devices and embedded developers are not that good with handling variable-sized objects.

128
00:13:09,970 --> 00:13:24,470
Although there was no vulnerability in ZigBee, but only the implementation, I can guess that if five developers will have to implement this model, at least two of them will get it wrong.

129
00:13:24,570 --> 00:13:28,850
So it still should be done correctly.

130
00:13:29,170 --> 00:13:36,010
So have you checked the updated bridge firmware, like if they used more mitigations?

131
00:13:37,410 --> 00:13:43,850
We checked the updated firmware version for the patch, so we would know how did they actually fix it.

132
00:13:43,870 --> 00:13:48,450
And to check that they fixed it correctly, so we could continue on with the publication.

133
00:13:50,250 --> 00:13:55,090
We only saw a small patch, as I said earlier, just an additional lift check.

134
00:13:55,090 --> 00:14:00,890
We didn't notice any change in the compilation or anything of this sort.

135
00:14:01,570 --> 00:14:14,170
If they are hearing this switch, I really urge them to update their libc version and compile to use dynamic addresses instead of static addresses.

136
00:14:14,170 --> 00:14:18,310
This will be a huge step forward in the security of their device.

137
00:14:18,470 --> 00:14:20,070
That's great.

138
00:14:20,290 --> 00:14:23,270
Let's see, what else do we have coming through over there?

139
00:14:23,270 --> 00:14:25,350
Anything else, Sighad?

140
00:14:25,730 --> 00:14:27,370
No, I'll ask a question.

141
00:14:27,370 --> 00:14:34,610
I noticed in your talk, you spoke a lot about your sort of false starts, right?

142
00:14:34,610 --> 00:14:41,110
And you tried this, you tried that, and these didn't work out, and those didn't work out.

143
00:14:41,110 --> 00:14:53,150
And then you also kind of mentioned hitting a wall on the erase issue before you were able to find the second implementation that still contained the vulnerability.

144
00:14:53,810 --> 00:14:54,650
So, two questions.

145
00:14:54,650 --> 00:15:02,810
One was just, you know, what about those false starts did you think were important enough to include in the talk?

146
00:15:02,810 --> 00:15:09,330
And secondly, you know, what got you to the thinking that got you past that wall?

147
00:15:10,270 --> 00:15:10,890
Okay.

148
00:15:10,890 --> 00:15:12,670
So, I started the first one.

149
00:15:13,210 --> 00:15:24,050
Without the false starts, I wouldn't have been able to actually find the vulnerability that eventually I found, and to reliably exploit it.

150
00:15:24,050 --> 00:15:41,690
Because even as in the slides, I didn't even have enough time in the blog post, which was just uploaded, you can see that there was an additional false vulnerability, but there is a vulnerability, but it isn't exploitable.

151
00:15:42,030 --> 00:16:08,210
And even if I wouldn't have encountered this code module, and the treatment of ZigBee addresses and the ZigBee phone book, which initially had a vulnerability, but it wasn't exploitable, I wouldn't have been able to understand where to store the shellcode and how to construct my shellcode and how to use it.

152
00:16:08,210 --> 00:16:22,570
So, every part in this research, even if I didn't eventually find a vulnerability in the specific model that I tried to, I learned a few things about the device and about the memory layout.

153
00:16:22,570 --> 00:16:26,490
And every one of them was important in the overall attack at the end.

154
00:16:26,490 --> 00:16:40,930
So, that was the main reason I decided to talk about all of the steps in the research, even if there were some dead ends, because it gives additional information that we later on use during the exploit.

155
00:16:40,930 --> 00:16:46,670
So, it was important about hitting the wall.

156
00:16:46,770 --> 00:17:05,290
Then, when you start a research with an interesting attack vector, and you're already into it, you got the firmware, it's loaded into your disassembler, you bought a kit with the hardware, you have everything, you really want to find vulnerabilities.

157
00:17:06,550 --> 00:17:12,150
And in most of the projects that I worked on, there are critical vulnerabilities.

158
00:17:12,170 --> 00:17:13,930
We just need to find them.

159
00:17:14,170 --> 00:17:18,170
So, you check one module, it's a dead end.

160
00:17:18,170 --> 00:17:20,810
You go to the other one, it's a dead end.

161
00:17:20,810 --> 00:17:23,410
You go to the third one, it's a dead end.

162
00:17:23,410 --> 00:17:28,370
And then you go back and you check your initial assumptions.

163
00:17:28,370 --> 00:17:34,970
Maybe there is some assumption that we thought about, but it's wrong.

164
00:17:34,970 --> 00:17:37,550
The device might behave differently.

165
00:17:37,930 --> 00:17:45,950
Maybe we skipped a module because it looked well written, but we didn't check it deeply enough.

166
00:17:45,950 --> 00:17:49,610
So, we can go back to that module and test it again.

167
00:17:49,610 --> 00:17:55,570
So, essentially, in a security research, we attack the device in layers.

168
00:17:55,570 --> 00:17:58,550
We want to find the path of least resistance.

169
00:17:58,830 --> 00:18:13,790
And it's really common to reiterate over the same module again and again, because now we want to go deep into that module after we had a shadow look on all of the modules we initially marked.

170
00:18:13,850 --> 00:18:16,640
So, we have a few iterations.

171
00:18:17,270 --> 00:18:22,640
We most of the times we find critical vulnerabilities.

172
00:18:24,200 --> 00:18:31,640
It's not easy to continue on when you get to a dead end and when you get to multiple dead ends.

173
00:18:32,280 --> 00:18:45,880
But you're already into it and you don't want to raise a white flag and surrender and to the research team in the office to laugh about you.

174
00:18:45,980 --> 00:18:47,760
So, you want to continue on.

175
00:18:47,760 --> 00:18:50,980
You want to prove that you actually can break this device.

176
00:18:51,520 --> 00:18:55,020
And it's really important not to never to give up.

177
00:18:56,700 --> 00:19:06,180
That sounds like there might be a little bit of an extra story there about being laughed at in the office, but certainly not one that we can need to talk about today.

178
00:19:08,240 --> 00:19:14,280
Were you ever able to find a way to overcome the 60 second limit in the exploit?

179
00:19:18,100 --> 00:19:20,020
Sadly, no.

180
00:19:22,980 --> 00:19:33,760
Technically, there is a grace period that once the user requested a bridge to search for new light bulbs, we have roughly 60 seconds.

181
00:19:34,180 --> 00:19:37,920
In some experiments, it wasn't exactly 60 seconds.

182
00:19:37,920 --> 00:19:40,160
It looked more like two minutes.

183
00:19:40,160 --> 00:19:44,240
But essentially, there's a timer.

184
00:19:44,240 --> 00:19:50,680
Most probably some thread on the main CPU initiates a timer.

185
00:19:50,680 --> 00:19:57,980
And when the timer expires, a message is sent to the modem and the modem shuts down the communication.

186
00:19:58,020 --> 00:20:09,560
So, unless we starve the thread that is responsible for the timer, the timer will expire and we will be blocked out.

187
00:20:09,560 --> 00:20:12,400
And it is a good security design.

188
00:20:12,400 --> 00:20:21,220
We can't send messages to the bridge unless the user requested a bridge to look for new light bulbs.

189
00:20:21,220 --> 00:20:22,960
So, it is a good design.

190
00:20:22,960 --> 00:20:25,340
It blocks most of the attack vector.

191
00:20:25,580 --> 00:20:29,580
However, there's no reset button for the light bulbs.

192
00:20:29,580 --> 00:20:37,900
And there's no indication of please just pair this light bulb again, according to the addresses of the light bulb.

193
00:20:37,940 --> 00:20:43,720
So, essentially, the design started quite good, but broke somewhere in the middle.

194
00:20:44,460 --> 00:20:52,560
We did find out that if we bombed the controller with multiple messages, we can starve the rest of the threads.

195
00:20:53,160 --> 00:20:56,240
But it has some disadvantages as well.

196
00:20:56,240 --> 00:21:01,900
Because if we starve the rest of the threads, then the watchdog will restart the bridge.

197
00:21:02,280 --> 00:21:05,620
And we mostly don't want that to happen.

198
00:21:06,340 --> 00:21:11,580
So, the 60 seconds is... it is a hard limit.

199
00:21:11,580 --> 00:21:14,400
We can't really do a lot about it.

200
00:21:15,360 --> 00:21:16,400
Excellent.

201
00:21:16,440 --> 00:21:20,940
So, yeah, do we have anything else currently coming through the Discord chat?

202
00:21:20,940 --> 00:21:22,820
Yes, we have a question.

203
00:21:22,820 --> 00:21:28,680
Did you start working on IoT exploitation at Checkpoint, or is this an area you've been working on beforehand?

204
00:21:29,640 --> 00:21:31,620
That's a good question.

205
00:21:31,620 --> 00:21:35,220
It really depends how you define IoT.

206
00:21:35,240 --> 00:21:51,420
If IoT is anything that is not Windows, Linux, or mobile, then I started working on embedded devices practically from my first year on work.

207
00:21:52,480 --> 00:22:10,060
If we rule out network equipment, for example, then actual embedded devices were from after three or four years of work.

208
00:22:10,060 --> 00:22:13,740
So, it wasn't the first device that I encountered.

209
00:22:13,740 --> 00:22:20,360
But I did research embedded devices way before I started working on Checkpoint.

210
00:22:21,680 --> 00:22:23,000
Excellent.

211
00:22:23,140 --> 00:22:28,610
And did you ever think of attempting to brick the other bulbs or possibly the controller?

212
00:22:31,620 --> 00:22:34,240
There is a sad story about that.

213
00:22:34,240 --> 00:22:41,360
Because if you break the device, you also lose your own device.

214
00:22:41,360 --> 00:22:47,740
And then you need to go and purchase a new device and convince some manager to once again buy it.

215
00:22:47,740 --> 00:22:53,180
And then you need to tell the manager, yeah, we need to buy it again, because we bricked the earlier one.

216
00:22:53,360 --> 00:22:56,540
And you can't do that often.

217
00:22:57,400 --> 00:23:01,340
We had that on the research in the previous year.

218
00:23:02,040 --> 00:23:09,180
We presented a DEF CON ransomware on DSLR cameras, and we had to test the patch from the vendor.

219
00:23:09,480 --> 00:23:21,720
But if the patch will work, we'll get locked out from the device, and we won't be able to demonstrate the attack, which we wanted to demonstrate on a live demo.

220
00:23:21,760 --> 00:23:29,760
So, once we noticed that it will be some issue about it, we went to buy an additional camera.

221
00:23:29,900 --> 00:23:33,740
So, if we lose one of them, we still had a backup.

222
00:23:34,000 --> 00:23:39,160
So, it is quite easy to break the devices.

223
00:23:39,420 --> 00:23:45,580
And most of the times, you don't want to do that, because you lose your own research device and you need to buy a new one.

224
00:23:45,580 --> 00:23:51,420
A few years ago, I actually bricked my device on a different research project.

225
00:23:51,680 --> 00:23:57,100
And if you break your device, then people really laugh.

226
00:23:57,240 --> 00:24:03,740
Because, yeah, he bricked his device, we need to buy a new one, and you don't want to be that researcher.

227
00:24:03,860 --> 00:24:06,080
So, you really don't want to break your own device.

228
00:24:06,700 --> 00:24:09,700
Sounds like quite the environment at work that you have there.

229
00:24:10,840 --> 00:24:20,940
So, it seems like a lot of times, a lot of years at DEF CON, you know, the big story comes out about this big thing is insecure, there's going to be these problems.

230
00:24:20,940 --> 00:24:28,600
And you're talking about how that people could get into a home network, or maybe even a business network through a light bulb.

231
00:24:29,240 --> 00:24:34,180
So, what do you think about overall security concerns based on your research?

232
00:24:34,180 --> 00:24:38,140
Is this something that people at large should be really concerned about?

233
00:24:38,140 --> 00:24:42,020
Or is it being handled really well by the manufacturers?

234
00:24:43,500 --> 00:24:48,600
I wouldn't trust the manufacturers at all, specifically in IoT devices.

235
00:24:48,960 --> 00:24:54,380
It doesn't look like security is a top priority in their devices.

236
00:24:54,720 --> 00:25:07,780
If we look specifically on the light bulbs case, you would be more worried about a neighbor hijacking all of my light bulbs and turning them to whichever color they want.

237
00:25:07,780 --> 00:25:14,460
Because they could have done that years ago, even from the conclusions of the previous researchers.

238
00:25:14,620 --> 00:25:19,400
And it's a flaw in ZigBee, you can't fix that.

239
00:25:19,480 --> 00:25:29,100
So, specifically in light bulbs, anyone can hijack your light bulb and steal them to control them from their own network.

240
00:25:29,100 --> 00:25:32,640
And there's nothing really you can do about that.

241
00:25:32,640 --> 00:25:43,880
If you're worried about someone attacking your bridge and infiltrating your network, most probably it won't happen a lot.

242
00:25:44,560 --> 00:25:52,860
We are not releasing our full exploit, and we work quite hard on the exploit, it will be reliable and will work correctly.

243
00:25:54,500 --> 00:26:07,080
If you're a real target and some high authority wants to hijack your network, they could do that.

244
00:26:07,080 --> 00:26:09,860
Will someone do that to your neighbor?

245
00:26:09,860 --> 00:26:11,600
Most probably not.

246
00:26:12,000 --> 00:26:22,580
That said, on the light bulbs, two years ago, we showed you we can infiltrate the network from a fax machine.

247
00:26:22,580 --> 00:26:31,960
And then the attack was easier, more reliable, and I can be in China and still attack your all-in-one printer.

248
00:26:31,960 --> 00:26:36,900
So, that one is more concerning.

249
00:26:38,060 --> 00:26:44,120
And I would worry more about using a fax than using smart light bulbs.

250
00:26:44,120 --> 00:26:45,100
Excellent.

251
00:26:45,640 --> 00:26:49,940
Sighed, how are we doing with that Discord channel there?

252
00:26:49,940 --> 00:26:55,560
Coming up with anything else, or should we kind of start giving him some wrap-up questions?

253
00:26:56,040 --> 00:27:05,520
So, we had one question about, did this research ever give you the kind of insight you started out with on why people want connected light bulbs?

254
00:27:06,300 --> 00:27:07,960
It actually did.

255
00:27:07,960 --> 00:27:13,280
It turns out that smart light bulbs are actually quite cool.

256
00:27:13,440 --> 00:27:23,340
I read about a few people in the north which use the light bulbs and calibrate them to match the season and the clock.

257
00:27:23,360 --> 00:27:33,280
So, they will still get sunrise and sunset, even if they don't actually have that way in the north because of the season.

258
00:27:34,280 --> 00:27:45,680
You have quite a lot of control over the light bulb, both the intensity and the color itself, and you can sync multiple light bulbs to get a scene.

259
00:27:45,880 --> 00:27:48,500
And it is really cool.

260
00:27:48,500 --> 00:28:11,900
It isn't very practical because, for example, if there's a power shutdown, then all of your light bulbs go reset, and then you lose all of your scheme, all of the colors, and all of the intensity, and you get all of the light bulbs go white, go to the maximum lighting,

261
00:28:11,900 --> 00:28:15,740
and it happens quite a lot.

262
00:28:15,740 --> 00:28:26,440
The power has some sort of glitch, and you're not supposed to connect your light bulbs to a backup system or to a UPS or anything of this sort.

263
00:28:26,600 --> 00:28:38,040
So, if you're into the colors of the light bulbs, you need to have pretty good electricity in your city or in your state.

264
00:28:38,040 --> 00:28:41,800
Otherwise, you need to recalibrate your light bulbs again and again.

265
00:28:41,800 --> 00:28:43,800
That's quite annoying.

266
00:28:44,160 --> 00:28:45,620
That's great.

267
00:28:46,040 --> 00:28:52,540
So, what would be your one main takeaway from your research or call to action?

268
00:28:52,540 --> 00:28:55,220
To happen after this?

269
00:28:55,220 --> 00:28:58,910
What should people take away from your research and your presentation?

270
00:28:59,640 --> 00:29:11,880
So, if I have a message to manufacturers, then please compile with security mitigations and use the latest versions of each library.

271
00:29:11,880 --> 00:29:15,400
It really adds a large amount of security.

272
00:29:15,400 --> 00:29:30,500
If it's for researchers, then it turns out that practically any device that you can think of using any protocol will most probably still be vulnerable.

273
00:29:30,500 --> 00:29:39,860
On ZigBee, we have a maximal transmission unit of 127 bytes, and we still reliably exploited the vulnerability.

274
00:29:39,860 --> 00:29:52,960
So, even with really harsh constraints and really esoteric protocols, we can still consistently, year over year, present in DEF CON that we broke an additional device.

275
00:29:52,960 --> 00:29:58,300
So, everything practically could be broken.

276
00:29:58,300 --> 00:30:05,940
And even if you have harsh constraints, you most probably will still be able to exploit the vulnerability once you find it.

277
00:30:06,080 --> 00:30:10,320
So, if you pick a target, don't give up.

278
00:30:10,320 --> 00:30:13,920
Most probably, you could get a win out of your research.

279
00:30:13,920 --> 00:30:17,140
So, just try hard enough.

280
00:30:17,640 --> 00:30:20,880
Let's slide one last question in there for you, from Brief Halo.

281
00:30:20,880 --> 00:30:27,620
What recommendations would you give to someone interested in studying IoT exploitation formally, like at a university?

282
00:30:30,260 --> 00:30:45,040
There are some good courses in several universities, but usually reading write-ups from researchers that published their research, and you read about it, and it was interesting.

283
00:30:45,040 --> 00:30:48,720
Reading the write-ups usually gets you a lot of tips.

284
00:30:48,720 --> 00:31:01,620
So, if you read the publications from Colin O'Flynn, you get a lot of new knowledge about hardware, and how UART works, and how UBIT works, and you can learn a lot from practical write-ups of researchers.

285
00:31:01,920 --> 00:31:07,560
It will be more practical than most of the courses in many universities.

286
00:31:07,820 --> 00:31:08,980
That's great.

287
00:31:08,980 --> 00:31:09,460
All right.

288
00:31:09,460 --> 00:31:10,920
Thank you so much for doing this.

289
00:31:10,920 --> 00:31:13,220
This was a great talk with you.

290
00:31:13,220 --> 00:31:15,380
I really enjoyed your presentation as well.

291
00:31:15,380 --> 00:31:17,440
Thank you so much for doing this.

292
00:31:17,920 --> 00:31:18,780
Thank you.

293
00:31:18,780 --> 00:31:19,400
All right.

294
00:31:19,400 --> 00:31:24,040
Have a good night, and we will be back in about 30 minutes with another speaker.