Back in 2014, I shared the story of how my Linksys router had gotten hacked via a vulnerable CGI script. Since then, I’ve archived relevant news postings in order to track the IoT device vulnerability trend, which, suffice to say, is not encouraging. Check out, for example, these sample headlines from just the last year:

Depressed yet?

Routers are an obvious attack point, both because they’re the nexus of the network (specifically, the various devices on that network) behind them, and because there are multiple potential Achilles’ heels: the WAN connection (for anyone on the Internet) and the Wi-Fi LAN connection (for anyone in wireless coverage range).

Once you’ve circumvented the router’s firewall, you can (as in my thankfully unsuccessful earlier case study) attempt to turn it into a “zombie” capable of issuing mass DDoS (distributed denial-of-service) attacks and the like. You can also attempt to gain access to devices behind it; data stored on computers and NASs, for example, or images and sound (both microphone and speaker) associated with network-connected cameras. Frankly, after having read no shortage of stories about hacked cameras in children’s bedrooms and the like, I’m not sure which of these (data archives or cameras) represents the more egregious breach.

Traditional network cameras are vulnerable by virtue of the fact that (via UPnP, hard-wired firewall holes, or the like) they’re usually directly accessible over the Internet, along with the fact that they’re self-contained; they embed full web server functionality (which, as the above links indicate, often contains vulnerabilities). One company’s reference design often propagates to numerous products from multiple retail suppliers, multiplying the impact of such vulnerabilities.

Such products are often poorly supported at best; the manufacturer is focused on getting the next product out the door and generating revenue, versus maintaining existing products. And suffice it to say that many such products are sourced from countries in which vulnerabilities exploitable by government and other entities are viewed as a positive.

Newer “cloud”-centric approaches decrease the local processing “intelligence” but trade off potential vulnerabilities elsewhere in the ecosystem. This is why, for example, I took great pains in my recent series of posts reviewing Blink’s surveillance camera system to point out the following:

The LFR connection between each camera and its Sync Module nexus is proprietary; a thorough Google search I made in the hopes of revealing its secrets was fruitless. All Blink network nodes (cameras and Sync Module) also leverage Wi-Fi, complete with whatever encryption scheme you’ve implemented on the LAN.

Keep in mind, though, that you’re also able to view live camera streams via a WAN connection, and don’t forget about the motion trigger-activated and “cloud”-stored video clips. Live or archived video transmission over the WAN is not, as far as my research can tell, scrambled beyond that of normal data packets. And I suppose it’s theoretically possible that a hacker (or rogue employee) could also access video clips stored on Blink’s servers, with the rogue employee also theoretically being able to remotely control a live camera view.

That all being said, a post I found from Blink’s director of customer support on the company’s community discussion forum is quite emphatic and pretty definitive:

“We are not able to see your video, clips or turn on your camera video or make the mic “hot”. Like any vendor that has thought about the service side of these types of products, we’ve built in a lot of remote diagnostics.

Yes, we can send diagnostic triggers, like alerts or reset the camera, see timestamps, duration of clips, last clip times and devices that recorded. We can see Wifi and LFR signal strength, battery voltage, battery drain, usage statistics.

I’ll say it again, we do not and can not control your camera video or audio remotely, for the obvious reasons.”

That all said, even if someone isn’t able to directly hack any hardware node in the cloud-centric ecosystem hardware (or a link between two nodes), there’s of course another possibility; a hack of the user’s account, either by surmounting a weak or repeatedly-used (and hacked elsewhere) username/password combination, or via a successful “phishing” expedition. Such scenarios are particularly likely if the camera login is the same as that used for a user’s Amazon (Blink, Ring), Facebook (Portal), or Google (Next) account, for example.

And speaking of Google, partnerships between companies provide yet another weak link to potential unwanted camera access. As recently covered extensively in the tech media (and first reported by the affected user on Reddit), the owner of a Xiaomi networked camera and a Google Nest Hub (formerly called the Google Home Hub) leveraged a business (therefore “handshaking” protocol) relationship between the two companies to link their products together. Lo and behold, however, he started viewing the outputs of others‘ cameras, including some highly personal images:

Xiaomi Mijia Intelligent 1080P IP Camera

Google Nest Hub IoT device

others' camera output

others' camera output

And note: this particular person wasn’t even trying to hack the system at the time! To its credit, Google reacted quickly, temporarily severing the linkage pending a thorough security review (the root cause, along with a fix, is believed to now be known). Nonetheless, anyone who believes this is a one-time scenario is naive.

Dare you trust your family’s privacy to a security camera system, readers? Sound off in the comments.

Brian Dipert is Editor-in-Chief of the Embedded Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.

Related articles: