WEBVTT 00:25.790 --> 00:27.170 All right. 00:27.170 --> 00:29.010 Welcome back, everybody. 00:29.010 --> 00:32.350 We have another great speaker for you today. 00:32.530 --> 00:41.410 We have Paul Marapici, who's here to tell us a little bit more about his presentation, Abusing Peer-to-Peer to Hack 3 Million Cameras. 00:41.410 --> 00:43.650 Ain't nobody got time for that. 00:43.650 --> 00:45.030 How's it going, Paul? 00:45.110 --> 00:46.090 Very good. 00:46.090 --> 00:47.490 Very good to be here, guys. 00:47.490 --> 00:48.150 All right. 00:48.150 --> 00:50.470 Welcome to this Q&A. 00:50.470 --> 00:59.270 Looking forward to asking you some questions, and hopefully we'll get a whole bunch of questions for people on the Track 1 Live Q&A stream in Discord. 00:59.550 --> 01:09.210 But how about if you just kind of give us a little bit overview of yourself, who you are, 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:15.550 Yeah, sure. 01:15.610 --> 01:16.470 So, yeah. 01:16.470 --> 01:18.010 My name's Paul Marapici. 01:18.010 --> 01:21.070 I am based out of San Jose, California. 01:21.070 --> 01:33.910 And so my talk was... so basically, I got some IP cameras, and it's pretty much assumed that these things are insecure, I think, when people pick these up. 01:33.910 --> 01:36.850 But I just kind of wanted to see how far that I could take it. 01:36.870 --> 01:42.730 And I basically ended up finding a way to access literally millions of cameras. 01:43.150 --> 01:44.690 So, I mean, I figured it would be bad. 01:44.690 --> 01:49.270 I figured, you know, maybe someone could target maybe a couple, or maybe the crypto wasn't so good. 01:49.270 --> 01:55.650 But yeah, you could take it to the extreme of extremes and start jacking these things left and right. 01:56.190 --> 01:56.850 Awesome. 01:56.870 --> 02:01.230 So, I think we also have something else to do with you first. 02:01.230 --> 02:05.470 But let me see if Siget has any ideas about what we might want to do with you. 02:06.370 --> 02:09.530 Well, it just so happens that Paul here is a first-time speaker. 02:09.530 --> 02:17.690 And every time we 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:21.990 Yeah, that's not the word I was looking for. 02:22.450 --> 02:24.830 So, English has been a second language to me. 02:27.410 --> 02:30.890 So, we will commemorate the event with a shot. 02:30.890 --> 02:33.750 So, I'd love to ship a bottle off to you. 02:33.750 --> 02:35.990 But unfortunately, we've got to rely on your own stock. 02:35.990 --> 02:40.730 And so, if you can join me in a quick drink, we'll christen this talk for you. 02:40.730 --> 02:43.430 So, yeah, cheers, gentlemen. 02:49.030 --> 02:50.390 Awesome stuff. 02:50.390 --> 02:51.510 All right. 02:51.810 --> 02:54.350 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:04.170 So, let's see. 03:04.790 --> 03:06.610 Questions that we have coming in. 03:06.610 --> 03:12.250 Do you see any coming through on the Discord chat already there, Siget? 03:12.250 --> 03:12.950 It might be kind of a... 03:12.950 --> 03:13.770 We have one. 03:13.770 --> 03:14.670 We have one. 03:14.670 --> 03:16.330 Thanks for your research. 03:16.330 --> 03:31.130 Are any of the exploitable elements you discussed, such as the direct connection with UIDs or traffic analysis, the supernode required for the P2P environment to operate effectively from a user point of view, or would alternative architectures, which is cameras operators could use, 03:31.130 --> 03:35.030 utilize third-party access controls, end-to-end content encryption? 03:35.090 --> 03:40.630 Basically, how ought a P2P environment be designed to be both convenient and secure? 03:41.210 --> 03:42.150 Right. 03:43.390 --> 03:49.110 In terms of the super device ones, I would say that's not necessary to the whole thing. 03:49.170 --> 03:53.050 That's pretty much entirely to kind of help the network. 03:53.590 --> 04:01.050 Vendors will actually put up a bunch of their own relay servers, and honestly, not that that's any better, because they have access to that traffic. 04:02.710 --> 04:05.250 So, that's not necessary. 04:05.250 --> 04:08.170 It just kind of helps when people need connections, I guess. 04:09.730 --> 04:15.250 I don't think the peer-to-peer aspect is inherently bad. 04:15.290 --> 04:24.770 It just kind of comes down to, you know, making sure that the traffic is protected, making sure that there's identity verification going on, so you know who you're actually talking to. 04:25.570 --> 04:27.430 I think those things could help a lot. 04:27.430 --> 04:32.830 And, of course, the fact you can predict or otherwise obtain UIDs is a huge problem. 04:33.610 --> 04:39.470 So, you might want a way to protect those a little bit more, or have the ability to change them. 04:40.150 --> 04:43.450 I mean, personally, I don't think I would want a device doing this. 04:43.690 --> 04:46.190 It kind of depends on people's risk tolerance. 04:46.790 --> 04:52.570 But there are certainly a lot of ways that they could have made this, you know, a little bit less gross. 04:53.670 --> 04:54.470 Awesome. 04:54.570 --> 05:03.910 Yeah, in your presentation, you even did a really quick demo at the end where you captured some binary and put that through the video feed. 05:03.910 --> 05:05.150 You got to see some chickens. 05:07.430 --> 05:09.750 So, that was kind of interesting. 05:09.750 --> 05:17.190 Through your research, did you ever, let's say, see anything interesting when you were kind of checking out to see what was coming through? 05:17.190 --> 05:20.690 Or did you not really look at the video streams all that much? 05:22.350 --> 05:24.270 Yeah, I've had a few interesting things. 05:24.270 --> 05:30.990 I mean, obviously, as part of the research, sometimes you have to go and try to connect to something or see how far you can get. 05:31.750 --> 05:38.270 I certainly avoided, like, you know, more personal, like, in-home stuff. 05:38.290 --> 05:41.170 Because, I mean, I'm not trying to spy on people. 05:42.110 --> 05:51.690 Some of the more, I guess, guilt-free ones you can say are, like, you know, someone might have one of, 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 --> 05:59.690 And he emailed me. 05:59.690 --> 06:02.070 He says, hey, you know, I found your research. 06:02.170 --> 06:04.870 And what happened was my camera got stolen. 06:05.430 --> 06:10.550 And he was continuing to watch the camera with the app on his phone. 06:10.550 --> 06:12.870 And he said, all of a sudden, this thing came back online. 06:13.350 --> 06:18.550 So, is there any way that you could, like, you know, steal the password or find the IP address or anything like that? 06:18.550 --> 06:21.990 I said, yeah, give me the UID and I'll see what I can do. 06:22.270 --> 06:25.390 And not two hours later, you know, I started up the man-in-the-middle attack. 06:25.390 --> 06:32.690 Not two hours later, the thing connects to me and drops the password and the IP address, of course. 06:32.930 --> 06:40.790 So, you know, I guess if you're a thief, stealing a peer-to-peer camera is a major OPSEC fail. 06:41.450 --> 06:45.290 It's gonna seriously leak exactly where you are. 06:45.290 --> 06:50.450 So, I sent that back to him and I don't know what's happened of that. 06:50.650 --> 06:55.830 But, you know, it felt pretty cool to be able to use an exploit like that to actually help someone. 06:55.870 --> 07:01.490 Like, you know, hey, you lost your camera, but here's the password if you want to take a look and see what's going on in there. 07:01.950 --> 07:09.090 Yeah, that was pretty interesting how you were showing that you can use some of the Google's geolocation to find out where the camera is. 07:09.090 --> 07:12.470 And I'm guessing that's similar to what you did for your friend there. 07:12.470 --> 07:15.770 Just how close were you able to figure out? 07:15.770 --> 07:21.310 Is it, like, within a few meters of where the camera actually is with the geolocation? 07:21.570 --> 07:22.350 Yeah. 07:22.350 --> 07:23.690 Oh, man. 07:23.930 --> 07:30.630 So, I suspect the way that that works is, like, obviously Google drives around for Street View. 07:30.630 --> 07:37.410 And I imagine that as they're doing that, they're collecting every single base station ID that they see. 07:37.430 --> 07:44.870 So, depending on what they're seeing, you know, obviously they're storing the exact location that they're at when they do that. 07:45.870 --> 07:52.550 Depending on the MAC addresses that you give that API, and I think there's a whole bunch of other parameters to kind of, like, fine-tune that. 07:52.550 --> 07:58.430 So, depending on what you give it, they can figure out, like, exactly where they were when they picked it up. 07:59.550 --> 08:07.030 I've put 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:09.490 Like, yeah, it's pretty dead on. 08:09.550 --> 08:14.310 And, I mean, I imagine in all cases, it might not be that accurate. 08:14.310 --> 08:23.610 It's probably going to matter on the density of the Wi-Fi networks around you, because, of course, that's going to give them more ways to improve the accuracy. 08:24.550 --> 08:26.090 But, yeah. 08:26.090 --> 08:27.010 Oh, man. 08:27.310 --> 08:29.030 They store a lot of data on that. 08:29.030 --> 08:32.910 And as I said, it is dirt cheap to make those requests. 08:32.910 --> 08:35.630 Like, it's a couple cents per call or something like that. 08:35.890 --> 08:38.070 And anyone can start doing that, yeah. 08:38.070 --> 08:39.410 That's all crazy. 08:39.490 --> 08:42.950 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 --> 08:56.990 Ah, that's a good question. 08:58.370 --> 09:00.170 I'm honestly not sure. 09:00.710 --> 09:05.690 I have only done UDP hole-punching stuff with IPv4 scenarios. 09:05.690 --> 09:08.190 I admittedly haven't tried it in IPv6. 09:08.630 --> 09:12.510 I don't... admittedly, I don't know too much about IPv6 just yet. 09:12.750 --> 09:15.170 And, of course, I mean, these devices are so primitive. 09:15.170 --> 09:17.730 I've yet to come across one that actually uses it. 09:19.150 --> 09:20.790 So, I'm not sure. 09:20.850 --> 09:22.170 That's a really good question. 09:22.170 --> 09:23.910 Sorry, I can't answer. 09:24.410 --> 09:33.230 Yeah, one of the common questions that we have been asking speakers is, what types of research could somebody else build on top of yours? 09:33.230 --> 09:37.530 Or maybe, where could somebody go further with the research that you've done? 09:37.530 --> 09:43.150 And maybe checking out the IPv6 could be something that somebody else could take a look into as well. 09:43.430 --> 09:45.090 Yeah, that would be really cool. 09:45.530 --> 09:50.690 Another one that... some guy actually already reached out to me saying he wanted to look into it. 09:50.690 --> 09:57.830 I did mention ThruTech's Kali platform, which is probably the biggest peer-to-peer vendor that I know. 09:59.050 --> 10:05.110 I'd love for people to kind of start poking at that and kind of see if they have any similar problems. 10:05.110 --> 10:06.070 Or who knows? 10:06.070 --> 10:07.610 I mean, maybe they're in better shape. 10:07.610 --> 10:10.310 But we don't know until we poke, so... 10:10.310 --> 10:10.890 Yeah. 10:11.890 --> 10:16.550 Sigurd, do we have any anything else coming in from the Discord channel for Paul? 10:17.090 --> 10:18.550 Yeah, so we have a question. 10:18.550 --> 10:23.070 Can you explain how a device can connect to a supernode without knowing the UID? 10:24.650 --> 10:37.450 Yeah, so when a device needs to make a connection, it'll ask the P2P servers to do a relay request. 10:37.450 --> 10:43.030 Like, if it can't do a peer-to-peer connection, it'll send a request to basically pull down a list of relays. 10:43.290 --> 10:49.790 That will return an array of IPs and ports, and then it'll try to connect to each one of those. 10:49.790 --> 10:50.890 And eventually, it'll find one. 10:50.890 --> 10:52.750 One of those may be a supernode. 10:53.250 --> 10:58.550 So, when someone's trying to connect to a device, that's how that works. 10:59.210 --> 10:59.730 Cool. 10:59.730 --> 11:01.250 I hope that answers your question. 11:02.210 --> 11:18.190 Yeah, and SivarakuKitten followed up with a second question and said that, I understand why this super device proxying would be useful, even said, insert huge air quotes here, for finding a route out of your own internal network. 11:18.190 --> 11:23.990 But why would anyone want or need to proxy traffic via Joe Random's camera on the internet? 11:23.990 --> 11:26.750 What use case would such a method enable? 11:27.550 --> 11:33.610 I think it is just basically taking the load off of the vendor servers. 11:33.810 --> 11:40.990 If they have, you know, a million devices and there's only like two or three relay servers, then those are going to have a lot of heavy lifting. 11:40.990 --> 11:45.950 And of course, those are going to have limited bandwidth and just limited everything, really. 11:46.130 --> 11:56.890 So, it's kind of just, again, to add more relays to the vendor's network to provide the support for more people to make connections if necessary. 11:58.330 --> 12:01.550 The vendors could also just buy more relay servers. 12:01.590 --> 12:07.450 With this architecture, there's really not a limit to the number of relays that a vendor could put in their network. 12:07.790 --> 12:12.010 But it is more cost effective for them to offload that on the users. 12:12.010 --> 12:16.710 So, really, that's the biggest reason, is it saves the vendors money. 12:17.710 --> 12:22.110 And again, it's actually not an uncommon thing in peer-to-peer architecture. 12:22.250 --> 12:25.150 Supernodes are pretty much everywhere. 12:25.570 --> 12:27.150 Skype used to do this, too. 12:27.610 --> 12:32.150 And it just, you know, kind of helps with the redundancy of the network, I suppose. 12:32.550 --> 12:37.110 Yeah, I think you said in the presentation that even with Skype, you could opt out of it. 12:37.730 --> 12:42.810 Yeah, but with these devices, I mean, I have never seen something disclaim that it does this. 12:42.810 --> 12:51.250 So, you would have to notice, like, man, this thing is throwing off a lot of traffic and connecting to the other side of the world when I'm not using it for some reason, you know? 12:51.250 --> 12:51.930 Yeah. 12:52.010 --> 12:57.110 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:05.290 Yes. 13:05.510 --> 13:14.070 So, I mean, I've mentioned smart doorbells and baby monitors, but those are really cameras under the hood, just kind of rebranded. 13:14.310 --> 13:21.730 But in terms of, like, real other use cases, I've also seen these peer-to-peer libraries implemented in NATs. 13:21.810 --> 13:22.650 Not NATs, sorry. 13:22.650 --> 13:23.290 God. 13:23.830 --> 13:24.710 NASes. 13:25.150 --> 13:27.030 So, yeah, network storage devices. 13:27.030 --> 13:37.830 So, I guess if people have a NAS in their home and they want to connect to it, this will give them the ability to do that, which is horrifying because that's just screaming for, you know, huge data theft. 13:38.050 --> 13:44.310 But one thing that I discovered actually pretty late in the game here was alarm systems. 13:44.310 --> 13:51.670 And there is actually a specific company that I think loads this into all of their alarms. 13:51.670 --> 13:56.950 And the traffic going to these things is entirely in clear text. 13:56.950 --> 14:06.730 So, you can do, the super device attack, and you can sit and you can see these, like, streams of configuration data for alarm systems. 14:06.810 --> 14:10.290 And, you know, that's insane. 14:10.690 --> 14:14.550 Yeah, that sounds like a whole other topic of research right there as well. 14:15.010 --> 14:15.650 Yeah, yeah. 14:15.650 --> 14:27.230 So, if anyone wants to dig into that, I mean, feel free to... I don't want to elaborate on it right here, but feel free to hit me up and I may be able to kind of give people some more insight into that. 14:27.230 --> 14:30.430 Yeah, maybe if somebody talks to you, you can say, 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:49.630 Yeah, so I have a question about, do you have an estimate of how much traffic was being routed through those relayed devices rather than the super nodes? 14:53.450 --> 14:55.990 I don't have an actual figure. 14:56.070 --> 15:04.910 I will say, at least with CS2, I do know that to some degree, it tries to keep track of how often it's running. 15:05.410 --> 15:09.390 And I think after it's done a session, it might shut off for a little while. 15:10.230 --> 15:22.230 But I don't think that there's actually a limit per se, because I'm pretty sure, you know, if you connect to it and you just want to stay connected for all day or whatever, I don't see a reason why it would drop you. 15:22.530 --> 15:26.250 So, that is theoretically unlimited. 15:27.550 --> 15:35.650 When I've let packet captures run before, I mean, even just in the matter of a couple hours, I've definitely seen a couple hundred megs go through easily. 15:36.270 --> 15:41.370 So, yeah, it can get up there pretty quickly, because it's video data, you know? 15:41.970 --> 15:50.070 And even when the video isn't flowing, there's still constant kind of like heartbeat messages going back and forth. 15:50.070 --> 15:52.410 It's constantly generating traffic in the meantime. 15:52.410 --> 15:56.910 But when the video starts going through, of course, that's going to be a little bit more heavy. 15:57.610 --> 16:02.990 This seems like a fun one for you, maybe you'll be able to expound on it a little bit. 16:03.530 --> 16:06.590 Is the full video feed going back to the vendor? 16:10.270 --> 16:11.150 Yes. 16:11.150 --> 16:14.370 I mean, honestly... so, here's the thing. 16:14.370 --> 16:21.610 With peer-to-peer, with like when UDP hole punching happens, I mean, that's a direct connection between you and the device. 16:21.610 --> 16:24.210 So, in that case, not necessarily. 16:24.770 --> 16:37.610 But if you're doing a relayed connection... so, even if you're not using a super device, which is some random person's camera, if you're using one of the vendors, relay servers, I mean, they at that point have access to everything going through that. 16:37.710 --> 16:43.530 So, if they're not using encryption or... if they're using encryption, often they know the key. 16:43.750 --> 16:54.090 So, they could very easily, you know, pick up every single thing going through that relay and watch it or store it or really do whatever. 16:54.490 --> 16:58.390 So, that's kind of... you know, that's another risk. 16:58.430 --> 17:04.590 And that's another reason why I'm not a fan of really any of this stuff going through any vendor-owned servers. 17:04.590 --> 17:09.910 Because you really never know what they're doing or what back doors might be in place that allow them to do things. 17:11.570 --> 17:15.870 There's been so many times where I've seen cameras advertised as being encrypted. 17:16.150 --> 17:20.150 And as I've shown, I mean, some, first of all, lie about it. 17:20.210 --> 17:22.330 But yeah. 17:22.330 --> 17:25.210 Like, it doesn't matter if it's encrypted if they know the key anyway. 17:25.210 --> 17:27.590 It really doesn't matter in that case. 17:27.790 --> 17:29.910 So, yeah. 17:30.010 --> 17:31.870 Kind of a roundabout answer, I guess. 17:31.870 --> 17:32.230 But yeah. 17:32.230 --> 17:35.270 They absolutely can potentially pick up everything going through it. 17:35.270 --> 17:35.590 Yeah. 17:35.590 --> 17:35.910 Yeah. 17:35.910 --> 17:40.090 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:45.670 So, this probably dovetails right into your answer there. 17:46.090 --> 17:52.010 Are peer-to-peer devices fundamentally doomed in terms of internet-wide visibility? 17:52.010 --> 17:57.470 Or are there techniques that these could use to improve the situation or to limit exposure? 17:58.630 --> 17:59.570 Yeah. 17:59.570 --> 18:04.730 Like I said, I don't think peer-to-peer is inherently a bad thing. 18:04.730 --> 18:11.250 I can see the value 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:22.310 And I've thought about it a little bit. 18:22.310 --> 18:25.730 Like, if I were to design this sort of a thing, what would I want to do? 18:25.730 --> 18:33.190 And of course, you're gonna want to have legitimate cryptography, like a TLS sort of situation going on. 18:35.350 --> 18:44.470 The identity verification problem is a little bit tricky, because you might want to do something like trust on first use. 18:44.470 --> 18:48.870 It's not like the vendor can really issue a certificate, because that can be exploited. 18:50.790 --> 18:53.330 So yeah. 18:53.730 --> 18:56.610 It's possible, but it's tricky. 18:56.810 --> 19:08.190 And I think some of the ways that could make it more secure, like having a trust on first use sort of a thing, they're not user-friendly, or most people would be kind of confused or put off by it. 19:08.190 --> 19:11.350 So I think there's very little chance of measures like that being put in. 19:12.070 --> 19:12.870 Cool. 19:14.970 --> 19:26.650 So while there are ways that this could be done effectively, I would say the chances of them actually being rolled out by vendors are pretty slim, because convenience is always gonna kind of take priority, I think, with this sort of thing. 19:27.390 --> 19:33.570 And does it seem to appear to jump between relays, or will it sit on a single one for the entire session? 19:34.470 --> 19:36.290 I think it'll sit on one. 19:36.510 --> 19:46.130 If the relay suddenly drops, like say it's using a super device and someone pulls the plug on their camera, I think it'll re-establish the connection with another one. 19:47.510 --> 19:53.690 But otherwise, I think it'll basically stay on the same one as long as it possibly can. 19:54.530 --> 19:55.370 Cool. 19:56.150 --> 19:58.430 How are we looking over there, Sigat? 19:58.430 --> 20:01.170 Anything standing up to you for questions? 20:01.510 --> 20:03.190 So we got a new question. 20:03.710 --> 20:09.610 I've heard Chinese nationals constantly trying to use these to get a look at us, not the government, not business, just curious people. 20:09.730 --> 20:11.290 Have you seen this type of traffic? 20:15.070 --> 20:18.510 I haven't really seen that sort of a thing. 20:20.390 --> 20:23.230 Obviously, I've shown it's certainly possible. 20:23.790 --> 20:27.570 But I mean, I can't really make any accusations. 20:28.810 --> 20:37.670 I guess one thing I can kind of add is I have had people ask me if they think that any of this design or behavior is intentional. 20:38.950 --> 20:43.030 I mean, I honestly don't think that it is. 20:43.330 --> 20:49.070 I don't think that this is something that's been put in place deliberately to allow for this sort of thing. 20:50.770 --> 20:59.490 In terms of any vendor that I've actually been able to make contact with, some of the responses have shown that they're really just very naive when it comes to security. 21:00.330 --> 21:04.970 I mean, I've even had responses come back to me like, how did you get our encryption key? 21:04.970 --> 21:06.990 It's like, dude, it's right there in the firmware. 21:07.050 --> 21:08.970 And they're like, well, how did you get that? 21:09.290 --> 21:14.370 It's like, dude, your firmware is a zip file, and you let people download it. 21:14.370 --> 21:16.950 So this isn't magic. 21:17.350 --> 21:20.830 They just don't really think that people are going to do that sort of thing. 21:21.170 --> 21:26.930 And then the logical follow-up to this is they obfuscate it, right? 21:27.990 --> 21:38.630 One method of protecting these firmware files, which as I said, are basically just zip files, is one swapped a couple of the zip magic numbers. 21:38.690 --> 21:44.730 So all you had to do to open it up was swap those magic numbers back, and then it's fine. 21:44.730 --> 21:47.490 And they're like, how did you decrypt it? 21:47.490 --> 21:48.630 It's like, it's not encrypted. 21:48.630 --> 21:49.590 It's not encrypted. 21:49.590 --> 21:51.450 You swapped a couple numbers. 21:52.710 --> 21:54.730 So yeah, I think... 21:55.570 --> 21:56.730 Go ahead, sorry. 21:56.730 --> 22:05.370 Sorry, I was going to say, when I saw your mention about the vendor claiming that they had no API, it wasn't a problem. 22:05.370 --> 22:11.690 They had gone to the same school of security as some of the election security vendors had. 22:12.790 --> 22:24.630 Yeah, if I had any wish, it really would be for these companies to hire a security professional, like do some serious security architecting. 22:24.990 --> 22:34.250 Just because you came up with an encryption method over the weekend that you thought no one is ever going to break, that is our job. 22:34.250 --> 22:36.730 Like, we take pleasure in busting that stuff apart. 22:37.090 --> 22:42.670 So eventually, someone's going to figure it out, and there goes your protection. 22:43.310 --> 22:59.410 And in the case of P2P, when you're a transport layer like that, and you are kind of higher up in the supply chain, pushing your stuff down to all these different device manufacturers, who are then selling it to resellers, who are then selling it to users, 22:59.410 --> 23:04.470 there's a lot of impact beneath you. 23:04.470 --> 23:11.850 So you really have a responsibility to take this stuff seriously and invest some time into getting this stuff right. 23:12.290 --> 23:19.150 So if I were to get one of these cameras, 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:31.810 When you buy a device, first of all, I mean, the brand name doesn't mean anything, because who knows where it's actually coming from. 23:32.250 --> 23:37.170 Some don't actually even mention that they use peer-to-peer, they just use it kind of under the hood. 23:37.650 --> 23:50.050 The best way to determine if one of these is using the affected peer-to-peer libraries is to use Wireshark and see if it's reaching out to anything on UDP port 32100. 23:50.390 --> 24:08.570 And kind of to connect to that, or expand on that, if you want to make sure that you never have one of these devices active in your home, then you can set up a firewall rule to block outbound UDP port 32100, like on your router, or if you have a dedicated firewall appliance or something. 24:11.650 --> 24:27.330 Yeah, so you talked about the supply chain issues of this and the actual lack of insight and the lack of people being able to look at the vendor and tell whether this is affected by it or not. 24:27.470 --> 24:41.730 This is actually the third talk that I've moderated that's talked about these supply chain type issues where the vulnerability is so far up the chain that when it gets to someone, they don't even know it could be there. 24:42.270 --> 24:51.770 I mean, do you have any comments on just kind of that supply chain risk writ large, and other than the folks at the top of that chain have to be more diligent? 24:54.090 --> 24:56.870 I think it's going to be a continued problem for a while. 24:57.590 --> 25:05.950 Yeah, because I think people are going to kind of continue poking up higher and higher like this and finding more and more crazy things that are very widespread. 25:07.330 --> 25:11.630 And also, it's hard to fix. 25:11.630 --> 25:21.930 It's really hard to fix because even if these 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:34.410 With like the HiChip cameras, I think a great example is like SV3C, right? 25:34.410 --> 25:37.070 They are a reseller of HiChip. 25:37.090 --> 25:43.170 If you go on SV3C's site, they're not necessarily going to have the latest firmware from HiChip. 25:43.170 --> 25:47.230 Like they are also going to have to receive it from HiChip and put it on their site. 25:47.310 --> 25:50.330 And there are plenty of resellers that don't do that. 25:50.330 --> 25:52.330 Like they don't even offer firmware downloads. 25:52.330 --> 26:03.190 So if you buy a device, even though there may be a firmware available for it, you're just going to know to go to this reseller's site, and they're not going to have anything listed. 26:03.190 --> 26:05.490 And you're going to be like, well, I guess I have the latest version. 26:05.630 --> 26:07.210 And you're going to stay vulnerable. 26:07.570 --> 26:11.870 So it's hard to fix. 26:11.870 --> 26:20.430 Like even when things even if things do start eventually going in the right direction, there's going to be a lot of stuff out there that remains problematic. 26:21.370 --> 26:25.590 And if I just keep one of these devices on a VLAN, would I then be safe? 26:27.210 --> 26:27.930 No. 26:27.930 --> 26:28.990 No, you're not. 26:29.110 --> 26:31.570 That can certainly stop things like pivoting. 26:31.570 --> 26:35.410 So if someone gets a shell, maybe they may not be able to hit other things on the network. 26:35.650 --> 26:38.830 But someone could still steal the password. 26:38.830 --> 26:42.250 They can still certainly connect to it and view it. 26:42.610 --> 26:48.630 They can still potentially see what Wi-Fi networks are near you and get your location. 26:49.210 --> 26:54.070 It's been pretty common where I've expressed these concerns to people. 26:54.070 --> 26:55.370 And they're like, oh, I don't care. 26:55.370 --> 26:57.510 I mean, my camera is just looking at my dog. 26:57.690 --> 27:12.610 Or I'll just put it on a VLAN and, you know, it's like... how comfortable are you with someone still accessing this thing and either viewing it without you realizing it or figuring out more information about you? 27:12.610 --> 27:14.530 Like, are you really truly okay with that? 27:14.530 --> 27:16.390 Like, you want to stick to your guns on that one? 27:16.630 --> 27:18.690 And some people really don't care. 27:18.690 --> 27:20.270 They're like, yeah, let them see where I am. 27:20.270 --> 27:24.550 But I mean, I disagree with that mentality. 27:25.410 --> 27:30.870 And where can people get the password reset exploit that you mentioned in your presentation? 27:31.750 --> 27:33.250 Yeah, I'm sorry, guys. 27:33.250 --> 27:36.530 I goofed and didn't put a link in my slides. 27:36.530 --> 27:46.890 So, if you go to hacked.camera, I did put a link up to the High Chip Reset script as well as the Wireshark Dissector. 27:47.150 --> 27:54.190 And another thing that I put up is in the slide deck, there was like the flyover on the map where it showed where all the devices are. 27:54.350 --> 27:57.090 I have a link here that says Device Map. 27:57.090 --> 28:00.010 And if you click on that, it is fully interactive. 28:00.010 --> 28:05.070 You can scroll around the world and see the density of devices all over the place. 28:05.230 --> 28:08.210 So, you can, you know, have a blast playing with that. 28:08.550 --> 28:11.090 And do you have any IP cameras in your home now? 28:13.510 --> 28:14.330 Disconnected. 28:16.070 --> 28:19.050 I have a giant hoard of garbage in my closet. 28:21.290 --> 28:29.750 I think what I will probably do, because this is another question I get, is if these aren't safe, what are safe? 28:31.710 --> 28:35.690 I personally would probably build one my own. 28:35.690 --> 28:38.650 It's the sort of thing where I would want full control of it. 28:39.450 --> 28:43.230 Obviously, not everyone is going to be able to or willing to do that. 28:43.230 --> 28:52.950 So, while I haven't had a chance to look into, I think Nest is a great example, I haven't had a chance to look into those kind of cameras. 28:52.950 --> 28:57.910 I would imagine those are probably a little bit more thoughtfully designed. 28:58.230 --> 29:01.910 But I'm not gonna believe it until I put it to the test. 29:01.910 --> 29:04.330 And I think that's a pretty good practice. 29:04.330 --> 29:10.650 Because sometimes you never know how far down the goes, as this talk kind of showed. 29:11.110 --> 29:17.150 So, I personally would recommend building them yourself, if you can. 29:17.150 --> 29:23.130 But if not, then at least go with someone who has a legitimate security architecture program. 29:23.130 --> 29:25.930 Or at very least, a channel to disclose bugs. 29:26.030 --> 29:34.610 Because, gosh, disclosing these things to vendors, even if you manage to find out the actual device manufacturer, getting a response sometimes is impossible. 29:34.610 --> 29:35.710 Excellent. 29:36.410 --> 29:37.670 Last question for you. 29:37.670 --> 29:41.250 What should be kind of the takeaways that people get from this? 29:41.250 --> 29:44.770 What do you really want people to get from your presentation? 29:44.770 --> 29:48.130 And what kind of maybe change do you want to see going forward? 29:48.130 --> 29:51.750 Or things that people can think about from watching your presentation? 29:54.850 --> 30:02.770 Well, anything that prioritizes convenience over security is probably gonna screw you. 30:04.610 --> 30:05.050 Yeah. 30:05.050 --> 30:10.010 And if it is kind of prioritizing convenience, then see what it's doing. 30:10.290 --> 30:16.350 Because not everyone is super keen on how to do these things properly. 30:16.610 --> 30:23.910 So, it's sort of a... if someone is offering you some magic to make your life easier, look into what it is, really. 30:23.910 --> 30:27.190 Like, poke at it a little bit and make sure that it's solid. 30:28.470 --> 30:30.870 I guess that's really the biggest thing. 30:32.810 --> 30:33.430 Yeah. 30:33.430 --> 30:34.190 Excellent. 30:34.710 --> 30:35.510 Great. 30:35.510 --> 30:37.410 Thank you so much for doing this, Paul. 30:37.810 --> 30:55.370 When we're all done with this, if you could put some contact information in the track one channels, if you want people to be able to get in touch with you, maybe ways that they can get the scripts that you mentioned, anything like that so that people could continue this conversation with you would be great. 30:55.950 --> 30:57.190 Yeah, absolutely will do. 30:57.190 --> 30:58.630 It's been an absolute pleasure. 30:58.630 --> 30:59.890 I'm glad you guys enjoyed. 30:59.890 --> 31:01.310 Thank you so much for doing this, Paul. 31:01.310 --> 31:04.310 And we will be back in about another 30 minutes with another speaker. 31:04.770 --> 31:05.630 Sounds good. 31:05.630 --> 31:06.290 Take care.