Live data from Hacker News

Wyze security incident update

forums.wyze.com

51–60 of 161 posts

Re: Wyze security incident update

#51

Earlier quoted context omitted.

The primary use case for a camera watching something that might get stolen is to provide proof of theft for insurance. In some cases it can provide clear evidence of what exactly was stolen, and in some cases information about who stole it. Unless the camera has lasers, it isn't very good at stopping said theft. ;)

Why would your insurance require a proof of the theft? That is not how insurances work usually.

Yeah all they require is a police report.

Re: Wyze security incident update

#52

Earlier quoted context omitted.

The primary use case for a camera watching something that might get stolen is to provide proof of theft for insurance. In some cases it can provide clear evidence of what exactly was stolen, and in some cases information about who stole it. Unless the camera has lasers, it isn't very good at stopping said theft. ;)

Why would your insurance require a proof of the theft? That is not how insurances work usually.

Of course you need to provide proof of theft. I can't simply go to my insurance, file a claim for a high-value item, and expect them to not ask any more questions. This would be rife with fraud (read: not a reasonable business model) otherwise.

Re: Wyze security incident update

#53

> The incident was caused by a third-party caching client library that was recently integrated into our system. This client library received unprecedented load conditions caused by devices coming back online all at once. As a result of increased demand, it mixed up device ID and user ID mapping and connected some data to incorrect accounts. That seems like enough of a line of bullshit to steer me away from ever using…

sounds like a hashing function with insufficient entropy. "increased demand" would lead to a higher likelihood of hash collisions.

Re: Wyze security incident update

#54
Wyze cameras can actually be used very securely, as long as you bother to jump through some hoops.

First of all, google "Wyze RTSP firmware". It's the official firmware from the vendor that enables the RTSP protocol. Now you can enable RTSP via the app and give the camera a fixed IP address in your DHCP server.

RTSP is a pretty standard protocol, so you can now view the feed via VNC player, record it 24/7 via ffmpeg, use tools like motion, etc.

The camera will still try to connect to cloud, but you can move it to a local-only Wi-Fi network, or outright block it from reaching the outer world on the router side.

And if you want advanced stuff (multiple streams, organized recording, etc), there is a plethora of free/open-source security camera tools (iSpy for instance). It all takes time to learn and configure, but you can have your own fully closed-circuit surveillance network, while still using the Wyze's rather cheap hardware.

Re: Wyze security incident update

#55

Wyze cameras can actually be used very securely, as long as you bother to jump through some hoops. First of all, google "Wyze RTSP firmware". It's the official firmware from the vendor that enables the RTSP protocol. Now you can enable RTSP via the app and give the camera a fixed IP address in your DHCP server. RTSP is a pretty standard protocol, so you can now view the feed via VNC player, record it 24/7 via ffmpeg,…

https://forums.wyze.com/t/how-to-download-wyze-rtsp-files-th...

Re: Wyze security incident update

#56
post #12

Earlier quoted context omitted.

How so? I've seen caching clients exhibit some really weird behaviour under heavy load. It's not beyond the pale that, eg, the caching library doesn't do proper locking before writing, resulting in writes stomping all over each other. Caching is normally read heavy, not write heavy, so it's plausible it wouldn't be something you'd see much under typical operation. After an outage, they'd be dealing with a thundering…

Yes but either the library is seriously bugged (like, expecting writes to be ordered and screwing up things if it gets too many writes for different objects at the same time) or there was some serious bug in their implementation. Anyway the attitude and the message passed in the communication seems like handwashing to me. I might be too cynic, though.

How else would you say a 3rd party library had a bug under heavy load? 1. You don't want a defamation lawsuit your way. 2. If it was vendor code, you have a contract that may be under a NDA. 3. If it was a vendor, lawyers, lots and lots of lawyers, they likely had to say the minimal amount. The fact they sent out communications for each type of incident in such a short time was great.

Re: Wyze security incident update

#57

This is the sort of thing that makes me salty that Unifi Protect is basically cloud locked in. No direct IP connection with "local" account support on the mobile app.

I recall seeing setting that this cloud access can be disabled, and you could just VPN to get your “local” only access back.

Re: Wyze security incident update

#58

> The incident was caused by a third-party caching client library that was recently integrated into our system. This client library received unprecedented load conditions caused by devices coming back online all at once. As a result of increased demand, it mixed up device ID and user ID mapping and connected some data to incorrect accounts. That seems like enough of a line of bullshit to steer me away from ever using…

sounds like a hashing function with insufficient entropy. "increased demand" would lead to a higher likelihood of hash collisions.

Not sure I follow. Hash functions don't require entropy, and a hash collision in a hash map shouldn't cause incorrect data to be returned (it just makes them less efficient).

Re: Wyze security incident update

#59

Earlier quoted context omitted.

Do you think the issue was something else? "People randomly see other people's content" is an issue that would immediately make me think some issue with caching is the culprit. Given their openness in the rest of the communications, I don't see why they would make this part up. Edit: Of course, I'm also curious what the actual bug was. A discussion below is suggesting several plausible ways (e.g. concurrency issues,…

> Do you think the issue was something else? No, I'm not questioning whether or not it was a caching issue. I'm taking exception to the lack of accountability. They chose the library. They (probably) chose to ignore a documented or common failure mode of caching systems through either poor choice of key or lack of synchronization. They've obviously designed their infrastructure in a way that isn't resilient to its cu…

It's not even that: the quoted language doesn't even blame the library - it appears to blame increased load.

"As a result of increased demand, it mixed up device ID" - no, it mixed up IDs as a result of some sort of a concurrency bug. I don't understand the point of deflecting this far.

Re: Wyze security incident update

#60
post #34

This is one of the reasons why you want end-to-end encryption wherever possible. Even a bad implementation with cloud-synced encryption keys (which defeats most of the benefits of e2e) would have stopped this. The response in this case (notifying customers and specifically stating whether they were affected or not) is excellent, but this seems to be a repeat of a previous incident from September 2023: https://www.the…

I wonder how many people would continue to so casually use these services if they understood that, for the most part, there is rarely proper end-to-end encryption of their data with these services. It is awfully disingenuous when these companies' marketing materials describe their services as "encrypted" when it usually just means there are two independent TLS pipes, which both terminate in their "cloud"; this surely…

Too many. I've consulted with friends who installed "smart" security cameras and other IoT devices. I really spelled it out, saying that there's a very real possibility that one day they'll find out someone's been listening in on all of their private conversations (audio) or watching them through their own cameras.

Responses typically range from "I'm not that interesting" to "I really don't care". I think it's too abstract of a threat for most people to take seriously before it happens to them.

Post reply on HN