Lek in app geeft kwaadwillenden toegang tot Facebook-account
De Facebook-apps voor iOS en Android slaan tokens om automatisch in te loggen in plain text op. Daardoor kunnen kwaadwillenden door het kopiëren van een bestand toegang krijgen tot iemands Facebook-account zonder wachtwoord.
Het bewuste bestand .com.facebook.Facebook.plist, zou gekopieerd kunnen worden via een verborgen desktopcomputer of via publieke laadpunten, schrijft de ontdekker van het lek, Gareth Wright. Het vereist geen jailbreak of root-toegang om toegang tot het bestand te krijgen. In het bestand staan tokens, waardoor de applicatie weet op welk account het ingelogd is.
Door het bestand te kopiëren en de Facebook-app te openen, krijgt een gebruiker toegang tot het account van degene onder wiens account het bestand is aangemaakt. Er is geen bescherming tegen: het .plist-bestand kan op elk willekeurig apparaat worden gezet en worden uitgewisseld tussen iPhones en Android. Tweakers.net heeft de claim geverifieerd en het blijkt te kloppen: ook als de iPhone via een wachtwoord is beveiligd, heeft een kwaadwillende toegang tot de bestanden.
Facebook heeft een statement gemaakt dat is gepubliceerd door The Next Web, waarin Facebook het beveiligingsissue bevestigt. Facebook claimt echter dat het alleen mogelijk is op apparaten met root-toegang. Volgens Wright is dat onjuist en vereist het geen root-toegang, omdat het bestand niet op de systeem-partitie staat in zowel iOS als Android. In tegenstelling tot de site vraagt de app niet om verificatie als wordt ingelogd vanaf een andere locatie.
Wright waarschuwt gebruikers om uit te kijken met waar ze hun toestel inpluggen: het kopiëren van het bestand hoeft maar een paar seconden te duren. De iPhone-versie van Dropbox bevat hetzelfde beveiligingslek als de Facebook-app. Een zelfde soort probleem kwam eerder naar voren bij de desktopsoftware van Dropbox. De Android-versie van Dropbox zou wel veilig zijn.
Facebook lijkt niet van plan te zijn het probleem aan te pakken, terwijl Dropbox heeft beloofd snel een update uit te brengen. Facebook zou het probleem kunnen oplossen door tokens versleuteld op te slaan en om extra controle te vragen als een gebruiker inlogt vanaf een nieuw apparaat.
Reacties (68)
Sterk, ze zijn niet eens van plan het snel op te lossen bij facebook. En dat is dan één van de grootste bedrijven ter wereld...
Een van de grootste bedrijven ter wereld ? Hoe kom je hier in hemelsnaam bij ?
Het is maar hoe je het bekijkt. Kijk je naar winst, omzet, hoeveelheid werknemers/locaties of kijk je bijvoorbeeld naar invloed of hoeveelheid gebruikers. In de laatste 2 gevallen is FB zeker wel 1 van de grootste.
Zo veel bedrijven zijn er niet ter wereld met een geschatte waarde van meer dan $100 miljard...
ja lid van de nieuwe internet bubble als "we" niet oppassen.
De algemene perceptie is dan ook dat deze geschatte waarde een complete 'overvaluation' is. Facebook is nog geen 10 jaar oud waardoor het zeer lastig in te schatten is wat de toekomst zal brengen. Kijkt men bijvoorbeeld naar een bedrijf met een gelijke waardering als Berkshire Hathaway, wat al sinds 1962 als hedgefund opereert, dan weet het een vrijwel constante jaaromzet van 143 miljard (2011) te genereren. Als men dit bedrag vergelijkt met de jaaromzet van Facebook ($3,5 miljard in 2011), dan is het niet geheel onlogisch dat men de conclusie trekt dat een tweede .com bubble onafwendbaar is.
[Reactie gewijzigd door databit op vrijdag 6 april 2012 23:23]
Maar, Facebook heeft op dit moment gewoon een hele hoop Goodwill. Dus jou theorie, hoe simpel en daardoor overtuigend hij voor 'men' ook zal klinken, is niet geheel logisch 
waar worden verder conclusies genomen dat de tweede .com bubble onafwendbaar is, zoals jij hier zegt?
waar worden verder conclusies genomen dat de tweede .com bubble onafwendbaar is, zoals jij hier zegt?
Facebook maakt echter wel forse winst, dus zo vanzelfsprekend is een tweede .com bubble niet.
Facebook intereseert zich geheel niets voor privacy. Dat hebben ze al herhaalde malen aangetoond.
Vorig jaar ontdekte een Amerikaans TV station dat bij WiFi-connecties het facebook login user+password zo in plain-text over de lucht ging. Het TV station liet zien dat gewoon bij de starbucks wifi te sniffen via simpele tools, je zo de gegevens kon bekijken en inloggen. Het werd aan Facebook gemeld, maar die hadden geen interesse er wat aan te doen.
Pas nadat andere organisaties amok gingen maken, heeft men het aangepast.
Maar dat dat enkel was op basis van de slechte publiciteit, blijkt nu maar weer. Gewoon diezelfde fout bij de telefoon apps. In dit geval is het gelukkig ietsje minder erg, dan bij de clear-text wifi, maar passwords horen gewoon nooit in plain text opgeslagen te worden.
Als de security te kraken is, of het bestand te koperen en daarna via bruto force te kraken (zoals bij Google Wallet) kun je nog goed argmenteren dat het een lek/hack is. Bij plain text is het botte onwil van de makers.
Vorig jaar ontdekte een Amerikaans TV station dat bij WiFi-connecties het facebook login user+password zo in plain-text over de lucht ging. Het TV station liet zien dat gewoon bij de starbucks wifi te sniffen via simpele tools, je zo de gegevens kon bekijken en inloggen. Het werd aan Facebook gemeld, maar die hadden geen interesse er wat aan te doen.
Pas nadat andere organisaties amok gingen maken, heeft men het aangepast.
Maar dat dat enkel was op basis van de slechte publiciteit, blijkt nu maar weer. Gewoon diezelfde fout bij de telefoon apps. In dit geval is het gelukkig ietsje minder erg, dan bij de clear-text wifi, maar passwords horen gewoon nooit in plain text opgeslagen te worden.
Als de security te kraken is, of het bestand te koperen en daarna via bruto force te kraken (zoals bij Google Wallet) kun je nog goed argmenteren dat het een lek/hack is. Bij plain text is het botte onwil van de makers.
tja, als je gmail alleen via http verbind, dan gaat je logingegevens ook in plain text over de lucht.
Net als zoveel websites.
Net als zoveel websites.
Fatsoenlijke websites laten het gewoon niet toe om een non-SSL verbinding te maken met login beveiligde onderdelen.
Overigens Gmail zelf staat ook standaard ingesteld op SSL.
En aldus de Google FAQ zélf kan het niet eens zonder SSL omdat de verbinding dan geweigerd wordt!? Ik heb zelf geen GMail, dus ik kan het niet testen, maar ik vind het zelfs dan nog een verschil of een gebruiker zelf de beveiliging uitzet of dat die gewoonweg standaard niet aan staat.
Overigens Gmail zelf staat ook standaard ingesteld op SSL.
En aldus de Google FAQ zélf kan het niet eens zonder SSL omdat de verbinding dan geweigerd wordt!? Ik heb zelf geen GMail, dus ik kan het niet testen, maar ik vind het zelfs dan nog een verschil of een gebruiker zelf de beveiliging uitzet of dat die gewoonweg standaard niet aan staat.
[Reactie gewijzigd door Armin op vrijdag 6 april 2012 23:40]
FYi, Facebook gebruikt ook standaard https
Weet je dat zeker? Ik heb het zelf in moeten schakelen via m'n settings.
"Gebruik regulier loginformulier om in te loggen via beveiligde verbinding."
Staat er elke keer als je wilt reageren zonder ingelogd te zijn.
Per definitie zeg jij dus dat deze site niet fatsoenlijk is.
Staat er elke keer als je wilt reageren zonder ingelogd te zijn.
Per definitie zeg jij dus dat deze site niet fatsoenlijk is.
Die app voor de android heet FaceNiff, gratis te downloaden en het werkt nogsteeds.... Lol
@Armin In dit geval wordt het wachtwoord niet in plain text opgeslagen...
Maar de secret info (SBSessionAccessToken, FBSessionKey, FBSessionSecret) verder wel en dat is dus ook niet goed omdat je ook met die info in kunt loggen.
Ik snap de devs dan ook niet die het in hun botte hoofd halen op deze manier de "security" te implementeren! Wanneer worden devs geleerd op een secure manier te programmeren?
Maar de secret info (SBSessionAccessToken, FBSessionKey, FBSessionSecret) verder wel en dat is dus ook niet goed omdat je ook met die info in kunt loggen.
Ik snap de devs dan ook niet die het in hun botte hoofd halen op deze manier de "security" te implementeren! Wanneer worden devs geleerd op een secure manier te programmeren?
Lek in app geeft kwaadwillenden toegang tot Facebook-account
Nobody likes that...Facebook lijkt niet van plan te zijn het probleem aan te pakken
Vind het een slechte zaak. Ik vraag me af waarom ze de tokens in het bestand niet koppelen aan het device. Zodat het alleen op het apparaat werkt waar het bestand op is aangemaakt.
Nog slechter is natuurlijk dat Facebook er momenteel nog niks aan wilt doen. Terwijl het heel gewoon is dat mensen ergens hun telefoon opladen.
Nog slechter is natuurlijk dat Facebook er momenteel nog niks aan wilt doen. Terwijl het heel gewoon is dat mensen ergens hun telefoon opladen.
Er mag in de nieuwe guidelines niet meer gebruik worden gemaakt van de UDID, de unieke identifier van elk iDevice. Zie: nieuws: 'Apple blokkeert apps die apparaat-id opvragen'. Niets mis mee, Facebook moet het gewoon versleuteld opslaan zoals gezegd en/of nieuwe apparaten identificeren net zoals op de desktop al gebeurd.
op android mag het nog altijd wel zover ik weet, dus daar heb je dan in ieder geval wel een goeie, makkelijke en sterke oplossing.
komt alle gezellig naar G+? qua Nederlanders is dat jammerlijk nog een beetje leeg.
inderdaad, maar aan de andere kant vind ik het wel lekker rustig 
Ik zet je wel in mijn kringetje ! G+ is de bom.
Er zit in Chrome (en misschien andere browsers ook wel) een soortgelijk lek. Vul je password ergens in en laat je browser het ding opslaan. Bij terugkomst staat je password ingevuld. Rechtsklik op het password invoerveld; Inspect element. Dan vervang je bij type "password" door "text" en druk je op enter. En zie daar... je password. Dit werkt natuurlijk ook bij andere mensen zodra je fysiek toegang hebt tot hun computer 
Dit soort dingen zijn een goede reden om je password nergens op te slaan...
Dit soort dingen zijn een goede reden om je password nergens op te slaan...
Dit is geen lek. Ga eens naar voorkeuren en dan naar opgeslagen wachtwoorden beheren. Daar staan ze ook plain text. Niet zo raar ook. Hoe kan Chrome het wachtwoord anders voor je invullen?
Je zou verwachten dat dat op zijn minst versleuteld gebeurt toch? Maar goed, misschien ben ik daar ouderwets. Ik vind het gewoon een lek
En ik vind ook dat je als gebruiker een password invoerveld niet ineens zichtbaar mag maken door simpelweg de HTML te veranderen.
Dat steevast naarbeneden modden begin ik ook steeds minder te begrijpen; Het gaat om een probleem met plain-text opslaan van wachtwoorden. Mijn voorbeeld geeft aan dat dit een veel omvattender probleem is dan alleen bij mobiele apps.
In Facebook is het ineens een "lek"; terwijl dit in vrijwel iedere browser op precies dezelfde manier gebeurt. Dat is mijn punt en het zou fijn zijn als men dit onderkent en tja; ongewenst is dat zeker, maar mijn schuld is dat ook niet
En ik vind ook dat je als gebruiker een password invoerveld niet ineens zichtbaar mag maken door simpelweg de HTML te veranderen.
Dat steevast naarbeneden modden begin ik ook steeds minder te begrijpen; Het gaat om een probleem met plain-text opslaan van wachtwoorden. Mijn voorbeeld geeft aan dat dit een veel omvattender probleem is dan alleen bij mobiele apps.
In Facebook is het ineens een "lek"; terwijl dit in vrijwel iedere browser op precies dezelfde manier gebeurt. Dat is mijn punt en het zou fijn zijn als men dit onderkent en tja; ongewenst is dat zeker, maar mijn schuld is dat ook niet
[Reactie gewijzigd door 0rbit op vrijdag 6 april 2012 21:01]
als het goed is worden de wachtwoorden niet als plain text opgeslagen.
met enkel het bestand met daarin de wachtwoorden kun je niets.
dat jij de wachtwoorden gewoon kan zien in de app die de ww lijst heeft aangemaakt is iets anders.
met enkel het bestand met daarin de wachtwoorden kun je niets.
dat jij de wachtwoorden gewoon kan zien in de app die de ww lijst heeft aangemaakt is iets anders.
Het opslaan van credentials binnen browsers is nooit een "lek" geweest. Dit is "de" manier hoe form authentication werkt en een browser kan enkel "nadoen" wat een gebruiker anders met de hand invoert heeft in de password box. Die Harry Potter truk met een dom inspector kan je in dat laatste geval ook gewoon gebruiken om het wachtwoord te tonen. (en zo zijn er nog tig andere mogelijkheden).Je zou verwachten dat dat op zijn minst versleuteld gebeurt toch? Maar goed, misschien ben ik daar ouderwets. Ik vind het gewoon een lek
En ik vind ook dat je als gebruiker een password invoerveld niet ineens zichtbaar mag maken door simpelweg de HTML te veranderen.
Dat steevast naarbeneden modden begin ik ook steeds minder te begrijpen; Het gaat om een probleem met plain-text opslaan van wachtwoorden. Mijn voorbeeld geeft aan dat dit een veel omvattender probleem is dan alleen bij mobiele apps.
In Facebook is het ineens een "lek"; terwijl dit in vrijwel iedere browser op precies dezelfde manier gebeurt. Dat is mijn punt en het zou fijn zijn als men dit onderkent en tja; ongewenst is dat zeker, maar mijn schuld is dat ook niet
Het enige wat een browser kan doen is de locale bestanden encrypten waar de wachtwoorden in opgeslagen zijn, zodat andere "locale" gebruikers hier niet "bij kunnen komen" -- maar het daadwerkelijk afschermen van de wachtwoorden binnen de browser zelf heeft niet veel nut.
[Reactie gewijzigd door Qreed op vrijdag 6 april 2012 22:39]
Met welke sleutel? Of beter gezegd: en waar sla je die sleutel dan op? Om te kunnen werken moet de app met alleen informatie die op de telefoon aanwezig is in kunnen loggen.Je zou verwachten dat dat op zijn minst versleuteld gebeurt toch?
Er zijn maar twee echte oplossingen voor dit probleem:
- Je gebruikers uitleggen dat "Remember password" niet alleen een ontzettend handige functie is, maar ook een verschrikkelijke onveilige functie. Helaas denk ik niet dat het vandaag de dag afgelopen week heb ik voor het eerst Windows 8 geprobeerd waar je standaard de tekst in wachtwoordvelden zichtbaar kunt maken...!? nog een haalbare kaart is om gebruikers zover te krijgen dat ze hun wachtwoord elke keer invullen.
- Dedicated hardware gebruiken (lees: TPM-chip) voor het opslaan van gevoelige informatie.
*kuch* master password
Ach een facebook cookie van een computer stelen is nog makkelijk, daar is zelfs een app voor op Android om alle devices in een netwerk af te scannen op facebook cookies. Volgens mij zijn er gewoon geen praktische oplossingen om dit te vermeiden.
... FB van me iTouch gegooid. Ik zie geen logische reden waarom Facebook de beveiligingslek niet zouden dichten. Erg onprofessionele actie vind ik het.
Je bedoelt iPod touch.
Heb het vermoeden dat de afdeling marketing een stokje heeft gestoken voor extra beveiliging.. de klant moet immers zonder extra handeling meteen ingelogd zijn, want stel je voor dat ze gebruikers verliezen die het invoeren van een code teveel gedoe vinden >.<
Als het mogelijk is om bestanden te downloaden van een gelockte iphone, dan vind dat er ook een taak voor apple is weggelegd. Ik krijg steeds minder vertrouwen er in dat de iphone/ipad veilig zijn.
Dit heeft niets te maken met Apple, maar met software die door derden zoals Facebook is geschreven.
Denk dat Apple eerder controleert of het hun product uitkomt. Is het nuttig, verkopen we daardoor meer? Plus dat een bedrijf die volgens Apple veilig is verklaard niet die hele rompslomp van checks hoeft te doorlopen voordat ze een app in de store zetten.
Terugkomend op financieel plaatje, stel dat Apple de Facebook app verwijderd, gros van de Apple bezitters zal eerst Apple benaderen waarom ze niet meer op Facebook komen.
Enerzijds zullen er veel klanten zijn die het toejuichen (Apple waakt over de veiligheid) en anderzijds een legioen klanten (die niet zoals ons dit soort nieuws volgen) die zeggen: neem geen iPhone want Facebook werkt niet!
Terugkomend op financieel plaatje, stel dat Apple de Facebook app verwijderd, gros van de Apple bezitters zal eerst Apple benaderen waarom ze niet meer op Facebook komen.
Enerzijds zullen er veel klanten zijn die het toejuichen (Apple waakt over de veiligheid) en anderzijds een legioen klanten (die niet zoals ons dit soort nieuws volgen) die zeggen: neem geen iPhone want Facebook werkt niet!
Je weet dat de lek bij Facebook zit? Of vind je ook dat het Apple's schuld is dat het bij Android (volgens jou) fout gaat? Of ben je het wel met me eens dat het lek in het systeem van Facebook zit.
[Reactie gewijzigd door ZpAz op vrijdag 6 april 2012 21:55]
Nee, van een gelockte telefoon hoor je geen data af te kunnen halen.
Bij Windows Phone of Symbian moet je ook eerst de unlock code intoetsen alvorens aan de slag te kunen met spectievelijk Zune of NokiaSuite/MassStorage.
Bij Windows Phone wordt zelfs express de telefoon vergrendeld zodra je de USB insteekt in de PC om de gebruiker te dwingen de PIN in te geven.
Als bij iOS je data kunt kopieren van een gelockte telefoon zonder eerst een PIN te hebben ingeven, is dat wel degelijk ook een fout van Apple.
Bij Windows Phone of Symbian moet je ook eerst de unlock code intoetsen alvorens aan de slag te kunen met spectievelijk Zune of NokiaSuite/MassStorage.
Bij Windows Phone wordt zelfs express de telefoon vergrendeld zodra je de USB insteekt in de PC om de gebruiker te dwingen de PIN in te geven.
Als bij iOS je data kunt kopieren van een gelockte telefoon zonder eerst een PIN te hebben ingeven, is dat wel degelijk ook een fout van Apple.
Maar dat is dan ook niet het geval, het is aangepast in het originele bericht. Je moet het device dus wel degelijk unlocken voordat je er daadwerkelijk bij kunt.
"Update: While Wright's initial post claims that the issue affects "locked passcoded unmodified iOS Devices" when connected to a PC set up to capture the .plist file, The Next Web has now updated its report to indicate that in its testing the technique does not work on devices protected with a passcode."
"Update: While Wright's initial post claims that the issue affects "locked passcoded unmodified iOS Devices" when connected to a PC set up to capture the .plist file, The Next Web has now updated its report to indicate that in its testing the technique does not work on devices protected with a passcode."
Als bridgestone een verkeerde rubber gebruikt voor jouw winterbanden waardoor deze slippen. Is het dan de schuld van de fabrikant van jouw auto?
Nee, maar je vergeet hoe de gemiddelde consument denkt. Ik heb product x gekocht waarmee ik product y gebruikt. Product y heeft een gebrek.. consument belt/klaagt over product x voordat consument naar de echte "boosdoener" stapt.. product y.
Voorbeeld: je koopt een stofzuiger, de meegeleverde stofzak is vol (ja, een met stofzak dus geen type dyson geval) en je haalt een nieuwe. Je staat vrolijk de stofnestjes bij je pc weg te zuigen als je merkt dat je stofzuiger ineens moeite heeft met de nestjes.. De stofzak kan het niet zijn, die is net nieuw! Dus is het de stofzuiger zelf. Of zou het misschien toch de stofzak zijn?
Voorbeeld: je koopt een stofzuiger, de meegeleverde stofzak is vol (ja, een met stofzak dus geen type dyson geval) en je haalt een nieuwe. Je staat vrolijk de stofnestjes bij je pc weg te zuigen als je merkt dat je stofzuiger ineens moeite heeft met de nestjes.. De stofzak kan het niet zijn, die is net nieuw! Dus is het de stofzuiger zelf. Of zou het misschien toch de stofzak zijn?
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
