start	end	text
1440	4240	Good afternoon, everyone, and thank you all for coming.
4240	7300	This is Abusing Peer-to-Peer to Hack 3 Million Cameras.
7340	12100	This talk is the culmination of about two years of research, so I'm very excited to
12100	13740	finally be able to share this with you all.
13740	15520	And with that, let's get started.
16520	21660	I'm going to be talking about an obscure feature lurking in IoT devices around the world.
21660	25960	Peer-to-peer is intended to make life easier for people, but it's had the nasty side effect
25960	28620	of exposing millions of devices to the internet.
28620	31380	Even those behind firewalls are not immune.
31820	35480	Hundreds of different brands are affected by this, including security cameras, alarm
35480	37740	systems, and even baby monitors.
37920	40340	But exposure is just the tip of the iceberg.
40340	44460	When hordes of insecure things get put on the internet, you can bet the end result is
44460	45960	not going to be pretty.
46080	48820	So I'm here to show you just how bad this can get.
49300	53500	By the end of this talk, you'll see how peer-to-peer devices work, the numerous ways
53500	58500	they can be exploited, and finally, how a $40 purchase from Amazon is all you need to
58500	60340	start hacking into other devices.
61500	62600	So who am I?
62600	67420	My name is Paul Marapici, I am a security researcher based out of San Jose, California,
67420	71000	and I probably spend too much time getting angry at computers.
71320	75940	I largely focus on offensive security, and I work on the red team at a certain enterprise
75940	77140	cloud company.
77360	82620	When I'm not breaking things, I make music, I dabble in photography, and I have two cats,
82620	85640	who funny enough, are the catalyst for this entire story.
87100	92020	In 2018, I adopted a pair of rescue kittens, and I wanted to keep an eye on them as they
92020	93640	slowly took over my apartment.
94200	99680	I had an old IP camera from around 2002, but this was now 2018, so I figured I could get
99680	100920	something a little better.
101320	106840	Amazon has a wide selection of IP cameras, and some are marked as Amazon's choice, and
106840	109180	there's quite a few with decent enough reviews.
109540	115920	This SV3C model, for example, is $40, and it has 4 stars with nearly 2,000 reviews,
115920	118000	so it sounds like a pretty good deal.
118420	122840	I figured this would be like any other network device, where if I wanted to view it externally,
122840	124340	I would need to forward a port.
124460	128640	But once I hooked it up, I realized I could immediately view it from my phone, no setup
128640	129620	required.
129880	133680	This shook me a little bit, because it implies it's either doing something to get around
133680	137780	my router, or it's sending my video through some third-party servers.
137780	141280	Either way, I'm freaked out, so I load up Wireshark.
141660	144760	And as we can see, this camera is very chatty.
144760	149040	It's pinging three different servers every 40 seconds, two of which are in China.
149040	153820	And as I continue watching, I start noticing that sometimes my video is being funneled
153820	156200	through mysterious servers all over the world.
156200	160940	At one point, I even see this camera talking to a Comcast IP in a different state.
161240	164880	It turns out a lot of people have noticed this sketchy behavior.
165280	170000	There are a lot of concerned reviews talking about this suspicious traffic on UDP port
170000	171400	32100.
171400	175220	Not just on my brand of camera, but on many, many different models.
175240	177120	So now I'm extremely intrigued.
177120	178520	What is this, exactly?
179640	181320	Well, this is peer-to-peer.
181320	185560	And I'm sure the name is conjuring memories of file-sharing networks like Napster and
185560	188580	Kazaa, but the context here is a little bit different.
188680	193200	In the context of IoT, peer-to-peer is a feature that lets people connect to their device from
193200	195880	anywhere in the world without any special setup.
195940	199780	You have to remember, some folks don't even know how to log into their routers, never
199780	201420	mind how to forward a port.
201420	204740	So vendors started coming up with ways to make connecting easier.
204740	209160	To achieve this, devices with peer-to-peer will automatically work around both NAT and
209160	212220	firewalls so anyone from the outside can connect in.
212220	216260	But thankfully, your device doesn't have any gaping security holes, right?
217080	219120	So where does this feature come from?
219120	223680	Peer-to-peer is not typically something that's developed in-house by device manufacturers.
223720	228180	There are actually several different players in the industry who develop peer-to-peer solutions,
228180	230300	and device makers will get it from them.
230420	234680	So this originates from higher up in the supply chain, meaning any faults in it are going
234680	236820	to propagate downward very quickly.
237140	242980	The largest is probably ThruTech, whose Kali platform is in use by over 66 million devices.
242980	247220	If you've got a Wyze camera at home, chances are it's using ThruTech's platform.
247480	253900	This talk will focus on two products in particular, CS2 Network P2P and Shenzhen Uni iLink P2P.
253900	259360	According to CS2, their product is in use by over 50 million devices, and iLink P2P
259360	262700	is actually a functionally identical clone of CS2.
262700	268220	Its market share is relatively smaller, but it's still present in over 3.6 million devices.
268880	273400	So with peer-to-peer existing in over 100 million devices, it's obviously a popular
273400	273940	feature.
273940	275840	But what are the risks here?
275840	280660	Well, primarily, peer-to-peer by its very nature is meant to expose devices.
280660	285460	And this should be pretty scary, given IoT has a pretty notorious history when it comes
285460	286580	to security.
286680	292040	But convenience always wins, so devices are now punching through your firewall by design.
292240	296940	In many cases, there's no way to turn this feature off, and anyone that has your device's
296940	300500	unique identifier, or UID, can easily connect to it.
300500	304840	I'll be demonstrating how these UIDs aren't exactly all that hard to come by.
305120	309000	These devices are typically running Linux under the hood, with everything as root, of
309000	309940	course.
309980	314440	So when you pair that with how they're also essentially online without a firewall, the
314440	317940	insanity of this whole concept really starts to set in.
317980	322700	While there are obvious risks, like spying on someone's camera or disabling their alarm
322700	326580	system, those pale in comparison to remote code execution.
326780	331820	Malware leveraging the ability to punch through firewalls could really spread like wildfire.
332560	336600	So now we know what peer-to-peer does, and we've come up with a few ways that we can
336600	338020	potentially have fun with it.
338020	342600	Let's get a bit deeper here and see what one of these peer-to-peer networks actually looks
342600	343460	like.
344540	350280	A peer-to-peer network is governed by peer-to-peer servers, and these are our gateways to
350280	351660	millions of devices.
352200	356620	These servers are imperative to this whole system working properly, and the reason for
356620	359820	this is these servers actually orchestrate everything.
359820	364800	They manage devices, and they also are what handle connections between users and their
364800	365640	devices.
365640	369400	You can basically think of these as command and control servers.
369460	373540	There are hundreds of these on the internet because manufacturers will have dedicated
373540	375680	servers for their own devices.
375960	381940	It's very common to see these hosted on cloud providers like Alibaba and AWS, and they
381940	385120	typically listen on UDP port 32100.
386260	391640	Then, of course, you have devices, and these could be anything, but the common theme here
391640	394700	is these will be 100% internet accessible.
394940	400020	A very important concept here is that all of these devices will have a UID or a unique
400020	404620	identifier, and if someone knows your UID, they can connect to your device.
404620	408500	So this isn't something that you really want falling into the wrong hands.
408680	413380	These UIDs are generated by the peer-to-peer providers and burned into the device during
413380	414300	manufacturing.
414300	418080	So if someone learns your UID, this isn't something you can change.
418420	420420	Let's have a closer look at these.
420680	425720	A UID has three separate parts, a prefix, a serial number, and a check code.
425720	430880	The prefix is basically used for product grouping, and a single vendor may have several of these
430880	435180	and their server will only respond to their own specific prefixes.
435520	439760	The serial is simply the device identifier, and these are effectively just sequential
439760	440760	numbers.
440900	443800	And finally, the check code is a security feature.
443800	448040	It's used to protect UIDs and also try to prevent device spoofing.
448040	452540	A peer-to-peer server will reject any requests where the check code is not correct.
453840	456000	And finally, there are clients.
456000	460500	A client could be any desktop or mobile app for connecting to a device.
460500	465740	It could be for viewing video, retrieving files, or even configuring an alarm system.
465800	471120	But before a client can do any of that, the user needs to put in their UID so the client
471120	472760	can make the connection.
474410	479140	And under the hood, this whole thing runs on a fairly basic UDP protocol.
479240	484060	There are control messages for setting up connections, and DRW or device read-write
484060	487300	messages that actually wrap the application data.
487500	492340	Messages are really just C structures with a 4-byte header, and a signature of this protocol
492340	493880	is its magic number.
493880	498700	The first byte of any peer-to-peer message will begin with hexadecimal F1.
498700	503880	And thanks to debug information being left in, it was fairly easy to reverse this protocol,
503880	507520	and I was actually able to create a Wireshark dissector for it.
508140	512920	This was done using a plugin called Wireshark Generic Dissector, which lets you quickly
512920	515740	write dissectors using a declarative language.
515740	520880	I'll actually be releasing this today, so if you have any devices that use P2P, you
520880	524120	can use this to get a little more insight into what's going on.
525960	528960	So, with all that, we're finally at the crux of this.
528960	531140	How does this connection actually happen?
531140	534880	Or more importantly, how does peer-to-peer punch a hole through your firewall?
534900	539480	As I mentioned, I was able to access this camera without forwarding any ports.
539540	542480	The magic trick here really isn't magic at all.
542620	547680	Peer-to-peer simply takes advantage of a particular behavior present in NAT and firewalls.
548220	552980	UDP hole punching is a way to establish direct connections in the presence of NAT.
552980	557640	For those unfamiliar with the terminology, NAT is just Network Address Translation,
557640	562840	which is used by routers to forward traffic from the internet to the proper host on the LAN.
563100	567220	The router does this by watching outbound packets and automatically creating inbound
567220	570240	rules to correctly bring the response back in.
570320	574100	The router needs to do this because if it didn't, we wouldn't be able to get responses
574100	576120	back from our requests.
576340	580600	But consider if two networks that are using NAT want to talk to each other.
580600	585560	Any packet sent to the other is going to be dropped because no forwarding rules exist.
585640	587760	So how can we get around this?
587840	591680	Well, this is actually one of the main functions of the peer-to-peer servers.
591820	595980	Both sides can use a peer-to-peer server to swap addresses with each other.
596080	600020	And at that point, they can go ahead and send packets at each other.
600020	605260	This will punch holes in their respective NATs and let traffic from the other side come through.
605460	610360	In summary, just by sending UDP packets to each other, both sides can create a direct
610600	612520	channel of communication.
613820	616560	So this demonstrates how this works.
616740	621820	When a connection request happens, the peer-to-peer servers will tell both sides the other's
621820	622760	information.
622760	626180	The device will send a packet to the client and vice versa.
626180	629720	And even though these may not actually be delivered, that doesn't matter.
629720	632320	The point here is just to open ports.
632440	636520	After both sides have done this, then they should be able to talk to each other.
637120	641120	But the problem with UDP hole punching is it doesn't always work.
641200	645860	It usually works with most home networks, but it might not work in more complicated
645860	648160	enterprise or mobile networks.
648300	652820	For this situation, a client and a device can use what's called a relay server, which
652820	657380	exists on the network specifically to help clients and devices make connections.
657700	662720	As long as both sides can connect to the same relay, then it can proxy data between them.
663720	669540	What's really fascinating is that some networks will actually use people's devices as extra
669540	671280	relays for the network.
671440	677480	And that means someone else's camera may very well be proxying your own video feed.
677480	682460	These are called super devices, and this behavior is kept secret from users.
682460	686300	They are never asked if they are okay with having their bandwidth donated.
686300	689440	And if they have quotas, this could certainly cause a problem.
689440	693660	And as sketchy as this sounds, this concept isn't actually unheard of.
693660	698960	The more standard terminology for these is super nodes, and they're a relatively common
698960	701180	occurrence in peer-to-peer software.
701480	706240	Skype actually used to do this too, but at least people had the ability to opt out of
706240	706920	that.
707060	709560	Spoiler alert, we're going to have fun with these.
710100	714060	Okay, so with the background out of the way, now we can start getting to the really good
714060	714840	stuff.
714940	718920	Since these networks are supporting millions of devices, is there anything we can do to
718920	719960	hunt them down?
719960	724260	And specifically, is there any way we can guess or generate UIDs?
725040	729840	If we want to do this, the first step is going to be to find some peer-to-peer servers.
729840	734540	Again, these are essentially gateways to devices, so finding them has a lot of value.
734720	739720	I started doing this by looking at desktop and phone apps, as these are obviously going
739720	741460	to be using a vendor's servers.
741800	746100	However, this is a bit tedious, and there is a much more efficient way to do it.
746100	749280	We can use NMAP's host detection to do this.
749540	754280	The protocol has a simple hello message, and any valid peer-to-peer server will come back
754280	755640	with an ACK message.
755640	761080	So we can configure this probe and then run it against the entire IP space of a cloud
761080	763340	provider like AWS or Alibaba.
763820	769020	AWS in particular is very kind and provides an up-to-date listing of their current IP
769020	769760	ranges.
770060	775900	I've come across 618 peer-to-peer servers since 2018, and some basic fingerprinting
775900	781280	has shown that 86% of these are CS2, and 14% are ILINK P2P.
782460	786760	So next, if we want to use these servers to find devices, we're going to need to find
786760	788460	out what prefixes they support.
788460	793880	Like before, I started looking for these in apps and even Amazon reviews, because sometimes
793880	798860	people will include their UIDs in their photos without realizing what they're doing.
799060	803920	These two reviews have 11 different UIDs, and they're using three different prefixes.
804560	809180	Sifting through these is also kind of tedious and quickly provides diminishing returns.
809180	811020	So what is a better way?
811360	815400	Well, when we try to connect to a device, the server will respond with an error code
815400	817200	if the UID isn't valid.
817200	821700	But that error code will change depending on if the prefix you asked for is valid.
821740	824460	So I wrote a script to brute force prefixes.
824460	829240	It continuously sends requests and saves any prefixes that appear to be valid.
829240	832600	There's no rate limiting or checks to prevent this sort of thing.
832600	837320	And depending on the latency between you and the server, you can find all three-letter
837320	842320	prefixes in about an hour and all four-letter prefixes in about 36 hours.
842460	846280	In total, I have found about 488 distinct prefixes.
846460	851520	And while the average server hosts about four prefixes, there are a couple that have 130.
852880	857620	So we're at a point where we've got servers and we know which prefixes they support.
857620	861440	We can also predict serial numbers because they're just sequential numbers.
861440	864900	If we want to find UIDs, the problem is now the check code,
864900	867760	which exists precisely to stop this sort of thing.
868160	871800	If the check code is off by even one letter, the UID will be rejected.
872040	873520	These are five letters long.
873520	876360	And while that's not an impossible key space to brute force,
876360	880900	it's still enough to thwart any efforts to find a large number of devices quickly.
881080	883100	So how can we get around this?
884540	887760	Well, with ILinkP2P, luck would be in our favor.
887760	892880	I found a variant of the ILinkP2P library that contained the algorithm they use to generate
892880	897700	check codes. It basically hashes a few components using a modified MD5
897700	901740	and then puts together the letters from the hash to create the check code.
901860	906460	This was apparently included in the library to do client-side UID validation,
906460	909680	which is odd given the peer-to-peer server does this anyway,
909680	912460	but someone thought it was a good idea to ship this.
912520	917220	This is a big deal because we can now generate any valid ILinkUID,
917220	921180	meaning we can now connect to any online ILink device.
921440	925160	And with this ability, we can start to do some very interesting things.
925160	928440	For one, we can now find out how many devices are online,
928440	933220	but what would be even more interesting is finding out where these devices are.
933320	936700	We can use a UID to get the IP address of a device,
936700	941140	and using that, we can approximate its location using IP geolocation.
942660	945800	So what you're seeing here is an enumeration script I wrote.
945800	949180	It generates a UID, grabs its IP from the servers,
949180	952280	and then looks it up using MaxMind's GeoLite database.
952280	955180	This is going at 10,000 requests per minute.
956300	959880	Taking this another step further, I was able to visualize this data
959880	962680	with LeafletMarkerCluster and OpenStreetMap.
962680	967760	Of the 3.6 million devices I've seen, Europe makes up about 21% of this,
967760	973120	with France, Italy, Germany, and the United Kingdom all having over 100,000 devices.
973120	979260	North America makes up about 8% of this total, with the U.S. seeing over 205,000 devices,
979260	983040	and Canada and Mexico both having over 40,000 each.
986280	990980	Finally, Asia is the most heavily impacted, with over 1.8 million devices.
991100	994920	China and Thailand alone make up more than half of the entire dataset.
996320	999420	Horrifyingly, lots of these devices use default passwords,
999420	1003200	meaning the UID is enough to gain full access to the camera.
1003200	1006380	I disclosed this to Shenzhen Uni in early 2019,
1006380	1010200	but despite multiple attempts, I never received a response back from them.
1010240	1015220	And despite this vulnerability, I've continued to see an increase in the use of iLink P2P.
1015220	1019620	In fact, thousands of new UIDs come online every single month.
1019760	1024860	CS2 doesn't appear to be affected by this vulnerability, but that's not the end of the story.
1026060	1029720	So now I have a way to directly connect to millions of cameras,
1029720	1034240	but I'm not really interested in spying on people or talking through their cameras.
1034240	1037360	That's creepy, and frankly, we're not in middle school here.
1037360	1039500	What we really want is shells.
1040000	1042640	So let's find some camera vulnerabilities.
1042960	1048060	When planning for this, I really wanted to focus on a big vendor for maximum impact.
1048060	1053320	Shenzhen High Chip Vision Technology is a major manufacturer in the IP camera industry.
1053700	1057400	They caught my attention because as I was looking into different brands,
1057400	1062520	I started to realize that a huge number of them were ultimately manufactured by HiChip.
1062520	1067750	In fact, close to 3 million of the iLink devices I have found are using HiChip prefixes.
1069160	1073060	This sort of practice is very common, where manufacturers will sell
1073060	1077360	white-labeled equipment to vendors who then resell it with their own branding.
1077360	1082160	This is a list of 50 different brands that are actually using HiChip under the hood.
1082160	1086060	So given their ubiquity, any vulnerabilities in HiChip's firmware
1086060	1088960	would be both widespread and very accessible.
1091260	1094420	So to get started, I began analyzing their firmware.
1094420	1097480	One function of interest was this read request method,
1097480	1100820	which is used to handle any commands coming in over peer-to-peer.
1100820	1106380	It even handles login, and we've got a 1024 byte buffer to read data off the wire.
1106680	1111480	The message header has a field that says how big the payload is, so of course that's validated.
1111800	1114680	To allow 10 times the size of the buffer.
1114680	1118200	Okay, so we've clearly got a buffer overflow here.
1118200	1121680	But how easy is it to exploit this? Because after all,
1121680	1125380	there have been defenses to stop exploits like this for years.
1125760	1128620	And the library doesn't seem to use any of them.
1128620	1133420	So one very reliable ROP gadget later, and we've got ourselves a system call,
1133420	1136060	and then a reverse shell with root privileges.
1137900	1140060	Obviously, any vulnerability is bad.
1140060	1143140	But the most devastating really tend to be those that are pre-auth,
1143140	1145880	because any anonymous person can exploit them.
1146020	1149420	In this case, as long as you have a UID, you can get a shell.
1149420	1152160	And we now have all the UIDs.
1153060	1157020	Once you get a shell, you can run binaries, you can browse the file system,
1157020	1159360	and you can even access the camera's password.
1159560	1163060	You can even directly invoke the camera's Wi-Fi utilities.
1163060	1165340	And here's why this is a really bad thing.
1165460	1169400	You can do a lot of really crazy things with base station MAC addresses.
1169400	1175280	Google has an entire API that uses MAC addresses to perform disturbingly accurate geolocation.
1175420	1179640	And the more information you give it, the more accurate the results are going to be.
1179640	1183580	So once you get a shell, you can use it to scan for nearby Wi-Fi networks
1183580	1186940	and potentially pinpoint the exact location of a camera.
1187220	1191180	If you want to try this yourself, check out Google's geolocation API,
1191180	1194020	feed it some MAC addresses of nearby wireless networks,
1194020	1196180	and see just how accurate it can get.
1196180	1198360	It costs literally pennies to do this.
1199880	1203960	It's hard to say exactly how many devices are affected by this vulnerability,
1203960	1207480	but given I found this bug in almost two years worth of firmware,
1207480	1210540	I think it's a pretty safe bet to say that this could be weaponized.
1210540	1214320	But thankfully, HiChip did release a patch for this in June 2020.
1215260	1217880	I did find another vulnerability worth mentioning.
1217880	1221440	It's not exploitable over P2P, but it's still pretty amusing.
1221660	1225900	Up until recently, you could anonymously reset the password of any HiChip camera
1225900	1228020	just by being on the same LAN.
1228020	1233140	The reason for this is apparently some devices don't have physical reset switches,
1233140	1238200	so instead you can just send a magic packet to the camera and it'll reset the password to admin.
1238260	1240260	I'll be releasing a script for this,
1240260	1244000	but I actually found out HiChip provided a tool to do this already,
1244000	1249760	so I'm not sure if this qualifies as an exploit per se, but have fun with this.
1251060	1253540	Okay, still got a few more tricks up my sleeve.
1253540	1255780	Let's talk about man-in-the-middle attacks.
1255780	1258200	When people hear man-in-the-middle attack,
1258200	1261800	they might associate it with something that's restricted to the local network.
1261800	1264420	Sniffing packets at a coffee shop, for example.
1264980	1267580	Peer-to-peer should be pretty scary by now,
1267580	1271880	but we haven't even talked about how it lets you intercept traffic over the internet.
1272380	1275060	This comes from the fact that, as we now know,
1275060	1279060	the peer-to-peer servers are responsible for coordinating all connections.
1279480	1283080	Clients and devices obey the orders of the peer-to-peer servers.
1283080	1289100	So, if we can influence that process in any way, we may be able to insert ourselves into a session.
1289340	1294440	This is particularly scary because despite being a transport layer for the application,
1294440	1298400	peer-to-peer doesn't actually perform any encryption or identity checks.
1298400	1301260	These measures are left entirely up to the application,
1301260	1304580	and as you can guess, most don't do a very good job of this.
1304800	1308060	In fact, some even outright lie about it.
1308080	1310780	This is a screenshot from VSTARCAM's app,
1310780	1313780	which assures you that it is building an encrypted channel,
1313780	1316600	but as you can see from the packet capture on the right,
1316600	1319460	there is absolutely no encryption happening here.
1320860	1322900	So, how do we get in the middle?
1322920	1327520	Well, once per minute, a device is going to log into its peer-to-peer servers.
1327680	1332400	This action tells the servers where the client needs to go when they request a connection.
1332560	1337020	The problem is, this login message just contains the device UID.
1337020	1340180	Absolutely no device-specific secret is used,
1340180	1342140	which means if we have a UID,
1342140	1347080	it's very easy for us to forge this login message and confuse the servers.
1347500	1351220	And if our timing is right, when the client requests a session,
1351220	1355160	the peer-to-peer server will tell them that we're the device.
1355240	1359220	And at that point, the client will happily try to authenticate to us.
1359220	1363200	And yes, that is Base64. It's always Base64.
1363660	1369540	So, we have the password, and now we can turn around and connect back to the real device.
1370480	1374520	This works with both CS2 and iLink P2P devices.
1374520	1378800	CS2 did try to patch this problem, but it's pretty easy to circumvent.
1378800	1382400	The login message is encrypted with what's called a CRC key,
1382400	1387780	but a vendor's devices all use the same CRC key, so you can just grab it right from the firmware.
1388040	1391120	And with some servers, you actually don't even need to go this far,
1391120	1396480	because it will still let you log in with the old login message, so there's not much of a point.
1396480	1400800	While this attack is certainly doable, there are a couple of drawbacks.
1400800	1406200	You need to have a specific UID to target, you need to know knowledge of the protocol,
1406200	1409500	and you actually need to wait for the person to try to connect.
1409740	1413540	However, there is another attack that has none of these requirements.
1413680	1416680	In fact, there is a way that someone with practically
1416680	1421020	zero hacking experience can start owning handfuls of devices.
1421940	1424340	Let's talk about super devices again.
1424340	1429700	These are devices in people's homes that are proxying sessions for other users.
1429760	1434680	A lot of vendors use these, so the chances of you buying a camera that will act as a super device
1434680	1439960	is pretty high. And as I said, P2P doesn't actually perform any encryption.
1440180	1443420	So what happens when a vendor's crypto sucks too?
1443820	1448500	That means that anyone can buy a device and access other people's traffic with it.
1448500	1452500	It means literally anyone on the planet can sniff your entire session
1452500	1456320	and capture your password or your video without you ever knowing.
1456440	1459900	There's no need to expend a ton of effort setting up a man-in-the-middle attack
1459900	1463280	when this exists in the product by design.
1463940	1468260	There are plenty of devices that don't even use encryption for sessions.
1468360	1471300	A little PCAP parsing can give you a raw video stream
1471300	1474660	that you can immediately watch with something like FFPlay.
1474660	1478240	And all the while, users will have no way of knowing
1478240	1481280	whether their connection is being intercepted like this.
1481280	1486240	In fact, it's a risk that they're taking every single time that they connect to their device.
1487120	1493420	As an added bonus, this has the side effect of leaking UIDs during the peer-to-peer handshake.
1493420	1497320	So alternatively, you can just take the credentials which you also probably captured
1497320	1499880	and connect back to the device yourself.
1499880	1505700	I actually developed a proof of concept of this just to collect UIDs by posing as a super device.
1505700	1513380	And by doing this, I was able to collect over 236,000 unique CS2 UIDs over the course of 10 months.
1513500	1516940	So even though CS2's check code algorithm has yet to be cracked,
1516940	1520580	this is a very reliable way for anyone to collect UIDs.
1520900	1525880	The funny thing is, CS2 actually mentioned this exact concern in a marketing deck.
1525880	1532140	They said a super device cannot spy on any data it relays because there is no API for this.
1532140	1535680	But of course, that's insane. You don't need an API to pull this off.
1535700	1539880	It's absolutely trivial to set up a camera and then leave Wireshark running
1539880	1543160	to capture every single packet flowing through that device.
1543560	1545760	So that's exactly what we're going to do.
1545760	1548400	This bullet cam is running iLink P2P.
1548400	1551160	So against my better judgment, I'm going to put this on the internet
1551700	1555460	and we'll run Wireshark for a while and see what we come back to.
1555620	1558580	Okay, so I left Wireshark running for a few hours
1558580	1561720	and we can see that this camera has stayed pretty busy.
1561720	1566360	I have the P2P dissector active so we can clearly see what it's been doing.
1566420	1569360	Each of these hello messages is the peer-to-peer servers
1569360	1573320	telling the camera to reach out and try to help someone with a session.
1573320	1577360	So this will generate some handshaking with both the client and the device.
1577560	1581060	Of particular interest is these relay packet messages,
1581060	1586340	which will actually contain a UID of the device that we're trying to relay for.
1586620	1590060	But we want to see some actual session traffic.
1590060	1594890	We can locate this by filtering for message DRW messages.
1595400	1598740	I'll go up here and apply that filter.
1606590	1609430	Sure enough, looks like we've got some traffic here.
1609430	1613770	If we actually pull up the resulting conversation here,
1613770	1616210	well, that sure looks like Base64.
1616910	1618380	If we copy that...
1622990	1625690	Yep, nice secure password there.
1626210	1629770	So there's some other information in plain text over here.
1629770	1634190	We can see some information about the camera, the firmware version,
1634190	1638630	and it looks like some other sort of name or identity information.
1639150	1640510	But what about video?
1640810	1643630	One of the ways that this DRW concept works
1643630	1648210	is there are message indexes and message channels.
1648250	1651730	And each channel is going to be used for a particular purpose.
1651730	1655470	So in this case here, it looks like there's a lot of
1656110	1660590	sort of authentication or negotiation going on on this channel zero.
1660590	1665510	But on this channel two, we start to see binary data.
1665990	1670110	So what I did here is I actually wrote a quick script
1670110	1674570	that is going to take the data from this packet capture
1674570	1678850	and just concatenate it together so we can pipe it into a video player.
1678850	1684710	So what we're going to do is just go and export packet dissections as JSON.
1684710	1689970	Call this export.json and make sure we hit packet bytes.
1690130	1691530	Save this.
1697700	1705660	And then we will go here and do node json2vid export.json.
1705660	1707860	Pipe that right into ffplay.
1708820	1712060	And we have some chickens, how about that?
1713340	1715340	So final thoughts.
1716320	1721180	I had a feeling things weren't going to be pretty when I started down this rabbit hole,
1721180	1724520	but I never could have imagined some of these things.
1724740	1727920	I've reported all of these problems to the vendors.
1727960	1730260	Shenzhen Uni never did get back to me,
1730260	1735980	and the number of devices using iLink P2P has steadily increased since I first reached out to them.
1736100	1740080	I've tried to contact a lot of vendors in China over the past few years,
1740080	1743660	and it's honestly pretty rare that I get a response at all.
1743860	1746940	So I'd also really like to give credit where it's due here,
1746940	1752600	because both CS2 Network and Hychip kept in close contact with me earlier this year,
1752600	1755780	even as the COVID situation was first emerging in China.
1756240	1759220	It was refreshing to see my concerns taken seriously,
1759220	1761560	and especially during such a difficult time.
1762160	1765700	The issues with CS2 are slated to be fixed in the next release,
1765700	1769320	and Hychip just released patches for their problems in late June.
1770460	1775080	With the warm and fuzzies over, uh, boy, things are not looking good.
1775180	1778320	Even with patches on the way, I think it's safe to say that
1778320	1781920	everything you just saw is going to be a problem for a long time.
1781920	1785080	And this is because a lot of these peer-to-peer problems
1785080	1789620	are outright architectural flaws, and they can't really be fixed retroactively.
1790100	1791840	I think even if they could be fixed,
1791840	1796220	it doesn't matter because most people don't update firmware anyway.
1796280	1800060	I've seen some devices with firmware versions going back half a decade.
1801480	1805660	In June of this year, I worked with the UK consumer watchdog group Witch
1805660	1809420	to try to get some of the affected devices pulled off of shelves.
1809540	1814120	Amazon, who sells more than 20 vulnerable brands, uh, didn't respond at all.
1814120	1818240	And eBay said to use IP cameras without an internet connection,
1818240	1821080	which isn't even possible with a good number of these.
1821080	1823340	So, you know, thanks for that advice.
1823980	1826440	Um, I do hope that this was inspiring to some of you,
1826440	1830060	because I think there's a lot of opportunity here for further research.
1830080	1834420	I think it's pretty clear that peer-to-peer is a pretty nasty vector,
1834420	1837000	and I'm sure there's a lot more vulnerabilities
1837560	1840760	in devices beyond what I've discovered on my own.
1840980	1845280	I also haven't really had a chance to dig into other peer-to-peer platforms.
1845280	1851440	For example, CalA, which is used by over 66 million devices, including Wyze cameras.
1851660	1856200	And I know they use a similar paradigm where a UID will get you device access.
1856200	1858740	So I think there's certainly opportunity there.
1858740	1861080	And while I focus my efforts on HiChip,
1861080	1864960	there are definitely other massive device manufacturers out there.
1864960	1868360	In general, I encourage folks to climb up the supply chain a bit
1868360	1873960	if you're looking for vulnerabilities that could be both widespread and potentially high impact.
1874960	1877840	I'd like to leave you with a few reverse engineering tips
1877840	1880580	that have led me to some major discoveries.
1880580	1882400	First, if you're doing reversing,
1882400	1886820	be sure to collect as many different samples and variants as you possibly can.
1886820	1890960	Run diffs against them, look for abnormal changes in file sizes.
1890960	1895760	Some may leave in debug symbols, extra logging, and alternate functionality.
1895760	1898440	So those are all new avenues of exploration.
1898880	1903240	Also, APKs are a great way to check out things with minimal effort.
1903240	1908800	Java can decompile into beautiful, readable code that can very quickly reveal interesting things.
1909020	1911000	And finally, and most importantly,
1911000	1915300	throw every single interesting file name or magic string you find into GitHub.
1915300	1916240	Seriously.
1916240	1921380	It is incredible how many people push sensitive source code to public repositories.
1921600	1924240	And this has helped me find everything from SDKs,
1924240	1927500	to documentation, to full-on source repos for firmware.
1928380	1931100	Finally, I'd like to give a shout out to the folks who published
1931100	1933260	some of the initial research on peer-to-peer.
1933260	1937260	Their work was really inspiring and key to the success of my own research.
1937260	1939040	So cheers to you guys.
1939680	1941160	And that's a wrap, my friends.
1941160	1942960	Thank you all so much for coming.
1942960	1944980	Happy hacking and be safe out there.