CyberWire Daily — "Smile for the malware."

Research Saturday | October 18, 2025

Overview

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.

Key Discussion Points & Insights

Discovery of the Vulnerability

• Origin Story
  • Mickey Shkatov explains how a problematic webcam led to the research:

    “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)

Anatomy of the Vulnerable Device

• Supply Chain Complexity

  • The affected cameras are Lenovo-branded but built using a SigmaStar SoC kit, sometimes making the ultimate composition of the device opaque to Lenovo.

    “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)

  • Two models identified: Lenovo 510 and Performance FHD; the issue could extend to other rebranded SigmaStar-based cameras.

• Core Flaw: Firmware Update Insecurity

  • Firmware updates lack cryptographic signatures or validation; any payload can be flashed using a simple process.

    “…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)

Attack Surface and Exploitation

• Local (Not Physical) Access

  • Despite manufacturer advisories claiming attacks require “physical access,” researchers clarify that only local code execution is needed.

    “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

  • If an attacker has code execution on a connected PC—such as through phishing or exploitation—they can reflash the webcam firmware over USB, often with only user-level permissions.

    “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)

Malicious Device Behaviors Post-Compromise

• Reconfigurable Functionality

  • The webcam can be reprogrammed on the fly to present itself as a keyboard, storage device, or even a network interface, using the Linux gadget stack.

    “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)

    • Demonstrated example: Camera creates a network adapter and downloads a Metasploit payload, establishing a reverse shell to a command-and-control node (14:30-15:20).

• Espionage and Persistence

  • Potential to use camera’s built-in microphone/camera for spying, or as a beachhead for further malware deployment.
  • Attackers can disguise the device as other types of USB devices.

    “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

  • The team attempted (but didn’t conclusively succeed) to defeat webcam “power on” indicator lights, a known privacy concern.

    “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)

Supply Chain & Patch Response

• Vendor Coordination
  • Researchers contacted both Lenovo and SigmaStar. Firmware fixes have been released but may not be foolproof.

    “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)

Broader Implications for IoT & Smart Devices

• Trend: Linux Everywhere, Security an Afterthought
  • Move from simple firmware to Linux-based webcams is driven by feature creep (AI, face recognition) and ease of vendor development—not security.

    “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)

Community Response

• Defcon Presentation
  • The research debuted at Defcon to strong reactions:

    “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)

Notable Quotes & Memorable Moments

• “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)

Important Timestamps

| 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 |

Recommendations & Takeaways

• For Security Professionals:

  • Be aware: Even innocuous USB devices may host full Linux systems with capabilities ripe for weaponization.
  • Enumerate and audit connected peripherals; treat webcams with the same suspicion as IoT endpoints.
  • Firmware updates must use cryptographically signed validation; push vendors for secure supply chains and update mechanisms.

• Broader Lesson:

  • Rapid innovation and smart features, particularly using commodity Linux on embedded devices, create novel risks when security is back-burnered for speed and cost.

Episode Tone

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