Loading summary
Jesse Michael
You're listening to the Cyberwire Network, powered by N2K.
Dave Bittner
What's your 2am 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 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@vanta.com cyber that's v a n t a dot com cyber hello everyone and welcome to the Cyberwires Research Saturday. I'm Dave Bittner and this is our weekly conversation with research 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.
Mickey Shkatov
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 you know, 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.
Host/Announcer
Our guests today are Jesse Michael and Mickey Shkatov, principal researchers at Eclipsium, sharing their work entitled Now Weaponizing Linux Webcams.
Dave Bittner
Well, I mean, let's walk through it together. Here is 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 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 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 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, oem, 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.
Dave Bittner
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
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
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, 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
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
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
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
Wow. So in the research, you all showed that remote flashing is possible. Do I have that correct?
Mickey Shkatov
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
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
Right, right. There's some nuance there.
Jesse Michael
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
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
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
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 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
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
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
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 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
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
In layman's terms, basically, yes. Sigmastar, it's a bit complicated to explain, but sigmastar has this API SDK.
Jesse Michael
Known.
Mickey Shkatov
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
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
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
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
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
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
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
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'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
Right? Can you run doom on it?
Jesse Michael
Not maybe like we should work on that.
Host/Announcer
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
Limu Emu and Doug Here we have.
Jesse Michael
The Limu Emu in its natural habitat, helping people customize their car insurance and.
Dave Bittner
Save hundreds with Liberty Mutual. Fascinating.
Jesse Michael
It's accompanied by his natural ally, Doug Limu is that guy with the binoculars watching us cut the camera.
Dave Bittner
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.
Research Saturday | October 18, 2025
This episode centers on the recent research by Jesse Michael and Mickey Shkatov, principal researchers at Eclipsium, into serious and surprising vulnerabilities in a line of Lenovo-branded webcams. The show dives deep into a new class of attacks dubbed "Bad Cam," which weaponizes Linux-powered webcams through insecure firmware update processes. The discussion explores supply chain complexities, local vs. physical access, attack capabilities, and implications for smart device security.
“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 firmware update. I thought, I look it up and you know, 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.” — Mickey Shkatov (01:43)
Supply Chain Complexity
“A lot of times, 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.” — Jesse Michael (05:04)
Core Flaw: Firmware Update Insecurity
“…the update process was completely insecure. It literally was straightforward. Write what, where style… you would write [a binary file] directly into the flash on the camera, wherever I tell you to.” — Mickey Shkatov (06:53) “There wasn't any kind of cryptographic signature verification… you literally send commands like erase this region of the flash, write this file… without any real security guarantees.” — Jesse Michael (07:45)
Local (Not Physical) Access
“It requires local access, which just means arbitrary code execution… So it isn’t actually physical access, it is local access, which can mean remote access…” — Jesse Michael (10:07, 11:26)
Remote Flashing via Infected Host
“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…” — Mickey Shkatov (09:23)
Reconfigurable Functionality
“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.” — Jesse Michael (13:44)
Espionage and Persistence
“Everything that's on the USB gadget stack that Linux offers would be a potential device that can be shown to the host.” — Mickey Shkatov (22:11)
Indicator Evasion
“We started to look into, but we didn't fully figure out if we could turn off the light on the camera or not.” — Jesse Michael (17:21)
“One thing we did see is that it doesn’t… properly fix problems like this, you need to provision a key into the SoC itself...if you do have physical access, you can just reflash it back to a vulnerable version…” — Jesse Michael (18:50)
“It's like we're taking one step forward, two steps back when it comes to smart devices… now it's easier to just put some of the processing power in the camera…” — Mickey Shkatov (23:30) “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.” — Jesse Michael (25:12)
“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…” — Mickey Shkatov (22:39)
“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.”
— Mickey Shkatov (02:42)
On obscured supply chains:
“Lenovo might not know all the components that are inside. There is kind of an additional complication here that can have some bad implications.” — Jesse Michael (05:04–06:24)
Attack demonstration:
“One of the examples that we showed off was... bringing up a network connection, enabling connection sharing to get access to the Internet from the camera, and then downloading a metasploit payload...” — Jesse Michael (13:44–15:37)
On the evolution of devices:
“Now 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... more work for us.” — Mickey Shkatov (23:30–25:09)
On developer incentives:
“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... It's a lower curve for training and building something...” — Jesse Michael (25:12)
| Time | Segment/Topic | |-----------|--------------------------------------------------------------------------| | 01:43 | Discovery of the vulnerability | | 02:34 | Technical overview and context: How webcams are sourced/supplied | | 04:47 | Comparison to “Bad USB” attacks; supply chain risk | | 06:53 | Walkthrough of the firmware update vulnerability | | 09:15 | Discussion on local access and remote flashing capability | | 13:44 | Capabilities after compromise: espionage, network adapter, keylogging | | 17:21 | Is the physical camera light a privacy solution? | | 18:44 | Vendor response and limitations of patches | | 21:02 | Feasibility of attackers hiding malware in cameras | | 22:39 | Defcon community response | | 23:30 | Recommendations and broader IoT synthesis | | 25:09 | Final thoughts on market forces and developer security incentives |
For Security Professionals:
Broader Lesson:
Conversational, dryly humorous at times (especially around “can you run Doom on it?” at 26:07), and candid about both the technical challenge and the market incentives that leave devices exposed.
Summary by Podcast Summarizer AI | October 2025