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 , , 29 reacties

Elke kwaadwillende kon tot een week geleden afgeschermde foto's op Instagram openbaar maken door een lek in de beveiliging van de sociale fotodienst. Dat vereiste slechts een paar regels code. Instagrams moederbedrijf Facebook heeft het lek inmiddels gedicht.

Het lek, een zogenoemde cross site request forgery, vereiste slechts de regels code die een verzoek naar Instagram stuurde om het account van privé op openbaar te zetten. De ontwikkelaar die het lek ontdekte, kopieerde dat verzoek uit de Android-app van Instagram en paste dat toe op de browserversie. Omdat de browserversie geen zichtbare instelling heeft om posts van privé op openbaar te zetten, gebeurde dat op de achtergrond zonder dat de gebruiker er iets van merkte. Bovendien vereiste de actie geen extra stap, waardoor de gebruiker erop gewezen kon worden dat privé-foto's voortaan openbaar toegankelijk zouden zijn.

Een kwaadwillende had de code op een site kunnen embedden om vervolgens ingelogde gebruikers ertoe te verleiden naar die site te gaan. De ontwikkelaar lichtte Facebook in augustus in. De eerste fix in september bleek te omzeilen, waarna het lek op een andere manier moest worden gerepareerd. De bevestiging dat het lek compleet gedicht is, kwam vorige week. Instagram checkt nu de user agent waar het verzoek vandaan komt, waardoor de instelling niet meer op de browserversie kan worden gewijzigd. Bovendien zit er een extra check op de instelling, waardoor gebruikers bevestigen dat ze inderdaad hun foto's openbaar willen zetten. De ontwikkelaar heeft een geldbedrag gekregen voor het melden van het lek.

De ontwikkelaar kwam het lek op het spoor toen hij op zoek was naar kwetsbaarheden in de iOS- en Android-apps van Instagram. Het is onduidelijk of kwaadwillenden op een eerder moment het lek hebben ontdekt en misbruikt. Omdat het lek geen toegang verschafte tot het account zelf, zouden gebruikers de controle over het account hebben gehouden en in de app het account weer op privé hebben kunnen zetten.

Code om lek in Instagram te misbruiken

Moderatie-faq Wijzig weergave

Reacties (29)

Instagram checkt nu de user agent waar het verzoek vandaan komt, waardoor de instelling niet meer op de browserversie kan worden gewijzigd.
Maar is dit niet gewoon heel makkelijk te omzeilen/faken?
Nee. Het gaat hier om een CSRF. Dat wil zeggen dat een gebruiker/slachtoffer op een specifieke pagina terecht moet komen, of ergens op moet klikken om de aanval uit te voeren. Er wordt nu gecontroleerd dat de user agent diegene van de mobile app is. Een gebruiker zou dus al de user agent van zijn of haar gewone browser moeten wijzigen naar die van de app voor er een nieuwe aanval kan uitgevoerd worden.

[Reactie gewijzigd door StijnH op 10 februari 2014 19:37]

Als het alleen maar met die user-agent string zou zijn (wat dus niet zo is), valt het volgens mij wel makkelijk te ontwijken.

Je kan toch een pagina maken met daarin wat PHP, cookie stelen van gebruiken, dan die CSRF uitvoeren vanop je eigen server met een eigen custom made user-agent?

Of denk ik nu te simpel?
En hoe steel je dat cookie precies?

Eventueel kan de app natuurlijk ook een gehashde username/app-id/.... als user agent gebruiken.
Misschien moet je zelf ook even de gevonden sites doorlezen en erachter komen dat dat hier compleet niet van toepassing is. Cookies kun je in beginsel alleen stelen door javascript code te injecteren op de websites waar de cookies voor dienen, of door code te runnen buiten de browser om op de PC van het slachtoffer. Een eventuele derde mogelijkheid is natuurlijk een lek in een browser te exploiten, maar dan draai je ofwel een enorm verouderde browser ofwel je hebt toegang tot een zero day exploit.

En serieus, "lmgtfy"? Hoe lame is dat.

Bottom line is dat een UA check hier in feite al voldoende is. Ja, natuurlijk kun je dat aanpassen, maar waar het hier om gaat is dat code op een website dat niet aan kan passen in jouw browser op het moment dat je die website bezoekt.

[Reactie gewijzigd door .oisyn op 11 februari 2014 01:15]

Ja precies, user agent is makkelijk te vervalsen.

Vandaar waarschijnlijk dit:
Bovendien zit er een extra check op de instelling, waardoor gebruikers bevestigen dat ze inderdaad hun foto's openbaar willen zetten.
Maar of het nou helemaal veilig is, is nog maar de vraag.
tuurlijk, daarom ook dat dat niet de enige aanpassing is. Zo moet de gebruiker nu ook zelf een bijkomende bevestiging geven dat hij/zij effectief de verandering wenst door te voeren.
Vind ik vrij lang, bijna 5 maanden om dit lek te dichten...
Facebook heeft drie keer moeten proberen om het volledig op te lossen. Dan valt vijf maanden nog wel mee. De eerste keer meldde de ontwikkelaar ook de de bug daadwerkelijk verholpen was, dus vanaf dan begint het hele proces opnieuw.

Zie ook de tijdslijn op zijn website:
  • August 22th, 2013: Initial report with a proof of concept sent to Facebook.
  • August 28th, 2013: Facebook informed that the vulnerability has been escaled to Instagram’s development team.
  • September 6th, 2013: Response from Facebook asking for confirmation that issue has been resolved.
  • September 6th, 2013; Reply to Facebook confirming fix.
  • September 16th, 2013, New report to Facebook with a proof of concept to bypass de initial fix.
  • September 30th, 2013: Response from Facebook informing about the bug bounty reward’s details.
  • December 16th, 2013: Facebook sent the bug bounty reward.
  • January 23th, 2014: Report to Facebook about some weird behaviours and a possible new bypass in their second fix.
  • February 4th, 2014: Response from Facebook confirming the application finally has been properly patched.
  • February 4th, 2014: Report closed.

[Reactie gewijzigd door Alfredo op 10 februari 2014 19:15]

De titel is nogal zwaar voor een XSS aanval. Zo moet de target persoon deze code uitvoeren om aangevallen te worden. Nou hoeft dit niet moeilijk te zijn maar is het nog steeds een grote stap.

De titel probeert de aanval nogal te dramatiseren. Dat krijgen we dus met pop-journalistiek

[Reactie gewijzigd door shadylog op 10 februari 2014 20:55]

Als het de code is die in de afbeelding van de post staat dan hoef het target niet eens iets te doen. Gewoon stukje malicious JS laden en POST request maken. Apart dat er geen XSRF token bij zit :S, verbaast me dat zo'n groot bedrijf zoiets simpels mist, dat is echt web security 101 :(.
Toch goed van FB dat de ontdekker een geldbedrag heeft ontvangen. Dat gaat wel eens anders :P
Veel grote techbedrijven hebben wel een bug-hunting bounty. Kijk naar Google, Facebook, Mozilla, Github, iedereen aangesloten bij HackerOne (gesponsord door FB en MS) en vele anderen.
Bij de iets kleinere bedrijven loop je alleen volgens mij nogal snel het risico dat ze bang worden dat je wellicht al iets hebt aangericht, en bijvoorbeeld bij onderwijsinstellingen waar de IT-afdeling vrij klein is acht ik het ook niet onmogelijk dat de systeembeheerder gelijk in zijn eer gekwetst is als je meldt dat er iets mis is, waardoor je als student ook gelijk in de problemen zit.

Prima hoor, white hats, en als het bij een bedrijf als Facebook, Google of Mozilla is, zou ik in een dergelijk situatie ook wel het lek melden en er verder mijn mond over houden, maar bij een Nederlands bedrijf oid. wat iets kleiner is zou ik bij het per ongeluk ontdekken van een lek al nadenken of het wijsheid is om mijn mond te houden voor ze mij ergens van beschuldigen, of me gaan aanklagen omdat ik kennelijk in het systeem ben geweest.
Moeilijke zaak.
Ik heb een keer bij een shared hostingbedrijf bugs gemeld dat ik onbeperkt database kon aanmaken, zoveel opslag gebruiken als ik wil e.d. Reactie was dat ik er gebruik van mocht maken, verder waren ze er niet in geintresseerd hoe en wat. Later kwam ik er ook achter dat heel de server voor alle gebruikers erop gewoon leesbaar was, toen heb ik niet meer de moeite genomen om het te melden, maar heb me email er maar vanaf gehaald.
Toch weer een lesje om heel goed na te denken wat je op zo'n 'sharing' toestand zet. Echte privédingen moet je natuurlijk nooit van je hele leven online zetten, tenminste niet op een social network/file sharetoestand. Je gdrive/dropbox heel misschien, maar compromiterende foto's zou ik dat niet toevertrouwen. Toch nog zat mensen die hele pikante dingen op fb zetten, alleen voor echte vrienden. En dan komt er een hacker, of je zet zelf per ongeluk een vinkje verkeerd en je staat voor de hele wereld in je tijgertanga op het net...lekker slim.
Jij gaat er van uit dat je zelf de foto's opzet.
Het komt toch vaak voor dat iemand anders een foto van je maakt en die vervolgens op internet zet. Vaak is de insteek onschuldig, alleen de interpretatie door derden is altijd maar afwachten.

Zelf heb ik liever niet dat anderen foto's van me maken, gezellig of niet.
Goed punt.
Gelukkig is dat in mijn geval niet zo heel erg. Ik doe geen dingen waar ik achteraf spijt van heb. Nooit gedaan. Wel rare dingen gedaan uiteraard, maar nooit iets waarvoor ik me zou moeten schamen of voor een rechter verantwoorden.
Je bent er uiteindelijk wel zelf bij. Als je van die vrienden hebt die elke drol op internet zetten en je bent op pad om gekke dingen te doen, moet je maar een beslissing nemen. Vertrouw je ze of niet. Simpel zat. Beetje nadenken. Maar ja, ik ben nu geen 17 meer, dus ik zit niet in die omstandigheden. Gelukkig maar. Geen idee wat ik ermee zou doen op die leeftijd. Nadenken is in ieder geval niet de grootste hobby in die leeftijdsgroep. En dat mag ik zeggen als ouwe lul. Ben ook zo oud geweest. Alleen niet zo dom als het gros van mijn leeftijdsgenoten toen.
dit kon ik het begin met Facebook accounts ook. kun je ook gemakkelijk de private status omzeilen en alles openbaar maken. werkte weliswaar iets anders, maar was geen rockte science
Meer over CSRF:
https://www.owasp.org/ind...te_Request_Forgery_(CSRF)

[Reactie gewijzigd door Squ1zZy op 10 februari 2014 22:23]

Konden alleen kwaadwillenden dat ja? Interessant :-)
Dat is net het hele idee achter dit soort berichten. Een beveiligingsonderzoeker vindt een lek, werkt samen met de desbetreffende partij, krijgt eventueel een geldsom uitbetaald en nadat alles opgelost is wordt het lek uit de doeken gedaan.
Ja precies. Maar dat uit de doeken doen van zoiets kan dan ook gelijk weer de aanleiding zijn voor een andere kwaadwillende om op zoek te gaan naar een lek in de patch van het vorige lek, om het zo maar even te zeggen. Er wordt immers uit de doeken gedaan hoe ze het lek gepatched hebben, dus is het voor een kwaadwillende niet zo moeilijk om die patch weer ongedaan te maken lijkt me.
Een patch ongedaan maken?
Je bedoelt misschien een andere mogelijk probleem vinden.
Ja, hoe je het ook noemen wilt. Dat bedoelde ik inderdaad.
Niks mis mee lijkt mij? Het lijkt mij juist een probleem als organisaties zoals de NSA dit soort grapjes willend gaan misbruiken om data van je weg te trekken, om zo maar het een en ander te noemen..

Hulde aan deze mensen, dus. Vooral zo doorgaan.
Tuurlijk joh, ach het is gedicht dus laten we het maar in de doofpot stoppen... Ik vind het zeer belangrijk dit soort dingen te weten, wellicht moest je alles weer privé zetten.

Ik gebuik zelf geen Instagram maar toch.

[Reactie gewijzigd door [Remmes] op 11 februari 2014 04:58]

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