Kleine groep Wyze-gebruikers kon voorvertoning van andermans camerabeelden zien

Een aantal eigenaren van Wyze-camera's kon korte tijd de thumbnails van de beveiligingscamera van een ander zien. De oorzaak zou liggen in een langdurige storing, die volgens Wyze voortkwam uit problemen met Amazon Web Services.

Wyze-medeoprichter David Crosby bevestigt aan The Verge dat minstens veertien gebruikers konden meekijken in de leefomgeving van andere eigenaren van Wyze-camera's doordat andermans thumbnail werd getoond in het tabblad Gebeurtenissen. Volgens Crosby werd het probleem veroorzaakt door overbelasting na een AWS-storing.

Op Reddit melden verschillende gebruikers dat er onbekende camerabeelden verschenen in de Wyze-app. Sommigen kregen ook een pushmelding doordat er beweging werd gedetecteerd door de camera van een ander. Wyze benadrukt dat er geen livefeeds of video's naar de verkeerde gebruiker zijn gestuurd, alleen waarschuwingsminiaturen van gebeurtenissen.

Crosby stelt dat Wyze het tabblad Gebeurtenissen direct heeft uitgeschakeld nadat er meldingen over het voorval binnenkwamen. Het tabblad blijft tijdelijk offline, totdat Wyze het beveiligingsprobleem heeft onderzocht en opgelost. Daarnaast is er een extra verificatielaag toegevoegd voordat gebruikers in staat zijn om thumbnails te zien. Gebruikers werden gedwongen om uit te loggen om de tokens te resetten.

Iets minder dan een halfjaar geleden deed zich nog een soortgelijke situatie voor. Enkele Wyze-gebruikers meldden in september dat de camerafeeds van andere gebruikers zichtbaar waren via de webviewer van het bedrijf. Toen waren cacheproblemen volgens Wyze de oorzaak. Het gehele voorval zou toen ongeveer dertig minuten hebben geduurd.

Door Sabine Schults

Redacteur

18-02-2024 • 09:19

82 Linkedin Whatsapp

Submitter: wildhagen

Reacties (82)

82
82
37
1
0
30
Wijzig sortering
Dit snap ik dus niet. Hoe kan een "select * from cameras where user_id = x" nu verkeerd lopen?
Hoe kan zelfs een AWS storing zorgen dat x ineens x + y wordt?
Enige wat ik mij kan voorstellen, mbt. overbelasting, dat er oude cached thumbnails werden geserveerd van een backup/fail server met eigen of niet-unieke id's oid, who knows
Cached thumbnails die niet aan een ID gekoppeld zijn kunnen niet ineens bij een random ID getoond worden, als t goed ingericht is. Punt.
Daarom zeg ik niet-uniek, als in hergebruikt.
Hoeft overigens niet aan Amazon te liggen maar een eigen implementatie er overheen.

[Reactie gewijzigd door Sascha G. op 18 februari 2024 09:51]

Zelf dat lijkt me onmogelijk, de kans op een hash colission op een UUID is fenomenaal klein, amazon maakt gebruik van UUID's for file referenties.
De kans dat het meerdere keren gebeurd (meerdere gebruikers) is zo goed als onmogelijk.
Wat wel zou kunnen;
Wyse die een kleiner stuk van die UUID gebruikt omdat de UUID de lang is of vreemde karakters bevat (dashes)
Zo kunnen er uiteraard wel collisions gebeuren (en dat zal nog gebeuren)
Het probleem ligt hoe dan ook bij WYZE

Ik denk dat er iets gebeurd is en dat wyze dat verkeerd opgelost heeft waardoor er sideeffects ontstaan zijn.
uiteraard is het gemakelijker om de schuld van zo een groot privacy probleem op iemand anders te steken.
Klopt, zolang een identifier genoeg uniek of random is, krijg je geen onbedoelde cache hit en hoef je je in principe geen zorgen te maken om collision.
Maar vermoedelijk maken zij (ook) geen direct gebruik van de lange unieke identifiers die Amazon toekent.
Het zijn er in de praktijk weinigen die er geen eigen identifier voor hangen. Als daar vervolgens een andere file aan hangt, op één server X, op de ander Y, kun je zoiets krijgen.

Iets anders wat samenhangt met overbelasting/downtime en caches kan ik in ieder geval niet bedenken.

Vandaar...

Maar goed, genoeg glazenbollenpoetsen wat mij betreft.

[Reactie gewijzigd door Sascha G. op 18 februari 2024 14:18]

Dit had encrypted moeten zijn. Je hoort een ander zijn thumbnail/video/metadata niet te “kunnen” lezen.

Dat dit mogelijk is lijk me een datalek en wellicht zelfs strafbaar?
ik ben wel benieuwd onder welke wet jij denkt dat dit strafbaar is
AVG gezien het feit dat WYZE een dataverwerker is en dus onder die wetgeving valt.
Hoewel ik het met je eens ben, denk ik dat in grotere omgevingen wel eens wat fout gaat met load balancing (dubbele UIDs bijvoorbeeld)
In dat geval kan het heel goed zijn dat men terecht de schuld bij Amazon neerlegt.
Letterlijk wat ik schrijf/imply dus 👍
Hetzij dat het waarschijnlijker aan de implementatie/toepassing ligt met eigen id's ipv. bij Amazon

[Reactie gewijzigd door Sascha G. op 18 februari 2024 11:13]

Als het goed ingericht was was er niks misgegaan. Punt. ;)
Deze is diep. En geldt voor praktisch 100% van alle bugs en ezploits waar we over lezen.

Je hebt geen idee van de inrichting, of waar de storing zit. Het zou in AWS kunnen zitten, in WYZE op AWS of op de combinatie ervan.

Het zou zelfs zo kunnen zijn dat er iets overflowed is, waar dat niet bekend of verwacht was.

Maar goed, jij weet het beter
Blijkbaar is in sommige gevallen het kanaal van een ander te zien. Dat wijst wel enigzins op verkeerde prioriteiten en niet-serieuze beveiliging. Die streams van camera's worden in een lijst gegooid en zijn door een vreemde gebruiker zonder authorisatie gewoon te benaderen? Al zat er maar een random fabriekssleutel in, dan had je dit al niet.
Dat kun je zonder te weten hoe het gemaakt is, niet zeggen.

Als dit een edge case is, waar niemand op rekende bijvoorbeeld.

Sql string insertion was ooit ook nieuw.
Een edge case? Die apparaten "hacken" elkaar per ongeluk. :+
Ja, een systeem dat uitvalt dat normaal niet uitvalt, kan een edge case zijn
Natuurlijk erg makkelijk om dit vanaf de zijlijn te roepen, maar als door het uitvallen van een systeem iets als dit kan voorkomen klopt je ontwerp niet.
  • A: Gebruiker kan de wel data zien, behalve als systeem A aangeeft dat er geen rechten zijn
  • B: Gebruiker kan de data niet zien, behalve als systeem A aangeeft dat er wel rechten zijn
Optie A is per definitie een slechte implementatie, ook als systeem A niet uit zou moet kunnen vallen
Snap jij caching tot elk detail?

Had jij destijds sql injections voorzien? Of het lekken van data by hyperthreading?

Ik vermoed van niet.

Dus je stelling kan juist zijn, maar moet dat niet zijn.
Iedereen met inzicht had SQL-injectie kunnen voorzien. Het gevolg van een overbodige I/O laag in een gebruikerssysteem. Al veel langer is het idee dat een invoerveld alleen maar invoer conform een strikt formaat moet zijn en geen specifieke interpretatie hoort te doen gemeengoed in de security-sector. Als zoiets werkt heb je je eigen informatie-stromen gewoon niet goed in beeld.
Dezelfde structurele laksheid heeft er de afgelopen 20 jaar voor gezorgd dat mails in een mailbox vergaand code kunnen uitvoeren als je erop klikt en toevallig het verkeerde OS draait. Wie verzint het? En dan in een zakelijke omgeving gewoon iedereen Outook met default-instellingen toekennen. "Hoezo is dat een probleem?"

[Reactie gewijzigd door blorf op 19 februari 2024 20:00]

Ik wilde dit net zeggen, naar AWS wijzen lijkt mij totaal onlogisch hier, tenzij er bewijs daarvoor is.

[Reactie gewijzigd door djvdorp op 18 februari 2024 09:43]

Er zijn personen die altijd eerst naar anderen wijzen als er iets verkeerd gaat, dus waarom zal dit bij bedrijven anders zijn. Als het niet bij AWS ligt, dan blijkt dit over een paar weken en zeggen ze sorry. Daar hoor je niets meer van, omdat iedereen het inmiddels weer vergeten is. Tot het een derde keer gebeurt, want dan komt het als een boemerang weer terug. Daarom is het voor Wyze te hopen dat dit de laatste keer is, want dan kan iedereen dit vergeten.
"Er was een probleem met aws"
Als in, "we hebben daar de files verkeerd opgeslagen, "

Benieuwd hoe je dat u berhauot voor elkaar krijgt. Een icoon krijgt een algemeen naam, en geen met id ?
Of we hebben geknoeid met een tabel waarin UUID's opgeslagen werden.
Of misschien gewoon een verkeerde sql query geschreven dat geen select op userid deed.

Hoe dan ook UUID's zijn zo groot dat de kans veel te klein is dat er een colission is.
Laat staan dat er veel collisions zouden kunnen zijn...

Ik vraag mij af of amazon geen schadeclaim hiervoor kan indienen. Want nu lijkt amazon hier slecht
Of misschien is er niet met uuids gewerkt. Dat is maar een aannams.
Er word gewerkt met Amazon 3s files.
Die kunnen enkel opgeroepen worden via hun uuid
Hangt er maar net vanaf. Het zouden ook files met buckets thumbnails kunnen zijn?
Klinkt alsof ze een CDN gebruiken en die foutief headers / de query string hebben laten strippen.

Voor content delivery is het vrij normaal on browser headers, request headers en zelfs query strings (zoals "?site=tweakers) te strippen om zo cacheability te verbeteren. Tenslotte als deze informatie niet relevant is voor het bestand, waarom zou de cache server hier om geven

Bjvoorbeeld: logo.png kan prima gecached worden zonder enige verdere informatie, deze is voor iedereen toch het zelfde.

Gaat alleen een beetje fout als het gaat om "camera_thumbnail.jpg?id=12345&key=<sessie>", als je dat stript serveer je ineens de eerste beste request naar "camera_thumbnail.jpg" naar iedere gebruiker, ongeacht hun ID/sessie.
Belangrijk om te weten is dat het strippen van deze data puur op cache niveau gebeurt, deze worden vaak wel nog doorgestuurd naar de server zelf waneer deze een cache-miss krijgen, waardoor je dus het geval krijgt dat je ineens iemands thumbnail zit te serveren naar iedere gebruiker!

Zelfde probleem was een paar jaar geleden op steam het geval, waar je ineens profielen en pagina's van andere gebruikers perongeluk te zien kon krijgen.
Ik zie nog altijd niet waarom Cloudfront extra key's zou gaan strippen moest er iets mislopen in een ander systeem. Tenzij ze een Lambda@Edge gebruiken voor authentication en die ergens een exception smeet en de foutafhandeling gewoon "gotta catch 'em all" was en ze dan iedereen maar door lieten.
Je denkt er te lastig over na, het kan prima zijn dan een engineer even een "betere" cache policy heeft geïnstalleerd en er niet bij nagedacht om de thumbnail URI niet deel te laten maken van de stripbare URI's. Run dat een paar uur in Productie, kom er achter, zet de oude policy weer terug (of fix het) en een paar dagen later staat dit hier op tweakers :)

Onthoud dat een CDN wel gewoon de headers doorzet naar de origin, maar daarna na het verkrijgen van het bestand de headers en query strings dropt, en dit zelfde bestand dus doodleuk verder doorspeelt naar iedere client (zoals ik hier boven beschrijf in mijn reactie). Dan kan nog je security zo goed zijn en hoeft er helemaal niets mis te gaan op dat niveau, anders dan dat de cache gewoon niet snapt dat de thumbnail anders is afhankelijk van de headers.

[Reactie gewijzigd door smiba op 19 februari 2024 11:21]

Jup, dat kan inderdaad een reden zijn, het is makkelijk om zo'n dingen over het hoofd te zijn wanneer je probeert je CDN te optimaliseren. Zo heb ik zelf ook eens een foute change gedaan waardoor de verkeerde thumbnails verschenen, maar dat was ook maar op een publiek stuk van de site.

Maar ja, ze steken wel de schuld op AWS dus ik ben echt wel eens benieuwd wie wat nu verkeerd heeft gedaan.
Zal niet aan de db queries hebben gelegen, maar aan de uitgegeven tokens.
Waarom niet?

De thumbnail UUID's moeten ergens wel per user opgeslagen worden in een DB.
het is dan ook aannemelijk dat er iets misgelopen is bij de select van de thumbnails van een user.

Het kan zijn dat de userid verkeerd was in de query, waardoor de select verkeerde thumbnails ophaalde.
Noet als er tussenin een cache zit, wat ontzettend waarschijnlijk is.
En waar komen die tokens vandaan ? Uit een DB uiteraard :) .

Ik pas hem even aan, uitgaande dat alles in één DB zou draaien:

select cameras.* from cameras left inner join tokens
where cameras.user_id = x
and tokens.token = uuid
and tokens.user_id = x

Als het micro-services zijn; het is niet zo moeilijk om ff een check toe te voegen om te zien of de user_id overeenkomt met deze van de camera. Heb zoiets een kleine 10 jaar geleden in Spring Boot al gedaan en dat was zelfs puur annotation based.
Je maakt een grap zeker? Op de schaal waarop zij werken?
Welke over-engineered oplossing stel jij dan voor?
Bovenstaande code is zo simpel en zo eenvoudig te schalen en met een beetje DB optimalisatie kan je hier miljoenen mensen mee bedienen.
Ja jij gaat het allemaal direct aan een relationele db koppelen, waar je mooi dure join queries op uitvoert? Geen caching? Zal een feestje worden voor de users.

Als je voor een bedrijf als dit begint te praten in 'simpel' en 'beetje optimalisatie', dan kun je er wel vanuit gaan dat je een oversimplificatie uitvoert en geen zicht hebt op de volledige scope. Geeft natuurlijk niet, maar verkoop het dan niet alsof het hiermee 'ff' opgelost wordt.
Die query is alleen nuttig voor simpele demo's. In productie moet het schaalbaar, testbaar en onderhoudbaar zijn.

Zie bijvoorbeeld dit.
Linksom of rechtsom maakt niks uit of kafka of sql of no sql gebruikt.

Je moet ergens id's aan koppelen als je bepaalde dingen alleen aan bepaalde gebruikers wil tonen.
En wellicht gebeurd het op de machine zo, maar zit er een cache tussen en een zooitje loadbalancers. Er zijn nog zat plaatsen (te bedenken) tussen jouw gesimplificeerde query, en het verschijnen van de thumbnail, waar het fout kan gaan.

(Was reactie op @Hardfreak )

[Reactie gewijzigd door familyman op 18 februari 2024 22:23]

Sowieso, caches zijn een pita om mee te werken.
Op jet werk hebben wij 3 cache lagen en dan nog eens redis op onze backend.

Ik haat het elke keer iemand vraagt "waarom zie ik x niet verschijnen".
Je werkt bij twitter?
(Geintje)
Het systeem werkt nu eenmaal niet via één enkele simpele query. het resultaat van de query wordt vervolgens door een andere service opgepakt en daar kan door overbelasting asynchroniteit in ontstaan waardoor x de thumbnails van y krijgt en y krijgt de thumbnails van z.
Hash colissions is meestal een antwoord op een dergelijke vraag.

Zowiezo wil je natuurlijk niet iets als "select * from cameras where user_id = x", dat deden we al niet meer in 2004... Maar goed, als je met grote systemen werkt dan is niets echt 'simpel'...
To be honest, ik zie niet waarom dit voor grote systemen niet zou werken. Alles wordt tegenwoordig zo over-engineered dat je dus van dit soort bugs krijgt.
En hash collisions zijn een zeldzaamheid, dat is mss één gebruiker per 5 jaar of zo die dat zou moeten merken, niet ineens een nieuwswaardig aantal.
Waarom blijven mensen cloud diensten gebruiken hiervoor? Het is ook nog eens duur. Er zijn zoveel locale alternatieven, die gratis zijn en veel beter werken. Ook voor niet-Tweakers.
Omdat appje. Wat heeft een Ring deurbel voor nut als je niet thuis bent en je hebt geen appje? Wat heeft een camerasysteem voor zin als je niet thuis bent en je hebt geen appje?

Om te zorgen dat je die app hebt moet de leverancier ook zorgen dat je van buiten je netwerk ook verbinding moet kunnen maken. Dat doen ze met een centrale server (cloud omgeving) waar zowel je appje als je IoT verbinding mee maakt. Voor het IoT is er dus alleen een uitgaande verbinding nodig, wat simpel is. Maakt je appje verbinding met je IoT zelf, dan moet je IoT apparaat ergens met DynDNS bekend worden gemaakt. Anders weet je appje niet waar het moet zoeken. Dan, bij je router aangekomen, moet je router ook weten dat het verkeer doorgelaten moet worden (firewall), waar het heen moet (NAT translatie) en je IoT moet ook een vast(ig) IP adres hebben door een fixed IP adres in te stellen of een DHCP reservering te maken. De leverancier van het IoT zal dat moeten documenteren voor iedere veelgebruikte router.

Omdat én consumenten dat appje willen én consumenten willen zonder veel moeite buiten de deur weten wie er aanbelt, maakt Ring gebruik van een cloud dienst. En die slaan thumbnails op. Eufy doet dat ook, kreeg ook kritiek. En met die Cloud omgeving gaat wel eens wat mis, zoals nu.

Het enige alternatief om zeker te zijn dat je veilig bent is gewoon geen IoT apparaten in huis hebben.
Wat heeft een RIng deurbel voor nut?

Geen. Je kunt de deur niet open doen, je kan alleen melden dat je er niet bent. Dat had degene aan de deur natuurlijk nooit op een andere manier uitgevonden.
Iemand die je kent die aan de deur staat, zal jou gaan bellen.
Een bezorger geeft het pakje aan de buren, ook als je geen Ring hebt. Of gewoon bij een afhaalpunt laten bezorgen, kun je het halen als het jou past.
En voor ongewenst/onbekend bezoek hoef je de deur niet open te doen (colportage, jehova's, etc.). Ik weet wanneer er iemand komt of wanneer er wat bezorgt wordt. Val je buiten deze verwachting, dan doe ik niet open.

Alleen de politie maakt dankbaar gebruik van de surveillance, maar dan komen je naam en adres in het strafdossier.
Nochtans zijn er bijzonder veel Ring apparaten verkocht. Het ging in dit geval niet om een Ring specifiek, maar de wens van de moderne mens om meer IoT apparaten in huis te hebben. Die IoT apparaten dienen bediend of bekeken te worden vanaf de telefoon en werken om die reden met een appje.

Die combi maakt dat er altijd een cloud infrastructuur achter moet zitten en die cloud infra is kwetsbaar.
Dat jij er heen doeleinde voor hebt/kent betekent niet dat het product geen nut heeft...
Welk nut heeft het dan?

De enige situatie die ik kan destilleren? Je bent thuis, er wordt gebeld, je weet niet door wie, je kijkt op je Ring, er staat een onbekende, je besluit open te doen.

In elke andere situatie (je weet wie er komt, er staat een bekende, je besluit niet open te doen) heeft de Ring geen functie.

En ik betwist dat men in die eerste situatie de deur open doet. Ergo, geen nut.
1. Toch kan het handig zijn als je ziet wie er voor de deur staat als er wordt aangebeld en je niemand verwacht. Ik zou bijvoorbeeld best open doen voor een pakket bezorger om een pakket van de buren aan te nemen, maar heb geen zin in een collectante.
Ik zie dit als groot voordeel wanneer ik aan het werk ben (of zelfs in een meeting zit). Zo ook voor huizen waarbij er geen mogelijkheid is om te zien wie er voor de deur staat (portieken bijvoorbeeld).
2. Als je een bestelling verwacht en niet thuis bent kan je de voordeur/garagedeur openen. Uiteraard moet je hiermee wel je bezorger enigszins kennen (of goed van vertrouwen zijn), maar dat is bijvoorbeeld bij mij wel het geval.
Daarnaast kan je een bezorger vragen om het ergens in een voortuin achter te laten of bij specifieke buren waarmee je een goeie band hebt.
3. De camerabeelden kunnen handig zijn. Het hoeft niet eens zo te zijn om andere te helpen, maar ook kan je jouw eigen eigendommen ermee 'beschermen'.

Dit zijn redenen die ik zo kan verzinnen, wellicht hebben andere gebruikers nog redenen. Men zal echt niet € 100 aan een deurbel uitgeven zonder dat het nut heeft voor hen...
Precies, als ik zie (gewoon vanuit mijn raam...) dat een verkoper naar de deur loopt sta ik niet op, doeii.

[Reactie gewijzigd door JustFogMaxi op 18 februari 2024 20:06]

Zoals? Ik ben als Tweakers bezoeker bekend met wat zaken maar voor camera hosting weet ik buiten een lokale recorder en die via een VPN benaderen eigenlijk weinig opties voor beelden vanuit de cloud bekijken. Is namelijk niet m’n main interesse of vakgebied.
Er zijn zoveel locale alternatieven, die gratis zijn en veel beter werken.
Er is geen enkel gratis alternatief. Vergeet de stroomkosten en de tijd die nodig is om alles te beheren, te updaten, in te richten etc niet.Wil je daarbij ook nog eens iets wat je van overal en altijd kan bekijken dan wordt het nog meer werk.
Duur? Toen ik mijn Wyze cams kocht waren het spotgoedkope cameraatjes en de cloud dienst zat er gratis bij en is vziw nog altijd gratis voor de cams die ik destijds aangekocht heb.

Ik heb ze evenwel wel bijna allemaal uitgezet, en enkel wanneer ik met vakantie ga, gaan ze aan. Enkel diegene die op de voor en achterdeur zijn gericht blijven streamen, maar daar is dan ook van binnen in de woning niets op te zien zodat privacy gewaarborgd blijft.
Omdat dit voor niet-tweakers allesbehalve evident is. Ik krijg mijn meer dan capabele schoonouders niet zo ver om zelf een NAS op te zetten met remote toegang hoor.
Juist doordat tegenwoordig alles plug and play en via een app geregeld wordt hebben mensen steeds minder vaardigheid met apparatuur. Een groot deel weet helemaal niet dat het via een cloud gaat. Zelf thuis een lokaal systeem opzetten gaat velen gewoon niet lukken.
Gratis voor een bedrijf ? Zoals?
Dat het draait op een cloud instance .. of met een kubernetes omgeving op je eigen raspberry cluster .. of op je NAS gepropt…..
Positioneert zich wel op de schaal tussen hobby-Bob en ESCROW maar is niet relevant.

De vraag is: hoe is het mogelijk dat deze diensten niet met een end to end encryption zijn ingericht! Zo ben je eigenaar van je data en is je privacy geregeld zoals het hoort.

Daar staat wel een beetje tegenover dat de gemiddelde tweaker zich ook verslikt in de complexiteit en de WAF om het een en ander te onboarden. Juist lokaal zie je veel dat “och eigen netwerk dus veilig” conclusies.
Je bedoelt waarschijnlijk, lokale self-hosted oplossingen ?
Ik dacht eerst dat je bedoelde "in Nederland/België" en dat klonk nogal ongeloofwaardig.

Het kan lokaal, ik heb hiervoor thuis een homelab'je draaien met een eigen VPN server en Home Assistant + Frigate. Ik zie de gemiddelde persoon echt geen VPN opzetten en de YAML file van Frigate opzetten zodat de camera's uiteindelijk deftig werken.

Het ding is gewoon gemak. Ja AWS is duur en deze week had ik nog de discussie met onze SysOps'ers (die ons datacenter stuff beheren) en self-hosted compute is waarschijnlijk aanzienlijk goedkoper, maar high-available networking, firewalling (lees: licenses), redundant storage (en de kennis om een kapotte cluster te fixen) én CDN (+ een DC waar je een vette uplink krijgt) is een heel ander verhaal.

//edit: kleine verduidelijking over DC stuff

[Reactie gewijzigd door Hardfreak op 18 februari 2024 16:38]

Ik heb zelf ook best wel een hekel aan dat hele cloud gebeuren en zou het liefste alles lokaal willen gaan gebruiken. Alleen is het voor zover ik dan weet niet mogelijk om mijn camera's en deurbel lokaal te kunnen gebruiken. Of ja misschien wel als je goed bent in zelf programmeren dat er misschien wel een mogelijkheid zal zijn.
Dit laat opnieuw zien waarom
End to end encryptie belangrijk is

Was die encryptie er geweest dan had de storing nog kunnen plaatsvinden maar was er geen impact geweest omdat je de fout geserveerde afbeeldingen niet kon decrypten
De eerste normale reactie die ik lees.

En je hebt helemaal gelijk. Jouw scenario zou ervoor zorgen dat elke fout meteen zou zorgen dat er geen data lekt.

Het is zo zonde dat mensen encryptie alleen als oplossing voor security zien - terwijl er ook toepassing zijn in integrity en zelfs availability.

(Los van definities)
Mee eens, maar als dit soort problemen zich al voor doen (wat eigenlijk heel makkelijk te voorkomen is) dan zou ik weinig vertrouwen hebben in hun end to end encryptie.

Blijkbaar wordt specifieke gebruikersdata in een pool bewaard die toegankelijk is voor iedereen en het zou me niks verbazen als dit probleem wordt veroorzaakt door racing conditions. Wat inhoud dat als een radartje te traag is in het proces, je de data van een andere gebruiker uitgeserveerd kan krijgen, omdat het process ingehaald wordt door het process van een andere gebruiker. Alsof je voordringt in een rij met mensen die hun bestelling afhalen en je iemand anders bestelling mee krijgt.
Ik heb dit al zo vaak mis zien gaan en in de meeste gevallen kwam het door een foutieve caching.
Caching juist instellen (bv varnish) kan best tricky zijn en een development iteratie kan het stuq maken.

Mijn EZViz camera stelt dat de beelden end to end encrypted zijn. Bij het instellen van de camera moet ik een encryptiekey instellen en alleen met die key kan ik de videos decrypten in mijn app. Serverside zou alles, als het goed is, onleesbaar moeten zijn. Dus ook al zou er een config fout of hack zijn. Server side zou je alleen encrypted beelden moeten zien.
There are only two hard things in Computer Science: cache invalidation and naming things
Het klinkt alsof hier iets fundamenteel verkeerd zit, als dit meerdere keren voor komt?
Klopt. De S in IoT staat voor security.
Zou er een fout in de uitgifte van de tokens zitten waardoor ze dubbel zijn gebruikt. En gebruikers elkaar thumbnails zagen.
Dit kun je niet op AWS schuiven maar op je eigen configuratie en software.
De bron stelt niet dat het bedrijf de schuld legt bij AWS. Men stelt dat het lijkt te zijn begonnen na problemen met AWS.

Het is zeer goed mogelijk dat het bedrijf niet goed voorbereid was op dit soort uitval en daardoor klanten de problemen hadden.
Dus het is de schuld van aws dat mensen andermans feeds/thumbnails daarvan te zien krijgen?

Klinkt mij meer in de oren als een slap excuus voor het zelf niet goed geconfigureerd hebben of een programmeerfout in de software. Heb eerlijk gezegd nog nooit gehoord dat aws random assets terug gaat sturen door een storing.
Of er is iets uitgevallen, wat normaal niet uitvalt en waar wyze zich daarom niet op had voorbereid.

We hebben het hier over knetteruitgebreide infrastructuur, en mensen hier doen of het niet veel meer dan een usb in hun computer steken is....

Dit is toch tweakers?
Heb het al een keer eerder vermeld, maar dit gebeurt ook wel eens bij Aiwit. En dan doe je netjes melding en dan zeggen ze: het lijkt erop dat je camera stuk is, wil je een vervangend apparaat?
Ik neem aan dat er dan verder geen info bij zo'n thumbnail staat dus in die zin kan een ander er dan verder weinig mee. Zou dan al puur toeval zijn als je dan toevallig iemand herkent maar evenzogoed mag zoiets niet gebeuren.
Geef AWS maar de schuld... 🤔
Slechte code, dat is wel duidelijk. Infra problemen zouden nooit deze impact mogen hebben

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee