 Alright, um, my name is Mike Rago. I work for a company called 802 Secure and the title of this presentation is Spy vs Spy Who's Watching Who. The research behind this particular presentation is something we've been working on for a few years and it's kind of a mashup of new organic research that we've released as well as previous organic research that we released last year at DEF CON during Skytalks and the Wallachie. So we appreciate the IoT Village having us out to speak for the first time. This is the first time we've presented in the IoT Village and also appreciate the opportunity to sponsor the IoT Village too, so thanks guys. In terms of the overall research it's largely targeted at various types of surveillance, spy cameras, video cameras, etc. We do a lot of broad research across a variety of IoT devices and networks and one of the things we started to discover was beyond the supply chain being completely fragmented in terms of where all these devices are or more importantly their chipsets is that as a result of that software and the fact that the stuff's coming from all over the world it's largely insecure as you might expect and what we're going to do is talk a lot about more about how we've done a lot of live testing around these devices and a lot of the vulnerabilities we've uncovered. One of the areas that we focus on particular is on the wireless side. We have a long history in wireless ranging from Wi-Fi to Bluetooth to ZigBee to cellular to P25 and beyond and being able to look at devices autonomously and how they're communicating has allowed us to uncover some unique vulnerabilities and then furthermore how you think about that physically as well. I don't usually like to talk much about myself so I'll tell you a quick history about how I got into security instead. Um, I uh, back in the early 90s I worked for a company called Nasdaq and while working at the Nasdaq stock market I was always one of those guys that was diddling around while I was a unixus admin in Oracle DBA and I came across this guy known as Dan Farmer and he had a tool called Satan which one of the, one of the first vulnerability scanners long before there were things like Nessus, Qualis, uh, Encircle or other things. Just a, a quick check. Anybody here ever heard of Dan Farmer before? Alright cool. So there's some old folks like myself. So anyways I downloaded this tool. I saw Dan on the cover of Information Week. This guy had kind of long hair, kind of looked like Dave Mustaine sitting on top of a silicon graphics computer and I said this guy looks pretty cool. I gotta try out this tool. So I downloaded it and let it rip on the network and take, take down the trading floor in the middle of the day. Normally it was a fireable offense, uh, but I got called into the VP of security, um, in his office, um, and expecting to be fired and my biggest concern was what I was gonna tell my wife. And, um, so he said listen I'm here to offer you two options actually. You're either fired or you take over security here at NASDAQ. So obviously I took over security at NASDAQ which was a great way to throw me in the deep end of the pool and really get into security. So true story. Alright, so just a little background. How we think about IT, network security, right? Very much focused on the corporate network and the extension of that. Whether it be wireless in your wireless LAN, whether it be your OT networks, your industrial IoT, ICS, everything that comprises your environment. But as CIOs, as other folks that are, uh, responsible for those networks in those environments as well as the data, have to think about this in a whole new way with the explosion of IoT. Meaning that now building automation, 50% of new buildings going up have some type of IoT and wireless enabled functionality. Whether it be for the thermostats and the HVAC, whether it be for power, whether it be for lighting, blinds and all other types of things. If you're responsible for that building or your facilities are housed in it because of the data center, how do you look beyond the network to find a lot of those risks? 80% of IoT is wirelessly enabled. So thinking about that from a wireless standpoint can allow you to get better visibility into that. It's a kind of a new space that NIST is really, uh, endorsing and calling cyber physical. Cyber being your traditional IT and information security team and networks. Physical being the physical side of unmanaged devices, shadow IoT and all these nefarious devices as well. Well, although we tend to think about the network traditionally from, hey, do I have an IoT rogue on my network? Now that organizations are deploying smart TVs in the conference rooms. Printers for many years now have been wirelessly enabled, yet many times misconfigured. Now that there's wireless thumb drives, wireless SD cards, wireless storage devices. Well although these things may connect to your laptop, they don't touch the network at all, right? And so as a result, a lot of these things popping up in environments do represent a data risk to the environment. Also, in taking a look at the increased amount of drone activity, the ready availability of, uh, spy cameras and surveillance cameras. And now how easy it is to set up a rogue cell tower, we need to start thinking about our environments in a whole new way. And that was sort of the premise behind the research we've done in a lot of these areas in this particular case, a focus on surveillance and spy cameras. As we know within Amazon and other places, you can buy everything from surveillance cameras for your home, as well as a plethora of different types of surveillance or spy cameras. They come in all shapes or forms. We've tested many of them. Some of them operate on a battery. Some of them plug into the wall. Some of them are a wall charger for a cell phone, but built into it is a hidden camera. And how you connect to these devices is commonly over Wi-Fi or Bluetooth. You download an app and it allows you to leverage that video camera to record audio, video, take pictures and things like that. It's a lot of interesting protocols that comprise these devices, both at layer two and layer three and above. One of them being stupid service discovery protocol or actually called simple service discovery protocol or SSDP, which is an extension of UPMP. This allows IoT devices once you plop them on the network, either wired or wirelessly, to discover one another and potentially communicate to one another, machine to machine. Some of the packets and how these protocols are configured allow them to do automatic discovery, for example using M-search or allowing a device to notify another device of its presence on the network using notifies. In addition, your traditional and even current day surveillance cameras use a protocol known as RTSP or real time streaming protocol. And this is very much related to the video streams. And then lastly, as we all know, a lot of these devices, ideally via the app or the device itself, want to store the video, audio and pictures in the cloud, random cloud locations that you know nothing about. Some of the surveillance cameras that we've acquired and tested reveal a lot of really interesting information. First and foremost, they use HTTP like protocols. And in addition, they're typically wide open, no authentication and clear text. As we let this device record videos that it was storing either locally to a DVR or in the cloud, that a lot of this was being sent clear text. And if you're just simply sniffing the network and monitoring it using Wireshark or something else, you can actually see where these URLs are and where you can access the videos completely unauthenticated. We've done pen testing for a variety of companies, never ever have we seen this secured. In addition, we'll talk a little bit more about some research we released at RSA about how we exploited these protocols to actually do command and control and other interesting things. Spy cameras typically have a mobile app. So one of the first ones I tested came in a tiny small box. I bought it on Amazon for $20. Has a teeny little sensor or video camera built into it, a little sticky thing so you could stick it under a table or on a wall or hide it behind a book. And upon unboxing it, there was some paperwork in it and it was all in Chinese. But I saw a URL and I saw something that referenced a mobile app and I was like cool, I'm going to download this random map from a random location, an IP address that doesn't resolve to anything. So obviously I do this on a separate test network with test credentials and proceeded to go ahead and download that app. And then in doing so, paired to the actual device, a lot of these devices out of the box do support Wi-Fi and initially run an ad hoc mode device to device. You can enable it as an AP, you can put it on the network, things like that. Ideally if you're going to be using it as a spy camera though, you don't necessarily want to go plugging it into the network or the environment that you're doing surveillance on, right? So, but it's good to know the different functionality that's available there. Upon doing a lot of the testing and sniffing the network both on the wireless and the wired side and observing behaviors started to see a lot of communications to the cloud, to Alibaba, both in Canada and in China. In addition, it was starting to transmit the U-UID, uh, the MAC address and a variety of other things. Then I saw my username and password passed over the network too, in clear text out to the internet to some random cloud at Alibaba. So, definitely interesting, definitely suspicious, definitely freaked me out. Some of this research we released last year at Defcon 26, uh, both in the Wall of Sheep and, uh, further details in SkyTalks since that's a closed session. And interestingly enough, one week later, the U.S. put a ban on the exact same cameras that we covered in the talk. I can't say the two were related, but it was one heck of a coincidence. Some of the other vulnerability research started, starts to kind of touch on the physical aspects of IOT. Even for your own surveillance cameras perhaps at home, a lot of these things are enabled through a hub that may speak to the cameras via Wi-Fi, occasionally via Bluetooth, also commonly via ZigBee or Z-Wave as well. And we started to take a look at these hubs and their relevant functionality. Turning the hub around, I found two USB ports on it. We'd already been doing research and exposed some vulnerabilities and had submitted the vulnerabilities to Bug Crowd related to some different manufacturers of wireless thumb drives. We find these commonly in a lot of customer environments, especially in healthcare, interestingly enough. It seems, and what we find and have kind of determined is that a lot of people out there are obviously still buying, you know, small storage devices, but not necessarily realizing that there's wireless built into them. So they're using them just like a standard thumb drive or an SD card, but we, in our pen testing and analysis for them are discovering these devices via the fact that they're wirelessly enabled and they're wide open because nobody's configured them. Furthermore, a lot of them have a built-in battery. So even after you unplug it from the laptop and have stored data on it, that device is still on. So if you're walking around up and down the street, get on the bus, go to a coffee shop, all that data is readily accessible on a battery backed up thumb drive or SD card. So back to the IoT hub. So since I had all these devices hanging around and there were two available ports available on the IoT hub for the surveillance cameras, I decided to go ahead and plug one in and then connect to it wirelessly via the thumb drive. What I started to realize is, as the videos were being recorded, they were not only being recorded locally to the device and being sent to the cloud, they were being stored to my thumb drive. No authentication, no encryption. The only thing I did was I plugged in a thumb drive into the IoT hub. And by the way, with it being wirelessly enabled, it kind of freaked me out to check my own hub in my own house because I have a lot of people over all the time for parties. And I was kind of wondering, wow, anybody at the party could just walk by, turn my hub around when there's nobody in the room and plug in a thumb drive with wireless capability and be sitting outside the house viewing the videos being recorded by my surveillance cameras. And it's as simple as that. We did disclose the vulnerabilities to bug crowd. They did go ahead and notify the vendor and this has been patched. But these different types of surveillance cameras and the relevant hubs are coming out all the time. So if you have one in your house, make sure you're not vulnerable to this. If you want more information about this, some of these things we did live demonstrations of, both at the RSA conference and at DEF CON last year and the year before. Drones. So why am I talking about drones? Well, as we all know, drones can also be used for video surveillance and taking pictures and things like that. A lot of these drones have various types of wireless and RF capabilities. Detecting them sometimes can be done over RF, but in other cases, it requires radar. Specific to RF and specific to Wi-Fi, typically hobbyist drones like you might buy on Amazon. Even a drone such as that can be used for adversarial activity. Not only for recording audio and video, but as we know, dropping a small pathogen, flying over a security fence at an ICS facility, and even having tethered onto them additional battery backed up spy cameras as well. Typically when you unbox this thing, and I'm sure many of us here have played around with drones, right? They have a Wi-Fi capability built into them and you can download a mobile app and that mobile app will allow you to record video and take pictures as you're flying the thing around. It might even allow you to control the drone as you're flying it around. Many of the organizations we work with that are customers have this activity once or twice a day or roughly a few times a week. It's really difficult though to determine if it's a hobbyist or if it's adversarial. So if you're running Cali or formerly Backtrack and you run Aircraft NG or some of the other tools out there, you know, your flavor of the day, you can go ahead and run Kismet, Aircraft NG, all types of things to look at everything wirelessly, right? Especially Wi-Fi. In this case here, I went ahead and I was analyzing and sniffing and taking a look at how the drone, you know, was communicating, how it was configured from a Wi-Fi perspective and how my mobile device was paired to it. And it really uncovered a lot of interesting intelligence and information. In working with lots of customers, you know, they're trying to figure out how to solve the drone problem. We work with the casinos, we work with airports, we work with ICS and power facilities. And how a lot of customers initially think about this problem is, hey, we want to identify it and knock it out of the sky, right? And obviously if you do that, it's going to fall and probably hit something or hit somebody, right? So thinking about this from a more practical standpoint, could you perhaps look at this from a wireless standpoint and get enough intelligence here to still capture the adversary? So just like an access point, I'll see the BSSID, right? I can see that MAC address. As we all know, that part of that is comprised of an OUI that maps to a manufacturer. Interestingly enough though, if you take a look at the ESSID, more commonly known as the SSID, you'll actually see typically, unless it's hidden, the SSID. But interestingly enough, it's actually difficult on a lot of drones, at least based on when you take it out of the box, to actually change the SSID. So most people don't. And as a result, that SSID from the factory actually exposes two things. One, FLD, what type of drone is that? Well, we've done a lot of mapping and there's some public maps out there too and some tools on GitHub that actually map these out and this maps actually back to a specific type of drone, a specific manufacturer. Furthermore, the rest of the SSID exposes the last three octets of the MAC address, uniquely identifying the drone. So if I'm monitoring this over the course of a week, I can potentially identify a repeat offender, right? Because purely just seeing the SSID, I can see if it's the same drone or a different one. So additionally, I can also see the station or the mobile device paired to it that's being used to fly it around. So now I actually have two pieces of forensic information. Not only intelligence on the drone itself, but the mobile device paired to it or essentially the guy flying the drone, who's probably in a different location than where the drone actually is. So that's exactly what happened when we were doing some analysis. We're working with a critical infrastructure facility customer and they contacted us because they said, you know, we see, you know, drone alerts or some drone activity and furthermore, we saw the mobile device paired to the drone. The two devices were in two different locations. The mobile device was along the edge of the perimeter fence and inside the fence area, of course, was the drone because he flew it over the fence and was flying it around the power facility, especially by the power distribution units. Furthermore, just before that, we saw the mobile device paired to the guy's truck and determined that truck was a brand new Ford F-150 with smart technology. So he's probably listening to Pandora or Spotify or something like that, right? Parked the truck along the edge of the fence, unpaired, paired his mobile device to the drone and then flew it over the fence. So now we had three pieces of forensic data and providing that to the customer and that relevant forensics information allowed them to actually go back to their surveillance cameras because we're able to identify the location of the truck and the mobile device. They got the guy's license plate and they actually caught the guy. So when you think about drone activity, you think about video surveillance, you think about countermeasures related to this, all of this was done with just completely free tools built into Cali, right? And there's just some really powerful information there that you can use in your own way. Okay, so IoT protocol exfiltration and exploitation. There's so many different protocols that comprise IoT. And as we mentioned, the supply chain is just so messed up. You thought that Android fragmentation was bad. This is that on steroids, right? As I mentioned earlier, in looking at how a lot of these devices communicate and using SSDP or simple service discovery protocol, there are some discovery packets and things built into the protocol such as M-search to discover other devices to allow them to then potentially communicate machine to machine as well as notify packets, thus announcing their presence on the network. A lot of these protocols are clear text and unauthenticated and lack any integrity mechanisms as well. And in doing so, although they may be site-routable or essentially on the localized network, if I'm monitoring what's going on, I can actually inject packets and leverage some of the free form fields to inject things such as URLs, command and control options and other features. For example, in this case, there's an optional field sometimes used by the manufacturer, sometimes not, or the OPT field. And in doing so, we are able to actually modify the URL pointing to a separate URL or command and control location to allow this protocol to actually be exploited. So we went ahead and did that and communicated it and allowed this to be consumed by another IoT device. And interestingly enough, we observed that it consumed this information and wanted to ideally every once in a while communicate to this fake command and control URL or IP address, which we also tried, to see how it was consuming and using this information. So if you think about this for a moment, you plop all of these onto your network and you trust them. But you have one of these maybe from a manufacturer overseas of which you know nothing about. They communicate to other IoT devices on your same network. It includes something embedded like this and allows a very easy way across your network for all the devices to infect one another, either directly, indirectly or point them to various command and control centers to download additional software. So in our scenario, we did exactly that. We leveraged one of the video cameras I mentioned earlier for a lot of the vulnerabilities and testing that we had done already, went ahead and modified the device itself. So it was communicating this additional optional field with a malicious URL embedded in it and allowed it to be retrieved or received by other devices on the network. In doing so, we had a smart TV, a cheap one that I had gotten at Oli's and it went ahead and took this and we observed it trying to communicate following that to the IP address we had embedded in the OPT field. So as we think about a lot of these vulnerabilities, right, and how we interact with customers and do pen testing for them, it's really like a big lack of visibility beyond the network today, right? That physical space of unmanaged shadow IoT devices passing by, people passing by, right? But there's a wealth of information in there. We had a customer just last week that had a break in into the building. And by monitoring everything wirelessly, we actually found that that Sunday night during that one-hour timeframe of which they said there's never ever anybody in the building, we saw the guy's MAC address for his mobile device. And while although for iOS and for Android, those cycle through randomization, he must have been somebody that was there previously because it accidentally connected to the guest Wi-Fi and we got his legit MAC address from it. Just by listening, just by monitoring, just looking at that timeframe. In addition, in thinking about this, how can you leverage your own wireless LAN environment, whether it's Cisco, Aruba, Arrow Hive or something else, right? And really leverage that to identify what's going on beyond the network. If you have a device that disconnects an employee that disconnects from the network, do you have the ability to see if they're connecting to a spy camera or a drone or anything like a Wi-Fi pineapple? The physical space is becoming littered now with these IoT devices. And understanding the context and the characteristics of how these devices are connecting has a big impact on your network now and especially for the future. So I'll lead you with some lasting thoughts and things to think about in terms of overall hygiene for your environment, your network. We talked about a lot of the anomalous behaviors and vulnerabilities that we had found across a lot of spy cameras, surveillance cameras, drones, etc. Strange outbound connections connecting to the cloud, clear text, going to Alibaba, Canada and China, right, just to begin with. Seeing my username and password being transmitted from one of these random IoT devices, clear text out to the internet to some cloud provider. Furthermore, leveraging that intelligence to go to the cloud provider and by diddling with some of the URLs, actually discovering other people's videos, sending in that same repository. In addition, thinking about wireless security postures not only from misconfigurations but state change. We talked about how simply transmitting the OPT field with URLs, IP addresses, command and control or fake command and control centers and doing that via those specific packets such as Msearch and Notify and exploiting the OPT field or optional field for doing that allows other IoT devices to receive that information, potentially consume it and themselves try to communicate with that URL. That unto itself is a state change. Why did that IoT device that is a sensor or an actuator and sends a packet once an hour with an update or just a small group of packets once an hour with an update is now transmitting or communicating to an IP address outbound or further more even on a closed network attempting to. Following this session, a good friend of mine, Chet Hosmer and I have done a lot of research around this in which Chet has really created this Raspberry Pi that sits on the wired network and we've programmed it to baseline on the existing environment and identifying anomalous behaviors from that point moving forward. If you're interested in that, Chet will be presenting that here right at five o'clock over in the packet hacking village and if you miss that you can go to pythonforensics.org to get more information about that Raspberry Pi. So I appreciate the time today. I hope you got a few gold nuggets out of that and I'll hang out in case anybody's got any questions or comments but thank you for your time today.