[00:17.820 --> 00:24.700]  All right, and welcome back, everybody. We have another great speaker here today. We've got
[00:24.700 --> 00:29.400]  Eyal Iqin here to talk about light bulb security. How's it going, Eyal?
[00:30.120 --> 00:31.260]  Fine, how are you?
[00:31.260 --> 00:36.700]  I'm doing okay. We also have my co-goon here, Siget. Hey, Siget, how's it going?
[00:40.740 --> 00:47.300]  So, Eyal, can you kind of just take a minute and maybe give like a brief introduction of
[00:47.300 --> 00:51.880]  yourself and the presentation that you gave that people can go watch on DEF CON?
[00:53.620 --> 01:02.580]  Yes. So, hi, I'm Eyal. I'm a vulnerability researcher. I usually focus on embedded devices
[01:02.580 --> 01:09.380]  and network protocols. And this is a classic research in which I combine them both together
[01:09.380 --> 01:17.000]  to hack some, in this case, smart device. Essentially, in our research, we continued
[01:17.850 --> 01:23.950]  the previous research by two great researchers, Eyal Ronen and Colin O'Flynn,
[01:24.260 --> 01:31.780]  and they showed how they can take over a smart light bulb and propagate from one light bulb to
[01:31.780 --> 01:39.160]  the other. And our goal in this research was to take it one step further. We wanted to take
[01:39.160 --> 01:45.080]  over a light bulb and then from the light bulb take over the smart controller. And the controller
[01:45.080 --> 01:52.200]  is connected to both the radio network, the ZigBee network, and to the regular computer network. So,
[01:52.200 --> 01:59.120]  we could manage our smart light bulbs from our mobile app, for example. This basically means
[01:59.120 --> 02:07.880]  that using a malicious light bulb or an antenna, we could take over the controller and then
[02:07.880 --> 02:13.360]  infiltrate the network and attack computers inside it. So, we only need a radio antenna and
[02:13.360 --> 02:21.560]  we can infiltrate your home or your office network. So, that was the goal and this is what we
[02:21.560 --> 02:30.180]  demonstrated. That's excellent. All right. So, I know in your presentation, you kind of mentioned
[02:30.400 --> 02:38.140]  a whole bunch of the people's research that you based yours off of. What got you interested in
[02:38.140 --> 02:43.620]  this kind of thing? What made you want to look into trying to take things one step further
[02:43.620 --> 02:51.640]  from what the other research that previous people did? Okay. So, it was quite simple. One of
[02:51.640 --> 02:57.360]  the researchers, Eyal Ronen, is an old colleague of mine. And when he started working on his initial
[02:57.360 --> 03:03.800]  research roughly four years ago, it was the first time I actually heard of smart light bulbs.
[03:04.000 --> 03:09.720]  And I really didn't know why people need smart light bulbs because I really only need the light
[03:09.720 --> 03:15.500]  when I'm physically in the room and I'm physically capable of toggling on and off the switch. So,
[03:15.500 --> 03:19.800]  I don't really know why I need an app in order to control the light in the room that I'm currently
[03:19.800 --> 03:28.020]  in. And I figured out that smart light bulbs won't be a real thing. People won't buy it and
[03:28.020 --> 03:34.280]  forgot about it and continued on with my life. But it turns out that people actually buy
[03:34.280 --> 03:39.600]  smart lighting solutions. It turns out a lot of people specifically in the UK
[03:40.440 --> 03:49.780]  use it. It's not so popular here in Israel. So, Eyal Ronen talked with me again and he said,
[03:49.800 --> 03:57.860]  we have an opportunity to continue on our research because we had an additional task that we
[03:57.860 --> 04:03.300]  couldn't complete in our research. And since it turns out that people actually use smart light
[04:03.300 --> 04:10.040]  bulbs and in previous DEF CON talks, we infiltrated the network using a fax machine, it turns out that
[04:10.040 --> 04:16.740]  it could be interesting to do that over the radio as well, over ZigBee. So, this was the goal.
[04:16.740 --> 04:23.220]  We collaborated with the previous research team to get their equipment and knowledge from their
[04:23.220 --> 04:30.320]  results. And then we started on our way. Awesome. That's all great stuff. So,
[04:30.320 --> 04:34.000]  again, do we have any questions coming in yet or did you have any?
[04:36.710 --> 04:42.370]  Not sure if he's hearing me at all over there. Okay. Go for it.
[04:43.070 --> 04:47.990]  No, there's a comment that says, I hope you got a bounty for showing that the
[04:47.990 --> 05:00.210]  weren't completely implemented. The second part of the patch that you tested, right?
[05:00.210 --> 05:06.910]  Yeah. We didn't get any bounty. We usually don't get any bounty.
[05:07.310 --> 05:14.610]  I never worked on an embedded research which we received any bounty on any vulnerability
[05:14.610 --> 05:24.330]  whatsoever. Usually even when we report the vulnerabilities, they are only partially fixed
[05:24.330 --> 05:32.350]  or only the crucial vulnerabilities are actually patched. So, for example, our vulnerability
[05:32.910 --> 05:39.810]  was that we were able to show that in previous versions there were arrays which weren't parsed
[05:39.810 --> 05:45.130]  correctly. And in newer versions, they migrated the strings. But behind the scenes, we're still
[05:45.130 --> 05:53.250]  using them as arrays with the same vulnerability. So, the patch was to check the sizes of the
[05:53.250 --> 05:59.890]  arrays and handle them correctly instead of treating them as strings because strings are
[05:59.890 --> 06:06.290]  handled correctly and we only can send strings over the radio. So, there's no reason to treat
[06:06.290 --> 06:11.930]  them internally as arrays just because someone did it three years ago and that's the code. But
[06:13.090 --> 06:21.650]  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:28.130]  So, one of the questions that we see coming in from looks like Jiska. Did you get any further
[06:28.130 --> 06:32.990]  with the ZigBee modem itself? Like, were you able to extract its firmware?
[06:35.690 --> 06:41.270]  It's a good question. The problem we had with the ZigBee modem is that the firmware update is
[06:41.270 --> 06:48.690]  encrypted. And in a previous research, what they did was they had a power analysis attack and they
[06:48.690 --> 06:56.770]  extracted a key and decrypted a firmware update and signed their own firmware update. But it was
[06:56.770 --> 07:02.210]  only applicable for the firmware to the light bulbs themselves. It turns out that the modem
[07:03.030 --> 07:11.150]  uses a bit different cryptographic scheme. So, we had to, if we wished to get the firmware of the
[07:11.150 --> 07:18.810]  modem, we had to reiterate all of the research that the previous research team did. And we
[07:18.810 --> 07:25.210]  didn't have the resources for that at the time. So, we tried to live with it as a black box and
[07:25.790 --> 07:32.490]  we managed. It could be interesting to look on it because it's more advanced than the light bulb
[07:32.490 --> 07:40.750]  itself. It does more functionality. But no, we don't have the firmware, sadly.
[07:41.030 --> 07:47.910]  Okay. Yeah, I think in your presentation, you mentioned that previously, before your research,
[07:47.910 --> 07:52.850]  it was kind of thought the worst things that you could do was turn all the light bulbs on or turn
[07:52.850 --> 07:57.870]  all the light bulbs off or flicker them or anything like that. So now, based on the research that you
[07:57.870 --> 08:03.190]  did, what do you see as kind of a worst case scenario if somebody wanted to do bad things
[08:03.190 --> 08:10.630]  with your research? The classic scenario we thought about is either a neighbor attacking
[08:11.390 --> 08:18.230]  your network or someone parking a large van across the street and deploying an attack. And then
[08:19.650 --> 08:27.550]  we can easily hijack a given light bulb and convince it to connect to our network. And then,
[08:27.550 --> 08:33.030]  as you saw in the demo, if we turn off the light bulb, you think that it's broken and you just
[08:33.030 --> 08:38.350]  toss it away. And instead, we change the color so you'll know that something is wrong with your
[08:38.350 --> 08:44.950]  light bulb and try to reset it. But there's no reset button. There's no buttons at all to the
[08:44.950 --> 08:51.210]  light bulb. So the only way to reset the light bulb is to delete it from the app and then search
[08:51.210 --> 08:55.530]  for new light bulbs. And when you search for new light bulbs, we can actually attack your
[08:55.530 --> 09:01.630]  controller and infiltrate the network. So once we take over the controller, we are inside your
[09:02.120 --> 09:10.490]  home network or your office network. We can attack whichever computer we wish. We can sniff the
[09:10.490 --> 09:19.090]  traffic. And if inside your own network you use HTTP instead of HTTPS, we can sniff all of your
[09:19.090 --> 09:26.330]  traffic. And essentially, no one will notice an intruder on the bridge. You don't have an
[09:26.330 --> 09:32.290]  antivirus on your bridge. You don't have any security solution on it. So we can have a persistent
[09:32.290 --> 09:39.490]  foothold inside your network and attack additional computers. And just from being near your network
[09:39.490 --> 09:46.810]  with an antenna for five minutes. Wow. So knowing what you know now from this exploit, what would
[09:46.810 --> 09:55.790]  you suggest to the makers of IoT devices? Specifically in this case, there were some
[09:55.790 --> 10:03.690]  security mitigations in place, which is sadly quite rare. Usually we get none. And still,
[10:03.690 --> 10:08.890]  although there were some security mitigations, we're still able to exploit the vulnerability
[10:09.630 --> 10:16.790]  because there weren't enough mitigations. And actually, after our research,
[10:17.450 --> 10:27.050]  we looked again on the heap implementation that was used. And it was really weird for us that
[10:27.050 --> 10:32.750]  there were some security mitigations, but because the vendors didn't compile their own binary
[10:32.750 --> 10:38.730]  correctly, we were able to bypass the mitigations. Because it turns out that if you don't have
[10:38.730 --> 10:45.670]  security on by default, the vendor won't compile correctly their firmware. And they won't get
[10:45.670 --> 10:53.430]  anything because on their compiler, it's off by default. So in our team, we designed a new
[10:53.430 --> 11:03.190]  security mitigation called Safe Linking. And we integrated that into both glibc and uclibc-ng so
[11:03.190 --> 11:10.930]  that it will be a new security mitigation in popular malloc implementations. And it's on by
[11:11.330 --> 11:20.190]  default. So just this week, glibc introduced a new version that includes Safe Linking. And uclibc
[11:20.190 --> 11:27.490]  already have versions with Safe Linking. 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:51.110]  The most updated Linux version, glibc or uclibc version, and preferably even a good compiler
[11:51.110 --> 11:58.130]  with a good toolchain to actually compile with security mitigation. But just updating your libc
[11:58.130 --> 12:05.690]  implementation will be a huge step forward. Excellent. Segev, are you seeing any other
[12:05.690 --> 12:11.370]  questions for him coming through the Discord channel at track one live QA?
[12:11.810 --> 12:16.350]  So we have one. So your discovery was a modern firmware security problem,
[12:16.350 --> 12:18.510]  or just a ZigBee protocol issue?
[12:20.710 --> 12:28.750]  It turns out that ZigBee is complex, which wasn't a big surprise. But the vulnerability itself
[12:28.750 --> 12:36.370]  was an implementation vulnerability specific to that product. So Philips, now Signify,
[12:36.370 --> 12:42.850]  had an implementation vulnerability over the years. It changed a bit over the firmware versions.
[12:42.850 --> 12:47.910]  But essentially, it was an implementation vulnerability on their side. It wasn't a
[12:47.910 --> 12:57.310]  vulnerability on ZigBee. That said, ZigBee defines data types with variable lengths
[12:57.310 --> 13:03.750]  that should be received over the network. And usually, embedded devices and embedded developers
[13:03.750 --> 13:12.850]  are not that good with handling variable-sized objects. Although there was no vulnerability
[13:12.850 --> 13:20.850]  in ZigBee, but only the implementation, I can guess that if five developers will have to
[13:20.850 --> 13:28.850]  implement this model, at least two of them will get it wrong. 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:42.130]  We checked the updated firmware version for the patch, so we would know how did
[13:42.130 --> 13:47.230]  they actually fix it. And to check that they fixed it correctly, so we could continue on
[13:47.230 --> 13:55.090]  with the publication. 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:09.490]  If they are hearing this switch, I really urge them to update their libc version and compile
[14:10.170 --> 14:16.810]  to use dynamic addresses instead of static addresses. This will be a huge step forward
[14:16.810 --> 14:22.650]  in the security of their device. That's great. Let's see, what else do we have coming through
[14:22.650 --> 14:30.530]  over there? Anything else, Sighad? No, I'll ask a question. I noticed in your talk,
[14:30.530 --> 14:37.330]  you spoke a lot about your sort of false starts, right? And you tried this, you tried that,
[14:37.850 --> 14:43.570]  and these didn't work out, and those didn't work out. And then you also kind of mentioned hitting
[14:43.770 --> 14:51.650]  a wall on the erase issue before you were able to find the second implementation that still
[14:51.650 --> 14:59.230]  contained the vulnerability. So, two questions. One was just, you know, what about those false
[14:59.230 --> 15:04.470]  starts did you think were important enough to include in the talk? And secondly, you know,
[15:04.470 --> 15:12.670]  what got you to the thinking that got you past that wall? Okay. So, I started the first one.
[15:13.210 --> 15:19.790]  Without the false starts, I wouldn't have been able to actually find the vulnerability that
[15:19.790 --> 15:29.890]  eventually I found, and to reliably exploit it. Because even as in the slides, I didn't even have
[15:29.890 --> 15:35.890]  enough time in the blog post, which was just uploaded, you can see that there was an additional
[15:35.890 --> 15:46.050]  false vulnerability, but there is a vulnerability, but it isn't exploitable. And even if I wouldn't
[15:46.050 --> 15:55.190]  have encountered this code module, and the treatment of ZigBee addresses and the ZigBee
[15:55.190 --> 16:01.070]  phone book, which initially had a vulnerability, but it wasn't exploitable, I wouldn't have been
[16:01.070 --> 16:07.930]  able to understand where to store the shellcode and how to construct my shellcode and how to use
[16:07.930 --> 16:14.270]  it. So, every part in this research, even if I didn't eventually find a vulnerability in the
[16:14.270 --> 16:21.730]  specific model that I tried to, I learned a few things about the device and about the memory
[16:21.730 --> 16:27.490]  layout. And every one of them was important in the overall attack at the end. So, that was the
[16:27.490 --> 16:33.770]  main reason I decided to talk about all of the steps in the research, even if there were some
[16:33.770 --> 16:41.230]  dead ends, because it gives additional information that we later on use during the exploit. So,
[16:41.230 --> 16:49.870]  it was important about hitting the wall. Then, when you start a research with
[16:50.510 --> 16:57.030]  an interesting attack vector, and you're already into it, you got the firmware, it's loaded into
[16:57.030 --> 17:03.730]  your disassembler, you bought a kit with the hardware, you have everything, you really want
[17:03.730 --> 17:11.130]  to find vulnerabilities. And in most of the projects that I worked on, there are critical
[17:11.130 --> 17:18.730]  vulnerabilities. We just need to find them. So, you check one module, it's a dead end. You go to
[17:18.730 --> 17:25.990]  the other one, it's a dead end. You go to the third one, it's a dead end. And then you go back
[17:25.990 --> 17:34.290]  and you check your initial assumptions. Maybe there is some assumption that we thought about,
[17:34.290 --> 17:42.070]  but it's wrong. The device might behave differently. Maybe we skipped a module because it looked
[17:42.810 --> 17:47.790]  well written, but we didn't check it deeply enough. So, we can go back to that module
[17:48.310 --> 17:53.990]  and test it again. So, essentially, in a security research, we attack the device
[17:53.990 --> 18:01.910]  in layers. We want to find the path of least resistance. And it's really common to reiterate
[18:01.910 --> 18:09.290]  over the same module again and again, because now we want to go deep into that module after we had
[18:09.610 --> 18:16.640]  a shadow look on all of the modules we initially marked. So, we have a few iterations.
[18:17.270 --> 18:26.540]  We most of the times we find critical vulnerabilities. It's not easy to continue on
[18:26.540 --> 18:35.720]  when you get to a dead end and when you get to multiple dead ends. But you're already into it
[18:35.720 --> 18:44.320]  and you don't want to raise a white flag and surrender and to the research team in the office
[18:44.320 --> 18:49.280]  to laugh about you. So, you want to continue on. You want to prove that you actually can
[18:49.280 --> 18:55.020]  break this device. And it's really important not to never to give up.
[18:56.700 --> 19:01.200]  That sounds like there might be a little bit of an extra story there about being
[19:01.200 --> 19:06.180]  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:28.280]  Sadly, no. Technically, there is a grace period that once the user requested a bridge to
[19:28.280 --> 19:35.880]  search for new light bulbs, we have roughly 60 seconds. In some experiments,
[19:35.880 --> 19:43.400]  it wasn't exactly 60 seconds. It looked more like two minutes. But essentially, there's a
[19:43.400 --> 19:53.140]  timer. Most probably some thread on the main CPU initiates a timer. And when the timer expires,
[19:53.220 --> 20:00.400]  a message is sent to the modem and the modem shuts down the communication. So, unless we starve
[20:01.440 --> 20:09.560]  the thread that is responsible for the timer, the timer will expire and we will be blocked out.
[20:09.560 --> 20:15.620]  And it is a good security design. We can't send messages to the bridge
[20:17.360 --> 20:22.960]  unless the user requested a bridge to look for new light bulbs. So, it is a good design.
[20:22.960 --> 20:29.580]  It blocks most of the attack vector. However, there's no reset button for the light bulbs.
[20:29.580 --> 20:36.080]  And there's no indication of please just pair this light bulb again, according to the addresses
[20:36.080 --> 20:42.940]  of the light bulb. So, essentially, the design started quite good, but broke somewhere in the
[20:42.940 --> 20:50.900]  middle. We did find out that if we bombed the controller with multiple messages, we can starve
[20:50.900 --> 20:58.180]  the rest of the threads. But it has some disadvantages as well. Because if we starve
[20:58.180 --> 21:04.700]  the rest of the threads, then the watchdog will restart the bridge. And we mostly don't want that
[21:04.700 --> 21:14.400]  to happen. So, the 60 seconds is... it is a hard limit. We can't really do a lot about it.
[21:15.360 --> 21:19.560]  Excellent. So, yeah, do we have anything else currently coming through the
[21:20.420 --> 21:25.820]  Discord chat? Yes, we have a question. Did you start working on IoT exploitation at Checkpoint,
[21:25.820 --> 21:28.680]  or is this an area you've been working on beforehand?
[21:29.640 --> 21:38.780]  That's a good question. It really depends how you define IoT. If IoT is anything that is not
[21:38.780 --> 21:48.020]  Windows, Linux, or mobile, then I started working on embedded devices practically from my first
[21:48.020 --> 22:02.680]  year on work. If we rule out network equipment, for example, then actual embedded devices
[22:03.680 --> 22:13.740]  were from after three or four years of work. 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:28.610]  Excellent. And did you ever think of attempting to brick the other bulbs or possibly the controller?
[22:31.620 --> 22:38.340]  There is a sad story about that. Because if you break the device,
[22:38.960 --> 22:45.320]  you also lose your own device. And then you need to go and purchase a new device and convince some
[22:45.320 --> 22:50.600]  manager to once again buy it. And then you need to tell the manager, yeah, we need to buy it again,
[22:50.600 --> 23:00.180]  because we bricked the earlier one. And you can't do that often. We had that on the research in the
[23:00.180 --> 23:08.240]  previous year. We presented a DEF CON ransomware on DSLR cameras, and we had to test the patch from
[23:08.240 --> 23:16.100]  the vendor. But if the patch will work, we'll get locked out from the device, and we won't be able
[23:16.100 --> 23:24.640]  to demonstrate the attack, which we wanted to demonstrate on a live demo. So, once we noticed
[23:24.640 --> 23:31.820]  that it will be some issue about it, we went to buy an additional camera. So, if we lose one of
[23:31.820 --> 23:40.420]  them, we still had a backup. So, it is quite easy to break the devices. And most of the times,
[23:40.420 --> 23:45.580]  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:53.600]  A few years ago, I actually bricked my device on a different research project. And if you break
[23:53.600 --> 24:01.040]  your device, then people really laugh. Because, yeah, he bricked his device, we need to buy a new
[24:01.040 --> 24:06.080]  one, and you don't want to be that researcher. So, you really don't want to break your own device.
[24:06.700 --> 24:13.640]  Sounds like quite the environment at work that you have there. So, it seems like a lot of times,
[24:13.720 --> 24:19.760]  a lot of years at DEF CON, you know, the big story comes out about this big thing is insecure,
[24:19.760 --> 24:24.620]  there's going to be these problems. And you're talking about how that people could get into a
[24:24.620 --> 24:30.660]  home network, or maybe even a business network through a light bulb. So, what do you think about
[24:30.660 --> 24:36.740]  overall security concerns based on your research? Is this something that people at large should be
[24:36.740 --> 24:42.020]  really concerned about? Or is it being handled really well by the manufacturers?
[24:43.500 --> 24:49.720]  I wouldn't trust the manufacturers at all, specifically in IoT devices. It doesn't look
[24:49.720 --> 24:58.540]  like security is a top priority in their devices. If we look specifically on the light bulbs case,
[24:58.540 --> 25:04.600]  you would be more worried about a neighbor hijacking all of my light bulbs and turning them
[25:04.600 --> 25:12.660]  to whichever color they want. Because they could have done that years ago, even from the conclusions
[25:12.660 --> 25:21.240]  of the previous researchers. And it's a flaw in ZigBee, you can't fix that. So, specifically in
[25:21.240 --> 25:27.680]  light bulbs, anyone can hijack your light bulb and steal them to control them from their own
[25:27.680 --> 25:34.700]  network. And there's nothing really you can do about that. If you're worried about someone
[25:34.700 --> 25:43.880]  attacking your bridge and infiltrating your network, most probably it won't happen a lot.
[25:44.560 --> 25:49.560]  We are not releasing our full exploit, and we work quite hard on the exploit,
[25:49.560 --> 25:59.680]  it will be reliable and will work correctly. If you're a real target and some high
[26:01.880 --> 26:09.160]  authority wants to hijack your network, they could do that. Will someone do that to your
[26:09.160 --> 26:18.220]  neighbor? Most probably not. That said, on the light bulbs, two years ago, we showed you we can
[26:19.020 --> 26:26.500]  infiltrate the network from a fax machine. And then the attack was easier, more reliable,
[26:26.500 --> 26:36.900]  and I can be in China and still attack your all-in-one printer. 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:51.100]  Excellent. Sighed, how are we doing with that Discord channel there? Coming up with anything
[26:51.100 --> 26:58.220]  else, or should we kind of start giving him some wrap-up questions? So, we had one question about,
[26:58.220 --> 27:03.820]  did this research ever give you the kind of insight you started out with on why people
[27:03.820 --> 27:12.020]  want connected light bulbs? It actually did. It turns out that smart light bulbs are actually
[27:12.020 --> 27:20.060]  quite cool. I read about a few people in the north which use the light bulbs and calibrate them
[27:20.480 --> 27:28.700]  to match the season and the clock. So, they will still get sunrise and sunset, even if they don't
[27:28.700 --> 27:36.760]  actually have that way in the north because of the season. You have quite a lot of control over
[27:36.760 --> 27:43.720]  the light bulb, both the intensity and the color itself, and you can sync multiple light bulbs to
[27:43.720 --> 27:53.780]  get a scene. And it is really cool. It isn't very practical because, for example, if there's a power
[27:53.780 --> 28:02.960]  shutdown, then all of your light bulbs go reset, and then you lose all of your scheme, all of the
[28:02.960 --> 28:09.860]  colors, and all of the intensity, and you get all of the light bulbs go white, go to the maximum
[28:10.700 --> 28:20.000]  lighting, and it happens quite a lot. The power has some sort of glitch, and you're not supposed
[28:20.000 --> 28:27.820]  to connect your light bulbs to a backup system or to a UPS or anything of this sort. So, if you're
[28:27.820 --> 28:36.360]  into the colors of the light bulbs, you need to have pretty good electricity in your city or in
[28:36.360 --> 28:43.800]  your state. Otherwise, you need to recalibrate your light bulbs again and again. That's quite annoying.
[28:44.160 --> 28:52.540]  That's great. So, what would be your one main takeaway from your research or call to action?
[28:52.540 --> 28:58.910]  To happen after this? What should people take away from your research and your presentation?
[28:59.640 --> 29:09.140]  So, if I have a message to manufacturers, then please compile with security mitigations and use
[29:09.140 --> 29:16.460]  the latest versions of each library. It really adds a large amount of security. If it's for
[29:16.460 --> 29:26.220]  researchers, then it turns out that practically any device that you can think of using any
[29:26.220 --> 29:33.860]  protocol will most probably still be vulnerable. On ZigBee, we have a maximal transmission unit of
[29:33.860 --> 29:43.020]  127 bytes, and we still reliably exploited the vulnerability. So, even with really harsh
[29:43.020 --> 29:49.760]  constraints and really esoteric protocols, we can still consistently, year over year,
[29:49.760 --> 29:56.940]  present in DEF CON that we broke an additional device. So, everything practically could be
[29:56.940 --> 30:03.580]  broken. And even if you have harsh constraints, you most probably will still be able to exploit
[30:03.580 --> 30:11.260]  the vulnerability once you find it. So, if you pick a target, don't give up. Most probably,
[30:11.260 --> 30:17.140]  you could get a win out of your research. So, just try hard enough.
[30:17.640 --> 30:21.820]  Let's slide one last question in there for you, from Brief Halo. What recommendations
[30:21.820 --> 30:27.620]  would you give to someone interested in studying IoT exploitation formally, like at a university?
[30:30.260 --> 30:37.000]  There are some good courses in several universities, but usually reading write-ups
[30:37.000 --> 30:45.040]  from researchers that published their research, and you read about it, and it was interesting.
[30:45.040 --> 30:51.340]  Reading the write-ups usually gets you a lot of tips. So, if you read the publications from
[30:51.340 --> 30:56.740]  Colin O'Flynn, you get a lot of new knowledge about hardware, and how UART works, and how
[30:56.740 --> 31:03.220]  UBIT works, and you can learn a lot from practical write-ups of researchers. It will be more
[31:03.220 --> 31:09.780]  practical than most of the courses in many universities. That's great. All right. Thank
[31:09.780 --> 31:15.000]  you so much for doing this. This was a great talk with you. I really enjoyed your presentation as
[31:15.000 --> 31:20.060]  well. Thank you so much for doing this. Thank you. All right. Have a good night,
[31:20.060 --> 31:24.040]  and we will be back in about 30 minutes with another speaker.