Dave Bittner (4:47)

I see. Jesse, I'm going to get you to jump in here. I mean we've known about bad USB attacks for over a decade or so, but this is a little different. Does Bad Cam build on that legacy of bad USB attacks that kind of.

Jesse Michael (5:04)

Highlighted some of these previous issues with certain types of devices that could be reconfiguring themselves as a keyboard and other things like that? With those, it was usually more of a simpler chip like a fison controller, something that you could 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 some finding the right kernel module, you can reconfigure it to do different things and to kind of follow onto one thing that Mickey said. 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 chip vendor will create this camera and put all these things in it, build this software and tooling for Lenovo and ship it to them. And Lenovo might not know all the components that are inside. There is kind of an additional complication here that can have some bad implications.

Dave Bittner (6:13)

So Lenovo could say, you know, we have a certain set of specifications that we want met.

Jesse Michael (6:19)

Yeah.

Dave Bittner (6:19)

And the supplier meets them. But there may be more than that on board the hardware.

Jesse Michael (6:24)

Oh yeah, definitely. Like they, they, they don't, they don't even necessarily have all of the software that they could 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 (6:43)

I see. Well, let's walk through the key vulnerability here. What did you all find inside of these webcams that makes them vulnerable?

Mickey Shkatov (6:53)

The way that they chose to implement the update procedure, the update process was completely insecure. It literally was straightforward. Write what, where 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 other partitions that the vendor has set up on the flash, to the file system, to additional file systems, vendor specific configurations, et cetera, et cetera. It's just complete control over everything.

Jesse Michael (7:45)

Yeah. There wasn't any kind of cryptographic signature verification of this. So you essentially send it. This is a USB video device. So there's this USB video class uvc, and you can send it a specific type of message to switch it into a different update, this vendor specific message that you send to switch it into update mode. And then you send 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 in the flash without any, any real security guarantees. It does try to do an 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 then 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'll recalculate the MD5 for it, and send it over without any kind of any security guarantee or any kind of security check there.

Dave Bittner (9:15)

Wow. So in the research, you all showed that remote flashing is possible. Do I have that correct?

Mickey Shkatov (9:23)

Well, the camera, it's kind of the remote part is a bit interesting from my definition, 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 that 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 (10:07)

Yeah, to follow up on that a little bit, there's a distinction between physical access, which requires you being able to physically touch the device, versus local access, which just means you have code execution nearby. So if I have code execution, maybe I popped a browser bug and got code execution on the device or phished 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 was one of the, 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 arbitrary code 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, to the physically connected USB device. So it isn't actually physical access, it is local access, which can mean remote access, depending on how you get access to that local code execution.

Dave Bittner (11:24)

Right, right. There's some nuance there.

Jesse Michael (11:26)

Yeah. Yeah. I just wanted to kind of make clear that it's not physical access. It's not 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 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.

Dave Bittner (11:59)

We'll be right back. At Thales, they know cybersecurity can be tough and you can't protect everything. But with Thales, you can secure what matters most. With Thales industry leading platforms, you can protect critical applications, data and identities anywhere and at scale with the highest roi. That's why the most trusted brands and largest banks, retailers and healthcare companies in the world rely on Thales to protect what matters most. Applications, data and identity. That's Talas. T H A L E S learn more@thalesgroup.com cyber and now a word from our sponsor, ThreatLocker, the powerful Zero Trust Enterprise solution that stops ransomware in its tracks. Allowlisting is a deny by default software that makes application control simple and fast. Ring Fencing is an application containment strategy ensuring apps can only access the files, registry keys, network resources and other applications they truly need to function. Shut out cybercriminals with world class endpoint protection from Threat Locker. Well, I'm glad you made that clarification. Once the webcam is compromised, what kind of malicious behavior can it exhibit here? What's the range of possibilities?

Jesse Michael (13:44)

One of the examples that we showed off was that this device already had. 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 in its default configuration it didn't have a network gadget and network access running, but it was launching a telnet damage which seemed weird and it led us down the path of let's just turn it into a network device. 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 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 metasploit session back to the command and control running in the cloud. From there you can do additional things like download additional applications to run and other things like that. Depending on what kernel modules you have installed and what applications you have, you could potentially turn it into a listening device or take pictures through the camera. So it is a camera and it has a microphone built in. So that is something that you could potentially do.

Dave Bittner (15:37)

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 (15:53)

I'd say that's an accurate characterization. Yeah, because I think it is a general purpose device. It does have some restrictions for 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 have it reconfigure itself and reach out to to the network using the host connection without the user being aware of that. And it's an interesting capability to see. I've previously done stuff for Rubber duckies and Bash bunnies and other devices that have implemented this type of stuff previously I had seen mention of, here's how to manually set up the network in order to share it with a bash bunny, but I hadn't seen a. 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 (17:00)

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 it routine to circumvent that in this case?

Jesse Michael (17:21)

That is one thing that we started to look into, but we didn't fully figure out if we could turn off the light on the camera or not. Sometimes on some devices that is controlled by just GPIO pins. So 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 other similar interesting things. So in our presentation we did highlight a couple of other vendors that we identified. They're 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 SigmaStar 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 Sigma Star cameras.

Dave Bittner (18:44)

Yeah. Did you reach out to the manufacturer and let them know?

Jesse Michael (18:50)

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 do put a patch out. We haven't fully verified that that actually fixes the problem. One thing we did see is that it doesn't. 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 reflash it back to a vulnerable version, even if after it had the newer version on it. 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 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 (20:30)

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 it 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 (21:02)

In layman's terms, basically, yes. Sigmastar, it's a bit complicated to explain, but sigmastar has this API SDK.

Jesse Michael (21:14)

Known.

Mickey Shkatov (21:15)

Method of communicating with their devices and their stack. So as an attacker, you would enumerate USB devices, find 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'd 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 (21:51)

Right. And again, you know, forgive some of my questions here, that 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 be, it seemed to be a keyboard or a storage device or something like that.

Mickey Shkatov (22:11)

Yes. 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 (22:24)

So you presented this @Defcon. I'm really curious to know what the response was and 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 (22:39)

It was, it was very entertaining. We got more than a few laughs at some point. 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, any possible vendor of communication, venue of communications we could find.

Dave Bittner (23:19)

So what are your recommendations then, based on what you've discovered here? For the security professionals in our audience, what's the heads up that they should be aware of?

Mickey Shkatov (23:30)

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 still, there's still a lot of webcams out there that are very simplistic in design. They don't run Linux. They have dedicated firmware that just runs whatever monolithic or simplified OS to just perform converts image from an image sensor to a USB and just shows it to the host and then lets the host do all 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're seeing webcams that run Linux, same as this one, but open up a network adapter over USB to allow for firmware updates to be transferred via FTP to a USB device, which is wild, so to speak. 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 medium to contend with and just poke at that and more work for us.

Dave Bittner (25:09)

Yeah. Jesse, any additional thoughts?

Jesse Michael (25:12)

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's 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 building something 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 are trying to rush things out like this.

Dave Bittner (26:07)

Right? Can you run doom on it?

Jesse Michael (26:11)

Not maybe like we should work on that.

Host/Announcer (26:26)

We'd like to thank Jesse, Michael and Mickey Shkatov, principal researchers at Eclipses, 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 like the show, please share a rating and review your podcast app. Please also fill out the survey in the show notes or send an email to cyberwire2k.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're the nexus for discovering the people, tech and ideas shaping the industry. Learn how@m2k.com research Saturday's Senior Producer is Alice Carruth. Our producer is Liz Stokes. We're mixed by Elliot Peltzman, that's me and Trey Hester. Our executive producer is Jennifer Ibin. Peter Kilpe is our publisher. Dave will be back next week. Thanks for listening.

Mickey Shkatov (28:04)

Limu Emu and Doug Here we have.

Jesse Michael (28:08)

The Limu Emu in its natural habitat, helping people customize their car insurance and.

Dave Bittner (28:14)

Save hundreds with Liberty Mutual. Fascinating.

Jesse Michael (28:19)

It's accompanied by his natural ally, Doug Limu is that guy with the binoculars watching us cut the camera.

Dave Bittner (28:26)

They see us. Only pay for what you need@libertymutual.com Liberty Liberty Liberty Liberty Savings vary Underwritten by Liberty Mutual Insurance Co. Affiliates excludes Massachusetts Cyber Innovation Day is the premier event for cyber startups, researchers and top VC firms, firms building trust into tomorrow's digital world. Kick off the day with unfiltered insights and panels on securing tomorrow's technology. In the afternoon, the 8th annual DataTribe Challenge takes center stage as elite startups pitch for exposure, acceleration and funding. The Innovation Expo runs all day, connecting founders, investors and researchers around breakthroughs in cybersecurity. It all happens November 4th in Washington, DC. Discover the startups building the future of cyber. Learn more at CID Datatribe. Com.