215
Wyze says camera breach let 13,000 customers briefly see into other people’s homes
(www.theverge.com)
this post was submitted on 19 Feb 2024
215 points (100.0% liked)
Privacy
31866 readers
366 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
Chat rooms
-
[Matrix/Element]Dead
much thanks to @gary_host_laptop for the logo design :)
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The most specific fix they mentioned,
isn't going to fix anything, is it? People were already "verified" to view the events, I don't know how verifying them a second time is going to fix the underlying problem if it just serves up the same incorrect data from the massive data bucket that's visible to Wyze and Amazon and their employees.
No, this does actually sound like a solution. But it's a solution that should be scattered all throughout the process, and checked at multiple steps along the way. The fact that this wasn't here to begin with is a bigger problem than the "client library failure" as it shows Wyze's security practices are fucking garbage. And adding "one layer" is not enough. There should be several.
To give a bit better context, which I can only be guessing at by reading between the lines of their vague descriptions and my first hand experience with these types of systems...
Essentially your devices all have unique ids. And your account has an account/user ID. They're essentially "random numbers" that are unique within each set, but there appear to be devices that have the same ID as a some user's user ID.
When the app wants to query for video feeds it's going to ask the server "hey, get me the feed for devices A, B, and C. And my user ID is X". The server should receive this, check if that user has access to those devices. But that server is just the first external facing step. It then likely delegates the request through multiple internal services which go look up the feed for those device IDs and return them.
The problem that happened is somewhere in there, they had an "oopsie" and they passed along "get me device X, X, X for user ID X". And for whatever reason, all the remaining steps were like "yup, device X for user X, here you go". At MULTIPLE points along that chain, they should be rechecking this and saying "woah, user X only has access to devices A, B, and C, not X. Access denied."
The fact that they checked this ZERO times, and now adding "a layer" of verification is a huge issue imo. This should never have been running in production without multiple steps in the chain validating this. Otherwise, they're prone to both bugs and hacks.
But no, they clearly weren't verified to view the events. Their description implies that somewhere in the chain they scrambled what was being requested and there were no further verifications after that point. Which is a massive issue.