Don't know if any of you (or your clients) use Dropbox (I do), but if you do,
you should probably read this and pass it on:
============= Included Stuff Follows =============
Dropbox authentication: insecure by design
...
After some testing (modification of data within the config table, etc) it
became clear that the Dropbox client uses only the host_id to
authenticate. Here´s the problem: the config.db file is completely
portable and is *not* tied to the system in any way. This means that if
you gain access to a person´s config.db file (or just the host_id), you
gain complete access to the person´s Dropbox until such time that the
person removes the host from the list of linked devices via the Dropbox
web interface. Taking the config.db file, copying it onto another system
(you may need to modify the dropbox_path, to a valid path), and then
starting the Dropbox client immediately joins that system into the
synchronization group without notifying the authorized user, prompting for
credentials, or even getting added to the list of linked devices within
your Dropbox account (even though the new system has a completely
different name) - this appears to be by design. Additionally, the host_id
is still valid even after the user changes their Dropbox password (thus a
standard remediation step of changing credentials does not resolve this
issue).
...
============= Included Stuff Ends =============
Seen here:
http://dereknewton.com/2011/04/dropbox-authentication-static-host-ids/
http://tinyurl.com/3b9xdvv
WTF were they thinking?
Angus
--
Angus Scott-Fleming
GeoApps, Tucson, Arizona
1-520-895-3270
Security Blog: http://geoapps.com/
--
Angus Scott-Fleming
GeoApps, Tucson, Arizona
1-520-290-5038
Security Blog: http://geoapps.com/
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin
