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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 88 reacties, 29.228 views •
Submitter: Quinie

Foto's van Hyves-gebruikers die van de buitenwereld waren afgeschermd, bleken door een fout in de postkaartenmodule toch toegankelijk. Een gebruiker ontdekte dat hij elke foto als kaart kon selecteren door de url te manipuleren.

Hyves KaartjeChris Geers, alias tweaker Quinie, ontdekte dat de postkaart-module van Hyves een groot beveiligingslek bevatte. Deze module maakt het mogelijk om een Hyves-foto als postkaart te versturen, in samenwerking met TNT. Door een parameter in de url van de module aan te passen, was het mogelijk om elke Hyves-foto als postkaart te selecteren; ook foto's waarvan een gebruiker niet het recht heeft om ze te zien. Volgens Hyves is de module slechts korte tijd kwetsbaar geweest.

Geers ontdekte dat het bijvoorbeeld mogelijk was foto's te selecteren die enkel voor vrienden zichtbaar zouden moeten zijn, terwijl hij met de eigenaar van de foto's geen vrienden was. "De module controleerde niet of een gebruiker wel het recht had om de foto uit de url als kaart te selecteren", stelt Geers.

Bovendien was het mogelijk om verschillende variabelen die bij de foto hoorden uit te lezen, waaronder de unieke hash van een foto. Daaruit kon de volledige url van de foto worden afgeleid. Dit proces was bovendien te automatiseren, waardoor het mogelijk was om een database met foto's aan te leggen. Als bewijs overhandigde Geers aan Tweakers.net een lijst met zevenhonderd links naar foto's, die hij op deze manier wist te verzamelen.

Hoewel ook verborgen foto's konden worden achterhaald, was het niet mogelijk om specifiek foto's van een bepaalde gebruiker op te vragen. Er kon enkel op de unieke id van een foto worden geselecteerd. Nadat Geers met Hyves contact opnam over het probleem, werd het selecteren van foto's in de kaartjesmodule uit voorzorg uitgeschakeld. Ook werd de ontdekker uitgenodigd bij Hyves om het probleem samen te onderzoeken. Geers is erg te spreken over de reactie van Hyves: "Ze hebben het erg professioneel aangepakt", vindt hij. De links naar foto's die hij had verzameld, werken inmiddels niet meer.

Hyves erkent bij monde van woordvoerder Wouter Glaser dat er enige tijd een lek in de kaartjesmodule heeft gezeten. Glaser doet de kwetsbaarheid af als een 'klein lek', dat maar korte tijd heeft bestaan. "Dit lek is ontstaan na een update", stelt  de woordvoerder. "Het is na het melden direct opgelost en was geen groot gevaar voor gebruikers." De Hyves-woordvoerder stelt dat het lek vanzelf aan de orde was gekomen bij een routinecontrole. "Langer dan een dag heeft het niet kunnen bestaan", stelt hij. Dat roept wel de vraag op waarom de beveiliging van de module niet is getest voordat de update werd doorgevoerd.

Volgens woordvoerder Glaser was bovendien 'specifieke technische kennis' vereist om de bug te misbruiken, hoewel er niet veel meer nodig was dan het manipuleren van de url. "Je moet maar net weten dat het openstaat en dat het specifiek op die plek is te misbruiken", stelt Glaser. Momenteel zou de kaartjesmodule weer moeten werken, hoewel het selecteren van een foto uit een album als kaart nog niet mogelijk lijkt te zijn. Volgens Glaser doet Hyves zijn uiterste best om dit soort problemen te voorkomen.

Reacties (88)

zo lek als een mandje....ik ben wel benieuwd of je er uberhaupt eentje aan kan wijzen om je stelling te bevestigen. Ik heb een persoonlijk niks met Hyves maar qua security is het verre van slecht. En geloof me, ik doe software security/pentetratietesten voor mn werk, dus heb er de nodige verstand van.

[Reactie gewijzigd door Data-base op 5 januari 2011 20:11]

Hoe weet jij dat Hyves' security verre van slecht is? Kun je dat onderbouwen? Of praat je net als Saven maar gewoon in de rondte :X

* killingdjef moppert dat niemand tegenwoordig meer iets onderbouwt met feiten.... :'(
vroeger met hyves waren er al "afgeschermde" bestanden toch te bereiken met het manipuleren van url's. maar dat was in de tijd dat mensen met de nodige HTML kennis ook echt iets leuks konden maken van hun hives profiel.

tegenwoordig is het allemaal standaard CSS en kan niemand echt uitblinken met zn profiel omdat het bij iedereen het zelfde is.

dat mensen hun eigen HTML konden schrijven voor hun profiel is trouwens destijds ook al afgeschaft om veiligheidsredenen. ze zijn er druk mee bezig, maar hyves blijft een work in progress.

zowiezo is het een beetje zielige facebook kloon...
We zijn nu heel erg onder de indruk omdat jij software security/penetratietesten 'doet' en geloven je daarom meteen op je blauwe ogen dat Hyves niet zo lek als een mandje is.

Dus zoals al reeds opgemerkt; onderbouw je reactie eens, anders kom je natuurlijk niet zo heel geloofwaardig over.

Als Hyves echt zo heeft gereageerd als in het artikel staat vind ik dat ze deze bug of issue (hoe je het ook wilt noemen) netjes hebben afgehandeld.
Hyves is het meest gebruikte sociale netwerk in Nederland voor het geval je het nog niet wist.
Hyves is het meest gebruikte sociale netwerk in Nederland voor het geval je het nog niet wist.
Nu nog steeds? ik detecteerde een massale exodus toen de Telegraaf de hut overnam. (tot ik m'n account zelf hardhandig om zeep hielp)
Ja nog steeds.
Wellicht dat er mensen hun Hyves hebben opgezegd, maar ten opzichte van hun concurrenten blijft Hyves nog de meeste bezochte website qua community.
(dan reken ik YouTube even niet als community, anders valt die er nog wel boven)
En als je de film over facebook hebt gezien dan heb je ook je bedenkingen of hij wel de man is waar je je gegevens aan toe wil vertrouwen.
Ik heb laatst een film gezien waarin de USA alles heel netjes en keurig behandelde. Ik denk dat we nu maar al onze gegevens aan de USA moeten toevertrouwen.

DUH

FILM = NIET ECHT
Ja wat kan ik hier over zeggen. Een beetje programmeur houdt met dit soort dingen toch al rekening zonder er überhaupt over na te denken?
Nee, zonder na te denken krijg je precies dit soort situaties. Nadenken moet altijd, ook als het simpel lijkt..
Ik vind het inderdaad een klein lek. Hoewel verborgen foto's toch vertoont werden door URL manipulatie zijn de gevolgen van het misbruik niet groot.

Er zijn de afgelopen tijd veel vervelendere bugs in sites langsgekomen. Welke minder netjes en minder snel zijn opgelost.

Ik bedoel bijvoorbeeld:
Kasboek
NEM

Hoewel ik de foto's op mijn sociale site alleen voor vrienden toegankelijk heb gemaakt zet ik er geen foto's tussen die anderen die daar veel moeite voor willen doen echt niet mogen zien.

Wat ik wel mis in het artikel is hoe de URL was opgebouwd en hoe deze te manipuleren was. Was het een volgnummer dat verhoogd of verlaagd moest worden of een hash die gegokt moest worden. Was het duidelijk wie de eigenaar van de foto was.
Waarschijnlijk door een id achter de volgende url te plaatsen: http://www.hyves.nl/kaartje/?mediaId=
Alleen bij mijn eigen foto's lukt dat ook niet meer
Ja wat kan ik hier over zeggen. Een beetje programmeur houdt met dit soort dingen toch al rekening zonder er überhaupt over na te denken?
Rekening: ja, maar bij een enorm complexe applicatie kan er toch nog onverhoopt een bug in kruipen.
Van de beschrijving heb ik anders het gevoel dat er een structurele beveiligingsfout is gemaakt. Het lijkt er namelijk op dat de beveiliging iedere keer opnieuw geimplementeerd moet worden in nieuwe functionaliteit, i.p.v. dat er één functie is, die de beveiliging afhandeld, en die door nieuwe functies gebruikt wordt. En dan vraag je er om dat er dit soort bugs komen.
Correct er is inderdaad een structurele beveiligingsfout gemaakt: De authorisatie laag zit veel te hoog, namelijk in de view laag.

Als dit een model is van een software applicatie:

---------------------------------------
|............... View laag ............... |
---------------------------------------
|........ Business logic laag.........|
---------------------------------------
|.......... Resources laag ............|
---------------------------------------

Dan geeft de resources laag toegang tot het filesysteem (met bijvoorbeeld de genoemde foto's er op), de database, web services waar de app gebruik van kan maken e.d. In de business logic laag zitten de algoritmen die de applicatie maken tot wat hij is. Bijvoorbeeld de code om vriendschappen te maken of verbreken, berichten te plaatsen e.d. In de view laag tenslotte zit de code die het venster of de web pagina opbouwt, icoontjes er bij zet, knoppen aan en uit zet e.d.

Autorisatie is de code die controleert of een gebruiker iets mag. Deze code moet zo laag mogelijk zitten, bij voorkeur in de Resources laag. Als jij als ingelogde gebruiker gewoon geen OS permissies hebt op een bepaalde map in het filesysteem bijvoorbeeld, dan kan de applicatie daar gewoon geen fouten meer mee maken. Je mag er niet bij punt. Stop je die controle hoger, in de business logic laag dan heb je meer flexibiliteit, iemand mag er bijvoorbeeld wel bij, maar alleen als hij een 'vriend' is van de gebruiker waar de map van is. Dat is dan specifieke business logic waardoor het wel in de business logic laag moet zitten.

In de view laag hoort echter *nooit* autorisatie plaats te vinden. Autorisatie in de view laag is bijvoorbeeld voorkomen dat je iets kunt door de knop die je daarvoor moet indrukken niet te tonen... of in het geval van een web pagina door geen link te tonen die die actie uitvoert. Wat je doet als je zelf de url gaat zitten aanpassen is effectief de hele view laag passeren. In plaats van dat je 'netjes' op een linkje klikt maak je zelf je eigen link. Doordat deze mensen de beveiliging in de view laag hebben gestopt kun je dus de hele beveiliging passeren. Waarschijnlijk zal men dit oplossen door een extra check in de business logic laag toe te voegen, maar het is natuurlijk de vraag... als deze fout er in zat, hoeveel meer van dit soort fouten er dan in Hyves zitten.
Dit is niet altijd noodzakelijk een fout, dit kan ook een bewuste keuze zijn. Ik kan ook alle afbeeldingen van iedereen op facebook zien, zolang er maar iemand even de juiste url aan mij doorgeeft (http://sphotos.ak.fbcdn.net/...). Je kan inderdaad zeggen dat dit een fout is, maar dit gebeurt nu eenmaal om performantie redenen.

Het is nu eenmaal niet eenvoudig om hiervoor een performante oplossing voor te bedenken (filters voor elke afbeelding, dynamische afbeelding uit database, ...). Dat maakt een volledige "my album with a lot of photos" pagina gigantisch zwaar om te laden. Op zich is een random naam voor een foto al iets, zo dat je op z'n minst geen "http://facebook.com?profile=0123456789&image=1" dingen kan uithalen.

En door de complexiteit van sociale netwerksites, is de authorisatie van een foto minder voor de hand liggend dan je denkt. Mijn vrienden mogen deze foto zien, maar persoon X niet. Persoon Y die niet mijn vriend is wil ik deze foto ook mee delen, en ik wil ook een permalink met een code in voor mensen die geen facebook hebben, zodat ik hun deze link kan doorsturen en ze toch deze foto mogen zien. Je kan dit soort permissies dus niet instellen op filesystem-niveau.

De enige oplossing is dan om ze in de business logica te steken. En business logica (hoe performant ook. Zie http://developers.facebook.com/blog/post/358) is nog altijd pakken zwaarder dan gewoon files aanbieden vanop een file system.

En het feit dat foto's van verschillende plaatsen komen (door jouw geüpload, getagged bij vrienden, getagged in events, ...) maakt het nog eens complexer. Gooi hierbij het feit dat facebook 1.200.000 afbeeldingen per seconde aanbiedt (Bron: fosdem 2010), en deze authorisatie wordt een duur/moeilijk werkje.

Wat ze hier gedaan hebben blijft inderdaad een bug in hun systeem, waarschijnlijk als gevolg van een slechte ontwerpkeuze in hun architectuur. Maar dat schema van de 3 lagen (ook al is het correct) doet het toch wel een eenvoudiger overkomen dan het is. In elk van die lagen zitten er waarschijnlijk nog een aantal extra lagen met elk hun eigen verantwoordelijkheden.

Als je meer wil weten over facebook en hun architectuur, dit was zeker een interessante talk op fosdem: http://ftp.belnet.be/mirr...ntracks/facebook.xvid.avi
Wat is 'performantie' toch een lelijk woord. Volgens mij is het zelfs geen Nederlands. Laten we dat woord vermijden. Gebruik liever 'prestaties'.
Het is een Vlaams woord. De betekenis is ook echt iets anders dan prestaties.
Maar het hoort toch gewoon in de business logic laag? Het is geen view ding, geen resource ding maar is juist de exacte business logic voor het hyves gebeuren. Zoveel mogelijk laag weg stoppen brengt ook grote risico's met zich mee. Immers in die laag is alles vrij mogelijk, eigenlijk moet je daar zo min mogelijk echte applicatie taken leggen. Ik zeg niet dat we het oneens zijn, want in principe zitten we op 1 lijn maar het is altijd een schemer gebied.
was bovendien 'specifieke technische kennis' vereist om de bug te misbruiken
Volgens mij is het veranderen van de URL één van de allereerste dingen die de gemiddelde scholieren (gem 15 a 16 jaar) die iets meer dan gemiddeld van computers afweten doen.

In ieder geval dat werd er tzt op mijn school 10 jaar geleden wel geprobeerd...
Toen de eerste dynamische pagina's opkwamen.
Iets meer afweten can computers is nog steeds <1% van scholieren.
1% van heel veel is nog steeds veel.
<1% betekend minderdan 1% ;)

Anyway, Toen MySQL + PHP en dynamic content kwam opdagen was het juist de truuk om verborgen pagina's te bekijken.

Op veel websites was dat dan ook mogelijk dus ja ik denk dat elke scholier wel weet hoe je van bepaalde sites de URL moet kunnen lezen. Zie ook de URL van Tweakers ;)
Via de oudere versie van de Hyves app voor Android zat een soortgelijke bug. Ik kon ook foto's zien van anderen die je via je browser niet kon benaderen.

Snel programmeren en bedenken en nieuwe dingen bedenken als Hyves Mobile komt ten goede van de bedoeling: "een profielensite".

Na ook dit gelezen te hebben krijg je wel het gevoel dat Hyves de boel niet echt op orde te hebben...

[Reactie gewijzigd door BramBoos op 5 januari 2011 17:11]

Zelfde was tijdje terug zelfs op desktop.

Als iemand (die wel "bevriend" was met persoon x) mij een foto stuurde van persoon x kon ik 'm met de link van de desbetreffende persoon de foto gewoon zien.
Dat terwijl de hele hyves-profiel van persoon x "privé" en alleen voor vrienden was.

Maarja, als je foto's hebt waarvan je niet wilt dat vreemde ze kunnen zien strooi je er toch ook niet mee op straat? 8)7

Al publiceren ze m'n foto's in de NY-times, niks te verbergen. Anders staan ze niet op hyves/ andere social-networking-sites :)
Bij facebook kan je ook gewoon de afbeeldingsbron kopieren en aan eender wie doorgeven, ook mensen die normaal die foto niet mogen zien (omdat ze geen vriend zijn of geen privacy machtiging hebben).
Dat kan precies hetzelfde bij hyves. Je kan zelfs alleen de username wijizigen als je in de foto's kijkt. Dan heeft de foto ineens de rechten van die andere user. Heel slap
Het heeft natuurlijk niets te maken met verberen. Verder zal ik als reactie op je drogreden mijn welbekende drogreden weer eens van stal halen, als je niets te verbergen hebt dan zou je het ook niet erg vinden dat 500 cameraploegen je 24 uur per dag volgen en alles zonder censuur uitzenden op de TV van je oma/moeder/broer.

Of toch wel? Tuurlijk, iedereen heeft wat te verbergen, we zijn geen emotieloze robots.
Is dat wel een officiele app gemaakt door Hyves zelf? Ik denk het niet want die zijn er (nog) niet. In je geeft zelf al aan dat het met een browser niet te benaderen is op je pc dus lijkt me dat t probleem niet is dat Hyves zijn zaken niet op orde heeft. Hebben ze m.i. namelijk wel.

Maar tis eerder de maker van die app die zijn zaken niet op orde heeft...
Is dat wel een officiele app gemaakt door Hyves zelf?
Ja.
Juist als het een app van een derde is lijkt het mij dat Hyves zijn zaken niet op orde heeft. Die apps werken met API's en een van die API's is dan lek.

Het zou natuurlijk echt van de zotte zijn als je aan de client kant moet gaan controleren of je bepaalde content wel mag laten zien.
Hahaha dat ze het een kleine bug noemen ok. Maar dat het een post bug is.... Kom op zeg dat hoort standaard gecontroleerd te worden...
Haha afgeschermde profielen zijn ook te zien!
zitten wel meer bugs in de hyves site
In Tweakers.net zit ook een veiligheidslek, waardoor mensen die hun naam niet openbaar in hun profiel hebben staan wel met naam- en toenaam in nieuwsberichten opduiken!
In Tweakers.net zit ook een veiligheidslek, waardoor mensen die hun naam niet openbaar in hun profiel hebben staan wel met naam- en toenaam in nieuwsberichten opduiken!
Met toestemming.
Dus wat ze eigenlijk zeggen, is dat ze wel vaker bugs uitbrengen omdat toch niemand weet dat het er is....

Nu ben ik zelf al skeptisch sinds Hyves is overgenomen door Telegraaf?

Zulke dingen zullen weer leiden tot wat deletes van accounts.
Ach elke site heeft zo wel z'n flows, alleen die woordvoerder heeft weinig kaas gegeten van het technische aspect. Elke bimbo met een beetje verstand van kennis (en meer tijd dan een werkende member) had dit ook wel uit kunnen proberen.

/offtopic ; tijd dat ik m'n profiel daar maar eens ga verwijderen, want ik doe er toch geen bal meer mee. Facebook ftw O+

Op dit item kan niet meer gereageerd worden.



Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBSamsung

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True