All right. Welcome back, everybody. We have another great speaker for you today.
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. 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 for people on the Track 1 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 Marapici. 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, you know, maybe someone
could target maybe a couple, or maybe the crypto wasn't so good. But yeah, you could 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
Siget 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. So, yeah, cheers, gentlemen.
Awesome stuff. All right. So, now we get that underway.
That's a pretty big shot you got there, Siget.
So, let's see. Questions that we have coming in. Do you see any coming through on the
Discord chat already there, Siget? It 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 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,
utilize third-party access controls, 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, 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 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, like, you know, 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, you know, someone might have one of,
like, a landscape or a more public area, which feels, you know, a little bit less creepy.
One thing that does come to mind... I had a guy reach out to me a couple weeks ago.
And he emailed me. He says, hey, you know, 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, you know, 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, you know, 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, you know, I guess if you're a thief, stealing a peer-to-peer
camera is a major OPSEC fail. It's gonna seriously leak exactly where you are. So,
I sent that back to him and I don't know what's happened of that. But, you know, it felt pretty
cool to be able to use an exploit like that to actually help someone. 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. 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 Street View. And I imagine that as
they're doing that, they're collecting every single base station ID that they see. So, depending on
what they're seeing, you know, 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 in that.
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. Like,
it's a couple cents per call or something like that. 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, hole-punching stuff seems to be primarily an IPv4-related technique.
Does any of this peer-to-peer stuff work on an IPv6-only network?
Ah, that's a good question. I'm honestly not sure. I have only done UDP hole-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.
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 ThruTech's Kali 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...
Yeah. Sigurd, do we have any 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 P2P servers to do a
relay request. Like, 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 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. 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 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 vendors 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, you know, 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 disclaim 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 when I'm not using it
for some reason, you know? 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. NASes. 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,
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 insane. Yeah, that sounds like a whole other 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...
Sagan, 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, 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 hours,
I've definitely seen a couple hundred megs go through easily. So, yeah, it can get up there
pretty quickly, because it's video data, you know? And even when the video isn't flowing,
there's still constant 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 a little bit more heavy. This seems like a fun one for you,
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,
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 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, you know, pick up every single thing going through that relay
and 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
back doors might be in place that allow them to do things. There's been so many times where
I've seen cameras advertised 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.
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 terms of internet-wide visibility? Or are there techniques that these
could use to improve the situation or to limit exposure?
Yeah. 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.
And 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 of course, you're gonna want to have
legitimate cryptography, 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 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 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 pulls the plug on
their camera, I think it'll re-establish 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, Sigat? Anything standing up to you for questions?
So we got a new question. 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. 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 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 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, is 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.
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. They had gone to the same school of security as some of the election
security vendors had.
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. Like,
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, 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 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, like 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 being 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 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 like the HiChip cameras, I think a great example is like SV3C, right? They are a reseller
of HiChip. If you go on SV3C's site, they're not necessarily going to have the latest firmware
from HiChip. Like they are also going to have to receive it from HiChip and put it on their site.
And there are plenty of resellers that don't do that. Like 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's 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. 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. 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, 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? Like, are you
really truly okay with that? Like, you want to stick to your guns on that one? And some people
really don't care. They're 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, 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 gonna 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
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 gonna 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.
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 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.