Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wyze security incident update

forums.wyze.com

Post reply on HN
Print view View original

81–90 of 161 posts

Re: Wyze security incident update

#81

Post by sabujp »

matthewcford wrote: post #63
quatrefoil wrote: post #59

Earlier quoted context omitted.

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.

Likely to be a multi-threading issue; my bet is the cache client wasn't thread-safe. I've seen this in some apps before and the solution was to turn off multi-threading while we debug the library that was causing the issue.

This is the answer!

Re: Wyze security incident update

#82

Post by illusive4080 »

My work encountered this same sort of thing after an outage. Our Redis instance or client got confused. If a=b and c=d in our cache, a request for a returned d randomly.

We quickly realized that cache is fast but not infallible. Use proper security on all your resources. Don’t rely on UUIDs to obfuscate your data as security.

Re: Wyze security incident update

#83

Post by t0mas88 »

twisteriffic wrote: post #2

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

The whole thing points at everyone but themselves... "Originated at AWS" then "caused by a caching library"

Very little ownership on Wyze's side.

Re: Wyze security incident update

#84

Post by hamburglar »

twisteriffic wrote: post #2

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

Coincidentally, I just cancelled my wyze service because the product and support are so terrible. I wanted a simple way to see if there was a package on my doorstep but instead I got something that alerts me when any dog, person, or vehicle goes down my street, and all I’ve gotten from support is robotic responses suggesting I update my firmware and ignoring my direct questions, running out the clock on my ability to return the thing. At this point I’m not surprised their engineering is bad and amused that it’s caused two different security incidents.

Re: Wyze security incident update

#85

Post by mdaniel »

sgerenser wrote: post #65
matrix_overload wrote: post #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,…

Instead of patching, you can also just use PoE cameras that are designed for this use case (local RTSP) and are only a little more expensive than Wyze. I’ve installed an Amcrest doorbell that works well with Scrypted and HomeKit, and plan on adding some Amcrest cameras like these soon: https://www.amazon.com/dp/B083G9KT4C

lazyweb: https://github.com/koush/scrypted (regrettably the licensing is "it depends" https://github.com/koush/scrypted/blob/v0.93.0/LICENSE.md#li... )

and don't overlook that user's other repos, as seems like there are quite a few fun things in there: https://github.com/koush?tab=repositories

Re: Wyze security incident update

#86

Post by idiotsecant »

kevinsync wrote: post #49
firefalcon222 wrote: post #35

Not 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'm having great success with half a dozen v3's in tandem -- for $30 a camera, the quality is really unbeatable -- setup / notes below. 1. all cameras (firmware v4.36.9.139) have 64gb+ micro SD cards and record to local storage -- many people seem to have issues with anything greater than 32gb in v3's but I've found that this Verbatim tool [0] formats FAT32 at high capacity with no problems 2. all cameras have wz_min…

I did this for a long time and then realized I was dealing with a lot of bugginess where I'd have to restart cameras, things were wired to wall warts, etc, all to save just a few bucks. I got some cheap poe cameras off Amazon with built in rtsp and its been great.

Re: Wyze security incident update

#87

Post by pledess »

I'm wondering about the probability that, out of all the affected customers, at least one had the research skills and social skills to identify another customer and successfully ask to meet. Like, for an essay about "His schnauzer needed a mom. WyZettle: the amazing story of a pivot from a home camera service to a dating app."

Re: Wyze security incident update

#88

Post by spullara »

This actually looks like a concurrency bug in their request handling code that may have stored the user id and camera id in shared variables, under load the wrong camera id is seen by a user. At least based on the description of what they say happened.

Re: Wyze security incident update

#90

Post by gerwim »

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

Post reply on HN