CyberWire Daily - Smile for the malware. [Research Saturday]

Episode Date: October 18, 2025

Eclypsium researchers Jesse Michael and Mickey Shkatov to share their work on "BadCam - Now Weaponizing Linux Webcams." Eclypsium researchers disclosed “BadCam,” a set of vulnerabilities in certain Lenovo USB webcams that run Linux and do not validate firmware signatures, allowing attackers to reflash the devices and turn them into BadUSB-style tools. An adversary who supplies a backdoored camera or who gains remote code execution on a host can weaponize the webcam to emulate human-interface devices, inject keystrokes, deliver payloads, and maintain persistence — even re-infecting systems after OS reinstalls. The findings were presented at DEF CON 2025, Lenovo issued updated firmware/tools in coordination with SigmaStar, and researchers warn the same vector could affect other Linux-based USB peripherals, underscoring the need for firmware signing and stronger device attestation. The research can be found here: BadCam: Now Weaponizing Linux Webcams Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyberwire Network, powered by N2K. What's your 2 a.m. security worry? Is it, do I have the right controls in place? Maybe are my vendors secure? Or the one that really keeps you up at night, how do I get out from under these old tools and manual processes? That's where Vanta comes in. Vanta automates the manual. Vanta automates the manual. will work so you can stop sweating over spreadsheets, chasing audit evidence, and filling out endless questionnaires. Their trust management platform continuously monitors your systems, centralizes your data, and simplifies your security at scale. And it fits right into your workflows, using AI to streamline evidence collection, flag risks, and keep your program audit ready all the time. With Vanta, you get everything you need to move faster, scale confidently, and finally, get back to sleep. Get started at Vanta.com slash cyber. That's V-A-N-T-A-com

slash cyber. Hello, everyone, and welcome to the Cyberwires 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. Well, it was partially an accidental encounter with one of the cameras I had been using for a while. It had been causing me some problems over several meetings, and I thought maybe it requires a firmer update. I thought, I look it up and go to the manufacturer website, it's Lenovo, it's probably solid, download the firmware, and then I realized it's running Linux, and then everything else happened.

Our guests today are Jesse Michael and Mickey Schottav, principal researchers at Eclipse, sharing their work entitled Bad Cam, now weaponizing Linux webcams. Well, I mean, let's walk through it together here. Is at the core of this an issue with firmware? 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 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. 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? There are two models of this camera made by Lenovo or sold by Lenovo branded by them. 510 and the performance Web FHD I believe it's called. These cameras are based on a

preset kit by an SOC vendor called Sigma Star 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 an SOC vendor it creates different types of potential products or engineering development kits sends these out to big OEMs or ODMs and they choose whatever fits their

needs better and they work together, make a deal and hand it off to the vendor or EM ODM to continue support and branding and all of that other stuff. So the SOC vendor just creates the hardware and the interfaces to the hardware and hands it off to someone else to do whatever they need to do with it. 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 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 FISA controller or something that you could reprogram, and it's a little more difficult to rebuild some of that. with this particular ship 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 on to 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 supplier like Sigma Star.

So, like, Sigma Star, the SOC, system-on-ship 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. So Lenovo could say, you know, we have a certain set of specifications that we want met. Yeah. And the supplier meets them, but there may be more than. that on board the hardware. Oh, yeah, definitely. Like, 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 firmer 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. 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? 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. Yeah, there wasn't any kind of cryptographic signature verification of this.

So you essentially send it a, 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, kind of 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 real security guarantees. It does try to do like 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 then send it over without any kind of any security guarantee or any kind of security check there. Wow. So in the research you all showed that remote flashing is possible. Do I have that correct? Well, the camera, it's kind of, the remote part is a bit interesting by 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 need to 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. Yeah, to follow up on that a little bit. There's a distinction between physical access, which requires you having, 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 fish 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 that. like enabled network access for the camera itself using that USB gadget, which was 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 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 physically connected USB device. So it isn't actually physical access. It is a local access, which can mean remote access depending on how you get access to that local code execution. Right, right. There's some nuance there. Yeah, yeah. I just wanted to kind of make clear that it's not physical access. It's not like, 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. We'll be right back. At Talas, they know cybersecurity. can be tough and you can't protect everything. But with TALIS, you can secure what matters most. With TALIS's 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 TALIS to protect what matters most. Applications, data, and identity. That's TALIS. T-H-A. L-E-S. Learn more at talusgroup.com slash cyber. At TALIS, they know cybersecurity can be tough and you can't protect everything, but with TALIS, you can secure what matters most. With TALIS's industry-leading platforms, you can protect critical applications, data and identities, any way. and at scale with the highest ROI. That's why the most trusted brands and largest banks, retailers, and health care companies in the world

rely on TALIS to protect what matters most. Applications, data, and identity. That's TALIS. T-H-A-L-E-S. Learn more at talusgroup.com slash cyber. 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? 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 kind of let us down the path of, 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 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 metisplate payload from the command of control and having a remote shell or metasplate session back to the command of 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 a listening device or like take pictures through the, through the camera. So it is a camera and it has a microphone built in. So that is something that you could potentially do. 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? 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 have it reconfigure itself and reach out to the network using the host's connection without the user being aware of that.

and it's an interesting capability to see. I've previously done stuff for rubber duckeys and like bash bunnies and other devices that have kind of implemented this type of stuff. And previously I had seen mention of like, here's how to manually set up 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. 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? that is one thing that we started to look into but we didn't get uh we didn't fully figured out if we could turn off the camera the light on the camera or not uh 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 uh we don't know

if that's the case in this in this particular camera but uh one thing i would like to kind of highlight is that we were focused on Lenovo and these specific cameras, but Sigma Star 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 they're selling cameras that are ultimately sourced by SigmaSar. Some of them might be doing things better. It might be configuration options where they turned on certain features

that Sigma Star 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. Yeah. Did you reach out to the manufacturer and let them know? Yeah, we did reach out to both Sigma Star and Lenovo. Lenovo basically worked with Sigma Star to get firmer updates for the camera and was able to 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, 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 Sigma Star 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. So we don't know if there are ways to get around the software, update fixes that Sigma Star 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. 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. 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? In layman's terms, basically, yes. Sigma Star, it's a bit complicated to explain, but Sigma Star has this API slash SDK, known 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. 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 seem to be a keyboard or a storage device or something like that? Yes, everything that's on the USB gadget stack that Linux offers would be a potential device that can be shown to the host. So you presented this at DevCon. 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? It was. It was very entertaining. we got more than a few laughs at some point there were several key points we discussed aside from the entertainment

factor of this webcam becoming a bash money 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 vendor of communication, the venue of communications we could find. 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? 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. There are very simplistic in design.

They don't run Linux. They have dedicated firmware that just runs whatever monolithic or simplified OS 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 programming. 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 to a USB device, which is wild, so to speak. Yeah, it's just, 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.

Yeah. Jesse, any additional thoughts? 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, 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. 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 are trying to rush things out like this.

Right. Can you run? on it? Not maybe. Like, we shirk on that. We'd like to thank Jesse Michael and Mickey Schottov, principal researchers at Eclipse, 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 in your podcast app. Please also fill out the survey in the show notes, or send an email to cyberwire at 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 pre-eminent 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 at 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 Kilby is our publisher. Dave will be back next week. Thanks for listening. Day is the premier event for cyber startups, researchers, and top VC 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 eighth annual Data Tribe 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 cyber security. It all happens November 4th in Washington, D.C. Discover the startups building the future of cyber. Learn more at cid.d. datatribe.com.