How the hell these incidents happen? In the era of cloud and microservices why each user does not have their own dedicated resources?
An individual S3 bucket or policy for each user?
Wyze security incident update
111–120 of 161 posts
Re: Wyze security incident update
#112> Wyze blamed "a third-party caching client library that was recently integrated into our system" for the trouble. Yes, of course. Blame a third party library which was probably created by an open source maintainer instead of testing your own systems.
Of course, the reason this keeps happening is the infrastructure is designed to let it happen in certain cases. Notice how they explicitly say, they need to fix it in the front end. They can't fix it in the backend because that would break eavesdropping.
That’s a bit tinfoily take
Re: Wyze security incident update
#113How the hell these incidents happen? In the era of cloud and microservices why each user does not have their own dedicated resources?
An individual S3 bucket or policy for each user?
Everything user specific. Nothing should operate across users. Why should it anyway. You only need to aggregate logs across users, cloud watch does this.
Re: Wyze security incident update
#114Earlier quoted context omitted.
An individual S3 bucket or policy for each user?
Everything user specific. Nothing should operate across users. Why should it anyway. You only need to aggregate logs across users, cloud watch does this.
Well for one there is a hard limit of 1000 s3 buckets per account
Re: Wyze security incident update
#115In the meantime, Wyze has rolled back RTSP support, where it was possible to use their devices locally: https://support.wyze.com/hc/en-us/articles/360026245231-Wyze... A good response to this might be to put it back, and to extend other devices to be dual-use (Wyze Cloud or HA).
For those that want their Wyze cams 100% local (with RTSP), you can use wz_mini_hacks[0]. I've set up v2 and v3 cams using this, and they've never touched the internet or wyze app.
I've use the official RTSP firmware in the past on some v2 cams, but I remember it having some problems and not being as good as this solution.
Re: Wyze security incident update
#116Another in a long line of reasons to avoid low price, off-the-shelf, unauditable, cloud-enabled cameras. I continue to be amazed that there is not a reasonably priced, open source, audited, local-first solution, which doesn’t require a significant personal investment of time to install and maintain.
I cringe every time I browse Amazon and see the random cam/cloud service/Play store apps that I know so many people are installing without questioning anything about them.
Re: Wyze security incident update
#117Not my project but I have had great success with https://github.com/gtxaspec/wz_mini_hacks & V3 model. The V3 models need to be downgraded to a specific firmware first and patching it exposes RSTP streams using https://github.com/AlexxIT/go2rtc . Everything doable without ever installing Wyze app on an environment air gapped environment with no internet.
I finally gave up trying to use the mini hacks to make RTSP work reliably. I ended up using Wyze Bridge [0] instead, and it has been far more stable. Using Frigate for the web UI. It doesn't make for a local-only solution, but I don't use my cameras to record anything that would bother me if other people saw it.
As time and motivation permit, I've been converting the cameras I care about over to POE. But having to run cable across the house for each one means I haven't done them all.
Re: Wyze security incident update
#118How the hell these incidents happen? In the era of cloud and microservices why each user does not have their own dedicated resources?
> How the hell these incidents happen?
Because race to the bottom.
People want incredibly cheap products that are internet connected. Your average home user should not have to worry (and won't) about cybersecurity concerns, so this will continue to happen. The only out I can foresee is government regulation stepping in to make these incidents actually hurt for the companies, but America has basically no appetite for that.
Re: Wyze security incident update
#119Earlier quoted context omitted.
"Other than perhaps using cameras as a means to deter thieves, I’m not sure that low-value (under USD 5000) items like bicycles are worth the time and effort for insurers to launch full investigations over." I would agree, yet I have seen it happen. It is a somewhat difficult to predict path. I have seen some smaller claims (~$2000) take significantly longer and with more investigation than other very large (>$50,000…
> I would agree, yet I have seen it happen. You've seen insurance claims denied because someone didn't have an unverified video that allegedly showed a theft taking place, even with a police report in hand? (Seriously: How would an insurer know that you hadn't arranged to have your brother-in-law pretend to steal your bike for the camera?)
Just like there's an imperfect but effective barrier to lying to the cops for a police report, there's an imperfect but effective barrier to staging a theft on a video camera.
Re: Wyze security incident update
#120Earlier 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…
> I'm taking exception to the lack of accountability.
I'll bet money that their statement was run through legal and stripped of all possible blamey statements.
> They could have chosen to own that, but instead they blamed everyone else. That's not a sign of a trustworthy service provider.
I agree. Companies need to own up to their fuckups, even with legal tells them that it can hurt. Because all companies will fuck up; how they handle it is the differentiator.