Software Dropbox bevat kwetsbaarheid

De software van opslagdienst Dropbox bevat een kwetsbaarheid waardoor het ontvreemden van het host-id genoeg is om toegang tot alle bestanden te krijgen. Beschikking over iemands gebruikersnaam en wachtwoord is niet vereist.

Beveiligingsonderzoeker Derek Newton ontdekte de kwetsbaarheid. De clientsoftware van de populaire opslagdienst Dropbox, die gebruikers bestanden laat synchroniseren met de Dropbox-servers, gebruikt een sleutel met de naam 'host_id' om een computer aan een account te koppelen. Het host_id is opgeslagen in een configuratiebestand met SQLite als bestandsindeling. Opvallend is dat het host_id niet is gekoppeld aan gebruikersnaam of wachtwoord.

Wie de host_id-waarde of het SQLite-bestand van maximaal 100kB kopieert, kan hiermee ongemerkt inloggen op iemands Dropbox-account. Zowel het lezen als het schrijven naar bestanden is mogelijk. De software attendeert een gebruiker er niet op dat zijn bestanden vanaf een andere computer toegankelijk zijn, zelfs niet wanneer twee computers met hetzelfde host_id op hetzelfde moment een verbinding met de Dropbox-servers hebben.

Dropbox stelt tegenover The Next Web dat het niet om een beveiligingsprobleem gaat, omdat nog steeds toegang tot iemands computer vereist is om toegang te krijgen tot de bestanden. Het feit dat er maar één klein bestand hoeft te worden gekopieerd om vanaf een externe locatie toegang te krijgen tot iemands bestanden, kan echter wel degelijk interessant zijn voor makers van malware, stelt ontdekker Newton. Het configuratiebestand bevindt zich altijd op dezelfde locatie, waardoor het eenvoudig te kopiëren is.

Bovendien lost het wijzigen van een wachtwoord of het opnieuw installeren van Dropbox externe toegang niet op. Pas als de computer waarvan het configuratiebestand is gekopieerd, handmatig wordt verwijderd via de Dropbox-website, wordt de toegang ongedaan gemaakt.

Reacties (96)

[CoolGamer]

Het principe van een host_id is vergelijkbaar met een sessieid die op de meeste websites wordt gebruikt om je ingelogd te houden tussen verschillende bezoeken. Dat wordt opgeslagen in een cookie en is ook makkelijk te onderscheppen, vooral als je toegang hebt tot die pc.

Zelf ben ik er daarom van overtuigd dat dit principe niet onveiliger is dan een gemiddelde website waar je log-in wordt onthouden. Ze zouden de beveiliging kunnen verbeteren door bijvoorbeeld te onthouden waarvan ingelogd is (zoals bijvoorbeeld bij GMail wordt gedaan) of het host_id na een bepaalde periode te laten verlopen. Ook zouden ze het id op een veiligere locatie binnen het account van Windows kunnen opslaan, zoals bijvoorbeeld voor de wachtwoorden die opgeslagen zijn binnen Internet Explorer gebeurd.

[Reactie gewijzigd door CoolGamer op 31 juli 2024 01:38]

[Sn0zz]

Enige nadeel van hoe DropBox zoals ik het nu zie is dat je niet makkelijk een password oid kan aanpassen zodat een eventuele indringer na binnendringen geen toegang meer heeft. Voor de rest is het zoals door anderen eerder gezegd al een probleem als iemand sowieso op je systeem kon.

[Jo-W]

Het orginele artikel is duidelijker dan wat hier staat...
Het probleem is niet dat er credential(s) gestolen kunnen worden (dit kan immers niet vermeden worden, ook niet met wachtwoord dialogen) maar dat het toevoegen van een client geen notificatie aan de gebruiker geeft en dat na het veranderen van een wachtwoord alle clients nog steeds toegang hebben.

[HollowGamer]

Je kunt het wel zien op hun site, bij sessions.

[air2]

Het is ook meer het feit dat je je host_id niet (makkelijk) kunt resetten (zoals bij een username en password) dat het onveilig maakt. Want mijn username en wachtwoord zijn ook opgeslagen in m'n dropbox client.
Overigens is het wel vreemd dat deze informatie, in windows, versleuteld wordt met b.v. het useraccount.
Echt heel veilig ontworpen is het dus niet.

[Umbrah]

In feite lijkt dit heel erg op hoe een "token" gegeven wordt aan een applicatie dmv. OAuth, op deze manier kun je stellen dat Twitter en/of facebook, indien de cliënt applicaties hun gegevens knullig wegschrijven (wat er natuurlijk in zit), ook zo lek als een mandje zijn.

Het probleem hier is niet zozeer het HOE of WAT wordt weggeschreven, SQLite is een deugdzame oplossing, en "tokens" zijn dat ook. Het probleem is hier meer de implementatie: die SQLite database unencrypted opslaan is natuurlijk gekkenwerk. Een simpele truecrypt/PGP-constructie had al wat meer volstaan, met uiteraard de key daarvoor hardcoded in de client of obfuscated.

[GrooV]

Dropbox werkt ook met OAuth volgens mij

[latka]

Password hardcoded of obfuscaten is dus net zo veilig als helemaal niets doen. Enige veilige methode is de boel crypten met een door de gebruiker ingevoerd wachtwoord wat niet opgeslagen wordt.

[NTAuthority]

Een sleutel geassocieerd met het gebruikersaccount zelf is wel een veilige (en makkelijke, voor de gebruiker) methode, ware het niet dat de meeste gebruikers hun gebruikersaccount a) nooit vergrendelen, b) zonder wachtwoord laten en c) automatisch inloggen.

[i-chat]

ik snap dat idd ook niet, je zou toch verwachten dat ze gebruik zouden maken van een sessie token die bijv op tijd gelimmiteerd is, lees: dat je per inlog sessie een nieuwe token krijgt.

[niqck]

Storm in een glas water. Is zoals met SSH gebruik maken van een key zonder paswoord om zo op systemen in te kunnen loggen zonder paswoord. Dat is wat men bij veel bedrijven doet.

Om aan je host_id te komen heeft iemand toegang nodig tot je PC dus ben je eigenlijk al gecompromiteerd. "Once you're owned, you're owned, Dropbox or not!"

[TheNephilim]

Ja vind ik ook, een beetje overdreven allemaal! Als er al toegang tot je pc is, dan kunnen ze sowieso bij deze bestanden via de map Dropbox.

Word (bijv.) je laptop gestolen met daarop dropbox en dus je Host_id, dan verwijder je die toch bij toegestane PC's (zoiets kan toch?)

[Keypunchie]

Het gaat hier eerder om het scenario dat iemand langs je computer loopt, of een trojan heeft geinstalleerd en je gegevens steelt.

Vervolgens kan hij op zijn eigen computer in alle rust jouw dropbox documenten doorspitten Als je laptop niet gejat is, zul je ook je computer niet verwijderen.

Als je een trojan ontdekt, dan veeg je misschien je harde schijf schoon en wijzig je al je wachtwoorden, maar dan heeft de kwaadwillende hacker dus nog steeds toegang tot je dropbox documenten.

[Anoniem: 311111]

Sterker nog, privatekeys worden over het algemeen als veiliger gezien dan wachtwoordauthenticatie.

[bzerk]

ssh met public/private keys wordt idd veel gebruikt binnen bedrijfsnetwerken. Maar aan de private key heb je weinig buiten het bedrijsnetwerk omdat de bedrijfs systemen niet publiekelijk benaderbaar zijn. Het dropbox host_id kan dus echter gebruikt worden door iedereen op internet om bij je data te komen.

[LegacyCode]

Dat was allanger duidelijk. De linux command line client vereist geen gebruikersnaam en wachtwoord. Je moest een url die de host-id bevatte meegeven.

[Ventieldopje]

Dus toegang tot de pc is ook niet eens nodig, gewoon het netwerk sniffen en je bent er ook. Dit hadden ze wel in het artikel mogen vermelden!

[Plofkotje]

Nee, verbindingen naar Dropbox gaan over SSL.

[fdh]

als de url waarmee je op dropbox connecteerd de host_id echt als parameter heeft staan (ik gebruik het niet, dus ben niet zeker), dan kan je volgens mij wel sniffen.
De url zelf gaat clear text zijn.

[kvdveer]

Nee hoor, urls gaan netjes encrypted over de lijn, net als cookies, user agent en alle andere HTTP headers.

[Anoniem: 296748]

Een klein vraagje; als die urls encrypted zijn, hoe weet jouw ISP dan met wie je verbonden wil worden?

Knappe jongen als jij even een url gaat encrypten en vervolgens gaat gebruiken...



(bottomline; urls worden niet geencrypt)

[Anoniem: 311111]

Via het IP-adres? De parameters van een HTTP Request zijn HTTP-gebonden, hoeft de ISP verder niets van te weten. Een programma kan gewoon met het IP connecten en de host in de Host: header opnemen.

Bottomline: Het enige wat de ISP hoeft te weten is de IP/host, de locatie en dergelijke zijn een HTTP-ding en gaan mooi over SSL.

[Reactie gewijzigd door Anoniem: 311111 op 31 juli 2024 01:38]

[ThomasG]

Waar heb jij die onzin vandaan? De urls worden wel zeker geencrypt, het enigste wat er gebeurt is dat de host (ip van de server) unencrypted wordt doorgegeven, maar dat is ook logisch. De URL (wat meer is dan alleen de hostname) wordt gewoon encrypted doorgegeven.

[McRubz]

Gokje hoor, maar is het niet zo dat eerst:

• verbinding wordt gemaakt met de server (bijv. tweakers.net)
• er een beveiligde verbinding wordt opgezet
• de request (nieuws/73737/software-dropbox-bevat-kwetsbaarheid.html) versleuteld wordt verzonden?

[Anoniem: 351392]

nee de ssl handshake vind altijd plaats voordat ook maar enig verkeer over de verbinding gaat

[kevinv2u]

Binnen sommige bedrijven heeft iedere user 'Local Admin' rights waarna je dus gewoon even in de AppData\Roaming folder (Win7) van iemands profiel op zoek kunt gaan naar config.db om toegang te krijgen tot iemands dropbox folder.

[Reactie gewijzigd door kevinv2u op 31 juli 2024 01:38]

[_Eend_]

Waarom zou je dan moeilijk gaan doen? Je kunt als local admin dan ook bij de documenten van andere gebruikers..

[nehal3m]

"Dropbox stelt tegenover The Next Web dat het niet om een beveiligingsprobleem gaat, omdat nog steeds toegang tot iemands computer vereist is om toegang te krijgen tot de bestanden."

Physical acces = root access, zeggen we dan maar. Echt een adequate respons vind ik het niet, veel mensen realiseren zich het voorgaande niet en als men gevoelige data op die manier deelt komen er veel in de problemen. Het zou Dropbox sieren om wat code te schrijven die het aangeeft wanneer er andere computers zich aanmelden op een bepaalde Dropbox, zoals Windows Live Messenger dat bijvoorbeeld tegenwoordig doet.

[Ventieldopje]

Zoals ik hier boven ook al aangegeven heb, je hebt maar 1x toegang nodig tot iemand zijn account voor een niet al te lange tijd om schade toe te doen.

Bovendien als het waar is wat LegacyCode zegt:

Dat was allanger duidelijk. De linux command line client vereist geen gebruikersnaam en wachtwoord. Je moest een url die de host-id bevatte meegeven.

Dan is het nog veel slechter gesteld met de beveiliging als het artikel doet vermoeden, zo kun je dus makkelijk het netwerk sniffen op zoek naar de host key

[nehal3m]

Ja, daar heb je gelijk in. Wellicht is een total overhaul nodig wat het inlogsysteem betreft.

[Plofkotje]

Dat laatste is onzin, de verbinding naar Dropbox is geSSL't en Dropbox checkt het certificaat van de server.

[ZpAz]

Lijkt me wel een kwetsbaarheid? Bij het authenticeren zou ook het wachtwoord en gebruikersnaam meegestuurd moeten worden, zo lastig zal dat ook niet te maken zijn.

Hoop wel dat het snel gefixt wordt, vind het een fijne service.

[Gerco]

En waar ga je die dan opslaan? In diezelfde config database natuurlijk! Encrypted zeg je? De key moet ook op de machine staan tenzij je elke keer dat je inlogt je dropbox password wilt intikken.

Wanneer iemand toegang heeft tot je machine kunnen ze dit soort dingen doen en daar doe je weinig tegen. Wat je zou kunnen doen is de files op disk encrypten met Truecrypt of EFS (en dan geen auto login/mount aanzetten). Zelfs als je dat doet is je beveiliging nog steeds waardeloos wanneer iemand je machine aantreft zonder jou erachter en je scherm is niet gelocked.

Bescherming van lokale files is een zaak van het OS en niet van applicaties. Als je OS je hier niet tegen beschermt kan een applicatie het namelijk al helemaal niet. Je username en password meesturen zou het probleem zelfs flink verergeren, dan heeft de aanvaller namelijk je password ook nog eens en is het niet genoeg om de computer de toegang tot dropbox te ontzeggen.

[StiGMaTa]

De client software zou op zijn minst de pc-naam mogen meesturen (of ander hardware-id) en deze koppelen. Voor niet-gekoppelde hardware telkens een wachtwoord vragen bij het inloggen tot de apparaten gekoppeld zijn.
Dit valt ook te omzeilen, maar is toch al wat moeilijker dan een bestand te kopiëren.

[Keypunchie]

Liefst een hash van wat "unieke" gegevens. Anders valt het net iets te makkelijk te spoofen.

Naam van de PC, modelnummer van de harde schijf, MAC en nog wat van die dingen. Valt inderdaad ook te achterhalen, maar dan moet een kwaadwillende en eerst gaan reverse engineeren welke gegevens allemaal worden opgevraagd en dan die gaan spoofen.

[robvanwijk]

Of je schrijft je eigen client (is het protocol openbaar (of makkelijk te reverse-engineeren)?). Dan hoef je alleen de hash te onderscheppen en kun je die gewoon meesturen. Hoe dat ding berekend wordt maakt dan niks meer uit.
Met gebruik van een debugger (en veel geduld) is het misschien zelfs wel mogelijk om simpelweg een breakpoint te zetten tussen het genereren van het "ik wil aanmelden" netwerkpakketje en het daadwerkelijk versturen ervan. Als je dat lukt kun je de waarde doodeenvoudig overschrijden...

@Gerco hierboven: als je (een hash van) het password meestuurt los je in eerste instantie niks op. Maar dan zal het veranderen van het password in elk geval forceren dat het "token" waarmee succesvol geauthenticeerd kan worden van waarde verandert. Oftewel: password wijzigen en je bent weer de enige die toegang heeft. Het lost het probleem dan wel niet op, het maakt het wel kleiner.

* robvanwijk is blij dat ik (uit principe) niks op Dropbox heb staan wat echt geheim moet blijven (maar dat bestanden overschreven/verwijderd kunnen worden is wel ontzettend vervelend...).

[Gerco]

Je hebt gelijk met die wachtwoordhash natuurlijk. Het liefst logt die client in met een challenge-response waarbij de response uit (bijvoorbeeld) hash(challenge + host_id + passwordhash) bestaat.

Password is niet plain text bekend dus kan niet gejat worden en wanneer het password verandert zijn alle clients meteen uitgelogd. Als bonus kun je het host_id en password nog steeds niet sniffen mocht er iemand een SSL MITM voor elkaar hebben gekregen.

Je kan echter als attacker nog steeds gewoon die config.db jatten en als iemand anders inloggen. Daar veranderen bovenstaande fratsen helemaal niets aan.

[exyll]

Wat een onzin allemaal. Alle twitter desktop apps werken met een soortgelijk token. De app geef je via oauth toegang. Deze app krijgt dan zijn eigen access token. Je twitter wachtwoord wijzigen heeft hier ook geen effect op. Pas als je access op de twitter website revoked voor het specifieke token dan werkt de app niet meer. Deze tokens kun je ook achterhalen en dus ook kopieren.

[Haas_nl]

Als je nu zorgen maakt moet je toch eens afvragen of het uberhaupt wel slim is om belangrijke en prive bestanden via internet beschikbaar te maken.

[geekeep]

'slim' is een ietwat apart begrip om dit te beoordelen. Het is tegenwoordig gewoon noodzakelijk om te synchroniseren tussen alle verschillende apparaten die consumenten hebben om niet constant met USB sticks te moeten zeulen.

Ikzelf gebruik Dropbox voornamelijk voor school. Ik werk op verschillende PCs en laptops, en ben het echt beu geworden om constant overal (handmatig) de meest up-to-date versie van alle gemaakte bestanden te hebben. Daarnaast zorg ik er wel voor dat er geen gevoelige bestanden in de Dropbox folder staan. Ook sync ik alleen bestanden die ik ook daadwerkelijk op meerdere locaties nodig heb en laat ik sowieso andere documenten als foto's e.d. buiten beschouwing.
Als ik kijk naar de hoeveelheid USB sticks die ik in achtergelaten PCs heb gevonden, is Dropbox misschien niet eens zoveel onveiliger dan een fysieke hard-copy van je bestanden mee te dragen.

Ik ben het wel eens met de vraag of het online beschikbaar maken van bedrijfsbestanden, met een externe gratis dienst nota bene, wel verstandig is. In dit geval zou het bedrijf beter kunnen investeren in een synchronisatie service binnenshuis.

[E-B]

Als ik kijk naar de hoeveelheid USB sticks die ik in achtergelaten PCs heb gevonden, is Dropbox misschien niet eens zoveel onveiliger dan een fysieke hard-copy van je bestanden mee te dragen.

Daar ben je nog altijd zelf bij. Als je van een andere partij afhankelijk bent, in dit geval Dropbox, kan je niet iemand de schuld geven van het (mogelijk) onzorgvuldig omgaan met je gegevens. Een hard-copy kwijtraken heb je zelf op je geweten en kan je heel plat bekijken als je eigen fout. Enkel een overval komt overeen met deze situatie, iemand ontneemt fysiek je USB stick of jat je SQL db met je Dropbox gegevens.

Ik vind het overigens een kwalijke zaak dat het zo relatief eenvoudig is om de gegevens te achterhalen.

[Patriot]

Het zou natuurlijk wel weer veel onhandiger zijn als je steeds je gebruikersnaam en wachtwoord moet opgeven. Misschien is het een idee om dat dan te doen als het IP-adres anders is dan de laatste keer met dat host-id? Dan is het natuurlijk nog steeds lastig als je met een laptop de hort op gaat..

Het lijkt me sowieso handig om verdacht gedrag te gaan herkennen. Aanmelden met een host-id dat ergens anders in gebruik is moet direct leiden tot opnieuw inloggen en het verschaffen van een nieuw host-id voor dat apparaat (na authenticatie uiteraard ). Daarnaast kun je bijv. informatie over de hardware verzamelen en daar een hash van meezenden. Dat zal vast te spoofen zijn, maar het maakt het aanzienlijk lastiger.

[Reactie gewijzigd door Patriot op 31 juli 2024 01:38]

[Ventieldopje]

Het lijkt me sowieso handig om verdacht gedrag te gaan herkennen. Aanmelden met een host-id dat ergens anders in gebruik is moet direct leiden tot opnieuw inloggen en het verschaffen van een nieuw host-id voor dat apparaat (na authenticatie uiteraard ).

Je vergeet dat je maar 1x toegang nodig hebt om zo'n account leeg te halen of om bestanden te manipuleren, en "verdacht" gedrag opsporen kan natuurlijk altijd false-positives opleveren wat de gebruikersvriendelijkheid niet ten goede komt!

Verder vind ik dat ze deze belangrijke gegevens niet gewoon in een onversleutelde / beveiligde SQLite database hadden mogen zetten. Slecht ontworpen dus!

[Anoniem: 26222]

En die ene keer toegang kan dus al geblokkeerd worden, of kan er gevraagd worden om een wachtwoord. Het is niet zo dat ze daar eerst een paar uurtjes over moeten nadenken ofzo.

Verder heeft het ook geen zin om de database te encrypted, want de key om de database weer te decrypted zal dan hardcoded in de client moeten zitten en dus ook makkelijk te achterhalen.

Het is niet zo makkelijk te beveiligen als je denkt, zonder dat je iedere keer je wachtwoord in moet vullen.

[webloem]

Mm, wat slecht. Dropbox is toch een serieus bedrijf dat hier echt wel wat aan kan doen. Natuurlijk hebben ze gelijk dat je eerst toegang tot de pc nodig hebt en in dat geval heb je gewoonlijk ook al toegang tot de bestanden, maar echt netjes is het niet.

[Icekiller2k6]

De vraag is nu natuurlijk.. als je al aan die file kunt kun je in principe ook op dezelfde pc aan de dropbox..

Ik neem aan dat er een per session token veel zal kunnen verhelpen..

en gewoon ff mbv een seed de token opslaan zal ook veel helpen..
2 simpele manieren om een betere beveiliging te hebben..