Vulnerabilities / Threats
6/21/2011
02:34 PM
Connect Directly
LinkedIn
Twitter
Google+
RSS
E-Mail
50%
50%

Dropbox Files Left Unprotected, Open To All

A software bug rendered the account authentication mechanism non-functional for four hours, leaving customers fuming over the latest security lapse at the popular online file storage service.

Slideshow: Cloud Security Pros And Cons
Slideshow: Cloud Security Pros And Cons
(click image for larger view and for full slideshow)
Dropbox on Monday acknowledged that its vast store of files was left open to the world on Sunday for four hours as a result of a bug. During this period, any account could be accessed using any password.

The flaw, a software bug that rendered the service's authentication mechanism non-functional, only took five minutes to fix, once it was discovered.

Over 25 million customers store their files online with Dropbox, but only a few of those accounts showed activity during the four hour window of vulnerability. "A very small number of users (much less than 1 percent) logged in during that period, some of whom could have logged into an account without the correct password," said Dropbox co-founder and CTO Arash Ferdowsi, in a blog post. "As a precaution, we ended all logged in sessions."

Ferdowsi said that his company is investigating the incident and will notify account holders if any unusual activity is identified during the time when accounts were unprotected. An update to Ferdowsi's blog post indicates that these notifications have been sent out.

The issue was made public by security researcher Christopher Soghoian, who received a tip from a Dropbox user.

In May, Soghoian filed a complaint against Dropbox with the Federal Trade Commission alleging that the company's security claims have been deceptive. Previously, Dropbox had advertised that "All files stored on Dropbox servers are encrypted (AES-256) and are inaccessible without your account password." In April, the company altered its claims to make it clear that Dropbox, rather than the account holder, controls the file encryption keys, thereby enabling Dropbox to provide access to account holders' files when presented with lawful demands from authorities.

In March, the security of Dropbox's Android mobile client came under fire when security researcher Mike Cardwell revealed that the app was transmitting file metadata without SSL encryption.

The following month, Ferdowsi and Drew Houston, co-founder and CEO, explained that they had decided to favor performance over security because "enabling SSL for all metadata transfers made the app several times slower." They also acknowledged Cardwell's concerns and said they were working on a way to send metadata over SSL more efficiently in their mobile apps.

Dropbox's users have made their displeasure about Sunday's incident known in a series of comments appended to Ferdowsi's blog post. Many have said they plan to seek alternative cloud storage services.

As if on cue, Wuala, a competing cloud storage service operated by hard disk maker La Cie, published a blog post on Tuesday stating that Dropbox's problems wouldn't be an issue if files were encrypted by the client. "Encrypting your files before they are sent to the cloud makes Wuala inherently more secure than solutions that rely on server-side encryption," the company said.

It doesn't pay for small and midsize businesses to protect against security threats faced by only the largest companies. Here's how to focus your efforts on the right threats. Download our all-digital supplement. Download it now.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.