All right, welcome back everybody. We have another great speaker for you today. We have Paul Maripisi, who's here to tell us a little bit more about his presentation, abusing peer-to-peer to hack 3 million cameras.

Ain't nobody got time for that. How's it going, Paul? Very good, very good to be here, guys. All right, welcome to this Q&A. Looking forward to asking you some questions and hopefully we'll get a whole bunch of questions from people on the Track One Live Q&A stream in Discord. 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, anything so that people can kind of get a good idea about what your presentation was about? Yeah, sure. So yeah, my name's Paul Maripisi. I am based out of San Jose, California.

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. But I just kind of wanted to see how far that I could take it. And I basically ended up finding a way to access literally millions of cameras.

So I figured it would be bad. I figured maybe someone could target maybe a couple or maybe the crypto wasn't so good. But yeah, you can take it to the extreme of extremes and start jacking these things left and right. Awesome. So I think we also have something else to do with you first,

but let me see if Sigat has any ideas about what we might want to do with you. Well, it just so happens that Paul here is a first-time speaker. And every time we join someone to the whole speaker crowd at DEF CON, we commiserate the, or not commiserate, celebrate.

Yeah, that's not the word I was looking for. So English has been a second language to me. So we will commemorate the event with a shot. So I'd love to ship a bottle off to you, but unfortunately we've got to rely on your own stock. And so if you can join me in a quick drink, we'll christen this talk for you.

Yeah. Cheers. Cheers, gentlemen. Awesome stuff. All right. So now we get that underway. That's a pretty big shot you got there, Sigat.

So let's see. Questions that we have coming in. Do you see any coming through on the Discord chat already there, Sigat? Might be kind of a- We have one. We have one. Thanks for your research. Are any of the exploitable elements you discussed, such as the direct connection with UIDs

or traffic analysis, the super node required for the P2P environment to operate effectively from a user point of view? Or would alternative architectures, which this camera's operators could use, utilize third-party access controls and end-to-end content encryption? Basically, how ought a P2P environment be designed to be both convenient and secure?

Right. In terms of the super device ones, I would say that's not necessary to the whole thing. That's pretty much entirely to kind of help the network. 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.

So that's not necessary. It just kind of helps when people need connections, I guess. I don't think the peer-to-peer aspect is inherently bad. It just kind of comes down to 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. I think those things could help a lot. And of course, the fact you can predict or otherwise obtain UIDs is a huge problem. So you might want a way to protect those a little bit more or have the ability to change them.

I mean, personally, I don't think I would want a device doing this. It kind of depends on people's risk tolerance. But there are certainly a lot of ways that they could have made this a little bit less gross. Awesome. 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. You got to see some chickens. So that was kind of interesting. 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 or did you not really look at the video streams all that much?

Yeah, I've had a few interesting things. 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. I certainly avoided more personal, like in-home stuff because I mean, I'm not trying to spy on people.

Some of the more, I guess, guilt-free ones you can say are like someone might have one of like a landscape or a more public area which feels a little bit less creepy. One thing that does come to mind, I had a guy reach out to me a couple of weeks ago and he emailed me, he says,

hey, I found your research and what happened was my camera got stolen and he was continuing to watch the camera with the app on his phone. And he said, all of a sudden, this thing came back online. So is there any way that you could like, steal the password or find the IP address or anything like that? I said, yeah, give me the UID

and I'll see what I can do. And not two hours later, I started up the man in the middle attack, not two hours later, the thing connects to me and drops the password and the IP address, of course. So I guess if you're a thief, stealing a peer-to-peer camera is a major obstacle.

For sure. It's gonna seriously leak exactly where you are. So, I mean, I sent that back to him and I don't know what's happened with that, but it felt pretty cool to be able to use an exploit like that to actually help someone. Like, hey, you lost your camera, but here's the password if you wanna take a look and see what's going on in there.

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. And I'm guessing that's similar to what you did for your friend there. Just how close were you able to figure out? Is it like within a few meters of where the camera actually is with the geolocation?

Yeah, oh man. So I suspect the way that that works is like obviously Google drives around for a street view. And I imagine that as they're doing that, they are collecting every single base station ID that they see. So depending on what they're seeing,

obviously they're storing the exact location that they're at when they do that. 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. So depending on what you give it, they can figure out like exactly where they were when they picked it up. I've put in like some of my own Mac addresses

and I've been very unhappy with what I've seen. And that it's like, yeah, it's pretty dead on. And I mean, I imagine in all cases, it might not be that accurate. It's probably gonna matter on the density of the wifi networks around you because of course that's gonna give them more ways

to improve the accuracy. But yeah, oh man, they store a lot of data on that. And as I said, it is dirt cheap to make those requests. Like it's a couple cents per call or something like that. So, and anyone can start doing that, yeah. That's all crazy. Yeah, it looks like Spherical Kitten

has a question for you. The whole firewall, whole punching stuff seems to be primarily an IPv4 related technique. Does any of this peer-to-peer stuff work on an IPv6 only network? Oh, that's a good question. I'm honestly not sure.

I have only done UDP whole punching stuff with IPv4 scenarios. I admittedly haven't tried it in IPv6. I don't, admittedly, I don't know too much about IPv6 just yet. And of course, I mean, these devices are so primitive. I've yet to come across one that actually uses it. So I'm not sure.

That's a really good question. I'm sorry, I can't answer. 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? Or maybe where could somebody go further with the research that you've done? And maybe checking out the IPv6 could be something

that somebody else could take a look into as well. Yeah, that would be really cool. Another one that some guy actually already reached out to me saying he wanted to look into it. I did mention ThroughTech's Calais platform, which is probably the biggest peer-to-peer vendor that I know. I'd love for people to kind of start poking at that

and kind of see if they have any similar problems or who knows? I mean, maybe they're in better shape, but we don't know until we poke, so. Sega, do we have anything else coming in from the Discord channel for Paul? Yeah, so we have a question. Can you explain how a device can connect to a super node

without knowing the UID? Yeah. So when a device needs to make a connection, it'll ask the P2P servers to do a relay request. If it can't do a peer-to-peer connection, it'll send a request to basically pull down

a list of relays. That will return an array of IPs and ports, and then it'll try to connect to each one of those, and eventually it'll find one. One of those may be a super node. So when someone's trying to connect to a device, that's how that works. Cool. I hope that answers your question.

Yeah, and Sverk, we're getting 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. But why would anyone want or need to proxy traffic

via Joe Random's camera on the internet? What use case would such a method enable? I think it is just basically taking the load off of the vendor servers. If they have, you know, a million devices, and there's only like two or three relay servers, then those are gonna have a lot of heavy lifting,

and of course those are gonna have limited bandwidth, and just limited everything really. 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. The vendors could also just buy more relay servers.

With this architecture, there's really not a limit to the number of relays that a vendor could put in their network, but it is more cost effective for them to offload that on the users. So really that's the biggest reason, is it saves the vendor's money. And again, it's actually not an uncommon thing

in peer-to-peer architecture. Supernodes are pretty much everywhere. Skype used to do this too. And it just kind of helps with the redundancy of the network, I suppose. Yeah, I think you said in the presentation that even with Skype you could opt out of it. Yeah, but with these devices, I have never seen something disclaiming that it does this.

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, but I'm not using it for some reason. Yeah, so Chappy asks, you explored cameras primarily in your research. Did you try other IoT device types or what other types of devices

use this peer-to-peer technique? Yes, so I mean, I've mentioned smart doorbells and baby monitors, but those are really cameras under the hood, just kind of rebranded. But in terms of like real other use cases, I've also seen these peer-to-peer libraries implemented in NATs, not NATs, sorry, God, NASs.

So yeah, network storage devices. 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 huge data theft. But one thing that I discovered actually pretty late

in the game here was alarm systems. And there is actually a specific company that I think loads this into all of their alarms. And the traffic going to these things is entirely in clear text. 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. And that's insane. Yeah, that sounds like a whole nother topic of research right there as well. Yeah, yeah. 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. Yeah, maybe if somebody talks to you, you can say, well, the company name rhymes with. We can look into that. So are you seeing any good questions coming in on the channel? 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? I don't have an actual figure. 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. And I think after it's done a session, it might shut off for a little while, but I don't think that there's actually a limit per se, because I'm pretty sure 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.

So that is theoretically unlimited. When I've let packet captures run before, I mean, even just in the matter of a couple hours, I've definitely seen like a couple hundred minutes go through easily. So yeah, it can get up there pretty quickly because it's video data.

Even when the video isn't flowing, there's still constant heartbeat messages going back and forth. It's constantly generating traffic in the meantime, but when the video starts going through, of course that's going to be a little bit more heavy. This seems like a fun one for you and maybe you'll be able to expound on it a little bit.

Is the full video feed going back to the vendor? Yes, I mean, honestly, so here's the thing, with peer-to-peer, like when UDP hole punching happens, I mean, that's a direct connection between you and the device.

So in that case, not necessarily. 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. So if they're not using encryption or if they're using encryption, often they know the key.

So they could very easily pick up every single thing going through that relay and watch it or store it or really do whatever. So that's kind of, that's another risk. And that's another reason why I'm not a fan

of really any of this stuff going through any vendor-owned servers, because you really never know what they're doing or what back doors might be in place that allow them to do things. There's been so many times where I've seen cameras advertise as being encrypted. And as I've shown, I mean, some, first of all, lie about it, but yeah, like it doesn't matter

if it's encrypted if they know the key anyway. Like it really doesn't matter in that case. So yeah, kind of a roundabout answer, I guess. But yeah, they absolutely can potentially pick up everything going through it, yeah. Yeah, or even as you showed that you saw somebody's chickens coming through yours.

Yeah, exactly. So this probably dovetails right into your answer there. Are peer-to-peer devices fundamentally doomed in term of internet-wide visibility or are there techniques that these vendors could use to improve the situation or to limit exposure? Yeah, I mean, I don't, like I said,

I don't think peer-to-peer is inherently a bad thing. I can see the value of having a direct connection, especially for real-time things like video and audio. But if you're gonna set that up, yeah, there needs to be more protection in play.

I've thought about it a little bit. Like if I were to design this sort of a thing, what would I wanna do? And of course, you're gonna wanna have legitimate cryptography, like a TLS situation going on. The identity verification problem is a little bit tricky because you might wanna do something

like trust on first use. It's not like the vendor can really issue a certificate because that can be exploited. So yeah, it's possible, but it's tricky. 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. So I think there's very little chance of measures like that being put in. Cool. 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 kinda take priority, I think, with this sort of thing. And does it seem to appear to jump between relays or will it sit on a single one for the entire session? I think it'll sit on one. 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 reestablish the connection with another one. But otherwise, I think it'll basically stay on the same one as long as it possibly can. Cool. How are we looking over there, SIGAD? Anything standing up to you for questions?

So we got a new question that, I've heard Chinese nationals constantly trying to use these to get a look at us, not the government, not business, just curious people. Have you seen this type of traffic? Um, I haven't really seen that sort of a thing.

It's, obviously I've shown it's certainly possible, but I mean, I can't really make any accusations. 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. I mean, I honestly don't think that it is.

I don't think that this is like, you know, something that's been put in place deliberately to allow for this sort of thing. 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.

I mean, I've even had responses come back to me, like, how did you get our encryption key? It's like, dude, it's right there in the firmware. And they're like, well, how did you get that? It's like, dude, your firmware is a zip file and you let people download it. So like, this isn't magic. They just don't really think that people are gonna do that sort of thing.

And then the logical follow-up to this is they obfuscate it, right? One method of protecting these firmware files, which as I said, are basically just zip files, is one swapped a couple of those zip magic numbers. So all you had to do to open it up

was swap those magic numbers back and then it's fine. And they're like, how did you decrypt it? It's like, it's not encrypted. It's not encrypted. You swapped a couple of numbers. So yeah, I think, go ahead, sorry. Sorry, I was gonna say, when I saw your talk, your mention about the vendor claiming

that they had no API, therefore it wasn't a problem. I wonder if they had gone to the same school of security as some of the election security vendors had, so. Yeah, if I had any wish, it really would be for these companies to hire a security professional,

like do some serious security architecting, 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. We take pleasure in busting that stuff apart. So eventually, someone's gonna figure it out and there goes your protection.

And when you're, 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, it really, there's a lot of impact beneath you.

So you really have a responsibility to take this stuff seriously and invest some time into getting this stuff right. 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? That's a great question,

because it is not always obvious. 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. Some don't actually even mention that they use peer-to-peer, they just use it kind of under the hood. 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 32.100, and kind of to connect to that or expand on that. If you wanna 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 32.100 on your router, or if you have a dedicated firewall appliance or something. Yeah, so you talked about the supply chain issues of this and the actual lack of insight

and the lack of people to be able to look at the vendor and tell whether this is affected by it or not. 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. I mean, do you have any comments on just kind of that supply chain writ large and other than the folks at the top of that chain have to be more diligent? I think it's gonna be a continued problem for a while. Yeah, because I think people are gonna kind of continue

poking up higher and higher like this and finding more and more crazy things that are very widespread. And also, it's hard to fix. It's really hard to fix because even if these vendors start fixing things, in order for it to propagate down

is gonna take a long time. And in a lot of cases, there's no even real nice ways to update these things. With the Hi-chip cameras, I think a great example is SV3C, right? They are a reseller of Hi-chip. If you go on SV3C's site, they're not necessarily going to have

the latest firmware from Hi-chip. They are also gonna have to receive it from Hi-chip and put it on their site. And there are plenty of resellers that don't do that. They don't even offer firmware downloads. So if you buy a device, even though there may be a firmware available for it, you're just gonna know to go to this reseller's site

and they're not gonna have anything listed. And you're gonna be like, well, I guess I have the latest version and you're gonna stay vulnerable. So it's hard to fix. Even if things do start eventually going in the right direction, there's gonna be a lot of stuff out there that remains problematic.

And if I just keep one of these devices on a VLAN, would I then be safe? No, no, you're not. That can certainly stop things like pivoting. So if someone gets a shell, maybe they may not be able to hit other things on the network, but someone could still steal the password. They can still certainly connect to it and view it.

They can still potentially see what wifi networks are near you and get your location. It's been pretty common where I've expressed these concerns to people and they're like, oh, I don't care. I mean, my camera is just looking at my dog or I'll just put it on a VLAN. And 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? Like, are you really truly okay with that? Like, you wanna stick to your guns on that one? And some people really don't care to like, yeah, let them see where I am.

But I mean, I disagree with that mentality. And where can people get the password reset exploit that you mentioned in your presentation? Yeah, I'm sorry guys. I goofed and didn't put a link in my slides. 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. 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. I have a link here that says device map. And if you click on that, it is fully interactive. You can scroll around the world

and see the density of devices all over the place. So you can, you know, have a blast playing with that. And do you have any IP cameras in your home now? Disconnected. I have a giant hoard of garbage in my closet.

I think what I will probably do, cause this is another question I get is if these aren't safe, what are safe? I personally would probably build one my own. It's the sort of thing where I would want full control of it. Obviously not everyone is going to be able to

or willing to do that. 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 kinds of cameras. I would imagine those are probably a little bit more thoughtfully designed, but I'm not going to believe it until I put it to the test.

And I think that's a pretty good practice because sometimes you never know how far down the rabbit hole goes as this talk kind of showed. So I personally would recommend building them yourself if you can, but if not, then at least go with someone who has like a legitimate security architecture program

or at very least a channel to disclose bugs. Because gosh, like disclosing these things to vendors, even if you manage to find out the actual device manufacturer, getting a response sometimes is impossible. Excellent. Last question for you. What should be kind of the takeaways that people get from this?

What do you really want people to get from your presentation and what kind of maybe change do you want to see going forward or things that people can think about from watching your presentation? Um, well, anything that prioritizes convenience over security is probably going to screw you.

Yeah, and if it is kind of prioritizing convenience, then see what it's doing. Cause not everyone is super keen on how to do these things properly. So it's sort of a, if someone is offering you some magic to make your life easier,

look into what it is really, like poke at it a little bit and make sure that it's solid. I guess that's really the biggest thing. And yeah. Excellent. Great. Thank you so much for doing this, Paul. When you're, 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. Yeah, absolutely will do. It's been an absolute pleasure. I'm glad you guys enjoyed.

Thank you so much for doing this, Paul. And we will be back in about another 30 minutes with another speaker. Sounds good. Take care.