Abusing P2P to Hack 3 Million Cameras
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Marrapese, Paul
Question and Answer session for Paul Marrapese - Abusing P2P to Hack 3 Million Cameras
 All right. Welcome back everybody. We have another great speaker for you today. We have Paul Merra PC 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 1 live Q&A stream and 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 Merra PC. 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 mean, 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, again, is any ideas about what we might want to do with you? Well 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 you. So we will commemorate the event with a shot. So I'd love to ship a bottle off to you, but unfortunately we better 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 look at that underway. That's a pretty big shot you got there, so yeah. So let's see. Questions that we have coming in. Do you see any coming through on the Discord chat already there? So yeah, it might be kind of a. We have one, we have one thanks for your research or any of the exploitable elements you discuss 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 alternative architectures, which is cameras operators could use, utilize third party access controls and end end content encryption. Basically, how could how 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, 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. 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, you know, 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 get to see some chickens. Yeah. 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 and 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 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 and 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 off-sick fail. For sure. It's going to 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 want to take a look and see what's going on in there. Yeah, that was pretty interesting how you are 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 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 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. But yeah, oh man, they store a lot of data on that. And as I said, it is dirt cheap to make those requests. It's a couple cents per call or something like that. So anyone can start doing that. 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? That's a good question. I am 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, 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 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 through text Kale platform, which is probably the biggest peer-to-peer vendor that I know. I 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. Siga, 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 Supernode without knowing the UID? Yeah. So when a device needs to make a connection, it'll ask the peer-to-peer 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 Supernode. So when someone's trying to connect to a device, that's how that works. Cool. I hope that answers your question. Yeah, and Sivir, we can follow it 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 a million devices and there's only two or three relay servers, then those are going to have a lot of heavy lifting. And of course, those are going to 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. Devices 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 mean, 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. So Chappy asks, you explored cameras primarily in your research. Did you try other IoT device types or what other types of devices used 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 NASs, not NASs, sorry, 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, you know, 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, you know, the super device attack and you can sit and you can see these like streams of configuration data for alarm systems. And, you know, that's, that's insane. Yeah, that sounds like a whole nother topic of research right there as well. Yeah, yeah. So, you know, 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, some more insight into that. Yeah, maybe if somebody talks to you, you can say, well, the company name rhymes with, let me look into that. So, you seeing any good questions coming in on the channel? Yes, I have a question about, do you have an estimate of how much traffic was being routed through those, those relayed devices rather than super nodes? I don't have an actual figure. I will say, at least would see us to, I do know that to some degree it tries to keep track of how often it's running. 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, 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. So that is theoretically unlimited. When I've let packet captures run before, I mean, even just in the matter of a couple of hours, I've definitely seen like a couple hundred nodes go through easily. So yeah, it can get up there pretty quickly because it's video data, you know, it's, and even when the video isn't flowing, there's still constant, like kind of like 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, you know, 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, like, so here's the thing with peer to peer with 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, you know, some random person's camera, if you're using one of the like 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, you know, pick up every single thing going through that relay and then watch it or store it or really do whatever. So that's kind of, you know, 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 backdoors might be in place that allow them to do things. It's there's been so many times where I've seen cameras advertise as being encrypted. And as I, as I've shown, I mean, some first of all lie about it. 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. 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 going to 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 want to do? And, you know, of course, you're going to want to have legitimate cryptography, like like a TLS sort of situation going on. The identity verification problem is a little bit tricky because you might want to do something like trust on first use. It's not like the vendor can really issue a certificate because you don't, you know, 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 like, you know, kind of confused or put off by it. So I think there's very little chance of measures like that being put in. 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 going to kind of 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 like pulls the plug on their camera, I think it'll reestablish the connection with another one. But otherwise, I think it'll basically, you know, stay on the same one as long as it possibly can. Cool. How are we looking over there? Say, 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? I haven't really seen that sort of a thing. It's obviously I've shown it 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, this isn't magic. They just don't really think that people are going to 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, one swapped a couple of the 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 numbers. So yeah, I think, go ahead, sorry. I was going to say, when I saw your talk, you're mentioned about the vendor claiming that they had no API, therefore, 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 known is ever going to break, that is our job. We take pleasure in busting that stuff apart. So eventually, someone's going to figure it out and there goes your protection. 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, 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, 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 32100 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 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 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. 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? I think it's going to be a continued problem for a while. 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. 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 going to take a long time. And in a lot of cases, there's no even real nice ways to update these things with the high chip cameras. I think a great example is like SV3C, right? They are a reseller of high chip. If you go on SV3C's site, they're not necessarily going to have the latest firmware from high chip. They are also going to have to receive it from high 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 going to know to go to this reseller site and they're not going to have anything listed and you're going to be like, well, I guess I have the latest version and you're going to stay vulnerable. So it's hard to fix. 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. 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 Wi-Fi 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? Are you really truly okay with that? You want to stick to your guns on that one? And some people really don't care to 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 wire shark dissector. And another thing that I put up is in the slide deck, there was like a 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 have a blast playing with that. And do you have any IP cameras in your home now? Disconnected. I have a giant herd of garbage in my closet. I think what I will probably do, because 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 kind 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 a legitimate security architecture program or at very least a channel to disclose bugs. Because gosh, 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? 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. Because 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 we're all done with this, if you could put some contact information in the Track 1 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, it 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 30 minutes with another speaker. Sounds good. Take care.
 All right.  Welcome back everybody.  We have another great speaker for you today.  We have Paul Merra PC 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 1 live Q&A stream and 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 Merra PC.  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 mean, 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, again, is any ideas about what we might want to do with you?  Well 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 you.  So we will commemorate the event with a shot.  So I'd love to ship a bottle off to you, but unfortunately we better 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 look at that underway.  That's a pretty big shot you got there, so yeah.  So let's see.  Questions that we have coming in.  Do you see any coming through on the Discord chat already there?  So yeah, it might be kind of a.  We have one, we have one thanks for your research or any of the exploitable elements you discuss  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 alternative architectures,  which is cameras operators could use, utilize third party access controls and end end content  encryption.  Basically, how could how 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, 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.  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, you know, 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 get to see some chickens.  Yeah.  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 and 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 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 and 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 off-sick fail.  For sure.  It's going to 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 want to take a look and  see what's going on in there.  Yeah, that was pretty interesting how you are 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 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 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.  But yeah, oh man, they store a lot of data on that.  And as I said, it is dirt cheap to make those requests.  It's a couple cents per call or something like that.  So anyone can start doing that.  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?  That's a good question.  I am 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, 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 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 through text Kale platform, which is probably the biggest peer-to-peer vendor  that I know.  I 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.  Siga, 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 Supernode without knowing the UID?  Yeah.  So when a device needs to make a connection, it'll ask the peer-to-peer 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 Supernode.  So when someone's trying to connect to a device, that's how that works.  Cool.  I hope that answers your question.  Yeah, and Sivir, we can follow it 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 a million devices and there's only two or three relay servers, then those  are going to have a lot of heavy lifting.  And of course, those are going to 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.  Devices 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 mean, 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.  So Chappy asks, you explored cameras primarily in your research.  Did you try other IoT device types or what other types of devices used 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 NASs, not NASs, sorry, 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,  you know, 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, you know, the super device attack and you can sit and you can see these  like streams of configuration data for alarm systems.  And, you know, that's, that's insane.  Yeah, that sounds like a whole nother topic of research right there as well.  Yeah, yeah.  So, you know, 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, some more insight into that.  Yeah, maybe if somebody talks to you, you can say, well, the company name rhymes with,  let me look into that.  So, you seeing any good questions coming in on the channel?  Yes, I have a question about, do you have an estimate of how much traffic was being  routed through those, those relayed devices rather than super nodes?  I don't have an actual figure.  I will say, at least would see us to, I do know that to some degree it tries to keep  track of how often it's running.  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, 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.  So that is theoretically unlimited.  When I've let packet captures run before, I mean, even just in the matter of a couple  of hours, I've definitely seen like a couple hundred nodes go through easily.  So yeah, it can get up there pretty quickly because it's video data, you know, it's, and  even when the video isn't flowing, there's still constant, like kind of like 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, you know, 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, like, so here's the thing with peer to peer with 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, you know, some random person's camera,  if you're using one of the like 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, you know, pick up every single thing going through that relay  and then watch it or store it or really do whatever.  So that's kind of, you know, 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 backdoors  might be in place that allow them to do things.  It's there's been so many times where I've seen cameras advertise as being encrypted.  And as I, as I've shown, I mean, some first of all lie about it.  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.  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 going to 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 want to do?  And, you know, of course, you're going to want to have legitimate cryptography, like  like a TLS sort of situation going on.  The identity verification problem is a little bit tricky because you might want to do something  like trust on first use.  It's not like the vendor can really issue a certificate because you don't, you know,  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 like, you know, kind  of confused or put off by it.  So I think there's very little chance of measures like that being put in.  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  going to kind of 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 like pulls  the plug on their camera, I think it'll reestablish the connection with another one.  But otherwise, I think it'll basically, you know, stay on the same one as long as it possibly  can.  Cool.  How are we looking over there?  Say, 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?  I haven't really seen that sort of a thing.  It's obviously I've shown it 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, this isn't magic.  They just don't really think that people are going to 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,  one swapped a couple of the 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 numbers.  So yeah, I think, go ahead, sorry.  I was going to say, when I saw your talk, you're mentioned about the vendor claiming  that they had no API, therefore, 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 known  is ever going to break, that is our job.  We take pleasure in busting that stuff apart.  So eventually, someone's going to figure it out and there goes your protection.  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, 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, 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 32100 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 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 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.  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?  I think it's going to be a continued problem for a while.  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.  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 going to take a long time.  And in a lot of cases, there's no even real nice ways to update these things with the  high chip cameras.  I think a great example is like SV3C, right?  They are a reseller of high chip.  If you go on SV3C's site, they're not necessarily going to have the latest firmware from high  chip.  They are also going to have to receive it from high 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 going to know to go to this reseller site and they're not going to have anything  listed and you're going to be like, well, I guess I have the latest version and you're  going to stay vulnerable.  So it's hard to fix.  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.  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 Wi-Fi 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?  Are you really truly okay with that?  You want to stick to your guns on that one?  And some people really don't care to 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 wire shark dissector.  And another thing that I put up is in the slide deck, there was like a 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 have a blast playing with that.  And do you have any IP cameras in your home now?  Disconnected.  I have a giant herd of garbage in my closet.  I think what I will probably do, because 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 kind 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 a legitimate security architecture  program or at very least a channel to disclose bugs.  Because gosh, 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?  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.  Because 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 we're all done with this, if you could put some contact information in the Track  1 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, it 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 30 minutes with another speaker.  Sounds good.  Take care.
DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_0_971.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_972_1019.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_1020_1067.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_1068_1907.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_1908_2699.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_2700_6119.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_6120_9215.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_9216_9311.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_9312_9539.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_9540_40355.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_40356_41771.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_41772_41975.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_41976_42035.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_42036_42371.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_42372_42419.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_42420_42503.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_42504_42563.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_42564_42815.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_42816_43007.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_43008_43667.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_43668_43835.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_43836_43883.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_43884_43979.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_43980_44135.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_44136_44219.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_44220_44831.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_44832_44939.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_44940_45119.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_45120_45335.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_45336_45467.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_45468_45599.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_45600_45731.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_45732_45827.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_45828_46415.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_46416_46619.png DEF_CON_Safe_Mode_-_Paul_Marrapese_-_Abusing_P2P_t_JyEpuQyqtbU_46620_46706.png