DEF CON Safe Mode - Paul Marrapese - Abusing P2P to Hack 3 Million Cameras

good afternoon everyone and thank you all for coming this is abusing peer-to-peer to hack three million cameras this talk is the culmination of about two years of research so i'm very excited to finally be able to share this with you all and with that let's get started i'm going to be talking about an obscure feature lurking in iot devices around the world peer-to-peer is intended to make life easier for people but it's had the nasty side effect of exposing millions of devices to the internet even those behind firewalls are not immune hundreds of different brands are affected by this including security cameras alarm systems and even baby monitors but exposure is just the tip of the iceberg when hordes of insecure things get put on the internet you can bet the end result is not going to be pretty so i'm here to show you just how bad this can get by the end of this talk you'll see how peer-to-peer devices work the numerous ways they can be exploited and finally how a 40 purchase from amazon is all you need to start hacking into other devices so who am i my name is paul marapisi i am a security researcher based out of san jose california and i probably spend too much time getting angry at computers i largely focus on offensive security and i work on the red team at a certain enterprise cloud company when i'm not breaking things i make music i dabble in photography and i have two cats who funny enough are the catalyst for this entire story in 2018 i adopted a pair of rescue kittens and i wanted to keep an eye on them as they slowly took over my apartment i had an old ip camera from around 2002 but this was now 2018 so i figured i could get something a little better amazon has a wide selection of ip cameras and some are marked as amazon's choice and there's quite a few with decent enough reviews this sv3c model for example is 40 and it has four stars with nearly two thousand reviews so it sounds like a pretty good deal i figured this would be like any other network device where if i wanted to view it externally i would need to forward a port but once i hooked it up i realized i could immediately view it from my phone no setup required this shook me a little bit because it implies it's either doing something to get around my router or it's sending my video through some third-party servers either way i'm freaked out so i load up wireshark and as we can see this camera is very chatty it's pinging three different servers every 40 seconds two of which are in china and as i continue watching i start noticing that sometimes my video is being funneled through mysterious servers all over the world at one point i even see this camera talking to a comcast ip in a different state it turns out a lot of people have noticed this sketchy behavior there are a lot of concerned reviews talking about this suspicious traffic on udp port 32100 not just on my brand of camera but on many many different models so now i'm extremely intrigued what is this exactly well this is peer-to-peer and i'm sure the name is conjuring memories of file sharing networks like napster and kazaa but the context here is a little bit different in the context of iot peer-to-peer is a feature that lets people connect to their device from anywhere in the world without any special setup you have to remember some folks don't even know how to log into their routers never mind how to forward a port so vendors started coming up with ways to make connecting easier to achieve this devices with peer-to-peer will automatically work around both nat and firewalls so anyone from the outside can connect in but thankfully your device doesn't have any gaping security holes right so where does this feature come from peer-to-peer is not typically something that's developed in-house by device manufacturers there are actually several different players in the industry who develop peer-to-peer solutions and device makers will get it from them so this originates from higher up in the supply chain meaning any faults in it are going to propagate downward very quickly the largest is probably throughtech whose cali platform is in use by over 66 million devices if you've got a wise camera at home chances are it's using through tech's platform this talk will focus on two products in particular cs2 network p2p and shenzhen uni ilink p2p according to cs2 their product is in use by over 50 million devices and ilink p2p is actually a functionally identical clone of cs2 its market share is relatively smaller but it's still present in over 3.6 million devices so with peer-to-peer existing in over 100 million devices it's obviously a popular feature but what are the risks here well primarily peer-to-peer by its very nature is meant to expose devices and this should be pretty scary given iot has a pretty notorious history when it comes to security but convenience always wins so devices are now punching through your firewall by design in many cases there's no way to turn this feature off and anyone that has your device's unique identifier or uid can easily connect to it i'll be demonstrating how these uids aren't exactly all that hard to come by these devices are typically running linux under the hood with everything as root of course so when you pair that with how they're also essentially online without a firewall the insanity of this whole concept really starts to set in while there are obvious risks like spying on someone's camera or disabling their alarm system those pale in comparison to remote code execution malware leveraging the ability to punch through firewalls could really spread like wildfire so now we know what peer-to-peer does and we've come up with a few ways that we can potentially have fun with it let's get a bit deeper here and see what one of these p2p networks actually looks like a peer-to-peer network is governed by peer-to-peer servers and these are our gateways to millions of devices these servers are imperative to this whole system working properly and the reason for this is these servers actually orchestrate everything they manage devices and they also are what handle connections between users and their devices you can basically think of these as command and control servers there are hundreds of these on the internet because manufacturers will have dedicated servers for their own devices it's very common to see these hosted on cloud providers like alibaba and aws and they typically listen on udp port 32100 then of course you have devices and these could be anything but the common theme here is these will be 100 internet accessible a very important concept here is that all of these devices will have a uid or a unique identifier and if someone who knows your uid they can connect to your device so this isn't something that you really want falling into the wrong hands these uids are generated by the peer-to-peer providers and burned into the device during manufacturing so if someone learns your uid this isn't something you can change let's have a closer look at these a uid has three separate parts a prefix a serial number and a check code the prefix is basically used for product grouping and a single vendor may have several of these and their server will only respond to their own specific prefixes the serial is simply the device identifier and these are effectively just sequential numbers and finally the check code is a security feature it's used to protect uids and also try to prevent device spoofing a peer-to-peer server will reject any requests where the check code is not correct and finally there are clients a client could be any desktop or mobile app for connecting to a device it could be for viewing video retrieving files or even configuring an alarm system but before a client can do any of that the user needs to put in their uid so the client can make the connection and under the hood this whole thing runs on a fairly basic udp protocol there are control messages for setting up connections and drw or device read write messages that actually wrap the application data messages are really just c structures with a four byte header and a signature of this protocol is its magic number the first byte of any peer-to-peer message will begin with hexadecimal f1 and thanks to debug information being left in it was fairly easy to reverse this protocol and i was actually able to create a wireshark dissector for it this was done using a plug-in called wireshark generic dissector which lets you quickly write dissectors using a declarative language i'll actually be releasing this today so if you have any devices that use p2p you can use this to get a little more insight into what's going on so with all that we're finally at the crux of this how does this connection actually happen or more importantly how does peer-to-peer punch a hole through your firewall as i mentioned i was able to access this camera without forwarding any ports the magic trick here really isn't magic at all peer-to-peer simply takes advantage of a particular behavior present in nat and firewalls udp hole punching is a way to establish direct connections in the presence of nat for those unfamiliar with the terminology nat is just network address translation which is used by routers to forward traffic from the internet to the proper host on the lan the router does this by watching outbound packets and automatically creating inbound rules to correctly bring the response back in the router needs to do this because if it didn't we wouldn't be able to get responses back from our requests but consider if two networks that are using that want to talk to each other any packet sent to the other is going to be dropped because no forwarding rules exist so how can we get around this well this is actually one of the main functions of the peer-to-peer servers both sides can use a peer-to-peer server to swap addresses with each other and at that point they can go ahead and send packets at each other this will punch holes in their respective gnats and let traffic from the other side come through in summary just by sending udp packets to each other both sides can create a direct channel of communication so this demonstrates how this works when a connection request happens the peer-to-peer service will tell both sides the other's information the device will send a packet to the client and vice versa and even though these may not actually be delivered that doesn't matter the point here is just to open ports after both sides have done this then they should be able to talk to each other but the problem with udp hole punching is it doesn't always work it usually works with most home networks but it might not work in more complicated enterprise or mobile networks for this situation a client in a device can use what's called a relay server which exists on the network specifically to help clients and devices make connections as long as both sides can connect to the same relay then it can proxy data between them what's really fascinating is that some networks will actually use people's devices as extra relays for the network and that means someone else's camera may very well be proxying your own video feed these are called super devices and this behavior is kept secret from users they are never asked if they are okay with having their bandwidth donated and if they have quotas this could certainly cause a problem and as sketchy as this sounds this concept isn't actually unheard of the more standard terminology for these is super nodes and there are relatively a common occurrence in peer-to-peer software skype actually used to do this too but at least people had the ability to opt out of that spoiler alert we're gonna have fun with these okay so with the background out of the way now we can start getting to the really good stuff since these networks are supporting millions of devices is there anything we can do to hunt them down and specifically is there any way we can guess or generate uids if we want to do this the first step is going to be to find some peer-to-peer servers again these are essentially gateways to devices so finding them has a lot of value i started doing this by looking at desktop and phone apps as these are obviously going to be using a vendor's servers however this is a bit tedious and there is a much more efficient way to do it we can use nmap's host detection to do this the protocol has a simple hello message and any valid peer-to-peer server will come back with an ack message so we can configure this probe and then run it against the entire ip space of a cloud provider like aws or alibaba aws in particular is very kind and provides an up-to-date listing of their current ip ranges i've come across 618 peer-to-peer servers since 2018 and some basic fingerprinting has shown that 86 of these are cs2 and 14 are ilink p2p so next if we want to use these servers to find devices we're going to need to find out what prefixes they support like before i started looking for these in apps and even amazon reviews because sometimes people will include their uids in their photos without realizing what they're doing these two reviews have 11 different uids and they're using three different prefixes but sifting through these is also kind of tedious and quickly provides diminishing returns so what is a better way well when we try to connect to a device the server will respond with an error code if the uid is invalid but that error code will change depending on if the prefix you asked for is valid so i wrote a script to brute force prefixes it continuously sends requests and saves any prefixes that appear to be valid there's no rate limiting or checks to prevent this sort of thing and depending on the latency between you and the server you can find all three letter prefixes in about an hour and all four letter prefixes in about 36 hours in total i have found about 488 distinct prefixes and while the average server hosts about 4 prefixes there are a couple that have 130. so we're at a point where we've got servers and we know which prefixes they support we can also predict serial numbers because they're just sequential numbers if we want to find new ids the problem is now the check code which exists precisely to stop this sort of thing if the check code is off by even one letter the uid will be rejected these are five letters long and while that's not an impossible key space to brute force it's still enough to thwart any efforts to find a large number of devices quickly so how can we get around this well with ilink p2p luck would be in our favor i found a variant of the ilink p2p library that contained the algorithm they used to generate check codes it basically hashes a few components using a modified md5 and then puts together the letters from the hash to create the check code this was apparently included in the library to do client-side uid validation which is odd given the peer-to-peer server does this anyway but someone thought it was a good idea to ship this this is a big deal because we can now generate any valid ilink uid meaning we can now connect to on any online ilink device and with this ability we can start to do some very interesting things for one we can now find out how many devices are online but what would be even more interesting is finding out where these devices are we can use a uid to get the ip address of a device and using that we can approximate its location using ipgeolocation so what you're seeing here is an enumeration script i wrote it generates a uid grabs its ip from the servers and then looks it up using max mine's geolight database this is going at 10 000 requests per minute taking this another step further i was able to visualize this data with leaflet marker cluster and open street map of the 3.6 million devices i've seen europe makes up about 21 of this with france italy germany and the united kingdom all having over a hundred thousand devices north america makes up about eight percent of this total with the us seeing over 205 000 devices and canada and mexico both having over 40 000 each finally asia is the most heavily impacted with over 1.8 million devices china and thailand alone make up more than half of the entire dataset horrifyingly lots of these devices use default passwords meaning the uid is enough to gain full access to the camera i disclosed this to shenzhen uni in early 2019 but despite multiple attempts i never received a response back from them and despite this vulnerability i've continued to see an increase in the use of ilink p2p in fact thousands of new uids come online every single month cs2 doesn't appear to be affected by this vulnerability but that's not the end of the story so now i have a way to directly connect to millions of cameras but i'm not really interested in spying on people or talking through their cameras that's creepy and frankly we're not in middle school here what we really want is shells so let's find some camera vulnerabilities when planning for this i really wanted to focus on a big vendor for maximum impact shenzhen high chip vision technology is a major manufacturer in the ip camera industry they caught my attention because as i was looking into different brands i started to realize that a huge number of them were ultimately manufactured by high chip in fact close to 3 million of the ilink devices i have found are using high chip prefixes this sort of practice is very common where manufacturers will sell white labeled equipment to vendors who then resell it with their own branding this is a list of 50 different brands that are actually using high chip under the hood so given their ubiquity any vulnerabilities in high chips firmware would be both widespread and very accessible so to get started i began analyzing their firmware one function of interest was this read request method which is used to handle any commands coming in over peer-to-peer it even handles login and we've got a 10-24 byte buffer to read data off the wire the message header has a field that says how big the payload is so of course that's validated to allow 10 times the size of the buffer okay so we've clearly got a buffer overflow here but how easy is it to exploit this because after all there have been defenses to stop exploits like this for years and the library doesn't seem to use any of them so one very reliable rop gadget later and we've got ourselves a system call and then a reverse shell with root privileges obviously any vulnerability is bad but the most devastating really tend to be those that are pre-auth because any anonymous person can exploit them in this case as long as you have a uid you can get a shell and we now have all the uids once you get a shell you can run binaries you can browse the file system and you can even access the camera's password you can even directly invoke the camera's wi-fi utilities and here's why this is a really bad thing you can do a lot of really crazy things with base station mac addresses google has an entire api that uses mac addresses to perform disturbingly accurate geo-location and the more information you give it the more accurate the results are going to be so once you get a shell you can use it to scan for nearby wi-fi networks and potentially pinpoint the exact location of a camera if you want to try this yourself check out google's geolocation api feed it some mac addresses of nearby wireless networks and see just how accurate it can get it costs literally pennies to do this it's hard to say exactly how many devices are affected by this vulnerability but given i found this bug and almost two years worth of firmware i think it's a pretty safe bet to say that this could be weaponized but thankfully high chip did release a patch for this in june 2020. i did find another vulnerability worth mentioning it's not exploitable over p2p but it's still pretty amusing up until recently you could anonymously reset the password of any high chip camera just by being on the same lan the reason for this is apparently some devices don't have physical reset switches so instead you can just send a magic packet to the camera and it'll reset the password to admin i'll be releasing a script for this but i actually found out high chip provided a tool to do this already so i'm not sure if this qualifies as an exploit per se but have fun with this okay still get a few more tricks up my sleeve let's talk about men in the middle attacks when people hear man in the middle attack they might associate it with something that's restricted to the local network sniffing packets at a coffee shop for example peer-to-peer should be pretty scary by now but we haven't even talked about how it lets you intercept traffic over the internet this comes from the fact that as we now know the peer-to-peer servers are responsible for coordinating all connections clients and devices obey the orders of the peer-to-peer servers so if we can influence that process in any way we may be able to insert ourselves into a session this is particularly scary because despite being a transport layer for the application peer-to-peer doesn't actually perform any encryption or identity checks these measures are left entirely up to the application and as you can guess most don't do a very good job of this in fact some even outright lie about it this is a screenshot from vstarcam's app which assures you that it is building an encrypted channel but as you can see from the packet capture on the right there is absolutely no encryption happening here so how do we get in the middle well once per minute a device is going to log into its peer-to-peer servers this action tells the servers where the client needs to go when they request a connection the problem is this login message just contains the device uid absolutely no device specific secret is used which means if we have a uid it's very easy for us to forge this login message and confuse the servers and if our timing is right when the client requests a session the peer-to-peer server will tell them that we're the device and at that point the client will happily try to authenticate to us and yes that is base64 it's always base64 so we have the password and now we can turn around and connect back to the real device this works with both cs2 and ilink p2p devices cs2 did try to patch this problem but it's pretty easy to circumvent the login message is encrypted with what's called a crc key but avengers devices all use the same crc key so you can just grab it right from the firmware and with some servers you actually don't even need to go this far because it will still let you log in with the old login message so there's not much of a point while this attack is certainly doable there are a couple of drawbacks you need to have a specific uid to target you need to know knowledge of the protocol and you actually need to wait for the person to try to connect however there is another attack that has none of these requirements in fact there is a way that someone with practically zero hacking experience can start owning handfuls of devices let's talk about super devices again these are devices in people's homes that are proxying sessions for other users a lot of vendors use these so the chances of you buying a camera that will act as a super device is pretty high and as i said p2p doesn't actually perform any encryption so what happens when a vendor's crypto sucks too that means that anyone can buy a device and access other people's traffic with it it means literally anyone on the planet can sniff your entire session and capture your password or your video without you ever knowing there's no need to expend a ton of effort setting up a man-of-the-middle attack when this exists in the product by design there are plenty of devices that don't even use encryption for sessions a little pcap parsing can give you a raw video stream that you can immediately watch with something like ff play and all the while users will have no way of knowing whether their connection is being intercepted like this in fact it's a risk that they're taking every single time that they connect to their device as an added bonus this has the side effect of leaking uids during the peer-to-peer handshake so alternatively you can just take the credentials which you also probably captured and connect back to the device yourself i actually developed a proof of concept of this just to collect uids by posing as a super device and by doing this i was able to collect over 236 000 unique cs2 uids over the course of 10 months so even though cs2's check code algorithm has yet to be cracked this is a very reliable way for anyone to collect uids the funny thing is cs2 actually mentioned this exact concern in a marketing deck they said a super device cannot spy on any data it relays because there is no api for this but of course that's insane you don't need an api to pull this off it's absolutely trivial to set up a camera and then leave wireshark running to capture every single packet flowing through that device so that's exactly what we're going to do this bullet cam is running ilink p2p so against my better judgment i'm going to put this on the internet and we'll run wireshark for a while and see what we come back to okay so i left wireshark running for a few hours and we can see that this camera has stayed pretty busy i have the p2p dissector active so we can clearly see what it's been doing each of these hello messages is the peer-to-peer server is telling the camera to reach out and try to help someone with a session so this will generate some handshaking with both the client and the device of particular interest is these relay packet messages which will actually contain a uid of the device that we're trying to relay for but we want to see some actual session traffic and we can locate this by filtering for message drw messages so i'll go up here and apply that filter and sure enough looks like we've got some traffic here so if we actually pull up the resulting conversation here well that sure looks like base64 so if we copy that yep nice secure password there so there's uh some other information in plain text over here we can see some information about the camera the firmware version um and it looks like some other sort of name or identity information but what about video one of the ways that this drw concept works is there are message indexes and message channels and each channel is going to be used for a particular purpose so in this case here it looks like there's a lot of sort of authentication or negotiation going on on this channel 0 but on this channel 2 we start to see binary data so what i did here is i actually wrote a quick script that is going to take the data from this packet capture and just concatenate it together so we can pipe it into a video player so what we're going to do is just go and export packet dissections as json call this export.json and make sure we hit packet bytes save this and then we will go here and do node json2vid export.json pipe that right into ffplay and we have some chickens how about that so final thoughts i had a feeling things weren't going to be pretty when i started down this rabbit hole but i never could have imagined some of these things i've reported all of these problems to the vendors shenzhen uni never did get back to me and the number of devices using ilink p2p has steadily increased since i first reached out to them i've tried to contact a lot of vendors in china over the past few years and it's honestly pretty rare that i get a response at all so i'd also really like to give credit where it's due here because both cs2 network and high chip kept in close contact with me earlier this year even as the covid situation was first emerging in china it was refreshing to see my concerns taken seriously and especially during such a difficult time the issues with cs2 are slated to be fixed in the next release and high chip just released patches for their problems in late june with the warm and fuzzies over boy things are not looking good even with patches on the way i think it's safe to say that everything you just saw is going to be a problem for a long time and this is because a lot of these peer-to-peer problems are outright architectural flaws and they can't really be fixed retroactively i think even if they could be fixed it doesn't matter because most of people don't update firmware anyway i've seen some devices with firmware versions going back half a decade in june of this year i worked with the uk consumer watchdog group witch to try to get some of the affected devices pulled off of shelves amazon who sells more than 20 vulnerable brands didn't respond at all and ebay said to use ip cameras without an internet connection which isn't even possible with a good number of these so you know thanks for that advice i do hope that this was inspiring to some of you because i think there's a lot of opportunity here for further research i think it's pretty clear that peer-to-peer is a pretty nasty vector and i'm sure there's a lot more vulnerabilities in devices beyond what i've discovered on my own i also haven't really had a chance to dig into other peer-to-peer platforms for example calais which is used by over 66 million devices including wise cameras and i know they use a similar paradigm where a uid will get you device access so i think there's certainly opportunity there and while i focus my efforts on high chip there are definitely other massive device manufacturers out there in general i encourage folks to climb up the supply chain a bit if you're looking for vulnerabilities that could be both widespread and potentially high impact i'd like to leave you with a few reverse engineering tips that have led me to some major discoveries first if you're doing reversing be sure to collect as many different samples and variants as you possibly can run diffs against them look for abnormal changes in file sizes some may leave in debug symbols extra logging and alternate functionality so those are all new avenues of exploration also apks are a great way to check out things with minimal effort java can decompile into beautiful readable code that can very quickly reveal interesting things and finally and most importantly throw every single interesting file name or magic string you find into github seriously it is incredible how many people push sensitive source code to public repositories and this has helped me find everything from sdks to documentation to full-on source repos for firmware finally i'd like to give a shout out to the folks who published some of the initial research on peer-to-peer their work was really inspiring and key to the success of my own research so cheers to you guys and that's a wrap my friends thank you all so much for coming happy hacking and be safe out there you

Channel: DEFCONConference

Views: 30,696

Keywords: DEF, CON, DEFCON, DEF CON, hacker conference, security conference, information security conference, information security, conference speakers, hackers, hacking, hacking videos, security research, DEF CON 28, DEF CON Safe MOde, Paul Marrapese, P2P, IoT

Id: Z_gKEF76oMM

Length: 32min 34sec (1954 seconds)

Published: Wed Aug 05 2020