[HN Gopher] Wyze security incident update
___________________________________________________________________
Wyze security incident update
Author : johnkpaul
Score : 107 points
Date : 2024-02-19 14:24 UTC (8 hours ago)
(HTM) web link (forums.wyze.com)
(TXT) w3m dump (forums.wyze.com)
| twisteriffic wrote:
| > 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 wyze.
| pylua wrote:
| Device id and user ids are non unique?
| mistrial9 wrote:
| hash collisions?
| avg_dev wrote:
| This sounds like a pretty decent guess to me. I bet you are
| right.
| NathanKP wrote:
| I'd bet it's this, plus something even stupider like
| hashing a connection timestamp millisecond as the
| "uniqueness" of the hash. I've seen a lot of terrible code
| implementations that assume that there will never be two
| clients connecting in the exact same millisecond
| hn_20591249 wrote:
| Yeah I would very much likely to know what caching library has
| a failure mode of returning content for the wrong keys, that
| seems pretty bad if not a highly suspect explanation
| tgsovlerkhgsel wrote:
| 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, insufficient entropy in some key) how a
| problem could happen under load (although many of these would
| also lead to the problem happening with less load, just much
| less often).
| 15457345234 wrote:
| > I'm also curious what the actual bug was
|
| Hardware. Rowhammer-type effects occurring accidentally under
| sudden load spikes. The hardware has just got too dense.
|
| (I should clarify this is speculation, but reading the recent
| article included here on sudo using special maximum-distance
| bitfields to hold state internally
| (https://news.ycombinator.com/item?id=39165342)... it must be
| a problem that's being observed in the wild)
| tgsovlerkhgsel wrote:
| I can't imagine that happening with a sufficient frequency.
| A system making such mistakes so often would just be too
| unstable to keep an uptime >1h.
| 15457345234 wrote:
| With the 'cattle not pets' mindset that pervades modern
| development is the lifespan of ephemeral cache VMs that
| closely monitored? They get spun up and down on demand in
| most architectures. I can see this being an edge case
| failure when the system is trying to scale up, the
| existing VMs are getting absolutely hammered, the
| hypervisor is trying to start up new ones, memory
| pressure and iops on the existing ones are maxed out...
|
| It just seems like the most obvious root cause to me, a
| single bit-flip in a hashed value is going to give you
| the wrong result data without any other error because the
| hash value is already essentially heavily compressed,
| meanwhile the hash table is almost certain to be 100%
| stored in memory and very heavily accessed from multiple
| directions in a read/write manner.
| Arcuru wrote:
| No. That's not how that works.
| twisteriffic wrote:
| > 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 current level of usage (cold start is a
| normal part of software's lifecycle).
|
| They could have chosen to own that, but instead they blamed
| everyone else. That's not a sign of a trustworthy service
| provider.
| quatrefoil wrote:
| 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.
| matthewcford wrote:
| 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.
| sabujp wrote:
| This is the answer!
| Twirrim wrote:
| 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
| herd level of traffic as everything tries to reconnect, that'd
| be very different from normal write loads, even different than
| the write load they'd have seen when they first enabled
| caching.
| darkwater wrote:
| 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.
| jabart wrote:
| 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.
| yjftsjthsd-h wrote:
| The problem is how much they're pointing fingers at the
| library in the first place.
| dns_snek wrote:
| I might be splitting hairs, but they say that the
| incident was "caused by a third party library" when in
| fact, the incident was caused by insufficient testing on
| their part.
|
| It sounds like they're trying to shift blame for the
| incident but then they try to pat themselves on the back
| for all the effort they put into security. It comes
| across as dishonest.
|
| Technical details are appreciated but they should've
| emphasized that this is their own fault. Bonus points if
| they commit to at least consider E2EE which would
| sidestep the issue.
| SigmundA wrote:
| I would at least want to know the client library so I can never
| use it for anything. Also never trust the client and I hope
| they don't mean the actual client app such that it can access
| other user id without server validation...
| woodrowbarlow wrote:
| sounds like a hashing function with insufficient entropy.
| "increased demand" would lead to a higher likelihood of hash
| collisions.
| beala wrote:
| 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).
| RandomRandy wrote:
| I think that they are saying that the output space, i.e.
| the list of all possible hashes, is too small. Thus, IDs
| 1234 and 5678 lead to the same hash.
|
| The collision is not in the insertion into the hash map but
| rather in the look up.
| achille wrote:
| Same thing happened to OpenAI. Will you steer clear of OpenAI
| forever as well?
|
| https://news.ycombinator.com/item?id=35294082
| wutwutwat wrote:
| There are only two hard things in Computer Science: cache
| invalidation and naming things.
|
| -- Phil Karlton
| pkaeding wrote:
| And off-by-one errors
| t0mas88 wrote:
| The whole thing points at everyone but themselves...
| "Originated at AWS" then "caused by a caching library"
|
| Very little ownership on Wyze's side.
| hamburglar wrote:
| 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.
| jasongill wrote:
| > We've identified your Wyze account as one that was affected.
| This means that thumbnails from your Events were visible in
| another Wyze user's account and that a thumbnail was tapped. Most
| taps enlarged the thumbnail, but in some cases it could have
| caused an Event Video to be viewed.
|
| Kudos to Wyze for doing the things noted in the thread like being
| honest and prompt with notification etc, but "thumbnails from
| your Events were visible... and that thumbnail was tapped" is a
| pretty mealy-mouthed way to say "another person saw your private
| pictures and videos taken with your Wyze cameras"
| tripdout wrote:
| Well obviously, and I think people can figure that out.
|
| I actually appreciate the more specific details on how the
| private pictures and videos were actually viewed using
| terminology from the Wyze app.
| sneak wrote:
| Nobody should ever be surprised that sending video to someone
| else's computer (ie "the cloud") results in third parties viewing
| that video.
| 1letterunixname wrote:
| Or buying cheap, no-brand or upstart brand cameras with cloud
| capabilities.
|
| I had a heck of a time finding a proper POE recording DVR
| camera system for my mom's house without online or cloud
| bullshit, but still I isolated it on the network to not take
| any chances of UPnP port opening or dial-home crap.
|
| The only system I would trust would be one that laid out their
| security model, source to their apps, and had a self-hosted
| server DVR option. The captological signals of 99.9% of
| security system websites do not instill confidence in my mind.
| imglorp wrote:
| Got any brand/model recommendations? I also want to run full
| local.
| sponaugle wrote:
| I have 30 POE IP cameras connected to BlueIris (Running on
| a server). It records based on activity, and is entirely
| local (including being on a dedicated VLAN).
|
| The cameras are a wide variety of IP POE cameras which is
| helpful as I am not stuck to a single brand.
| LeafItAlone wrote:
| It's 2024. Everything is connected to the internet. Dropbox,
| Google, and Apple all offer multiple terabyte level plans. The
| default today is to store in the cloud. We are all storing data
| in someone else's computer.
|
| Instead of blaming the users, we must hold the companies
| responsible. Data privacy laws must be stricter and these
| incidents must be taken more seriously.
| jasonjayr wrote:
| And if the companies do not want to be responsible, empower
| the users to run things on their own without lockin.
| sneak wrote:
| You can indeed make laws to hold the companies responsible,
| but that's not going to change the situation where it's dumb
| to store private information on systems that aren't under
| your control.
|
| You might be able to cause consequences after the fact, but
| your data will still get leaked first. You can't undo a
| privacy violation with tort law, and there won't ever be
| criminal penalties.
|
| If you want your information to stay private, don't store it
| on other people's computers. IDGAF what "the default today"
| is. (Also, that's wrong - everyone that is serious and
| actually wants their data to remain private doesn't store it
| in the cloud. This is why the CIA got Amazon to build a
| custom airgapped on-prem AWS region at Langley, for
| instance.)
| LeafItAlone wrote:
| A main draw of these "security" cameras is to be able to
| remotely monitor the locations where they are, including
| being able to events in the event the devices are stolen.
| Should I build my own off site, redundant, data centers to
| make this possible without using a cloud service?
|
| > Also, that's wrong - everyone that is serious and
| actually wants their data to remain private doesn't store
| it in the cloud. This is why the CIA got Amazon to build a
| custom airgapped on-prem AWS region at Langley, for
| instance.)
|
| Do you think that "everyone that is serious and actually
| wants their data to remain private" is the default? In a
| random sampling of 100 people, how many do you think fall
| into this category?
|
| > This is why the CIA got Amazon to build a custom
| airgapped on-prem AWS region at Langley, for instance.
|
| Is your threat model the same as Langley's? Or might there
| just be different levels of what people's needs are?
|
| There's ideals and there's practicality. It's impractical
| in today's world to completely avoid cloud services. If you
| can do it, congratulations, more power to you.
| psanford wrote:
| There's a bunch of things in here that don't really make sense:
|
| > 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.
|
| What? How does load on the system affect correctness?
|
| > The outage originated from our partner AWS
|
| What does this mean? Was there an AWS outage for a service they
| use, or was this just a normal loss of an instance?
|
| It's interesting that they blame external entities for the root
| causes of the incident and don't take responsibility for what is
| ultimately on them.
| 0x0 wrote:
| > What? How does load on the system affect correctness?
|
| Seen this happen quite often with code that is not multi-thread
| safe, especially in languages like c# and java, such as using a
| static class property for data that should be request-scoped,
| or not using the appropriate concurrent collection classes etc.
| skipkey wrote:
| It's just a WAG, but I bet someone used a timestamp as a unique
| key, or at least part of one, so you were unlikely to get
| collisions except under load.
| CodesInChaos wrote:
| I assume the code was always incorrect, but only exhibits the
| problem in practice under high load. This could be a race-
| condition/data-race, or treating short hashes as unique.
| jabiko wrote:
| I would have liked them going more into the details of the
| caching issue. It sounds like they think the cache library was
| responsible for the issue, but a more technical analysis of what
| exactly went wrong within that library would be great.
| tgsovlerkhgsel wrote:
| 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.theverge.com/2023/9/8/23865255/wyze-security-cam...
| avg_dev wrote:
| Wow. That is decidedly not a good trend. Once is definitely bad
| enough, but twice...
| ls65536 wrote:
| 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 gives a false sense of security to end-users who
| may not understand the implications of such a setup.
| dns_snek wrote:
| 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.
| syntaxing wrote:
| This is one of the things Apple does right. HomeKit working local
| is a pretty great setup and just works. I put my HomeKit cameras
| on a VLAN without internet and device isolation and they still
| work seamlessly. The hard part is getting cameras that are
| wireless. I use scrypted but even then, getting ONVIF or RTSP
| isn't as straight forward nowadays. I also have a local frigate
| backup which works great too. You can pipe in the detection to
| scrypted with MQTT.
| radredgreen wrote:
| This may be a good place to introduce my HomeKit based Wyze v3
| camera reflashing side project. Still a work in progress.
|
| https://github.com/radredgreen/wyrecam
| t8sr wrote:
| A little off topic, but how is it possible that a tech startup
| named itself "Wyze" and didn't get sued by Google over the "Waze"
| trademark? In some accents it sounds exactly the same, and
| they're sort of in an adjacent product space.
| sqlacid wrote:
| Am I the only one that saw Wyze and thought Wyse? Guess I'm
| old.
| t8sr wrote:
| Right, that's another one. I get that the trademark space is
| pretty dense, but still - trademarks exist to stop consumers
| getting confused, and this naming really is confusing?
|
| Waze could come out with a line of dash cams, and then you'd
| have Waze cams and Wyze cams.
| vel0city wrote:
| Trademarks are about confusing names in a similar product
| market. Just having a similar-ish sounding name doesn't mean it
| violates the trademark. Self-driving cars are pretty different
| market to home security cameras.
| t8sr wrote:
| You're thinking of Waymo :) Waze is a crowdsourced traffic &
| maps thing. It's vaguely, if you squint, adjacent. I don't
| think it would be completely crazy, for example, for Waze to
| introduce a line of dash cams.
| firefalcon222 wrote:
| 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.
| kevinsync wrote:
| 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_mini_hacks [1] on the SD card with RTSP
| enabled
|
| 3. all cameras are connected via ethernet instead of wifi using
| this adapter [2] and wz_mini_hacks config
|
| 4. network blocks all outgoing internet connections for all
| cameras to keep them LAN-only -- this means I have to connect
| to VPN to review video when outside the house, but I'm cool
| with that
|
| 5. all RTSP streams are also recorded over the network via
| Agent DVR [3] to a NAS
|
| 6. the Wyze app (free tier, not paid) works normally with all
| of the above in place -- I find it much more intuitive to
| review recent videos in-app (streamed off the SD card), and
| then review the very occasional older video from a computer off
| the NAS (scrubbing through in VLC on a computer)
|
| For what it's worth, I don't use them like a Ring camera where
| you're responding to realtime video events / talking through
| the camera to a delivery person -- this is mostly just for 24/7
| recording. I have all object/motion detection events turned
| off, just a straight uninterrupted feed recording local and on
| the network.
|
| Links:
|
| 0. https://www.verbatim.com/index/search.php?words=fat32+tool
|
| 1. https://github.com/gtxaspec/wz_mini_hacks
|
| 2. https://www.amazon.com/dp/B07M5X9795
|
| 3. https://www.ispyconnect.com/docs/agent/about
| idiotsecant wrote:
| 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.
| uconnectlol wrote:
| connected cameras have been easily hackable circa 2001 and this
| isnt changing any time soon especially not with node.js smartcrap
| notatoad wrote:
| "Don't use Wyze" seems like the wrong takeaway from this.
|
| I'd go with "don't put internet-connected cameras in your house
| if you don't want those images on the internet". I've got a Wyze
| in my garage looking over my mountain bikes, and for $35 I don't
| really care if somebody else sees that image. But I'd never put
| one in my living space, regardless of their security track
| record.
| prmoustache wrote:
| What is the point of filming your mountain bikes? Do you watch
| them from your office with fondness of your most recent ride?
| Will that prevent them from being stolen? I doubt so.
| sponaugle wrote:
| 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. ;)
| prmoustache wrote:
| Why would your insurance require a proof of the theft? That
| is not how insurances work usually.
| chrisco255 wrote:
| Yeah all they require is a police report.
| lopkeny12ko wrote:
| 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.
| jt2190 wrote:
| > Of course you need to provide proof of theft.
|
| Generally filing a police report will suffice, if I'm not
| mistaken. Could you lie? Of course, but (1) it's
| generally not in your best interest because the insurer
| might raise your rates and/or discontinue coverage, and
| (2) you'd be making a decision to make false statements
| to the police for purpose of fraud, which most reasonable
| people won't do.
|
| 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.
| sponaugle wrote:
| "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)
| claims. I would assume there are certain metrics and
| algorithmic methods that effect how this plays out, so it
| is possible that someone who has had multiple small
| claims my get more attention than a single large claim.
|
| Either way - The concept of the camera is simple in
| providing evidence in cases where that evidence can help
| you.
| Cheer2171 wrote:
| My home insurance requires proof of theft.
|
| Often you use a police report. My local police department
| is on an unofficial slowdown strike because they don't
| feel appreciated post-BLM. Possibly also because if they
| "forget" to file police reports or they "get lost in the
| system" then the official crime rate goes down. It took
| me over a month to get a police report I could send to
| insurance for a simple break in, and spent more of my
| labor by hourly wage trying to get that report than the
| cost insurance reimbursed.
| sponaugle wrote:
| There is tremendous variance with what will be 'required'
| to complete an insurance claim. In some cases a simple
| statement will suffice. In others, a police report is
| sufficient. In some cases the insurance company will want
| to 'investigate'. In many cases the underwriter will have
| some additional requests.
|
| However it is always good to recognize the primary goals
| of the insurance parties - which is to not pay. They have
| strong incentives in that direction, and you providing
| proof of theft reduces the opportunities for those
| incentives to slow or reduce the payment.
|
| It is especially true in cases of undeclared specific
| items, like an expensive mountain bike that you do not
| have a dedicated policy on.
| creativeSlumber wrote:
| >The outage originated from our partner AWS and took down Wyze
| devices for several hours early Friday morning. ... As we worked
| to bring cameras back online, we experienced a security issue.
| Some users reported seeing the wrong thumbnails and Event Videos
| in their Events tab. ... 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.
|
| As an software engineer who's dealt with caches for large high
| throughput services, this does not make sense to me why they are
| blaming a caching client. It's your own code that will decide
| what is the cache key, and what value to pass as the cache key.
| Did the caching library have a bug where when you ask for a given
| key, it returned results for a different key? Or more likely did
| your own code have a bug where you mixed up the keys? I think we
| need more details on what went wrong in here.
| albert_e wrote:
| Lot of blaming others - for architecture, stack, configuration,
| and operational choices that are likey/should be own decisions
| that should come with taking ownership.
| darknavi wrote:
| 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.
| wredue wrote:
| I recall seeing setting that this cloud access can be disabled,
| and you could just VPN to get your "local" only access back.
| zzyzxd wrote:
| direct IP connection is coming:
| https://community.ui.com/questions/Unifi-Protect-Mobile-acce...
|
| but even with this, it's still an security camera app that
| can't send push notification without cloud access.
| matrix_overload wrote:
| 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.
| Shadowmist wrote:
| https://forums.wyze.com/t/how-to-download-wyze-rtsp-files-th...
| BuildTheRobots wrote:
| > Wyze Update 04/05/2022: RTSP was considered a beta feature
| and we are currently assessing the path forward as the
| firmware versions have aged quite a bit. Wyze has removed the
| firmware files for these versions for now and will update the
| pages when plans are finalized. Please note that firmware
| files take a while to work on and test so you may not see an
| update in the near future. Wyze apologizes for the
| inconvenience.
| sgerenser wrote:
| 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
| mdaniel wrote:
| lazyweb: https://github.com/koush/scrypted (regrettably the
| licensing is "it depends" https://github.com/koush/scrypted/b
| lob/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
| frognumber wrote:
| In 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).
| lofaszvanitt wrote:
| Accidentally mixed the IDs!
| voakbasda wrote:
| Another 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.
| n89nanda wrote:
| Looks like they had a similar issue in 2023.
| https://www.nytimes.com/wirecutter/blog/wyze-security-breach...
| illusive4080 wrote:
| 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.
| pledess wrote:
| 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."
| spullara wrote:
| 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.
| bhhaskin wrote:
| Yeah sounds like an issue with garbage collection/freeing up
| memory.
| fatkam wrote:
| I have my cameras blocked from the internet and doing backups in
| the attic.
| _obviously wrote:
| Are they wifi or closed circuit?
| fatkam wrote:
| PoE / Ethernet
| starttoaster wrote:
| Do any clients work with them when set up like this? Can you
| view your live/recorded camera streams somehow? Do you get
| little clips/events from the cameras sensing movement? Do you
| have any other Wyze security gear like the motion sensors or
| external floodlights?
|
| edit: Looking at another comment posted in this thread it looks
| like you don't use Wyze cameras at all, you were just
| commenting about your own non-Wyze setup.
| gerwim wrote:
| > 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.
| summarity wrote:
| Also "was recently integrated" - by ... magic?
| _obviously wrote:
| 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.
| scubadude wrote:
| Why do people have cameras inside their house anyway?
| arealaccount wrote:
| Income
| BugsJustFindMe wrote:
| To make sure my cat feeder doesn't suddenly stop working and
| kill my cat while I'm away for a few days. Or other variations
| of similar.
___________________________________________________________________
(page generated 2024-02-19 23:01 UTC)