[00:25.790 --> 00:32.350]  All right. Welcome back, everybody. We have another great speaker for you today.
[00:32.530 --> 00:38.010]  We have Paul Marapici, who's here to tell us a little bit more about his presentation,
[00:38.010 --> 00:43.650]  Abusing Peer-to-Peer to Hack 3 Million Cameras. Ain't nobody got time for that.
[00:43.650 --> 00:47.490]  How's it going, Paul? Very good. Very good to be here, guys.
[00:47.490 --> 00:53.550]  All right. Welcome to this Q&A. Looking forward to asking you some questions, and hopefully we'll
[00:53.550 --> 00:59.270]  get a whole bunch of questions for people on the Track 1 Live Q&A stream in Discord.
[00:59.550 --> 01:05.030]  But how about if you just kind of give us a little bit overview of yourself, who you are,
[01:05.030 --> 01:09.210]  maybe just a little bit about your presentation, what made you think of it.
[01:09.450 --> 01:13.970]  Anything so that people can kind of get a good idea about what your presentation was about.
[01:14.730 --> 01:21.070]  Yeah, sure. So, yeah. My name's Paul Marapici. I am based out of San Jose, California.
[01:21.070 --> 01:30.950]  And so my talk was... so basically, I got some IP cameras, and it's pretty much assumed that
[01:30.950 --> 01:35.350]  these things are insecure, I think, when people pick these up. But I just kind of wanted to see
[01:35.350 --> 01:41.390]  how far that I could take it. And I basically ended up finding a way to access literally
[01:41.390 --> 01:45.970]  millions of cameras. So, I mean, I figured it would be bad. I figured, you know, maybe someone
[01:45.970 --> 01:51.030]  could target maybe a couple, or maybe the crypto wasn't so good. But yeah, you could take it to
[01:51.570 --> 01:55.650]  the extreme of extremes and start jacking these things left and right.
[01:56.190 --> 02:01.890]  Awesome. So, I think we also have something else to do with you first. But let me see if
[02:01.890 --> 02:05.470]  Siget has any ideas about what we might want to do with you.
[02:06.370 --> 02:10.570]  Well, it just so happens that Paul here is a first-time speaker. And every time we
[02:11.410 --> 02:17.690]  join someone to the whole speaker crowd at DEF CON, we commiserate the... or not commiserate...
[02:18.970 --> 02:19.690]  Celebrate!
[02:20.230 --> 02:24.830]  Yeah, that's not the word I was looking for. So, English has been a second language to me.
[02:27.410 --> 02:33.970]  So, we will commemorate the event with a shot. So, I'd love to ship a bottle off to you. But
[02:33.970 --> 02:38.010]  unfortunately, we've got to rely on your own stock. And so, if you can join me in a quick
[02:38.010 --> 02:43.430]  drink, we'll christen this talk for you. So, yeah, cheers, gentlemen.
[02:49.030 --> 02:54.350]  Awesome stuff. All right. So, now we get that underway.
[02:56.130 --> 02:58.890]  That's a pretty big shot you got there, Siget.
[03:01.770 --> 03:08.630]  So, let's see. Questions that we have coming in. Do you see any coming through on the
[03:09.430 --> 03:12.950]  Discord chat already there, Siget? It might be kind of a...
[03:12.950 --> 03:18.090]  We have one. We have one. Thanks for your research. Are any of the exploitable elements
[03:18.090 --> 03:22.150]  you discussed, such as the direct connection with UIDs or traffic analysis, the supernode
[03:22.150 --> 03:27.090]  required for the P2P environment to operate effectively from a user point of view,
[03:27.090 --> 03:31.130]  or would alternative architectures, which is cameras operators could use,
[03:31.130 --> 03:37.230]  utilize third-party access controls, end-to-end content encryption? Basically, how ought a P2P
[03:37.230 --> 03:40.630]  environment be designed to be both convenient and secure?
[03:41.210 --> 03:48.530]  Right. In terms of the super device ones, I would say that's not necessary to the whole
[03:48.530 --> 03:54.770]  thing. That's pretty much entirely to kind of help the network. Vendors will actually
[03:54.770 --> 03:58.690]  put up a bunch of their own relay servers, and honestly, not that that's any better,
[03:58.690 --> 04:06.030]  because they have access to that traffic. So, that's not necessary. It just kind of
[04:06.030 --> 04:13.810]  helps when people need connections, I guess. I don't think the peer-to-peer aspect is inherently
[04:14.370 --> 04:19.190]  bad. It just kind of comes down to, you know, making sure that the traffic is protected,
[04:19.890 --> 04:23.550]  making sure that there's identity verification going on, so you know who you're actually
[04:23.550 --> 04:29.810]  talking to. I think those things could help a lot. And, of course, the fact you can predict
[04:29.810 --> 04:36.830]  or otherwise obtain UIDs is a huge problem. So, you might want a way to protect those
[04:36.930 --> 04:41.410]  a little bit more, or have the ability to change them. I mean, personally, I don't think
[04:41.410 --> 04:46.990]  I would want a device doing this. It kind of depends on people's risk tolerance. But
[04:46.990 --> 04:51.230]  there are certainly a lot of ways that they could have made this, you know, a little bit
[04:51.230 --> 04:57.710]  less gross. Awesome. Yeah, in your presentation, you even
[04:57.710 --> 05:02.910]  did a really quick demo at the end where you captured some binary and put that through
[05:02.910 --> 05:10.010]  the video feed. You got to see some chickens. So, that was kind of interesting. Through
[05:10.010 --> 05:15.050]  your research, did you ever, let's say, see anything interesting when you were kind of
[05:15.050 --> 05:19.730]  checking out to see what was coming through? Or did you not really look at the video streams
[05:19.730 --> 05:24.390]  all that much? Yeah, I've had a few interesting things. I
[05:24.390 --> 05:28.150]  mean, obviously, as part of the research, sometimes you have to go and try to connect
[05:28.150 --> 05:37.030]  to something or see how far you can get. I certainly avoided, like, you know, more personal,
[05:37.030 --> 05:43.010]  like, in-home stuff. Because, I mean, I'm not trying to spy on people. Some of the more,
[05:43.010 --> 05:46.330]  I guess, guilt-free ones you can say are, like, you know, someone might have one of,
[05:46.330 --> 05:51.690]  like, a landscape or a more public area, which feels, you know, a little bit less creepy.
[05:52.510 --> 05:58.090]  One thing that does come to mind... I had a guy reach out to me a couple weeks ago.
[05:58.590 --> 06:03.530]  And he emailed me. He says, hey, you know, I found your research. And what happened was
[06:03.530 --> 06:10.550]  my camera got stolen. And he was continuing to watch the camera with the app on his phone.
[06:10.550 --> 06:15.010]  And he said, all of a sudden, this thing came back online. So, is there any way that you could,
[06:15.010 --> 06:19.050]  like, you know, steal the password or find the IP address or anything like that? I said, yeah,
[06:19.050 --> 06:24.590]  give me the UID and I'll see what I can do. And not two hours later, you know, I started up the
[06:24.590 --> 06:29.790]  man-in-the-middle attack. Not two hours later, the thing connects to me and drops the password
[06:30.690 --> 06:38.430]  and the IP address, of course. So, you know, I guess if you're a thief, stealing a peer-to-peer
[06:38.430 --> 06:45.610]  camera is a major OPSEC fail. It's gonna seriously leak exactly where you are. So,
[06:45.610 --> 06:52.630]  I sent that back to him and I don't know what's happened of that. But, you know, it felt pretty
[06:52.630 --> 06:56.230]  cool to be able to use an exploit like that to actually help someone. Like, you know, hey,
[06:56.230 --> 07:00.810]  you lost your camera, but here's the password if you want to take a look and see what's going on
[07:00.810 --> 07:05.430]  in there. Yeah, that was pretty interesting how you were showing that you can use some of the
[07:05.430 --> 07:11.050]  Google's geolocation to find out where the camera is. And I'm guessing that's similar to what you
[07:11.050 --> 07:16.910]  did for your friend there. Just how close were you able to figure out? Is it, like, within a few
[07:16.910 --> 07:26.190]  meters of where the camera actually is with the geolocation? Yeah. Oh, man. So, I suspect the way
[07:26.190 --> 07:32.750]  that that works is, like, obviously Google drives around for Street View. And I imagine that as
[07:32.750 --> 07:38.870]  they're doing that, they're collecting every single base station ID that they see. So, depending on
[07:38.870 --> 07:43.530]  what they're seeing, you know, obviously they're storing the exact location that they're
[07:43.530 --> 07:49.690]  at when they do that. Depending on the MAC addresses that you give that API, and I think
[07:49.690 --> 07:53.270]  there's a whole bunch of other parameters to kind of, like, fine-tune that. So, depending on what
[07:53.270 --> 08:00.130]  you give it, they can figure out, like, exactly where they were when they picked it up. I've put
[08:00.130 --> 08:07.030]  in, like, some of my own MAC addresses, and I've been very unhappy with what I've seen in that.
[08:07.030 --> 08:13.790]  Like, yeah, it's pretty dead on. And, I mean, I imagine in all cases, it might not be that
[08:13.790 --> 08:17.770]  accurate. It's probably going to matter on the density of the Wi-Fi networks around you, because,
[08:17.770 --> 08:27.010]  of course, that's going to give them more ways to improve the accuracy. But, yeah. Oh, man.
[08:27.310 --> 08:33.110]  They store a lot of data on that. And as I said, it is dirt cheap to make those requests. Like,
[08:33.110 --> 08:38.070]  it's a couple cents per call or something like that. And anyone can start doing that, yeah.
[08:38.070 --> 08:42.950]  That's all crazy. Yeah, it looks like Spherical Kitten has a question for you.
[08:43.050 --> 08:50.290]  The whole firewall, hole-punching stuff seems to be primarily an IPv4-related technique.
[08:50.290 --> 08:55.090]  Does any of this peer-to-peer stuff work on an IPv6-only network?
[08:55.090 --> 09:04.250]  Ah, that's a good question. I'm honestly not sure. I have only done UDP hole-punching stuff
[09:04.250 --> 09:10.210]  with IPv4 scenarios. I admittedly haven't tried it in IPv6. I don't... admittedly, I don't know
[09:10.210 --> 09:15.310]  too much about IPv6 just yet. And, of course, I mean, these devices are so primitive. I've
[09:15.310 --> 09:22.170]  yet to come across one that actually uses it. So, I'm not sure. That's a really good question.
[09:22.170 --> 09:29.090]  Sorry, I can't answer. Yeah, one of the common questions that we have been asking speakers is,
[09:29.090 --> 09:35.390]  what types of research could somebody else build on top of yours? Or maybe, where could somebody
[09:35.390 --> 09:40.230]  go further with the research that you've done? And maybe checking out the IPv6 could be something
[09:40.230 --> 09:46.010]  that somebody else could take a look into as well. Yeah, that would be really cool. Another
[09:46.010 --> 09:50.690]  one that... some guy actually already reached out to me saying he wanted to look into it.
[09:50.690 --> 09:57.130]  I did mention ThruTech's Kali platform, which is probably the biggest peer-to-peer vendor that I
[09:57.130 --> 10:04.210]  know. I'd love for people to kind of start poking at that and kind of see if they have any similar
[10:04.210 --> 10:10.310]  problems. Or who knows? I mean, maybe they're in better shape. But we don't know until we poke, so...
[10:10.310 --> 10:17.790]  Yeah. Sigurd, do we have any anything else coming in from the Discord channel for Paul? Yeah, so we
[10:17.790 --> 10:23.070]  have a question. Can you explain how a device can connect to a supernode without knowing the UID?
[10:24.650 --> 10:36.910]  Yeah, so when a device needs to make a connection, it'll ask the P2P servers to do a
[10:36.910 --> 10:41.470]  relay request. Like, if it can't do a peer-to-peer connection, it'll send a request to basically pull
[10:41.470 --> 10:48.810]  down a list of relays. That will return an array of IPs and ports, and then it'll try to connect
[10:48.810 --> 10:54.810]  to each one of those. And eventually, it'll find one. One of those may be a supernode. So, when
[10:54.810 --> 11:01.250]  someone's trying to connect to a device, that's how that works. Cool. I hope that answers your question.
[11:02.210 --> 11:07.910]  Yeah, and SivarakuKitten followed up with a second question and said that,
[11:07.910 --> 11:15.010]  I understand why this super device proxying would be useful, even said, insert huge air quotes here,
[11:15.010 --> 11:20.510]  for finding a route out of your own internal network. But why would anyone want or need to
[11:20.510 --> 11:26.750]  proxy traffic via Joe Random's camera on the internet? What use case would such a method enable?
[11:27.550 --> 11:35.670]  I think it is just basically taking the load off of the vendor servers. If they have, you know,
[11:35.810 --> 11:40.030]  a million devices and there's only like two or three relay servers, then those are going to have
[11:40.130 --> 11:44.150]  a lot of heavy lifting. And of course, those are going to have limited bandwidth and just limited
[11:44.790 --> 11:50.770]  everything, really. So, it's kind of just, again, to add more relays to the vendor's network to provide
[11:51.870 --> 12:00.150]  the support for more people to make connections if necessary. The vendors could also just buy
[12:00.150 --> 12:04.470]  more relay servers. With this architecture, there's really not a limit to the number of
[12:04.470 --> 12:10.890]  relays that a vendor could put in their network. But it is more cost effective for them to offload
[12:10.890 --> 12:18.570]  that on the users. So, really, that's the biggest reason, is it saves the vendors money. And again,
[12:18.570 --> 12:23.010]  it's actually not an uncommon thing in peer-to-peer architecture. Supernodes are
[12:23.550 --> 12:29.990]  pretty much everywhere. Skype used to do this, too. And it just, you know, kind of helps with
[12:29.990 --> 12:34.030]  the redundancy of the network, I suppose. Yeah, I think you said in the presentation
[12:34.030 --> 12:40.490]  that even with Skype, you could opt out of it. Yeah, but with these devices, I mean, I have never
[12:40.490 --> 12:45.910]  seen something disclaim that it does this. So, you would have to notice, like, man, this thing is
[12:45.910 --> 12:49.810]  throwing off a lot of traffic and connecting to the other side of the world when I'm not using it
[12:49.810 --> 12:57.110]  for some reason, you know? Yeah. So, Chappy asks, you explored cameras primarily in your research.
[12:57.110 --> 13:03.490]  Did you try other IoT device types or what other types of devices use this peer-to-peer technique?
[13:04.430 --> 13:11.430]  Yes. So, I mean, I've mentioned smart doorbells and baby monitors, but those are really cameras
[13:11.430 --> 13:17.630]  under the hood, just kind of rebranded. But in terms of, like, real other use cases, I've also
[13:17.630 --> 13:25.850]  seen these peer-to-peer libraries implemented in NATs. Not NATs, sorry. God. NASes. So, yeah,
[13:25.850 --> 13:30.450]  network storage devices. So, I guess if people have a NAS in their home and they want to connect to it,
[13:30.450 --> 13:35.750]  this will give them the ability to do that, which is horrifying because that's just screaming for,
[13:35.750 --> 13:42.610]  you know, huge data theft. But one thing that I discovered actually pretty late in the game here
[13:42.610 --> 13:50.250]  was alarm systems. And there is actually a specific company that I think loads this into
[13:50.250 --> 13:58.470]  all of their alarms. And the traffic going to these things is entirely in clear text. So, you can do,
[13:58.470 --> 14:04.530]  the super device attack, and you can sit and you can see these, like, streams of configuration data
[14:04.530 --> 14:12.930]  for alarm systems. And, you know, that's insane. Yeah, that sounds like a whole other topic of
[14:12.930 --> 14:19.810]  research right there as well. Yeah, yeah. So, if anyone wants to dig into that, I mean, feel free
[14:19.810 --> 14:24.350]  to... I don't want to elaborate on it right here, but feel free to hit me up and I may be able to
[14:24.350 --> 14:29.130]  kind of give people some more insight into that. Yeah, maybe if somebody talks to you, you can say,
[14:29.130 --> 14:30.430]  well, the company name rhymes with...
[14:35.050 --> 14:38.530]  Sagan, are you seeing any good questions coming in on the channel?
[14:39.870 --> 14:43.850]  Yeah, so I have a question about, do you have an estimate of how much traffic was being routed
[14:43.850 --> 14:49.630]  through those relayed devices rather than the super nodes?
[14:53.450 --> 15:01.450]  I don't have an actual figure. I will say, at least with CS2, I do know that to some degree,
[15:01.450 --> 15:08.010]  it tries to keep track of how often it's running. And I think after it's done a session, it might
[15:08.010 --> 15:15.250]  shut off for a little while. But I don't think that there's actually a limit per se, because I'm
[15:15.250 --> 15:19.770]  pretty sure, you know, if you connect to it and you just want to stay connected for all day or
[15:19.770 --> 15:26.250]  whatever, I don't see a reason why it would drop you. So, that is theoretically unlimited.
[15:27.550 --> 15:32.490]  When I've let packet captures run before, I mean, even just in the matter of a couple hours,
[15:32.490 --> 15:38.810]  I've definitely seen a couple hundred megs go through easily. So, yeah, it can get up there
[15:38.810 --> 15:44.490]  pretty quickly, because it's video data, you know? And even when the video isn't flowing,
[15:44.490 --> 15:50.610]  there's still constant kind of like heartbeat messages going back and forth. It's constantly
[15:50.610 --> 15:54.630]  generating traffic in the meantime. But when the video starts going through, of course, that's
[15:54.630 --> 15:59.730]  going to be a little bit more heavy. This seems like a fun one for you,
[15:59.730 --> 16:06.590]  maybe you'll be able to expound on it a little bit. Is the full video feed going back to the vendor?
[16:10.270 --> 16:16.610]  Yes. I mean, honestly... so, here's the thing. With peer-to-peer,
[16:16.610 --> 16:20.650]  with like when UDP hole punching happens, I mean, that's a direct connection between you
[16:20.650 --> 16:27.630]  and the device. So, in that case, not necessarily. But if you're doing a relayed connection... so,
[16:27.630 --> 16:31.550]  even if you're not using a super device, which is some random person's camera, if you're using one
[16:31.550 --> 16:36.890]  of the vendors, relay servers, I mean, they at that point have access to everything going through
[16:36.890 --> 16:43.530]  that. So, if they're not using encryption or... if they're using encryption, often they know the key.
[16:43.750 --> 16:49.630]  So, they could very easily, you know, pick up every single thing going through that relay
[16:49.630 --> 16:57.190]  and watch it or store it or really do whatever. So, that's kind of... you know,
[16:57.190 --> 17:02.730]  that's another risk. And that's another reason why I'm not a fan of really any of this stuff going
[17:02.730 --> 17:06.970]  through any vendor-owned servers. Because you really never know what they're doing or what
[17:06.970 --> 17:12.870]  back doors might be in place that allow them to do things. There's been so many times where
[17:12.870 --> 17:19.010]  I've seen cameras advertised as being encrypted. And as I've shown, I mean, some, first of all,
[17:19.010 --> 17:25.210]  lie about it. But yeah. Like, it doesn't matter if it's encrypted if they know the key anyway.
[17:25.210 --> 17:32.230]  It really doesn't matter in that case. So, yeah. Kind of a roundabout answer, I guess. But yeah.
[17:32.230 --> 17:35.590]  They absolutely can potentially pick up everything going through it. Yeah.
[17:35.590 --> 17:40.090]  Yeah. Or even as you showed that you saw somebody's chickens coming through yours.
[17:40.150 --> 17:41.430]  Yeah, exactly.
[17:41.430 --> 17:47.730]  So, this probably dovetails right into your answer there. Are peer-to-peer devices
[17:47.730 --> 17:53.550]  fundamentally doomed in terms of internet-wide visibility? Or are there techniques that these
[17:53.550 --> 17:57.470]  could use to improve the situation or to limit exposure?
[17:58.630 --> 18:06.030]  Yeah. Like I said, I don't think peer-to-peer is inherently a bad thing. I can see the value
[18:06.030 --> 18:11.250]  of having a direct connection, especially for real-time things like video and audio.
[18:11.890 --> 18:18.850]  But if you're gonna set that up, yeah, there needs to be more protection in play.
[18:20.370 --> 18:24.410]  And I've thought about it a little bit. Like, if I were to design this sort of a thing,
[18:24.410 --> 18:27.510]  what would I want to do? And of course, you're gonna want to have
[18:29.050 --> 18:33.190]  legitimate cryptography, like a TLS sort of situation going on.
[18:35.350 --> 18:42.270]  The identity verification problem is a little bit tricky, because you might want to do something
[18:42.270 --> 18:47.930]  like trust on first use. It's not like the vendor can really issue a certificate, because that can
[18:47.930 --> 18:59.430]  be exploited. So yeah. It's possible, but it's tricky. And I think some of the ways that could
[18:59.430 --> 19:04.710]  make it more secure, like having a trust on first use sort of a thing, they're not user-friendly,
[19:04.710 --> 19:09.470]  or most people would be kind of confused or put off by it. So I think there's very little chance
[19:09.470 --> 19:12.870]  of measures like that being put in. Cool.
[19:14.970 --> 19:19.810]  So while there are ways that this could be done effectively, I would say the chances of them
[19:19.810 --> 19:24.350]  actually being rolled out by vendors are pretty slim, because convenience is always gonna kind
[19:24.350 --> 19:30.030]  of take priority, I think, with this sort of thing. And does it seem to appear to jump between
[19:30.030 --> 19:36.950]  relays, or will it sit on a single one for the entire session? I think it'll sit on one. If
[19:37.510 --> 19:42.030]  the relay suddenly drops, like say it's using a super device and someone pulls the plug on
[19:42.030 --> 19:49.230]  their camera, I think it'll re-establish the connection with another one. But otherwise,
[19:49.230 --> 19:53.690]  I think it'll basically stay on the same one as long as it possibly can.
[19:54.530 --> 20:01.170]  Cool. How are we looking over there, Sigat? Anything standing up to you for questions?
[20:01.510 --> 20:06.290]  So we got a new question. I've heard Chinese nationals constantly trying to use these to get
[20:06.350 --> 20:10.670]  a look at us, not the government, not business, just curious people. Have you seen this type of
[20:10.670 --> 20:21.810]  traffic? I haven't really seen that sort of a thing. Obviously, I've shown it's certainly
[20:22.310 --> 20:30.650]  possible. But I mean, I can't really make any accusations. I guess one thing I can kind of add
[20:30.650 --> 20:37.670]  is I have had people ask me if they think that any of this design or behavior is intentional.
[20:38.950 --> 20:46.330]  I mean, I honestly don't think that it is. I don't think that this is something that's been
[20:46.330 --> 20:53.130]  put in place deliberately to allow for this sort of thing. In terms of any vendor that I've actually
[20:53.130 --> 20:57.190]  been able to make contact with, some of the responses have shown that they're really just
[20:57.190 --> 21:03.650]  very naive when it comes to security. I mean, I've even had responses come back to me like,
[21:03.650 --> 21:07.230]  how did you get our encryption key? It's like, dude, it's right there in the firmware. And
[21:07.230 --> 21:12.550]  they're like, well, how did you get that? It's like, dude, your firmware is a zip file,
[21:12.550 --> 21:19.190]  and you let people download it. So this isn't magic. They just don't really think that people
[21:19.190 --> 21:26.310]  are going to do that sort of thing. And then the logical follow-up to this is they obfuscate it,
[21:26.310 --> 21:34.150]  right? One method of protecting these firmware files, which as I said, are basically just zip
[21:34.150 --> 21:41.790]  files, is one swapped a couple of the zip magic numbers. So all you had to do to open it up was
[21:41.790 --> 21:47.630]  swap those magic numbers back, and then it's fine. And they're like, how did you decrypt it? It's
[21:47.630 --> 21:54.730]  like, it's not encrypted. It's not encrypted. You swapped a couple numbers. So yeah, I think...
[21:55.570 --> 21:56.730]  Go ahead, sorry.
[21:56.730 --> 22:03.910]  Sorry, I was going to say, when I saw your mention about the vendor claiming that they had no API,
[22:03.910 --> 22:09.530]  it wasn't a problem. They had gone to the same school of security as some of the election
[22:09.530 --> 22:11.690]  security vendors had.
[22:12.790 --> 22:22.250]  Yeah, if I had any wish, it really would be for these companies to hire a security professional,
[22:22.250 --> 22:27.750]  like do some serious security architecting. Just because you came up with an encryption method
[22:27.750 --> 22:34.350]  over the weekend that you thought no one is ever going to break, that is our job. Like,
[22:34.350 --> 22:39.350]  we take pleasure in busting that stuff apart. So eventually, someone's going to figure it out,
[22:39.350 --> 22:48.390]  and there goes your protection. And in the case of P2P, when you're a transport layer like that,
[22:48.390 --> 22:53.550]  and you are kind of higher up in the supply chain, pushing your stuff down to all these
[22:53.550 --> 22:58.650]  different device manufacturers, who are then selling it to resellers, who are then selling
[22:58.650 --> 23:07.190]  it to users, there's a lot of impact beneath you. So you really have a responsibility to
[23:08.030 --> 23:11.850]  take this stuff seriously and invest some time into getting this stuff right.
[23:12.290 --> 23:14.810]  So if I were to get one of these cameras,
[23:14.810 --> 23:19.150]  how could I find out if I am affected by the things that you found in your research?
[23:19.590 --> 23:22.810]  That's a great question, because it is not always obvious.
[23:23.910 --> 23:28.790]  When you buy a device, first of all, I mean, the brand name doesn't mean anything, because
[23:29.490 --> 23:34.810]  who knows where it's actually coming from. Some don't actually even mention that they use
[23:34.810 --> 23:40.910]  peer-to-peer, they just use it kind of under the hood. The best way to determine if one of these
[23:40.910 --> 23:47.050]  is using the affected peer-to-peer libraries is to use Wireshark and see if it's reaching out
[23:47.050 --> 23:54.370]  to anything on UDP port 32100. And kind of to connect to that, or expand on that, if you want
[23:54.370 --> 23:59.550]  to make sure that you never have one of these devices active in your home, then you can set
[23:59.550 --> 24:06.410]  up a firewall rule to block outbound UDP port 32100, like on your router, or if you have a
[24:06.410 --> 24:16.810]  dedicated firewall appliance or something. Yeah, so you talked about the supply chain
[24:16.810 --> 24:23.170]  issues of this and the actual lack of insight and the lack of people being able to look at
[24:23.170 --> 24:28.870]  the vendor and tell whether this is affected by it or not. This is actually the third talk that
[24:28.870 --> 24:37.610]  I've moderated that's talked about these supply chain type issues where the vulnerability is so
[24:37.610 --> 24:42.470]  far up the chain that when it gets to someone, they don't even know it could be there. I mean,
[24:42.470 --> 24:47.170]  do you have any comments on just kind of that supply chain risk writ large,
[24:47.170 --> 24:51.770]  and other than the folks at the top of that chain have to be more diligent?
[24:54.090 --> 24:59.970]  I think it's going to be a continued problem for a while. Yeah, because I think people are going to
[24:59.970 --> 25:04.590]  kind of continue poking up higher and higher like this and finding more and more crazy things that
[25:04.590 --> 25:15.370]  are very widespread. And also, it's hard to fix. It's really hard to fix because even if these
[25:16.110 --> 25:21.930]  vendors start fixing things, in order for it to propagate down is going to take a long time.
[25:22.270 --> 25:28.470]  And in a lot of cases, there's no even real nice ways to update these things.
[25:28.470 --> 25:35.550]  With like the HiChip cameras, I think a great example is like SV3C, right? They are a reseller
[25:35.550 --> 25:42.010]  of HiChip. If you go on SV3C's site, they're not necessarily going to have the latest firmware
[25:42.010 --> 25:47.230]  from HiChip. Like they are also going to have to receive it from HiChip and put it on their site.
[25:47.310 --> 25:51.590]  And there are plenty of resellers that don't do that. Like they don't even offer firmware
[25:51.590 --> 25:57.210]  downloads. So if you buy a device, even though there may be a firmware available for it,
[25:57.210 --> 26:02.630]  you're just going to know to go to this reseller's site, and they're not going to have anything
[26:02.630 --> 26:06.330]  listed. And you're going to be like, well, I guess I have the latest version. And you're going to
[26:06.330 --> 26:14.970]  stay vulnerable. So it's hard to fix. Like even when things even if things do start eventually
[26:14.970 --> 26:19.110]  going in the right direction, there's going to be a lot of stuff out there that remains
[26:19.630 --> 26:25.590]  problematic. And if I just keep one of these devices on a VLAN, would I then be safe?
[26:27.210 --> 26:32.830]  No. No, you're not. That can certainly stop things like pivoting. So if someone gets a shell,
[26:32.830 --> 26:38.010]  maybe they may not be able to hit other things on the network. But someone could still steal
[26:38.010 --> 26:44.610]  the password. They can still certainly connect to it and view it. They can still potentially
[26:44.610 --> 26:51.350]  see what Wi-Fi networks are near you and get your location. It's been pretty common where I've
[26:52.510 --> 26:55.630]  expressed these concerns to people. And they're like, oh, I don't care. I mean,
[26:55.630 --> 27:00.290]  my camera is just looking at my dog. Or I'll just put it on a VLAN and, you know,
[27:00.290 --> 27:07.270]  it's like... how comfortable are you with someone still accessing this thing and either
[27:07.270 --> 27:13.250]  viewing it without you realizing it or figuring out more information about you? Like, are you
[27:13.250 --> 27:17.470]  really truly okay with that? Like, you want to stick to your guns on that one? And some people
[27:17.470 --> 27:23.490]  really don't care. They're like, yeah, let them see where I am. But I mean, I disagree with that
[27:23.490 --> 27:29.850]  mentality. And where can people get the password reset exploit that you mentioned in your
[27:29.850 --> 27:37.930]  presentation? Yeah, I'm sorry, guys. I goofed and didn't put a link in my slides. So, if you go to
[27:37.930 --> 27:45.810]  hacked.camera, I did put a link up to the High Chip Reset script as well as the Wireshark
[27:45.810 --> 27:51.810]  Dissector. And another thing that I put up is in the slide deck, there was like the flyover on the
[27:51.810 --> 27:57.490]  map where it showed where all the devices are. I have a link here that says Device Map. And if
[27:57.490 --> 28:03.150]  you click on that, it is fully interactive. You can scroll around the world and see the density
[28:03.150 --> 28:08.890]  of devices all over the place. So, you can, you know, have a blast playing with that. And do you
[28:08.890 --> 28:19.050]  have any IP cameras in your home now? Disconnected. I have a giant hoard of garbage in my closet.
[28:21.290 --> 28:28.630]  I think what I will probably do, because this is another question I get, is if these aren't safe,
[28:28.630 --> 28:36.990]  what are safe? I personally would probably build one my own. It's the sort of thing where I would
[28:36.990 --> 28:43.230]  want full control of it. Obviously, not everyone is going to be able to or willing to do that.
[28:43.230 --> 28:51.310]  So, while I haven't had a chance to look into, I think Nest is a great example, I haven't had
[28:51.430 --> 28:56.390]  a chance to look into those kind of cameras. I would imagine those are probably a little bit
[28:56.390 --> 29:02.450]  more thoughtfully designed. But I'm not gonna believe it until I put it to the test. And I
[29:02.450 --> 29:07.610]  think that's a pretty good practice. Because sometimes you never know how far down the
[29:07.610 --> 29:16.290]  goes, as this talk kind of showed. So, I personally would recommend building them yourself,
[29:16.290 --> 29:20.650]  if you can. But if not, then at least go with someone who has a legitimate
[29:20.650 --> 29:26.510]  security architecture program. Or at very least, a channel to disclose bugs. Because,
[29:26.510 --> 29:31.250]  gosh, disclosing these things to vendors, even if you manage to find out the actual
[29:31.250 --> 29:34.610]  device manufacturer, getting a response sometimes is impossible.
[29:34.610 --> 29:39.770]  Excellent. Last question for you. What should be kind of the takeaways that people
[29:39.770 --> 29:45.830]  get from this? What do you really want people to get from your presentation? And what kind of
[29:45.830 --> 29:50.350]  maybe change do you want to see going forward? Or things that people can think about from
[29:50.350 --> 29:56.550]  watching your presentation? Well, anything that
[29:57.230 --> 30:02.770]  prioritizes convenience over security is probably gonna screw you.
[30:04.610 --> 30:10.690]  Yeah. And if it is kind of prioritizing convenience, then see what it's doing. Because
[30:12.330 --> 30:18.870]  not everyone is super keen on how to do these things properly. So, it's sort of a... if someone
[30:18.870 --> 30:24.130]  is offering you some magic to make your life easier, look into what it is, really. Like,
[30:24.130 --> 30:30.870]  poke at it a little bit and make sure that it's solid. I guess that's really the biggest thing.
[30:32.810 --> 30:39.570]  Yeah. Excellent. Great. Thank you so much for doing this, Paul. When we're all done with this,
[30:39.570 --> 30:44.650]  if you could put some contact information in the track one channels, if you want people to
[30:44.650 --> 30:50.830]  be able to get in touch with you, maybe ways that they can get the scripts that you mentioned,
[30:51.270 --> 30:55.370]  anything like that so that people could continue this conversation with you would be great.
[30:55.950 --> 30:59.890]  Yeah, absolutely will do. It's been an absolute pleasure. I'm glad you guys enjoyed.
[30:59.890 --> 31:03.250]  Thank you so much for doing this, Paul. And we will be back in about another 30 minutes
[31:03.250 --> 31:06.290]  with another speaker. Sounds good. Take care.