[00:01.440 --> 00:04.240]  Good afternoon, everyone, and thank you all for coming.
[00:04.240 --> 00:07.300]  This is Abusing Peer-to-Peer to Hack 3 Million Cameras.
[00:07.340 --> 00:12.100]  This talk is the culmination of about two years of research, so I'm very excited to
[00:12.100 --> 00:13.740]  finally be able to share this with you all.
[00:13.740 --> 00:15.520]  And with that, let's get started.
[00:16.520 --> 00:21.660]  I'm going to be talking about an obscure feature lurking in IoT devices around the world.
[00:21.660 --> 00:25.960]  Peer-to-peer is intended to make life easier for people, but it's had the nasty side effect
[00:25.960 --> 00:28.620]  of exposing millions of devices to the internet.
[00:28.620 --> 00:31.380]  Even those behind firewalls are not immune.
[00:31.820 --> 00:35.480]  Hundreds of different brands are affected by this, including security cameras, alarm
[00:35.480 --> 00:37.740]  systems, and even baby monitors.
[00:37.920 --> 00:40.340]  But exposure is just the tip of the iceberg.
[00:40.340 --> 00:44.460]  When hordes of insecure things get put on the internet, you can bet the end result is
[00:44.460 --> 00:45.960]  not going to be pretty.
[00:46.080 --> 00:48.820]  So I'm here to show you just how bad this can get.
[00:49.300 --> 00:53.500]  By the end of this talk, you'll see how peer-to-peer devices work, the numerous ways
[00:53.500 --> 00:58.500]  they can be exploited, and finally, how a $40 purchase from Amazon is all you need to
[00:58.500 --> 01:00.340]  start hacking into other devices.
[01:01.500 --> 01:02.600]  So who am I?
[01:02.600 --> 01:07.420]  My name is Paul Marapici, I am a security researcher based out of San Jose, California,
[01:07.420 --> 01:11.000]  and I probably spend too much time getting angry at computers.
[01:11.320 --> 01:15.940]  I largely focus on offensive security, and I work on the red team at a certain enterprise
[01:15.940 --> 01:17.140]  cloud company.
[01:17.360 --> 01:22.620]  When I'm not breaking things, I make music, I dabble in photography, and I have two cats,
[01:22.620 --> 01:25.640]  who funny enough, are the catalyst for this entire story.
[01:27.100 --> 01:32.020]  In 2018, I adopted a pair of rescue kittens, and I wanted to keep an eye on them as they
[01:32.020 --> 01:33.640]  slowly took over my apartment.
[01:34.200 --> 01:39.680]  I had an old IP camera from around 2002, but this was now 2018, so I figured I could get
[01:39.680 --> 01:40.920]  something a little better.
[01:41.320 --> 01:46.840]  Amazon has a wide selection of IP cameras, and some are marked as Amazon's choice, and
[01:46.840 --> 01:49.180]  there's quite a few with decent enough reviews.
[01:49.540 --> 01:55.920]  This SV3C model, for example, is $40, and it has 4 stars with nearly 2,000 reviews,
[01:55.920 --> 01:58.000]  so it sounds like a pretty good deal.
[01:58.420 --> 02:02.840]  I figured this would be like any other network device, where if I wanted to view it externally,
[02:02.840 --> 02:04.340]  I would need to forward a port.
[02:04.460 --> 02:08.640]  But once I hooked it up, I realized I could immediately view it from my phone, no setup
[02:08.640 --> 02:09.620]  required.
[02:09.880 --> 02:13.680]  This shook me a little bit, because it implies it's either doing something to get around
[02:13.680 --> 02:17.780]  my router, or it's sending my video through some third-party servers.
[02:17.780 --> 02:21.280]  Either way, I'm freaked out, so I load up Wireshark.
[02:21.660 --> 02:24.760]  And as we can see, this camera is very chatty.
[02:24.760 --> 02:29.040]  It's pinging three different servers every 40 seconds, two of which are in China.
[02:29.040 --> 02:33.820]  And as I continue watching, I start noticing that sometimes my video is being funneled
[02:33.820 --> 02:36.200]  through mysterious servers all over the world.
[02:36.200 --> 02:40.940]  At one point, I even see this camera talking to a Comcast IP in a different state.
[02:41.240 --> 02:44.880]  It turns out a lot of people have noticed this sketchy behavior.
[02:45.280 --> 02:50.000]  There are a lot of concerned reviews talking about this suspicious traffic on UDP port
[02:50.000 --> 02:51.400]  32100.
[02:51.400 --> 02:55.220]  Not just on my brand of camera, but on many, many different models.
[02:55.240 --> 02:57.120]  So now I'm extremely intrigued.
[02:57.120 --> 02:58.520]  What is this, exactly?
[02:59.640 --> 03:01.320]  Well, this is peer-to-peer.
[03:01.320 --> 03:05.560]  And I'm sure the name is conjuring memories of file-sharing networks like Napster and
[03:05.560 --> 03:08.580]  Kazaa, but the context here is a little bit different.
[03:08.680 --> 03:13.200]  In the context of IoT, peer-to-peer is a feature that lets people connect to their device from
[03:13.200 --> 03:15.880]  anywhere in the world without any special setup.
[03:15.940 --> 03:19.780]  You have to remember, some folks don't even know how to log into their routers, never
[03:19.780 --> 03:21.420]  mind how to forward a port.
[03:21.420 --> 03:24.740]  So vendors started coming up with ways to make connecting easier.
[03:24.740 --> 03:29.160]  To achieve this, devices with peer-to-peer will automatically work around both NAT and
[03:29.160 --> 03:32.220]  firewalls so anyone from the outside can connect in.
[03:32.220 --> 03:36.260]  But thankfully, your device doesn't have any gaping security holes, right?
[03:37.080 --> 03:39.120]  So where does this feature come from?
[03:39.120 --> 03:43.680]  Peer-to-peer is not typically something that's developed in-house by device manufacturers.
[03:43.720 --> 03:48.180]  There are actually several different players in the industry who develop peer-to-peer solutions,
[03:48.180 --> 03:50.300]  and device makers will get it from them.
[03:50.420 --> 03:54.680]  So this originates from higher up in the supply chain, meaning any faults in it are going
[03:54.680 --> 03:56.820]  to propagate downward very quickly.
[03:57.140 --> 04:02.980]  The largest is probably ThruTech, whose Kali platform is in use by over 66 million devices.
[04:02.980 --> 04:07.220]  If you've got a Wyze camera at home, chances are it's using ThruTech's platform.
[04:07.480 --> 04:13.900]  This talk will focus on two products in particular, CS2 Network P2P and Shenzhen Uni iLink P2P.
[04:13.900 --> 04:19.360]  According to CS2, their product is in use by over 50 million devices, and iLink P2P
[04:19.360 --> 04:22.700]  is actually a functionally identical clone of CS2.
[04:22.700 --> 04:28.220]  Its market share is relatively smaller, but it's still present in over 3.6 million devices.
[04:28.880 --> 04:33.400]  So with peer-to-peer existing in over 100 million devices, it's obviously a popular
[04:33.400 --> 04:33.940]  feature.
[04:33.940 --> 04:35.840]  But what are the risks here?
[04:35.840 --> 04:40.660]  Well, primarily, peer-to-peer by its very nature is meant to expose devices.
[04:40.660 --> 04:45.460]  And this should be pretty scary, given IoT has a pretty notorious history when it comes
[04:45.460 --> 04:46.580]  to security.
[04:46.680 --> 04:52.040]  But convenience always wins, so devices are now punching through your firewall by design.
[04:52.240 --> 04:56.940]  In many cases, there's no way to turn this feature off, and anyone that has your device's
[04:56.940 --> 05:00.500]  unique identifier, or UID, can easily connect to it.
[05:00.500 --> 05:04.840]  I'll be demonstrating how these UIDs aren't exactly all that hard to come by.
[05:05.120 --> 05:09.000]  These devices are typically running Linux under the hood, with everything as root, of
[05:09.000 --> 05:09.940]  course.
[05:09.980 --> 05:14.440]  So when you pair that with how they're also essentially online without a firewall, the
[05:14.440 --> 05:17.940]  insanity of this whole concept really starts to set in.
[05:17.980 --> 05:22.700]  While there are obvious risks, like spying on someone's camera or disabling their alarm
[05:22.700 --> 05:26.580]  system, those pale in comparison to remote code execution.
[05:26.780 --> 05:31.820]  Malware leveraging the ability to punch through firewalls could really spread like wildfire.
[05:32.560 --> 05:36.600]  So now we know what peer-to-peer does, and we've come up with a few ways that we can
[05:36.600 --> 05:38.020]  potentially have fun with it.
[05:38.020 --> 05:42.600]  Let's get a bit deeper here and see what one of these peer-to-peer networks actually looks
[05:42.600 --> 05:43.460]  like.
[05:44.540 --> 05:50.280]  A peer-to-peer network is governed by peer-to-peer servers, and these are our gateways to
[05:50.280 --> 05:51.660]  millions of devices.
[05:52.200 --> 05:56.620]  These servers are imperative to this whole system working properly, and the reason for
[05:56.620 --> 05:59.820]  this is these servers actually orchestrate everything.
[05:59.820 --> 06:04.800]  They manage devices, and they also are what handle connections between users and their
[06:04.800 --> 06:05.640]  devices.
[06:05.640 --> 06:09.400]  You can basically think of these as command and control servers.
[06:09.460 --> 06:13.540]  There are hundreds of these on the internet because manufacturers will have dedicated
[06:13.540 --> 06:15.680]  servers for their own devices.
[06:15.960 --> 06:21.940]  It's very common to see these hosted on cloud providers like Alibaba and AWS, and they
[06:21.940 --> 06:25.120]  typically listen on UDP port 32100.
[06:26.260 --> 06:31.640]  Then, of course, you have devices, and these could be anything, but the common theme here
[06:31.640 --> 06:34.700]  is these will be 100% internet accessible.
[06:34.940 --> 06:40.020]  A very important concept here is that all of these devices will have a UID or a unique
[06:40.020 --> 06:44.620]  identifier, and if someone knows your UID, they can connect to your device.
[06:44.620 --> 06:48.500]  So this isn't something that you really want falling into the wrong hands.
[06:48.680 --> 06:53.380]  These UIDs are generated by the peer-to-peer providers and burned into the device during
[06:53.380 --> 06:54.300]  manufacturing.
[06:54.300 --> 06:58.080]  So if someone learns your UID, this isn't something you can change.
[06:58.420 --> 07:00.420]  Let's have a closer look at these.
[07:00.680 --> 07:05.720]  A UID has three separate parts, a prefix, a serial number, and a check code.
[07:05.720 --> 07:10.880]  The prefix is basically used for product grouping, and a single vendor may have several of these
[07:10.880 --> 07:15.180]  and their server will only respond to their own specific prefixes.
[07:15.520 --> 07:19.760]  The serial is simply the device identifier, and these are effectively just sequential
[07:19.760 --> 07:20.760]  numbers.
[07:20.900 --> 07:23.800]  And finally, the check code is a security feature.
[07:23.800 --> 07:28.040]  It's used to protect UIDs and also try to prevent device spoofing.
[07:28.040 --> 07:32.540]  A peer-to-peer server will reject any requests where the check code is not correct.
[07:33.840 --> 07:36.000]  And finally, there are clients.
[07:36.000 --> 07:40.500]  A client could be any desktop or mobile app for connecting to a device.
[07:40.500 --> 07:45.740]  It could be for viewing video, retrieving files, or even configuring an alarm system.
[07:45.800 --> 07:51.120]  But before a client can do any of that, the user needs to put in their UID so the client
[07:51.120 --> 07:52.760]  can make the connection.
[07:54.410 --> 07:59.140]  And under the hood, this whole thing runs on a fairly basic UDP protocol.
[07:59.240 --> 08:04.060]  There are control messages for setting up connections, and DRW or device read-write
[08:04.060 --> 08:07.300]  messages that actually wrap the application data.
[08:07.500 --> 08:12.340]  Messages are really just C structures with a 4-byte header, and a signature of this protocol
[08:12.340 --> 08:13.880]  is its magic number.
[08:13.880 --> 08:18.700]  The first byte of any peer-to-peer message will begin with hexadecimal F1.
[08:18.700 --> 08:23.880]  And thanks to debug information being left in, it was fairly easy to reverse this protocol,
[08:23.880 --> 08:27.520]  and I was actually able to create a Wireshark dissector for it.
[08:28.140 --> 08:32.920]  This was done using a plugin called Wireshark Generic Dissector, which lets you quickly
[08:32.920 --> 08:35.740]  write dissectors using a declarative language.
[08:35.740 --> 08:40.880]  I'll actually be releasing this today, so if you have any devices that use P2P, you
[08:40.880 --> 08:44.120]  can use this to get a little more insight into what's going on.
[08:45.960 --> 08:48.960]  So, with all that, we're finally at the crux of this.
[08:48.960 --> 08:51.140]  How does this connection actually happen?
[08:51.140 --> 08:54.880]  Or more importantly, how does peer-to-peer punch a hole through your firewall?
[08:54.900 --> 08:59.480]  As I mentioned, I was able to access this camera without forwarding any ports.
[08:59.540 --> 09:02.480]  The magic trick here really isn't magic at all.
[09:02.620 --> 09:07.680]  Peer-to-peer simply takes advantage of a particular behavior present in NAT and firewalls.
[09:08.220 --> 09:12.980]  UDP hole punching is a way to establish direct connections in the presence of NAT.
[09:12.980 --> 09:17.640]  For those unfamiliar with the terminology, NAT is just Network Address Translation,
[09:17.640 --> 09:22.840]  which is used by routers to forward traffic from the internet to the proper host on the LAN.
[09:23.100 --> 09:27.220]  The router does this by watching outbound packets and automatically creating inbound
[09:27.220 --> 09:30.240]  rules to correctly bring the response back in.
[09:30.320 --> 09:34.100]  The router needs to do this because if it didn't, we wouldn't be able to get responses
[09:34.100 --> 09:36.120]  back from our requests.
[09:36.340 --> 09:40.600]  But consider if two networks that are using NAT want to talk to each other.
[09:40.600 --> 09:45.560]  Any packet sent to the other is going to be dropped because no forwarding rules exist.
[09:45.640 --> 09:47.760]  So how can we get around this?
[09:47.840 --> 09:51.680]  Well, this is actually one of the main functions of the peer-to-peer servers.
[09:51.820 --> 09:55.980]  Both sides can use a peer-to-peer server to swap addresses with each other.
[09:56.080 --> 10:00.020]  And at that point, they can go ahead and send packets at each other.
[10:00.020 --> 10:05.260]  This will punch holes in their respective NATs and let traffic from the other side come through.
[10:05.460 --> 10:10.360]  In summary, just by sending UDP packets to each other, both sides can create a direct
[10:10.600 --> 10:12.520]  channel of communication.
[10:13.820 --> 10:16.560]  So this demonstrates how this works.
[10:16.740 --> 10:21.820]  When a connection request happens, the peer-to-peer servers will tell both sides the other's
[10:21.820 --> 10:22.760]  information.
[10:22.760 --> 10:26.180]  The device will send a packet to the client and vice versa.
[10:26.180 --> 10:29.720]  And even though these may not actually be delivered, that doesn't matter.
[10:29.720 --> 10:32.320]  The point here is just to open ports.
[10:32.440 --> 10:36.520]  After both sides have done this, then they should be able to talk to each other.
[10:37.120 --> 10:41.120]  But the problem with UDP hole punching is it doesn't always work.
[10:41.200 --> 10:45.860]  It usually works with most home networks, but it might not work in more complicated
[10:45.860 --> 10:48.160]  enterprise or mobile networks.
[10:48.300 --> 10:52.820]  For this situation, a client and a device can use what's called a relay server, which
[10:52.820 --> 10:57.380]  exists on the network specifically to help clients and devices make connections.
[10:57.700 --> 11:02.720]  As long as both sides can connect to the same relay, then it can proxy data between them.
[11:03.720 --> 11:09.540]  What's really fascinating is that some networks will actually use people's devices as extra
[11:09.540 --> 11:11.280]  relays for the network.
[11:11.440 --> 11:17.480]  And that means someone else's camera may very well be proxying your own video feed.
[11:17.480 --> 11:22.460]  These are called super devices, and this behavior is kept secret from users.
[11:22.460 --> 11:26.300]  They are never asked if they are okay with having their bandwidth donated.
[11:26.300 --> 11:29.440]  And if they have quotas, this could certainly cause a problem.
[11:29.440 --> 11:33.660]  And as sketchy as this sounds, this concept isn't actually unheard of.
[11:33.660 --> 11:38.960]  The more standard terminology for these is super nodes, and they're a relatively common
[11:38.960 --> 11:41.180]  occurrence in peer-to-peer software.
[11:41.480 --> 11:46.240]  Skype actually used to do this too, but at least people had the ability to opt out of
[11:46.240 --> 11:46.920]  that.
[11:47.060 --> 11:49.560]  Spoiler alert, we're going to have fun with these.
[11:50.100 --> 11:54.060]  Okay, so with the background out of the way, now we can start getting to the really good
[11:54.060 --> 11:54.840]  stuff.
[11:54.940 --> 11:58.920]  Since these networks are supporting millions of devices, is there anything we can do to
[11:58.920 --> 11:59.960]  hunt them down?
[11:59.960 --> 12:04.260]  And specifically, is there any way we can guess or generate UIDs?
[12:05.040 --> 12:09.840]  If we want to do this, the first step is going to be to find some peer-to-peer servers.
[12:09.840 --> 12:14.540]  Again, these are essentially gateways to devices, so finding them has a lot of value.
[12:14.720 --> 12:19.720]  I started doing this by looking at desktop and phone apps, as these are obviously going
[12:19.720 --> 12:21.460]  to be using a vendor's servers.
[12:21.800 --> 12:26.100]  However, this is a bit tedious, and there is a much more efficient way to do it.
[12:26.100 --> 12:29.280]  We can use NMAP's host detection to do this.
[12:29.540 --> 12:34.280]  The protocol has a simple hello message, and any valid peer-to-peer server will come back
[12:34.280 --> 12:35.640]  with an ACK message.
[12:35.640 --> 12:41.080]  So we can configure this probe and then run it against the entire IP space of a cloud
[12:41.080 --> 12:43.340]  provider like AWS or Alibaba.
[12:43.820 --> 12:49.020]  AWS in particular is very kind and provides an up-to-date listing of their current IP
[12:49.020 --> 12:49.760]  ranges.
[12:50.060 --> 12:55.900]  I've come across 618 peer-to-peer servers since 2018, and some basic fingerprinting
[12:55.900 --> 13:01.280]  has shown that 86% of these are CS2, and 14% are ILINK P2P.
[13:02.460 --> 13:06.760]  So next, if we want to use these servers to find devices, we're going to need to find
[13:06.760 --> 13:08.460]  out what prefixes they support.
[13:08.460 --> 13:13.880]  Like before, I started looking for these in apps and even Amazon reviews, because sometimes
[13:13.880 --> 13:18.860]  people will include their UIDs in their photos without realizing what they're doing.
[13:19.060 --> 13:23.920]  These two reviews have 11 different UIDs, and they're using three different prefixes.
[13:24.560 --> 13:29.180]  Sifting through these is also kind of tedious and quickly provides diminishing returns.
[13:29.180 --> 13:31.020]  So what is a better way?
[13:31.360 --> 13:35.400]  Well, when we try to connect to a device, the server will respond with an error code
[13:35.400 --> 13:37.200]  if the UID isn't valid.
[13:37.200 --> 13:41.700]  But that error code will change depending on if the prefix you asked for is valid.
[13:41.740 --> 13:44.460]  So I wrote a script to brute force prefixes.
[13:44.460 --> 13:49.240]  It continuously sends requests and saves any prefixes that appear to be valid.
[13:49.240 --> 13:52.600]  There's no rate limiting or checks to prevent this sort of thing.
[13:52.600 --> 13:57.320]  And depending on the latency between you and the server, you can find all three-letter
[13:57.320 --> 14:02.320]  prefixes in about an hour and all four-letter prefixes in about 36 hours.
[14:02.460 --> 14:06.280]  In total, I have found about 488 distinct prefixes.
[14:06.460 --> 14:11.520]  And while the average server hosts about four prefixes, there are a couple that have 130.
[14:12.880 --> 14:17.620]  So we're at a point where we've got servers and we know which prefixes they support.
[14:17.620 --> 14:21.440]  We can also predict serial numbers because they're just sequential numbers.
[14:21.440 --> 14:24.900]  If we want to find UIDs, the problem is now the check code,
[14:24.900 --> 14:27.760]  which exists precisely to stop this sort of thing.
[14:28.160 --> 14:31.800]  If the check code is off by even one letter, the UID will be rejected.
[14:32.040 --> 14:33.520]  These are five letters long.
[14:33.520 --> 14:36.360]  And while that's not an impossible key space to brute force,
[14:36.360 --> 14:40.900]  it's still enough to thwart any efforts to find a large number of devices quickly.
[14:41.080 --> 14:43.100]  So how can we get around this?
[14:44.540 --> 14:47.760]  Well, with ILinkP2P, luck would be in our favor.
[14:47.760 --> 14:52.880]  I found a variant of the ILinkP2P library that contained the algorithm they use to generate
[14:52.880 --> 14:57.700]  check codes. It basically hashes a few components using a modified MD5
[14:57.700 --> 15:01.740]  and then puts together the letters from the hash to create the check code.
[15:01.860 --> 15:06.460]  This was apparently included in the library to do client-side UID validation,
[15:06.460 --> 15:09.680]  which is odd given the peer-to-peer server does this anyway,
[15:09.680 --> 15:12.460]  but someone thought it was a good idea to ship this.
[15:12.520 --> 15:17.220]  This is a big deal because we can now generate any valid ILinkUID,
[15:17.220 --> 15:21.180]  meaning we can now connect to any online ILink device.
[15:21.440 --> 15:25.160]  And with this ability, we can start to do some very interesting things.
[15:25.160 --> 15:28.440]  For one, we can now find out how many devices are online,
[15:28.440 --> 15:33.220]  but what would be even more interesting is finding out where these devices are.
[15:33.320 --> 15:36.700]  We can use a UID to get the IP address of a device,
[15:36.700 --> 15:41.140]  and using that, we can approximate its location using IP geolocation.
[15:42.660 --> 15:45.800]  So what you're seeing here is an enumeration script I wrote.
[15:45.800 --> 15:49.180]  It generates a UID, grabs its IP from the servers,
[15:49.180 --> 15:52.280]  and then looks it up using MaxMind's GeoLite database.
[15:52.280 --> 15:55.180]  This is going at 10,000 requests per minute.
[15:56.300 --> 15:59.880]  Taking this another step further, I was able to visualize this data
[15:59.880 --> 16:02.680]  with LeafletMarkerCluster and OpenStreetMap.
[16:02.680 --> 16:07.760]  Of the 3.6 million devices I've seen, Europe makes up about 21% of this,
[16:07.760 --> 16:13.120]  with France, Italy, Germany, and the United Kingdom all having over 100,000 devices.
[16:13.120 --> 16:19.260]  North America makes up about 8% of this total, with the U.S. seeing over 205,000 devices,
[16:19.260 --> 16:23.040]  and Canada and Mexico both having over 40,000 each.
[16:26.280 --> 16:30.980]  Finally, Asia is the most heavily impacted, with over 1.8 million devices.
[16:31.100 --> 16:34.920]  China and Thailand alone make up more than half of the entire dataset.
[16:36.320 --> 16:39.420]  Horrifyingly, lots of these devices use default passwords,
[16:39.420 --> 16:43.200]  meaning the UID is enough to gain full access to the camera.
[16:43.200 --> 16:46.380]  I disclosed this to Shenzhen Uni in early 2019,
[16:46.380 --> 16:50.200]  but despite multiple attempts, I never received a response back from them.
[16:50.240 --> 16:55.220]  And despite this vulnerability, I've continued to see an increase in the use of iLink P2P.
[16:55.220 --> 16:59.620]  In fact, thousands of new UIDs come online every single month.
[16:59.760 --> 17:04.860]  CS2 doesn't appear to be affected by this vulnerability, but that's not the end of the story.
[17:06.060 --> 17:09.720]  So now I have a way to directly connect to millions of cameras,
[17:09.720 --> 17:14.240]  but I'm not really interested in spying on people or talking through their cameras.
[17:14.240 --> 17:17.360]  That's creepy, and frankly, we're not in middle school here.
[17:17.360 --> 17:19.500]  What we really want is shells.
[17:20.000 --> 17:22.640]  So let's find some camera vulnerabilities.
[17:22.960 --> 17:28.060]  When planning for this, I really wanted to focus on a big vendor for maximum impact.
[17:28.060 --> 17:33.320]  Shenzhen High Chip Vision Technology is a major manufacturer in the IP camera industry.
[17:33.700 --> 17:37.400]  They caught my attention because as I was looking into different brands,
[17:37.400 --> 17:42.520]  I started to realize that a huge number of them were ultimately manufactured by HiChip.
[17:42.520 --> 17:47.750]  In fact, close to 3 million of the iLink devices I have found are using HiChip prefixes.
[17:49.160 --> 17:53.060]  This sort of practice is very common, where manufacturers will sell
[17:53.060 --> 17:57.360]  white-labeled equipment to vendors who then resell it with their own branding.
[17:57.360 --> 18:02.160]  This is a list of 50 different brands that are actually using HiChip under the hood.
[18:02.160 --> 18:06.060]  So given their ubiquity, any vulnerabilities in HiChip's firmware
[18:06.060 --> 18:08.960]  would be both widespread and very accessible.
[18:11.260 --> 18:14.420]  So to get started, I began analyzing their firmware.
[18:14.420 --> 18:17.480]  One function of interest was this read request method,
[18:17.480 --> 18:20.820]  which is used to handle any commands coming in over peer-to-peer.
[18:20.820 --> 18:26.380]  It even handles login, and we've got a 1024 byte buffer to read data off the wire.
[18:26.680 --> 18:31.480]  The message header has a field that says how big the payload is, so of course that's validated.
[18:31.800 --> 18:34.680]  To allow 10 times the size of the buffer.
[18:34.680 --> 18:38.200]  Okay, so we've clearly got a buffer overflow here.
[18:38.200 --> 18:41.680]  But how easy is it to exploit this? Because after all,
[18:41.680 --> 18:45.380]  there have been defenses to stop exploits like this for years.
[18:45.760 --> 18:48.620]  And the library doesn't seem to use any of them.
[18:48.620 --> 18:53.420]  So one very reliable ROP gadget later, and we've got ourselves a system call,
[18:53.420 --> 18:56.060]  and then a reverse shell with root privileges.
[18:57.900 --> 19:00.060]  Obviously, any vulnerability is bad.
[19:00.060 --> 19:03.140]  But the most devastating really tend to be those that are pre-auth,
[19:03.140 --> 19:05.880]  because any anonymous person can exploit them.
[19:06.020 --> 19:09.420]  In this case, as long as you have a UID, you can get a shell.
[19:09.420 --> 19:12.160]  And we now have all the UIDs.
[19:13.060 --> 19:17.020]  Once you get a shell, you can run binaries, you can browse the file system,
[19:17.020 --> 19:19.360]  and you can even access the camera's password.
[19:19.560 --> 19:23.060]  You can even directly invoke the camera's Wi-Fi utilities.
[19:23.060 --> 19:25.340]  And here's why this is a really bad thing.
[19:25.460 --> 19:29.400]  You can do a lot of really crazy things with base station MAC addresses.
[19:29.400 --> 19:35.280]  Google has an entire API that uses MAC addresses to perform disturbingly accurate geolocation.
[19:35.420 --> 19:39.640]  And the more information you give it, the more accurate the results are going to be.
[19:39.640 --> 19:43.580]  So once you get a shell, you can use it to scan for nearby Wi-Fi networks
[19:43.580 --> 19:46.940]  and potentially pinpoint the exact location of a camera.
[19:47.220 --> 19:51.180]  If you want to try this yourself, check out Google's geolocation API,
[19:51.180 --> 19:54.020]  feed it some MAC addresses of nearby wireless networks,
[19:54.020 --> 19:56.180]  and see just how accurate it can get.
[19:56.180 --> 19:58.360]  It costs literally pennies to do this.
[19:59.880 --> 20:03.960]  It's hard to say exactly how many devices are affected by this vulnerability,
[20:03.960 --> 20:07.480]  but given I found this bug in almost two years worth of firmware,
[20:07.480 --> 20:10.540]  I think it's a pretty safe bet to say that this could be weaponized.
[20:10.540 --> 20:14.320]  But thankfully, HiChip did release a patch for this in June 2020.
[20:15.260 --> 20:17.880]  I did find another vulnerability worth mentioning.
[20:17.880 --> 20:21.440]  It's not exploitable over P2P, but it's still pretty amusing.
[20:21.660 --> 20:25.900]  Up until recently, you could anonymously reset the password of any HiChip camera
[20:25.900 --> 20:28.020]  just by being on the same LAN.
[20:28.020 --> 20:33.140]  The reason for this is apparently some devices don't have physical reset switches,
[20:33.140 --> 20:38.200]  so instead you can just send a magic packet to the camera and it'll reset the password to admin.
[20:38.260 --> 20:40.260]  I'll be releasing a script for this,
[20:40.260 --> 20:44.000]  but I actually found out HiChip provided a tool to do this already,
[20:44.000 --> 20:49.760]  so I'm not sure if this qualifies as an exploit per se, but have fun with this.
[20:51.060 --> 20:53.540]  Okay, still got a few more tricks up my sleeve.
[20:53.540 --> 20:55.780]  Let's talk about man-in-the-middle attacks.
[20:55.780 --> 20:58.200]  When people hear man-in-the-middle attack,
[20:58.200 --> 21:01.800]  they might associate it with something that's restricted to the local network.
[21:01.800 --> 21:04.420]  Sniffing packets at a coffee shop, for example.
[21:04.980 --> 21:07.580]  Peer-to-peer should be pretty scary by now,
[21:07.580 --> 21:11.880]  but we haven't even talked about how it lets you intercept traffic over the internet.
[21:12.380 --> 21:15.060]  This comes from the fact that, as we now know,
[21:15.060 --> 21:19.060]  the peer-to-peer servers are responsible for coordinating all connections.
[21:19.480 --> 21:23.080]  Clients and devices obey the orders of the peer-to-peer servers.
[21:23.080 --> 21:29.100]  So, if we can influence that process in any way, we may be able to insert ourselves into a session.
[21:29.340 --> 21:34.440]  This is particularly scary because despite being a transport layer for the application,
[21:34.440 --> 21:38.400]  peer-to-peer doesn't actually perform any encryption or identity checks.
[21:38.400 --> 21:41.260]  These measures are left entirely up to the application,
[21:41.260 --> 21:44.580]  and as you can guess, most don't do a very good job of this.
[21:44.800 --> 21:48.060]  In fact, some even outright lie about it.
[21:48.080 --> 21:50.780]  This is a screenshot from VSTARCAM's app,
[21:50.780 --> 21:53.780]  which assures you that it is building an encrypted channel,
[21:53.780 --> 21:56.600]  but as you can see from the packet capture on the right,
[21:56.600 --> 21:59.460]  there is absolutely no encryption happening here.
[22:00.860 --> 22:02.900]  So, how do we get in the middle?
[22:02.920 --> 22:07.520]  Well, once per minute, a device is going to log into its peer-to-peer servers.
[22:07.680 --> 22:12.400]  This action tells the servers where the client needs to go when they request a connection.
[22:12.560 --> 22:17.020]  The problem is, this login message just contains the device UID.
[22:17.020 --> 22:20.180]  Absolutely no device-specific secret is used,
[22:20.180 --> 22:22.140]  which means if we have a UID,
[22:22.140 --> 22:27.080]  it's very easy for us to forge this login message and confuse the servers.
[22:27.500 --> 22:31.220]  And if our timing is right, when the client requests a session,
[22:31.220 --> 22:35.160]  the peer-to-peer server will tell them that we're the device.
[22:35.240 --> 22:39.220]  And at that point, the client will happily try to authenticate to us.
[22:39.220 --> 22:43.200]  And yes, that is Base64. It's always Base64.
[22:43.660 --> 22:49.540]  So, we have the password, and now we can turn around and connect back to the real device.
[22:50.480 --> 22:54.520]  This works with both CS2 and iLink P2P devices.
[22:54.520 --> 22:58.800]  CS2 did try to patch this problem, but it's pretty easy to circumvent.
[22:58.800 --> 23:02.400]  The login message is encrypted with what's called a CRC key,
[23:02.400 --> 23:07.780]  but a vendor's devices all use the same CRC key, so you can just grab it right from the firmware.
[23:08.040 --> 23:11.120]  And with some servers, you actually don't even need to go this far,
[23:11.120 --> 23:16.480]  because it will still let you log in with the old login message, so there's not much of a point.
[23:16.480 --> 23:20.800]  While this attack is certainly doable, there are a couple of drawbacks.
[23:20.800 --> 23:26.200]  You need to have a specific UID to target, you need to know knowledge of the protocol,
[23:26.200 --> 23:29.500]  and you actually need to wait for the person to try to connect.
[23:29.740 --> 23:33.540]  However, there is another attack that has none of these requirements.
[23:33.680 --> 23:36.680]  In fact, there is a way that someone with practically
[23:36.680 --> 23:41.020]  zero hacking experience can start owning handfuls of devices.
[23:41.940 --> 23:44.340]  Let's talk about super devices again.
[23:44.340 --> 23:49.700]  These are devices in people's homes that are proxying sessions for other users.
[23:49.760 --> 23:54.680]  A lot of vendors use these, so the chances of you buying a camera that will act as a super device
[23:54.680 --> 23:59.960]  is pretty high. And as I said, P2P doesn't actually perform any encryption.
[24:00.180 --> 24:03.420]  So what happens when a vendor's crypto sucks too?
[24:03.820 --> 24:08.500]  That means that anyone can buy a device and access other people's traffic with it.
[24:08.500 --> 24:12.500]  It means literally anyone on the planet can sniff your entire session
[24:12.500 --> 24:16.320]  and capture your password or your video without you ever knowing.
[24:16.440 --> 24:19.900]  There's no need to expend a ton of effort setting up a man-in-the-middle attack
[24:19.900 --> 24:23.280]  when this exists in the product by design.
[24:23.940 --> 24:28.260]  There are plenty of devices that don't even use encryption for sessions.
[24:28.360 --> 24:31.300]  A little PCAP parsing can give you a raw video stream
[24:31.300 --> 24:34.660]  that you can immediately watch with something like FFPlay.
[24:34.660 --> 24:38.240]  And all the while, users will have no way of knowing
[24:38.240 --> 24:41.280]  whether their connection is being intercepted like this.
[24:41.280 --> 24:46.240]  In fact, it's a risk that they're taking every single time that they connect to their device.
[24:47.120 --> 24:53.420]  As an added bonus, this has the side effect of leaking UIDs during the peer-to-peer handshake.
[24:53.420 --> 24:57.320]  So alternatively, you can just take the credentials which you also probably captured
[24:57.320 --> 24:59.880]  and connect back to the device yourself.
[24:59.880 --> 25:05.700]  I actually developed a proof of concept of this just to collect UIDs by posing as a super device.
[25:05.700 --> 25:13.380]  And by doing this, I was able to collect over 236,000 unique CS2 UIDs over the course of 10 months.
[25:13.500 --> 25:16.940]  So even though CS2's check code algorithm has yet to be cracked,
[25:16.940 --> 25:20.580]  this is a very reliable way for anyone to collect UIDs.
[25:20.900 --> 25:25.880]  The funny thing is, CS2 actually mentioned this exact concern in a marketing deck.
[25:25.880 --> 25:32.140]  They said a super device cannot spy on any data it relays because there is no API for this.
[25:32.140 --> 25:35.680]  But of course, that's insane. You don't need an API to pull this off.
[25:35.700 --> 25:39.880]  It's absolutely trivial to set up a camera and then leave Wireshark running
[25:39.880 --> 25:43.160]  to capture every single packet flowing through that device.
[25:43.560 --> 25:45.760]  So that's exactly what we're going to do.
[25:45.760 --> 25:48.400]  This bullet cam is running iLink P2P.
[25:48.400 --> 25:51.160]  So against my better judgment, I'm going to put this on the internet
[25:51.700 --> 25:55.460]  and we'll run Wireshark for a while and see what we come back to.
[25:55.620 --> 25:58.580]  Okay, so I left Wireshark running for a few hours
[25:58.580 --> 26:01.720]  and we can see that this camera has stayed pretty busy.
[26:01.720 --> 26:06.360]  I have the P2P dissector active so we can clearly see what it's been doing.
[26:06.420 --> 26:09.360]  Each of these hello messages is the peer-to-peer servers
[26:09.360 --> 26:13.320]  telling the camera to reach out and try to help someone with a session.
[26:13.320 --> 26:17.360]  So this will generate some handshaking with both the client and the device.
[26:17.560 --> 26:21.060]  Of particular interest is these relay packet messages,
[26:21.060 --> 26:26.340]  which will actually contain a UID of the device that we're trying to relay for.
[26:26.620 --> 26:30.060]  But we want to see some actual session traffic.
[26:30.060 --> 26:34.890]  We can locate this by filtering for message DRW messages.
[26:35.400 --> 26:38.740]  I'll go up here and apply that filter.
[26:46.590 --> 26:49.430]  Sure enough, looks like we've got some traffic here.
[26:49.430 --> 26:53.770]  If we actually pull up the resulting conversation here,
[26:53.770 --> 26:56.210]  well, that sure looks like Base64.
[26:56.910 --> 26:58.380]  If we copy that...
[27:02.990 --> 27:05.690]  Yep, nice secure password there.
[27:06.210 --> 27:09.770]  So there's some other information in plain text over here.
[27:09.770 --> 27:14.190]  We can see some information about the camera, the firmware version,
[27:14.190 --> 27:18.630]  and it looks like some other sort of name or identity information.
[27:19.150 --> 27:20.510]  But what about video?
[27:20.810 --> 27:23.630]  One of the ways that this DRW concept works
[27:23.630 --> 27:28.210]  is there are message indexes and message channels.
[27:28.250 --> 27:31.730]  And each channel is going to be used for a particular purpose.
[27:31.730 --> 27:35.470]  So in this case here, it looks like there's a lot of
[27:36.110 --> 27:40.590]  sort of authentication or negotiation going on on this channel zero.
[27:40.590 --> 27:45.510]  But on this channel two, we start to see binary data.
[27:45.990 --> 27:50.110]  So what I did here is I actually wrote a quick script
[27:50.110 --> 27:54.570]  that is going to take the data from this packet capture
[27:54.570 --> 27:58.850]  and just concatenate it together so we can pipe it into a video player.
[27:58.850 --> 28:04.710]  So what we're going to do is just go and export packet dissections as JSON.
[28:04.710 --> 28:09.970]  Call this export.json and make sure we hit packet bytes.
[28:10.130 --> 28:11.530]  Save this.
[28:17.700 --> 28:25.660]  And then we will go here and do node json2vid export.json.
[28:25.660 --> 28:27.860]  Pipe that right into ffplay.
[28:28.820 --> 28:32.060]  And we have some chickens, how about that?
[28:33.340 --> 28:35.340]  So final thoughts.
[28:36.320 --> 28:41.180]  I had a feeling things weren't going to be pretty when I started down this rabbit hole,
[28:41.180 --> 28:44.520]  but I never could have imagined some of these things.
[28:44.740 --> 28:47.920]  I've reported all of these problems to the vendors.
[28:47.960 --> 28:50.260]  Shenzhen Uni never did get back to me,
[28:50.260 --> 28:55.980]  and the number of devices using iLink P2P has steadily increased since I first reached out to them.
[28:56.100 --> 29:00.080]  I've tried to contact a lot of vendors in China over the past few years,
[29:00.080 --> 29:03.660]  and it's honestly pretty rare that I get a response at all.
[29:03.860 --> 29:06.940]  So I'd also really like to give credit where it's due here,
[29:06.940 --> 29:12.600]  because both CS2 Network and Hychip kept in close contact with me earlier this year,
[29:12.600 --> 29:15.780]  even as the COVID situation was first emerging in China.
[29:16.240 --> 29:19.220]  It was refreshing to see my concerns taken seriously,
[29:19.220 --> 29:21.560]  and especially during such a difficult time.
[29:22.160 --> 29:25.700]  The issues with CS2 are slated to be fixed in the next release,
[29:25.700 --> 29:29.320]  and Hychip just released patches for their problems in late June.
[29:30.460 --> 29:35.080]  With the warm and fuzzies over, uh, boy, things are not looking good.
[29:35.180 --> 29:38.320]  Even with patches on the way, I think it's safe to say that
[29:38.320 --> 29:41.920]  everything you just saw is going to be a problem for a long time.
[29:41.920 --> 29:45.080]  And this is because a lot of these peer-to-peer problems
[29:45.080 --> 29:49.620]  are outright architectural flaws, and they can't really be fixed retroactively.
[29:50.100 --> 29:51.840]  I think even if they could be fixed,
[29:51.840 --> 29:56.220]  it doesn't matter because most people don't update firmware anyway.
[29:56.280 --> 30:00.060]  I've seen some devices with firmware versions going back half a decade.
[30:01.480 --> 30:05.660]  In June of this year, I worked with the UK consumer watchdog group Witch
[30:05.660 --> 30:09.420]  to try to get some of the affected devices pulled off of shelves.
[30:09.540 --> 30:14.120]  Amazon, who sells more than 20 vulnerable brands, uh, didn't respond at all.
[30:14.120 --> 30:18.240]  And eBay said to use IP cameras without an internet connection,
[30:18.240 --> 30:21.080]  which isn't even possible with a good number of these.
[30:21.080 --> 30:23.340]  So, you know, thanks for that advice.
[30:23.980 --> 30:26.440]  Um, I do hope that this was inspiring to some of you,
[30:26.440 --> 30:30.060]  because I think there's a lot of opportunity here for further research.
[30:30.080 --> 30:34.420]  I think it's pretty clear that peer-to-peer is a pretty nasty vector,
[30:34.420 --> 30:37.000]  and I'm sure there's a lot more vulnerabilities
[30:37.560 --> 30:40.760]  in devices beyond what I've discovered on my own.
[30:40.980 --> 30:45.280]  I also haven't really had a chance to dig into other peer-to-peer platforms.
[30:45.280 --> 30:51.440]  For example, CalA, which is used by over 66 million devices, including Wyze cameras.
[30:51.660 --> 30:56.200]  And I know they use a similar paradigm where a UID will get you device access.
[30:56.200 --> 30:58.740]  So I think there's certainly opportunity there.
[30:58.740 --> 31:01.080]  And while I focus my efforts on HiChip,
[31:01.080 --> 31:04.960]  there are definitely other massive device manufacturers out there.
[31:04.960 --> 31:08.360]  In general, I encourage folks to climb up the supply chain a bit
[31:08.360 --> 31:13.960]  if you're looking for vulnerabilities that could be both widespread and potentially high impact.
[31:14.960 --> 31:17.840]  I'd like to leave you with a few reverse engineering tips
[31:17.840 --> 31:20.580]  that have led me to some major discoveries.
[31:20.580 --> 31:22.400]  First, if you're doing reversing,
[31:22.400 --> 31:26.820]  be sure to collect as many different samples and variants as you possibly can.
[31:26.820 --> 31:30.960]  Run diffs against them, look for abnormal changes in file sizes.
[31:30.960 --> 31:35.760]  Some may leave in debug symbols, extra logging, and alternate functionality.
[31:35.760 --> 31:38.440]  So those are all new avenues of exploration.
[31:38.880 --> 31:43.240]  Also, APKs are a great way to check out things with minimal effort.
[31:43.240 --> 31:48.800]  Java can decompile into beautiful, readable code that can very quickly reveal interesting things.
[31:49.020 --> 31:51.000]  And finally, and most importantly,
[31:51.000 --> 31:55.300]  throw every single interesting file name or magic string you find into GitHub.
[31:55.300 --> 31:56.240]  Seriously.
[31:56.240 --> 32:01.380]  It is incredible how many people push sensitive source code to public repositories.
[32:01.600 --> 32:04.240]  And this has helped me find everything from SDKs,
[32:04.240 --> 32:07.500]  to documentation, to full-on source repos for firmware.
[32:08.380 --> 32:11.100]  Finally, I'd like to give a shout out to the folks who published
[32:11.100 --> 32:13.260]  some of the initial research on peer-to-peer.
[32:13.260 --> 32:17.260]  Their work was really inspiring and key to the success of my own research.
[32:17.260 --> 32:19.040]  So cheers to you guys.
[32:19.680 --> 32:21.160]  And that's a wrap, my friends.
[32:21.160 --> 32:22.960]  Thank you all so much for coming.
[32:22.960 --> 32:24.980]  Happy hacking and be safe out there.