Smile for the malware.
[ Music ]
Dave Bittner: Hello everyone and welcome to the CyberWire's "Research Saturday." I'm Dave Bittner and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems and protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. [ Music ]
Mickey Shkatov: When I was partially an accidental encounter with one of the cameras I had-I had been using for a while, it had been causing me some problems over several meetings and I thought maybe it requires a firmware update. I saw-I look it up and, you know, go to the manufacture website, it's Lenovo, it's probably solid, download the firmware, and then I realized that it's running Linux and then everything else happened.
Elliott Peltzman: Our guests today are Jesse Michael and Mickey Shkatov, Principle Researchers at Eclypsium, sharing their work entitled "BadCam - Now Weaponizing Linux Webcams." [ Music ]
Dave Bittner: Well, I mean, let's walk through it together here. Is at the core of this an issue with firmware?
Mickey Shkatov: The core of this is not the issue with the firmware, it's the issue with the lack of security of validating that the firmware is indeed the correct firmware, or is that it is signed and validated or issued by the vendor. That was the core problem. Having Linux on a webcam is not necessarily a bad thing, but having Linux on a camera that anyone can modify is a bad thing.
Dave Bittner: Well, tell us about this particular camera model. I mean, who is this designed for and what situations would it typically be installed to be used for?
Mickey Shkatov: There are two models of this camera made by Lenovo or sold by Lenovo, branded by them. The 510 and the Performance web-FHD I believe it's called. These cameras are based on a preset kit by an SoC vendor called SigmaStar which we assume was contracted or paid by Lenovo to create a custom board, a custom web camera product for them to rebrand and repackage, and just hand it off to the Lenovo engineers and they started maintaining it and making sure it works. And basically that's the usual chain of events when something like this happens is you have-you have an SoC vendor, it creates different types of potential products or engineering development kits, sends these out to big OEMs, ODMs and they choose whatever fits their needs better and they work together make a deal and hand it off to the vendor OEM, ODM to continue support and branding and all of that other stuff. So, the SoC vendor just creates the hardware and the interface to the hardware and hands it off to someone else to do, whatever they need to do with it.
Dave Bittner: I see. Jesse, I'm going to get you to jump in here. I mean, we've known about BadUSB attacks for over a decade or so, but this is a little different. Does BadCam build on that legacy of BadUSB attacks?
Jesse Michael: That kind of highlights some of these previous issues with certain types of devices that can be reconfiguring themselves as a keyboard and other things like that. With those it was usually more of a simpler chip like a Phison controller or something that you can reprogram and it's a little more difficult to rebuild some of that. With this particular chip because it's Linux, it literally has the full gadget interface, so you can just through shell scripts and maybe finding the right kernel module, you can reconfigure it to do different things. And to kind of follow onto one thing that Mickey said, like a lot of times eventual brand-like the brand like Lenovo, they don't necessarily know all of the components that are in this thing that has been supplied by a supplier like SigmaStar. So, like SigmaStar, the SoC System-on-a-Chip vendor, will create this camera and put all these things in it, build the software [inaudible 00:04:49] for Lenovo and ship it to them and Lenovo might not know all the components that are inside there is kind of the-and it is-additional complication here that can have some bad implications.
Dave Bittner: So, Lenovo could say, you know, we have a certain set of specifications that we want met.
Jesse Michael: Yeah.
Dave Bittner: And the supplier meets them, but there may be more than that on board the hardware?
Jesse Michael: Oh, yeah definitely. Like, they don't even necessarily have all of the software that they can even rebuild it themselves; they're dependent on that supplier to make firmware updates and if things like this come up, they have to go back to the supplier and ask them to fix it rather than being able to fix it themselves in a lot of these cases.
Dave Bittner: I see. Well, let's walk through the key vulnerability here. I mean, what did you all find inside of these webcams that makes them vulnerable?
Mickey Shkatov: The way that they chose to implement the way of the update procedure, the update process, was completely insecure. It literally was a straightforward write Webware style of, I will give you a binary file and you would write it directly into the flash on the camera wherever I tell you to; that opens up modifications for everything on the camera. So, it goes from the bootloader to the other partitions that the vendor has setup on the flash, to a file system, to additional file systems, vendor-specific configurations et cetera, et cetera. It's just complete control over everything.
Jesse Michael: Yeah, there wasn't any kind of cryptographic signature verification of this, so you essentially send it a-with-this is a USB video device, so there is this USB video class UVC and you can send it a specific type of message to switch it into a different update, kind of this vendor-specific message that you send to switch it into update mode and then you send the code to run on the camera and it doesn't really verify that. And then, you send code to run on the camera and then you're literally sending commands like, "erase this region of the flash," "write this file that I just transferred to you to this other region of the flash" without any real security guarantees. It does try to do a-like a MD5 check, but it's literally just verifying that the transfer succeeded over the USB connection, not that it is at all the firmware image that you were supposed to update. So, it calculates the MD5 right before it sends it and they verifies on the other end that the transfer over the USB connection went correctly, but there isn't any kind of even a hash or anything provided by the vendor; it's just whatever the update tool calculates right then. So, you could just modify the firmware file, it will recalculate the MD5 for it and then send it over without any kind of any security guarantee or any kind of security check there.
Dave Bittner: Wow. So, in the research you all showed that remote flashing is possible? Do I have that correct?
Mickey Shkatov: Well, the-it's kind of the remote part is a bit interesting from [inaudible 00:08:17], because the fact the camera is connected to a computer, it has to be connected over USB obviously, but if you have any software running on the machine, even if it's not administrator, you just need user access to the USB device and then you just communicate over regular USB commands. Then you can flash the camera. So, remotely it can be done if you have a footprint on the machine and then you discover it, but if one of these devices is plugged into it then you just flash it, but you don't necessarily need to escalate to admin.
Jesse Michael: Yeah, to follow-up on that a little bit, like there is a distinction between the physical access which requires you having to physically touch the device versus local access which just means, you have code execution nearby. So, if I have code execution maybe I hopped a browser bug and got code execution on the device, or phish somebody, or did something else that got code execution, I can then make modifications to that camera without any problem and from there you can then do things like enable network access for the camera itself using that USB gadget which one of the fun examples that we had. But yeah, I think one of the things that we noticed in the Lenovo advisory is they explicitly said it was physical access; that's not actually true. It requires local access which just means, arbitrate to an execution. If I SSH to a device that has one of these systems connected, I'm connecting to it remotely through that SSH section, but I have local code execution running, running some command that allows me to talk to the physically connected USB device. So, isn't actually physical access, it is a local access which can mean a remote access depending on how you get access to that local code execution.
Dave Bittner: Right. Right. There is some nuance there.
Jesse Michael: Yeah. Yeah.
Dave Bittner: Yeah.
Jesse Michael: I just wanted to kind of make clear that it's not physical access, it's not like-it's like this particular device is not listening on an Ethernet port already, we were able to enable it and give it network access post-exploitation, but I think a lot of people will mistake that distinction between local access and physical access to mean that you need to be able to physically touch the device to exploit it and you really don't in this case. [ Music ]
Dave Bittner: We'll be right back. [ Music ] Well, I'm glad you made that clarification. Once the webcam is compromised, what kind of malicious behavior can it exhibit here to what's the range of possibilities?
Jesse Michael: One of the examples that we showed off was that this device already had-like one of the things that we thought was interesting is just looking at the init scripts from the device; as it came from the vendor, it was running a Telnet daemon. So, it's like it-by its default configuration it didn't have a network that were gadget network access running, but it was launching a Telnet daemon which seemed weird and it kind of led us down the path of like, let's just turn it into a network device and basically by reconfiguring things and using the Linux gadget framework, we were able to essentially turn this into a network device and a keyboard which then sends commands to the laptop or device that it's connected to in order to enable Internet sharing with the camera. So, then the camera itself can then make that network connections out to a command and control. One of the examples that we showed off was doing this in order to bring up a network connection, enable connection sharing to get access to the Internet from the camera and then downloading a metasploit payload from the command and control and having a remote shell or a metasploit session back to the command and control running in the cloud, and from there you can do additional things like download additional applications to run and other things like that. And depending on what kernel modules you have installed and what applications you have, you could potentially turn it into like a listening device, or like take pictures through the camera. So, it is a camera and it is a-it has a microphone built in so that is something that you can potentially do.
Dave Bittner: Is it fair to describe this by saying, this is first and foremost a Linux device that has camera functionality rather than saying this is a camera device that runs Linux?
Jesse Michael: I'd say that's an accurate characterization yeah, because I think it is a general purpose device; it does have some restrictions for like the size of the file system is not huge so you do need to be a little careful with that, but you can download and run additional things over the network, because you can it reconfigure itself and reach out to the network using the host connection without the user being aware of that and it's an interesting capability to see.
Dave Bittner: Yeah.
Jesse Michael: I have previously done stuff for like Rubber Ducky's and like Bash Bunny's and other devices that have kind of implemented this type of stuff and previously I had seen a mention of like "Here is how to manually setup the network in order to share it with a Bash Bunny," but I hadn't seen a script where the device itself enables Internet sharing for itself in order to get access out. So, I thought that was kind of an interesting approach to take to kind of flip the attack around a little bit.
Dave Bittner: Yeah. Let me ask what I presume is a silly question, which is that when I think of webcams, I think of a light going on when they power up, right? Is this-or are we-is it routine to circumvent that in this case?
Jesse Michael: That is one thing that we started to look into but we didn't get-we didn't fully figure out if we could turn off the camera-the light on the camera or not. Sometimes on some devices that is controlled by just GPIO pins, so for like software within the camera. It's not something that's physically wired as a circuit outside of the software control. We don't know if that's the case in this particular camera, but one thing I would like to kind of highlight is that, we were focused on Lenovo and these specific cameras, but SigmaStar makes cameras for a number of other vendors and I think it's an open question as far as which other devices are vulnerable to this type of thing or other similar interesting things. So, in our presentation we did highlight a couple of other vendors that we identified that are selling cameras that are ultimately sourced by SigmaStar. Some of them might be doing things better; it might be configuration options where they turned on certain features that SigmStar had provided but others didn't, so I'm not saying that these other vendors are necessarily all vulnerable, but there might be other things to look at there, because there were a lot of additional vendors that are selling these SigmaStar cameras.
Dave Bittner: Yeah. Did you reach out to the manufacturer and let them know?
Jesse Michael: Yeah, we did reach out to both SigmaStar and Lenovo; Lenovo basically worked with SigmaStar to get firmware updates for the camera and was able to put patch out. We haven't fully verified that that actually fixes the problem. One thing we did see is that it doesn't-like so, a lot of times in order to properly fix problems like this you need to provision a key into the SoC itself, so then the SoC is verifying the flash. We don't know if the SigmaStar SoC has fuses, but the update that we saw, if you do have physical access you can just re-flash it back to a vulnerable version even if after it had the newer version on it. So, we don't know if there are ways to get around the software update fixes that SigmaStar did, but they did do updates that instead of just updating the kernel and file system, this new update that was released does update U-Boot that's in the camera also and that's what is applying the updates. So, hopefully that is actually done in a secure way, but just if you do have physical access to the camera, this is kind of where that distinction between physical access versus local access comes in. Like, if you buy one of these third-party or like buy it from eBay or something or some other third-party provider, you don't really have a guarantee that somebody hasn't flashed it back to a vulnerable version that has these like an implant already in it.
Dave Bittner: Yeah. Mickey, so I'm curious, I mean, is the reality of this that let's say I'm a bad actor and I've gotten access to a user's machine; is as simple as poking around to see if they have a webcam that has these sorts of capabilities that perhaps this is a place that I can hide my malware within this little remote Linux device that's been hosed up to the core machine?
Mickey Shkatov: In laymen's terms, basically yes.
Dave Bittner: Okay.
Mickey Shkatov: For SigmaStar it's a bit complicated to explain, but SigmaStar has this API/SDK/no method of communicating with their devices and their stack. So, as an attacker you would enumerate USB devices, find the devices that identify as cameras, and then you can poke at them by sending them special commands that might trigger a reboot and then you would know if it's potentially affected or potentially vulnerable to anything. And then, you could just take the model and adapt your payload to it. It might take some time, but it's not out of the realm of possibility.
Dave Bittner: Right. And again, you know, forgive some of my questions here that they may sound simple, but in your research am I correct that you could flash the device so that to the host computer it would seem to be something else now, it would seem to be a keyboard or a storage device, or something like that?
Mickey Shkatov: Yes. Everything that's-everything that's on the USB gadget stack that Linux offers, would be a potential device that can be shown to the host.
Dave Bittner: So, you presented this at DEF CON, I'm really curious to know what the response was and the-how the crowd felt about this? It seems to me like this would be a very entertaining presentation. How did it go for you?
Mickey Shkatov: It was. It was very entertaining. We got a-we got more than a few laughs at some point. It was a-there were several key points we discussed, well aside from the entertainment factor of this webcam becoming a Bash Bunny. There was the entire other side of logistics of getting the GPL code or communicating with vendors and communicating with finding people to get source code, reaching out over LinkedIn, Twitter, any possible venue of communications we could find.
Dave Bittner: So, what are your recommendations then based on what you discovered here for the security professionals in our audience, what's the heads up that they should be aware of?
Mickey Shkatov: Well, the biggest takeaway from this is it's like we're taking one step forward, two steps back when it comes to smart devices. In the past-well, still there are still a lot of webcams out there that are very simplistic in design, they don't run Linux. They have dedicated firmware that just it runs whatever monolithic or simplified OS just perform. It converts image from an image sensor to a USB and just shows it to the host and then lets the host do all of the heavy lifting of post-processing, or AI, or image recognition or stuff like that. But it seems that now it's easier to just put some of the processing power in the camera and have the camera do it for you which borrows a lot of elements from the IoT world. So, now we see-we're seeing webcams that run Linux same as this one, but open up a network adaptor or USB to allow for firmware updates to be transferred by an FTP to a USB device which is wild, right? It's [multiple speakers]. Yeah, it's just like-yeah, we are bringing in the known stack of issues that we've seen in IoT and stuff that's connected to the web over to the USB stack and now we have the USB pipeline to-the medium to contend with and just poke at that and more work for us.
Dave Bittner: Yeah. Jesse, any additional thoughts?
Jesse Michael: I mean, yeah. I think just as Mickey was saying, like adding new features like AI face recognition and things like that has been a driver for adding these devices, but also there is the just the time to market of like, if I have a vendor that can give me this SoC that runs Linux, it's easy to port my stuff to it rather than maybe some real-time OS with a architecture chip that I'm not familiar with. This is just an ARM processor that runs Linux and a lot of people are familiar with that these days. So, it's a lower curve for training and building something like training your developers to building something, but and it lets you get things out, get to the market faster and a lot of times security is an afterthought and I think that is something that we'll just continue to see when people try-or try to rush things out like this.
Dave Bittner: Right. Can you run Doom on it?
Jesse Michael: Not-maybe, you know, like we try to [laughter]. [ Music ]
Elliott Peltzman: We'd like to thank Jesse Michael and Mickey Shkatov, Principle Researchers at Eclypsium sharing their work "BadCam - Now Weaponizing Linux Webcams." We'll have a link in the show notes. And that's "Research Saturday" brought to you by N2K CyberWire. We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cybersecurity. If you liked the show, please share a rating and review in your podcast app. Please also fill out the survey in the show notes or send an email to cyberwire@n2k.com. We're proud that N2K CyberWire is part of the daily routine of the most influential leaders and operators in the public and private sector from the Fortune 500 to many of the world's preeminent intelligence and law enforcement agencies. N2K helps cybersecurity professionals and organizations grow, learn, and stay ahead. We are the nexus for discovering the people, tech, and ideas shaping the industry. Learn how at n2k.com. "Research Saturday" senior producer is Alice Carruth. Our producer is Liz Stokes. We're mixed by Elliott Peltzman, that's me, and Tre Hester. Our executive producer is Jennifer Eiben. Peter Kilpe is our publisher. Dave will be back next week. Thanks for listening. [ Music ]
