WEBVTT 00:17.820 --> 00:21.280 All right, and welcome back, everybody. 00:21.280 --> 00:24.360 We have another great speaker here today. 00:24.360 --> 00:28.300 We've got Eyal Iqin here to talk about light bulb security. 00:28.300 --> 00:29.400 How's it going, Eyal? 00:30.120 --> 00:31.260 Fine, how are you? 00:31.260 --> 00:32.340 I'm doing okay. 00:32.340 --> 00:35.380 We also have my co-goon here, Siget. 00:35.380 --> 00:36.700 Hey, Siget, how's it going? 00:40.740 --> 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? 00:53.620 --> 00:54.640 Yes. 00:54.640 --> 00:57.200 So, hi, I'm Eyal. 00:57.200 --> 00:59.360 I'm a vulnerability researcher. 00:59.360 --> 01:04.900 I usually focus on embedded devices and network protocols. 01:05.060 --> 01:13.740 And this is a classic research in which I combine them both together to hack some, in this case, smart device. 01:14.800 --> 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. 01:33.060 --> 01:37.680 And our goal in this research was to take it one step further. 01:37.740 --> 01:44.140 We wanted to take over a light bulb and then from the light bulb take over the smart controller. 01:44.400 --> 01:51.420 And the controller is connected to both the radio network, the ZigBee network, and to the regular computer network. 01:51.460 --> 01:57.400 So, we could manage our smart light bulbs from our mobile app, for example. 01:57.980 --> 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. 02:11.100 --> 02:18.720 So, we only need a radio antenna and we can infiltrate your home or your office network. 02:18.780 --> 02:22.540 So, that was the goal and this is what we demonstrated. 02:22.680 --> 02:24.300 That's excellent. 02:24.320 --> 02:25.620 All right. 02:26.200 --> 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. 02:36.520 --> 02:39.240 What got you interested in this kind of thing? 02:39.240 --> 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? 02:48.960 --> 02:49.580 Okay. 02:49.580 --> 02:51.240 So, it was quite simple. 02:51.340 --> 02:54.760 One of the researchers, Eyal Ronen, is an old colleague of mine. 02:54.760 --> 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. 03:04.000 --> 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. 03:14.940 --> 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. 03:21.300 --> 03:26.660 And I figured out that smart light bulbs won't be a real thing. 03:26.660 --> 03:31.720 People won't buy it and forgot about it and continued on with my life. 03:32.120 --> 03:36.240 But it turns out that people actually buy smart lighting solutions. 03:36.240 --> 03:41.240 It turns out a lot of people specifically in the UK use it. 03:41.240 --> 03:44.340 It's not so popular here in Israel. 03:45.080 --> 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. 04:00.260 --> 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. 04:14.900 --> 04:16.740 So, this was the goal. 04:16.740 --> 04:24.400 We collaborated with the previous research team to get their equipment and knowledge from their results. 04:24.640 --> 04:26.700 And then we started on our way. 04:26.900 --> 04:27.840 Awesome. 04:27.840 --> 04:30.020 That's all great stuff. 04:30.120 --> 04:34.000 So, again, do we have any questions coming in yet or did you have any? 04:36.710 --> 04:39.590 Not sure if he's hearing me at all over there. 04:39.590 --> 04:40.250 Okay. 04:40.790 --> 04:42.370 Go for it. 04:43.070 --> 04:50.510 No, there's a comment that says, I hope you got a bounty for showing that the weren't completely implemented. 04:52.130 --> 05:00.210 The second part of the patch that you tested, right? 05:00.210 --> 05:01.230 Yeah. 05:01.290 --> 05:04.030 We didn't get any bounty. 05:04.030 --> 05:06.910 We usually don't get any bounty. 05:07.310 --> 05:16.210 I never worked on an embedded research which we received any bounty on any vulnerability whatsoever. 05:17.190 --> 05:28.870 Usually even when we report the vulnerabilities, they are only partially fixed or only the crucial vulnerabilities are actually patched. 05:28.870 --> 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. 05:40.730 --> 05:43.470 And in newer versions, they migrated the strings. 05:43.470 --> 05:48.350 But behind the scenes, we're still using them as arrays with the same vulnerability. 05:48.590 --> 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. 06:04.930 --> 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. 06:11.750 --> 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. 06:21.790 --> 06:26.590 So, one of the questions that we see coming in from looks like Jiska. 06:26.630 --> 06:30.430 Did you get any further with the ZigBee modem itself? 06:30.430 --> 06:32.990 Like, were you able to extract its firmware? 06:35.690 --> 06:37.250 It's a good question. 06:37.250 --> 06:42.250 The problem we had with the ZigBee modem is that the firmware update is encrypted. 06:43.110 --> 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. 06:55.730 --> 07:00.950 But it was only applicable for the firmware to the light bulbs themselves. 07:00.950 --> 07:06.910 It turns out that the modem uses a bit different cryptographic scheme. 07:06.910 --> 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. 07:18.130 --> 07:21.650 And we didn't have the resources for that at the time. 07:21.650 --> 07:27.470 So, we tried to live with it as a black box and we managed. 07:28.290 --> 07:33.450 It could be interesting to look on it because it's more advanced than the light bulb itself. 07:33.450 --> 07:36.870 It does more functionality. 07:37.250 --> 07:40.750 But no, we don't have the firmware, sadly. 07:41.030 --> 07:41.830 Okay. 07:41.850 --> 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. 07:55.710 --> 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? 08:05.850 --> 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. 08:17.730 --> 08:25.650 And then we can easily hijack a given light bulb and convince it to connect to our network. 08:25.710 --> 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. 08:34.510 --> 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. 08:41.110 --> 08:43.210 But there's no reset button. 08:43.410 --> 08:45.670 There's no buttons at all to the light bulb. 08:45.670 --> 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. 08:52.630 --> 08:57.950 And when you search for new light bulbs, we can actually attack your controller and infiltrate the network. 08:57.950 --> 09:04.330 So once we take over the controller, we are inside your home network or your office network. 09:04.330 --> 09:09.410 We can attack whichever computer we wish. 09:09.410 --> 09:11.350 We can sniff the traffic. 09:11.350 --> 09:20.350 And if inside your own network you use HTTP instead of HTTPS, we can sniff all of your traffic. 09:20.350 --> 09:25.450 And essentially, no one will notice an intruder on the bridge. 09:25.450 --> 09:28.610 You don't have an antivirus on your bridge. 09:28.610 --> 09:30.650 You don't have any security solution on it. 09:30.650 --> 09:37.010 So we can have a persistent foothold inside your network and attack additional computers. 09:37.010 --> 09:41.850 And just from being near your network with an antenna for five minutes. 09:41.850 --> 09:42.310 Wow. 09:42.310 --> 09:50.190 So knowing what you know now from this exploit, what would you suggest to the makers of IoT devices? 09:52.550 --> 10:00.190 Specifically in this case, there were some security mitigations in place, which is sadly quite rare. 10:00.190 --> 10:02.110 Usually we get none. 10:02.850 --> 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. 10:13.750 --> 10:22.790 And actually, after our research, we looked again on the heap implementation that was used. 10:22.930 --> 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. 10:36.470 --> 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. 10:44.190 --> 10:49.630 And they won't get anything because on their compiler, it's off by default. 10:49.630 --> 10:56.130 So in our team, we designed a new security mitigation called Safe Linking. 10:56.130 --> 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. 11:09.890 --> 11:12.070 And it's on by default. 11:12.130 --> 11:19.050 So just this week, glibc introduced a new version that includes Safe Linking. 11:19.050 --> 11:23.830 And uclibc already have versions with Safe Linking. 11:23.830 --> 11:27.490 And this security mitigation would have blocked our attack. 11:27.490 --> 11:33.170 It would have demanded us to have an additional infleek vulnerability, which we couldn't find. 11:33.830 --> 11:42.750 So nowadays, vendors just need to use the most updated versions of libraries that they use. 11:42.750 --> 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. 11:55.890 --> 12:02.250 But just updating your libc implementation will be a huge step forward. 12:02.350 --> 12:03.170 Excellent. 12:03.630 --> 12:11.370 Segev, are you seeing any other questions for him coming through the Discord channel at track one live QA? 12:11.810 --> 12:13.150 So we have one. 12:13.370 --> 12:18.510 So your discovery was a modern firmware security problem, or just a ZigBee protocol issue? 12:20.710 --> 12:27.490 It turns out that ZigBee is complex, which wasn't a big surprise. 12:27.490 --> 12:33.630 But the vulnerability itself was an implementation vulnerability specific to that product. 12:33.630 --> 12:39.770 So Philips, now Signify, had an implementation vulnerability over the years. 12:39.770 --> 12:42.850 It changed a bit over the firmware versions. 12:42.850 --> 12:47.050 But essentially, it was an implementation vulnerability on their side. 12:47.050 --> 12:49.970 It wasn't a vulnerability on ZigBee. 12:51.230 --> 13:00.010 That said, ZigBee defines data types with variable lengths that should be received over the network. 13:00.010 --> 13:09.310 And usually, embedded devices and embedded developers are not that good with handling variable-sized objects. 13:09.970 --> 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. 13:24.570 --> 13:28.850 So it still should be done correctly. 13:29.170 --> 13:36.010 So have you checked the updated bridge firmware, like if they used more mitigations? 13:37.410 --> 13:43.850 We checked the updated firmware version for the patch, so we would know how did they actually fix it. 13:43.870 --> 13:48.450 And to check that they fixed it correctly, so we could continue on with the publication. 13:50.250 --> 13:55.090 We only saw a small patch, as I said earlier, just an additional lift check. 13:55.090 --> 14:00.890 We didn't notice any change in the compilation or anything of this sort. 14:01.570 --> 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. 14:14.170 --> 14:18.310 This will be a huge step forward in the security of their device. 14:18.470 --> 14:20.070 That's great. 14:20.290 --> 14:23.270 Let's see, what else do we have coming through over there? 14:23.270 --> 14:25.350 Anything else, Sighad? 14:25.730 --> 14:27.370 No, I'll ask a question. 14:27.370 --> 14:34.610 I noticed in your talk, you spoke a lot about your sort of false starts, right? 14:34.610 --> 14:41.110 And you tried this, you tried that, and these didn't work out, and those didn't work out. 14:41.110 --> 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. 14:53.810 --> 14:54.650 So, two questions. 14:54.650 --> 15:02.810 One was just, you know, what about those false starts did you think were important enough to include in the talk? 15:02.810 --> 15:09.330 And secondly, you know, what got you to the thinking that got you past that wall? 15:10.270 --> 15:10.890 Okay. 15:10.890 --> 15:12.670 So, I started the first one. 15:13.210 --> 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. 15:24.050 --> 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. 15:42.030 --> 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. 16:08.210 --> 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. 16:22.570 --> 16:26.490 And every one of them was important in the overall attack at the end. 16:26.490 --> 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. 16:40.930 --> 16:46.670 So, it was important about hitting the wall. 16:46.770 --> 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. 17:06.550 --> 17:12.150 And in most of the projects that I worked on, there are critical vulnerabilities. 17:12.170 --> 17:13.930 We just need to find them. 17:14.170 --> 17:18.170 So, you check one module, it's a dead end. 17:18.170 --> 17:20.810 You go to the other one, it's a dead end. 17:20.810 --> 17:23.410 You go to the third one, it's a dead end. 17:23.410 --> 17:28.370 And then you go back and you check your initial assumptions. 17:28.370 --> 17:34.970 Maybe there is some assumption that we thought about, but it's wrong. 17:34.970 --> 17:37.550 The device might behave differently. 17:37.930 --> 17:45.950 Maybe we skipped a module because it looked well written, but we didn't check it deeply enough. 17:45.950 --> 17:49.610 So, we can go back to that module and test it again. 17:49.610 --> 17:55.570 So, essentially, in a security research, we attack the device in layers. 17:55.570 --> 17:58.550 We want to find the path of least resistance. 17:58.830 --> 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. 18:13.850 --> 18:16.640 So, we have a few iterations. 18:17.270 --> 18:22.640 We most of the times we find critical vulnerabilities. 18:24.200 --> 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. 18:32.280 --> 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. 18:45.980 --> 18:47.760 So, you want to continue on. 18:47.760 --> 18:50.980 You want to prove that you actually can break this device. 18:51.520 --> 18:55.020 And it's really important not to never to give up. 18:56.700 --> 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. 19:08.240 --> 19:14.280 Were you ever able to find a way to overcome the 60 second limit in the exploit? 19:18.100 --> 19:20.020 Sadly, no. 19:22.980 --> 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. 19:34.180 --> 19:37.920 In some experiments, it wasn't exactly 60 seconds. 19:37.920 --> 19:40.160 It looked more like two minutes. 19:40.160 --> 19:44.240 But essentially, there's a timer. 19:44.240 --> 19:50.680 Most probably some thread on the main CPU initiates a timer. 19:50.680 --> 19:57.980 And when the timer expires, a message is sent to the modem and the modem shuts down the communication. 19:58.020 --> 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. 20:09.560 --> 20:12.400 And it is a good security design. 20:12.400 --> 20:21.220 We can't send messages to the bridge unless the user requested a bridge to look for new light bulbs. 20:21.220 --> 20:22.960 So, it is a good design. 20:22.960 --> 20:25.340 It blocks most of the attack vector. 20:25.580 --> 20:29.580 However, there's no reset button for the light bulbs. 20:29.580 --> 20:37.900 And there's no indication of please just pair this light bulb again, according to the addresses of the light bulb. 20:37.940 --> 20:43.720 So, essentially, the design started quite good, but broke somewhere in the middle. 20:44.460 --> 20:52.560 We did find out that if we bombed the controller with multiple messages, we can starve the rest of the threads. 20:53.160 --> 20:56.240 But it has some disadvantages as well. 20:56.240 --> 21:01.900 Because if we starve the rest of the threads, then the watchdog will restart the bridge. 21:02.280 --> 21:05.620 And we mostly don't want that to happen. 21:06.340 --> 21:11.580 So, the 60 seconds is... it is a hard limit. 21:11.580 --> 21:14.400 We can't really do a lot about it. 21:15.360 --> 21:16.400 Excellent. 21:16.440 --> 21:20.940 So, yeah, do we have anything else currently coming through the Discord chat? 21:20.940 --> 21:22.820 Yes, we have a question. 21:22.820 --> 21:28.680 Did you start working on IoT exploitation at Checkpoint, or is this an area you've been working on beforehand? 21:29.640 --> 21:31.620 That's a good question. 21:31.620 --> 21:35.220 It really depends how you define IoT. 21:35.240 --> 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. 21:52.480 --> 22:10.060 If we rule out network equipment, for example, then actual embedded devices were from after three or four years of work. 22:10.060 --> 22:13.740 So, it wasn't the first device that I encountered. 22:13.740 --> 22:20.360 But I did research embedded devices way before I started working on Checkpoint. 22:21.680 --> 22:23.000 Excellent. 22:23.140 --> 22:28.610 And did you ever think of attempting to brick the other bulbs or possibly the controller? 22:31.620 --> 22:34.240 There is a sad story about that. 22:34.240 --> 22:41.360 Because if you break the device, you also lose your own device. 22:41.360 --> 22:47.740 And then you need to go and purchase a new device and convince some manager to once again buy it. 22:47.740 --> 22:53.180 And then you need to tell the manager, yeah, we need to buy it again, because we bricked the earlier one. 22:53.360 --> 22:56.540 And you can't do that often. 22:57.400 --> 23:01.340 We had that on the research in the previous year. 23:02.040 --> 23:09.180 We presented a DEF CON ransomware on DSLR cameras, and we had to test the patch from the vendor. 23:09.480 --> 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. 23:21.760 --> 23:29.760 So, once we noticed that it will be some issue about it, we went to buy an additional camera. 23:29.900 --> 23:33.740 So, if we lose one of them, we still had a backup. 23:34.000 --> 23:39.160 So, it is quite easy to break the devices. 23:39.420 --> 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. 23:45.580 --> 23:51.420 A few years ago, I actually bricked my device on a different research project. 23:51.680 --> 23:57.100 And if you break your device, then people really laugh. 23:57.240 --> 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. 24:03.860 --> 24:06.080 So, you really don't want to break your own device. 24:06.700 --> 24:09.700 Sounds like quite the environment at work that you have there. 24:10.840 --> 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. 24:20.940 --> 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. 24:29.240 --> 24:34.180 So, what do you think about overall security concerns based on your research? 24:34.180 --> 24:38.140 Is this something that people at large should be really concerned about? 24:38.140 --> 24:42.020 Or is it being handled really well by the manufacturers? 24:43.500 --> 24:48.600 I wouldn't trust the manufacturers at all, specifically in IoT devices. 24:48.960 --> 24:54.380 It doesn't look like security is a top priority in their devices. 24:54.720 --> 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. 25:07.780 --> 25:14.460 Because they could have done that years ago, even from the conclusions of the previous researchers. 25:14.620 --> 25:19.400 And it's a flaw in ZigBee, you can't fix that. 25:19.480 --> 25:29.100 So, specifically in light bulbs, anyone can hijack your light bulb and steal them to control them from their own network. 25:29.100 --> 25:32.640 And there's nothing really you can do about that. 25:32.640 --> 25:43.880 If you're worried about someone attacking your bridge and infiltrating your network, most probably it won't happen a lot. 25:44.560 --> 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. 25:54.500 --> 26:07.080 If you're a real target and some high authority wants to hijack your network, they could do that. 26:07.080 --> 26:09.860 Will someone do that to your neighbor? 26:09.860 --> 26:11.600 Most probably not. 26:12.000 --> 26:22.580 That said, on the light bulbs, two years ago, we showed you we can infiltrate the network from a fax machine. 26:22.580 --> 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. 26:31.960 --> 26:36.900 So, that one is more concerning. 26:38.060 --> 26:44.120 And I would worry more about using a fax than using smart light bulbs. 26:44.120 --> 26:45.100 Excellent. 26:45.640 --> 26:49.940 Sighed, how are we doing with that Discord channel there? 26:49.940 --> 26:55.560 Coming up with anything else, or should we kind of start giving him some wrap-up questions? 26:56.040 --> 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? 27:06.300 --> 27:07.960 It actually did. 27:07.960 --> 27:13.280 It turns out that smart light bulbs are actually quite cool. 27:13.440 --> 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. 27:23.360 --> 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. 27:34.280 --> 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. 27:45.880 --> 27:48.500 And it is really cool. 27:48.500 --> 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, 28:11.900 --> 28:15.740 and it happens quite a lot. 28:15.740 --> 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. 28:26.600 --> 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. 28:38.040 --> 28:41.800 Otherwise, you need to recalibrate your light bulbs again and again. 28:41.800 --> 28:43.800 That's quite annoying. 28:44.160 --> 28:45.620 That's great. 28:46.040 --> 28:52.540 So, what would be your one main takeaway from your research or call to action? 28:52.540 --> 28:55.220 To happen after this? 28:55.220 --> 28:58.910 What should people take away from your research and your presentation? 28:59.640 --> 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. 29:11.880 --> 29:15.400 It really adds a large amount of security. 29:15.400 --> 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. 29:30.500 --> 29:39.860 On ZigBee, we have a maximal transmission unit of 127 bytes, and we still reliably exploited the vulnerability. 29:39.860 --> 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. 29:52.960 --> 29:58.300 So, everything practically could be broken. 29:58.300 --> 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. 30:06.080 --> 30:10.320 So, if you pick a target, don't give up. 30:10.320 --> 30:13.920 Most probably, you could get a win out of your research. 30:13.920 --> 30:17.140 So, just try hard enough. 30:17.640 --> 30:20.880 Let's slide one last question in there for you, from Brief Halo. 30:20.880 --> 30:27.620 What recommendations would you give to someone interested in studying IoT exploitation formally, like at a university? 30:30.260 --> 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. 30:45.040 --> 30:48.720 Reading the write-ups usually gets you a lot of tips. 30:48.720 --> 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. 31:01.920 --> 31:07.560 It will be more practical than most of the courses in many universities. 31:07.820 --> 31:08.980 That's great. 31:08.980 --> 31:09.460 All right. 31:09.460 --> 31:10.920 Thank you so much for doing this. 31:10.920 --> 31:13.220 This was a great talk with you. 31:13.220 --> 31:15.380 I really enjoyed your presentation as well. 31:15.380 --> 31:17.440 Thank you so much for doing this. 31:17.920 --> 31:18.780 Thank you. 31:18.780 --> 31:19.400 All right. 31:19.400 --> 31:24.040 Have a good night, and we will be back in about 30 minutes with another speaker.