Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 47 reacties

Hardwarefabrikant Logitech heeft ruim achthonderd facturen van klanten in een eenvoudig te vinden open-directory geplaatst. Daardoor lagen de naw-gegevens van de klanten op straat. Inmiddels is het probleem opgelost.

De facturen zijn afkomstig van een actie van Logitech, 3=2, waarbij klanten die drie Logitech-producten kopen het derde product gratis krijgen. Om de korting te kunnen claimen, moeten klanten onder meer hun factuur uploaden. Die facturen werden echter opgeslagen in een subdirectory van de actiesite, waarvan de directory-listing bovendien vrij opvraagbaar bleek te zijn.

Een anonieme bron tipte Tweakers over het privacyprobleem, dat eenvoudig te ontdekken was. "Het viel me op dat de voorwaarden van de actie waren gewijzigd nadat de actie was ingegaan", zegt hij. "Ik wilde kijken of de oude voorwaarden nog online stonden." De map waarin de voorwaarden stonden, 'images', bleek een open-dir. Daardoor was de subdirectory met 832 facturen eenvoudig te vinden. De facturen bevatten onder meer naw-gegevens, maar voor zover bekend geen betalingsgegevens. Het gaat om alle facturen die zijn geüpload sinds de start van de actie, begin vorige maand.

Het gaat om een eenvoudig te voorkomen probleem; op zijn minst had Logitech toegang vanaf het web tot de map met facturen moeten voorkomen, wat op de door Logitech gebruikte Apache-webserver zeer eenvoudig is. Beter nog zou het zijn geweest om de facturen op te slaan in een map die voor Apache helemaal niet toegankelijk was.

Na melding van Tweakers heeft Logitech het privacyprobleem opgelost. "Logitech heeft de site uit voorzorg direct offline gehaald, waardoor de gegevens niet langer te zien zijn", laat het bedrijf weten. Logitech laat ook weten dat het het privacyprobleem 'heel vervelend' vindt. De site komt later weer online, als het probleem volledig is opgelost.

De voorwaarden van de actie werden overigens gewijzigd nadat kopers erover klaagden op Gathering of Tweakers. Het is onduidelijk wat er precies is gewijzigd; de Logitech-woordvoerster kan daarover geen duidelijkheid geven.

open dir logitech

Moderatie-faq Wijzig weergave

Reacties (47)

"Logitech heeft de site uit voorzorg direct offline gehaald, waardoor de gegevens niet langer te zien zijn", aldus woordvoerster Renée Rijken. Ze zegt dat Logitech het privacyprobleem 'heel vervelend' vindt. De site komt later weer online, als het probleem volledig is opgelost.
Want een edit die directory listings uit zet en een reload was te moeilijk? 8)7
Dus dan maar 'offline halen' om het probleem op te lossen? Volgens mij snappen ze daar weinig van webservers.

@hier onder:

Je kan gewoon globaal directory listings uitzetten, en met 1x rgrep heb je in alle mogelijke configuratie bestanden alle Indexes configuraties te pakken. Dit kost echt niet meer dan 1 minuut.

Het offline halen is een typische management reactie. Ze weten te weinig van de materie om iets te doen, en gaan eerst impulsief reageren, consulteren daarna de juridische afdeling en daarna kijken ze of IT het op moet lossen.

[Reactie gewijzigd door johnkeates op 8 september 2014 13:36]

Dat lijkt inderdaad vaak een gebruikte tactiek als een bedrijf niet meer snapt wat er is misgegaan. In plaats van het probleem oplossen gewoon een hele site offline trekken. "Welk probleem? De site is offline, dus het is opgelost!"
Ik vind het nog niet zo dom hoor, dit was 1 map, maar er zijn hier al heel veel dingen misgegaan, dus dat mogen ze rustig rechtzetten.
- Apache had nooit bij deze files mogen komen. Technische opzet van deze actie is dus ergens misgegaan, iemand heeft besloten om persoonsgegevens op een publiek toegankelijke server te zetten.
- Deze folder had nooit in Apache leesrechten voor iedereen mogen krijgen, dus ofwel iemand is gruwelijk tegen de policy ingegaan (waarna je wilt uitzoeken wie dat was, dat kan achteraf prima, maar het is handiger om het nu uit te zoeken, op een server die offline is en nog in originele staat), of er zit iets scheef in de policies zelf.

Omdat dit probleem bij meer bestanden kan spelen is het beter om dat rustig te analyseren, in plaats van een hotfix toe te passen, waarna je alleen maar brandweer aan het spelen bent, en geen idee hebt waar de problemen vandaan komen. Als je er zeker van bent dat dit niet nog eens gebeurt kan het alsnog weer aan. I mean, is het echt zo belangrijk dat die server 24/7 up is? Ik betwijfel het. De hoofdsite staat nog, en die actie kan altijd nog een dagje verlengd worden.
Een -Indexes was ruim voldoende geweest, alle bestandsnamen zijn keurig gehasht dus niemand die even alle 832 bestandsnamen gaat vinden of daar überhaupt de moeite voor zal nemen.

[Reactie gewijzigd door ouweklimgeit op 8 september 2014 14:29]

Dat lost alleen de directory listing probleem zelf op, niet dat de bestand op een totaal verkeerde plaats staan. Er stond een topic op GOT. Weet jij zeker dat daar nergens een link naar deze open directory staat? Want GOT wordt zeer frequent door de Google spiders geindexeerd en als dan de link naar de Logitech open-dir wordt gevolgd doet Google ook gewoon die 800+ PDF bestanden indexeren.

Of had jij door de snelheid van je reactie daarover nog niet nagedacht? Want je moet dan minimaal ook de leesrechten op deze directory verwijderen. Vervolgens inloggen bij de Google webmaster tools om eventuele 'foutief' geindexeerde bestanden uit de index te halen.

Een nog betere oplossing is een regex aanmaken voor de open-dir welke voor elke (virtuele) pdf in deze folder een 410 (gone) terug geeft. Daarmee zullen alle spiders de PDF bestanden uit hun index halen..

De actie van Logitech is dus de enige en juiste in het geval van een privacy lek. Eerst website offline, dan rustig analyseren wat de scope van het probleem is. Ook rustig alternatieven kunnen bespreken en daarna resources inplannen om de wijzigingen door te voeren. Want je eerste reactie bij dergelijke problemen is bijna onvolledig en niemand is geholpen met halve oplossingen..

Dat komt eigenlijk vooral door de beperkte invalshoek welke elke persoon heeft. Een programmeur/beheerder denkt vooral een de IT oplossing, maar had jij al nagedacht over de juridische implicaties van dit lek, een PR campagne om het image weer te verbeteren, een excuusbrief naar die 800+ klanten, etc, etc?
De IT'ers snappen het waarschijnlijk wel, maar de baas niet ;)
De baas kijkt alleen naar marketing en sales, en die kijken naar ROI. Outsourcen naar snelle toko voor dit soort dingen is vaak de enige optie die ze overwegen, want de prijs is zo lekker laag en ze leveren ook sneller dan om het intern te doen. Vaak worden security en compliancy niet meegenomen in het contract en gaat of z'n site door met het lek erin of gaat op zwart totdat de contractonderhandelingen zijn afgerond.

Veel IT'ers zijn er niet meer, want DevOps is het nieuwe mantra en broad empowerment gaat dan vaak hand in hand. Het is opgeleverd en in productie voordat het is afgerond en de developer werkt al aan zijn volgende opdracht om zo geld voor het bedrijf te blijven verdienen. Voeg daar kapotte frameworks aan toe die nooit geupdate worden en je bent terug bij af.
Misschien willen ze op andere pagina's juist wel de directory listings blijven gebruiken.
Bvb een pagina met alle drivers die ze gemaakt hebben maar niet meer supporteren.

zo kunnen mensen met oude apparatuur nog steeds hun drivers downloaden en moeten zijn er verder geen werk noch opmaak tijd in steken. gewoon alle oude drivers naar daar verplaatsen.

Dat zou een mooie service zijn zonder dat ze er veel werk in moeten steken.
Dan nog is het handiger om voor die folder de directory listing aan te zetten dmv een .htaccess bestandje in de betreffende folder. Globaal kan het dan gewoon uit blijven staan.

Vaak ook handig om een leeg .html bestand in dit soort folders te gooien icm een deny all .htaccess, mocht het niet mogelijk zijn om de folder buiten de web root te houden.
Een directorylisting uitzetten heeft geen zin als de directorylisting al bij derden bekend is...

@hieronder: ook in het algemeen geldt, dat je bestandsnamen kunt raden. Vertrouwelijke bestanden op een webserver in een toegankelijke map zetten is dus nooit een goed idee.

[Reactie gewijzigd door mae-t.net op 8 september 2014 21:29]

Het ging ook niet om het beschermen van de dat die al gelekt is, maar om het standaard uitzetten van directory indexes op productie servers. Dit klinkt een beetje als een typisch gevalletje vaarbij DevOps niet bestond en SysOps niet precies wist wat nodig was om dat de developer het zelf ook niet wist.

[Reactie gewijzigd door johnkeates op 8 september 2014 17:55]

Kan me er wel iets bij voorstellen. Waarschijnlijk willen ze alle dirs nu nalopen, want wellicht is het op andere plekken ook het geval.
Eerst en vooral offline halen en dan pas het probleem oplossen en testen of er nog meer van die grapjes in zitten. Niet alleen directory listings uitzetten, de volledige map afschermen van internet, want wie de list van bestanden al heeft zou gewoon verder kunnen gaan.

Dan pas weer Online zetten
Directory listing uitzetten werkt nu al niet meer natuurlijk. Je kan door middel van bovenstaande screenshot gewoon direct naar een bestand gaan ;) Dan heeft de listing alleen uitzetten niet heel veel nut natuurlijk.
Ik was juist verbaast over het feit dat logitech het serieus neemt en meteen de boel offline gooit inplaats van de stap die de meeste bedrijven nemen, gewoon doorgaan totdat het daadwerkelijk wordt misbruikt en het aan het licht komt.

Als ze op de hoogte zijn gesteld en de boel platgooien omdat het snelste te doen is dan kan ik dat alleen maar positief beschouwen. Natuurlijk niet zo handig dat opendirs uberhaupt aan staan maar dat ze uit voorzorg de boel offline gooien totdat het belletje wordt gedaan naar de persoon die weet wat er in de httpd.conf moet staan.. kan die keuze alleen maar toejuichen.

De Apache server in de openSUSE/SUSE repositories heeft directory listings trouwens standaard uitstaan om dit soort situaties te voorkomen

[Reactie gewijzigd door Xthemes.us op 8 september 2014 13:31]

Met alleen de dir listing uitzetten is het probleem natuurlijk niet opgelost, dan kan je nog steeds bij de bestanden. Die hele map moet gewoon weg uit de webroot. Ik begrijp goed dat ze het op deze manier doen, beter dan dat ze het te licht opvatten. Misschien dat bestaande code ook moet worden aangepast, zodat nieuwe uploads weer niet op dezelfde plek belanden.
Los hiervan is het natuurlijk een erg domme fout.
Het offline halen is een typische management reactie. Ze weten te weinig van de materie om iets te doen, en gaan eerst impulsief reageren, consulteren daarna de juridische afdeling en daarna kijken ze of IT het op moet lossen.
Je schrijft dit alsof die procedure een negatief iets is..wat denk je zelf, dat een manager even een ticket aanmaakt bij de servicedesk met het vertrouwen dat het probleem over een kwartiertje wel opgelost zal zijn?

Altijd maar de typische reacties 'dit is binnen een minuutje opgelost, dus wat een overtrokken reactie van het bedrijf'. En niemand die benoemt dat die beheerder zo dom was om dat minuutje niet eerder te besteden en nu zijn werkgever behoorlijk in verlegenheid heeft gebracht.

[edit: zinsbouw]

[Reactie gewijzigd door WaterFire op 9 september 2014 08:24]

Eh, denk je nou serieus dat het offline halen dan niet via een ticket gaat? Dat een edit en een reload veel meer tijd kost dan een stop?

Het feit dat een management laag besloten heeft dat er een probleem is en dat er dan maar een server plat moet betekent dat ze net zo goed hadden kunnen zeggen: zet directory listings uit en reload de config.

Uiteindelijk denk ik niet dat hier zo veel management lagen waren, dat dit ook geen in-house IT project betrof en dat er ook geen personen met de juiste kennis en procedures aan dit verhaal te pas kwamen. Ten eerste om dat dit door SysOps en door DevOs prima afgedekt was geweest als ze dat hadden, maar dat hadden ze niet lijkt me zo. Daarnaast kan je aan de manier waarop ze met hun server configuratie om gaan er bijna al van uit gaan dat er geen server of applicatie beheerder was die wist wat ie deed. Het feit dat dit soort directory listings zo maar open staan zegt eigenlijk al dat er eigenlijk gewoon niet de juiste kennis was, waar dit spul dan ook geprogrammeerd is.
Het feit dat een management laag besloten heeft dat er een probleem is en dat er dan maar een server plat moet betekent dat ze net zo goed hadden kunnen zeggen: zet directory listings uit en reload de config
Als je serieus denkt dat een manager Sales weet wat een directory listing is ben je misschien een beetje wereldvreemd...
Een manager sales heeft niks met een ITSM-management laag te maken meneer. Is het echt nodig om meteen met woorden als 'wereldvreemd' te gaan strooien?
Jazeker, als je schrijft
Het offline halen is een typische management reactie. Ze weten te weinig van de materie om iets te doen, en gaan eerst impulsief reageren, consulteren daarna de juridische afdeling en daarna kijken ze of IT het op moet lossen
Blijkt daar niet uit dat je de ITSM laag bedoelde maar gewoon 'het management' . Dat je ITSM er nu voor plaatst zet je zin in een andere context, best makkelijk.
'het management' bestaat niet. Misschien in de volksmond, maar dit is tweakers.net en dat geeft genoeg context bij een artikel over een falende webserver configuratie om te weten dat it over ITSM gaat en niet over HR of iets dergelijks.
elk site houder/bouwer die geen standaard tampletse gebruikt maar zelf een site ontwikkeld zal altijd wel zo'n fout maken.
daarom vind ik het een beetje raar dat er geen standaard is voor sites.
Als je een standaard pakket zou gebruiken kan dit je nog steeds overkomen, dit is simpelweg een server misconfiguratie. Hier de schuldige aanwijzen of het degene is die de server configuratie doet of de degene die de website software schrijft zou een moeilijk verhaal zijn. Alhoewel degene die de software schrijft vast in staat was om een .htaccess te schrijven die toegang tot die directory ontzegt. Het is een fout die mij ook had kunnen overkomen.

[Reactie gewijzigd door Xthemes.us op 8 september 2014 14:09]

probleem met alleen directory toegang ontzeggen, betekent echter dat je nog steeds een potentieel 'lek' hebt. je kan dan namelijk via brutoforce bestandsnamen genereren en dus mogelijk andere pdf/jpg bestanden opvragen die niet van jou zijn.

door buiten de directory plaatsen (of directe http toegang via .htaccess te blokkeren) kan je ook dit voorkomen. door dan eerst in PHP de gebruiker (en dus de rechten te controleren) kan je vervolgens netjes de toegang regelen omdat je via je script wel netjes bij de bestanden kan komen.
Ligt eraan in hoeverre je de toegang ontzegt.
Met een "Options -Indexes" zou dat inderdaad nog kunnen.
Met een "Deny from all" echter niet.

edit:
Precies dus wat je zegt :P

[Reactie gewijzigd door Xthemes.us op 8 september 2014 14:10]

gewoon alle requests naar de folder (of de files in de folder) redirecten naar een 404, maar buiten de pub dir is sowieso beter (en netter).
wat een onzin! alsof er nooit een lek in standaard templates / plugins zou zitten!
dan ga je er dus vanuit dat iemand anders dit voor je gecontroleerd heeft, lekker makkelijk.

een beetje maatwerk ontwikkelaar vangt dit gewoon goed af door (zoals in het artikel staat) een directory buiten je public dir te pakken. ook instellen in .htaccess had al een oplossing kunnen zijn..
slecht dat dit niet is ingesteld in apache, slecht dat de ontwikkelaar dit niet heeft gecontroleerd en afgevangen.

jammer dat er niet getest is of er ook een php file geupload en vervolgens uitgevoerd kon worden, dan was t feest helemaal compleet geweest 8)7
waarschijnlijk zou je laatste test strafbaar zijn en voor je 't weet staan dr een paar van thtc voor je deur ;)
daar heb je een punt :P
Er was een tweaker in dit topic erg diep aan het zoeken: Oneerlijke reclame van Logitech ? zou hij het geweest zijn? ^^

Daarnaast, is dit wel een hele slechte zaak om het zo "open en bloot" op internet te zetten.
Ze zegt dat Logitech het privacyprobleem 'heel vervelend' vindt.
Het is toch echt meer dan heel vervelend. Als je zo graag dit soort gegevens wil verzamelen dan moet je er ook maar voor zorgen dat je de boel goed beveiligd. Het wordt tijd dat een toezichthouder hier eens hard tegen op treed met een goede boete en een automatische schadevergoeding aan de betrokkenen.
dat vind ik ook, maar hetzelfde voor particulieren die alles open en bloot op strava, facebook enz plaatsen... daar is met wat instellingen ook het één en andere privé te zetten.
liever niet, voor je het weet krijg je hackers in dienst van de multinationals die concurrenten gaan hacken (hetzelfde als het misbruiken van een pay per click ad)

Zat bedrijven die het woord ethiek niet kennen, philips, mediamarkt, intel etc...
Het is natuurlijk geen bijdrage aan het probleem of artikel maar het eerste wat me binnen schoot tijdens het lezen van het artikel en ik denk ik zet er ook wat bij:
Beter nog zou het zijn geweest om de facturen op te slaan in een map die voor Apache helemaal niet toegankelijk was.
Volgens mij wordt het uploaden van de documenten ook door apache gedaan dus moet hij wel toegang hebben (schrijfrechten wel te verstaan). Leesrechten zou hij dan inderdaad weer niet moeten hebben tenzij apache moet checken of een bepaalde bestandsnaam al bestaat (alhoewel dit wel in een database zal staan ivm de gehashte namen). Toegang vanaf het web moet zeker dichtstaan.

Maar misschien vergis ik me....
Grappig wel dat bij het lezen van dit artikel de reclame banner boven het artikel van Cyso was, bij mij.
Slogan: "De persoons- en betalingsgegevens van uw klanten altijd veilig".
Ik ken ook nog wel een website van een reisorganisatie waarbij je door het ophogen van boekingsnummer in de url ineens de bevestiging van iemand anders te zien krijgt (incl. NAW, en data wanneer iemand niet thuis is!).

Dit heb ik netjes bij ze aangegeven, maar ze zijn nog druk bezig met de ontwikkeling van de nieuwe website ofzo.. Geen prioriteit.

[Reactie gewijzigd door Oeroeg op 8 september 2014 14:41]

3=2, voor kleine waarden van 3
Nee, dat artikel sluit niet aan op deze klacht... ja het betreft een klacht over de 3=2 actie, maar dat topic gaat over de voorwaarden.
Indirect gaat het wel over de betreffende actie, in dit topic gaat het inderdaad over de voorwaarden.
Uit het artikel hier:
Een anonieme bron tipte Tweakers over het privacyprobleem, dat eenvoudig te ontdekken was. "Het viel me op dat de voorwaarden van de actie waren gewijzigd nadat de actie was ingegaan", zegt hij. "Ik wilde kijken of de oude voorwaarden nog online stonden." De map waarin de voorwaarden stonden, 'images', bleek een open-dir. Daardoor was de subdirectory met 832 facturen eenvoudig te vinden.
Als je dat topic op GoT ook even leest (en dan met name de reacties van "GlowMouse") dan is het redelijk duidelijk dat 't waarschijnlijk van daaruit gekomen is.
Dat kan wel, maar dat topic gaat dan nog steeds niet over dit probleem... en ik zie niet waar Glowmouse naar dit probleem refereert? Misschien later aangepast hoor... maar ik zie het absoluut niet staan. Verder goed mogelijk hoor dat het mede daardoor is ontdekt... maar het topic linkt echt niet naar dit probleem.

[Reactie gewijzigd door MicGlou op 8 september 2014 14:07]

Glowmouse gaf al aan dat de meta van de site niet klopte. Ik ga er dan ook vanuit dat hij verder heeft gezocht, want hij kijkt ook in de Last-Modified header van de pdf.
Als je de broncode bekijkt van de officiele pagina van Logitech staat er:

HTML:
<meta name="description" content="U koopt drie Logitech producten en u ontvangt één Logitech product gratis." />

Het woordje 'verschillende' staat hier niet bij. Het lijkt erop dat dit later in tekst is bijgevoegd, zonder dat de description is aangepast. Wat nog meer opvalt, is dat deze pdf is gewijzigd na het ingaan van de actie op 4 augustus (de Last-Modified header geeft aan Mon, 25 Aug 2014 15:39:28 GMT).
edit: opmaak

[Reactie gewijzigd door remunj1988 op 8 september 2014 14:18]

Klopt het topic gaat niet direct over het probleem, maar wel indirect. Dus het is wel mogelijk dat dit topic aanleiding is geweest, daar zijn we het over eens. Ik ben wel van mening dat het topic gelinkt mag worden, mede door de aangedragen punten en dan doel ik op de reacties van Glowmouse.

offtopic: Je hoeft je niet boos te maken, iedereen heeft zijn eigen mening. Je hoeft ook niet te papegaaien, frustratie zijn niet goed.

Edit: Ik heb zelf de link niet geplaatst maar goed ik ben sportief en incasseer wel.

[Reactie gewijzigd door remunj1988 op 8 september 2014 15:07]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True