Rss

Archives for : November2011

How it Works

Atheist:

  1. Make a big fuss about how Christians are wrong and are wasting their life worshiping God.
  2. Themselves waste their life on the Internet complaining about step 1.
Look no¬†further¬†than the Reddit Atheist section for proof. If I ever need reminding that I’m not wasting my life, I just have a quick look through there to see what I’m doing wrong this time ūüôā

Dropbox Android Security Flaw

Note: Please make sure to read the response to my email from Dropbox at the bottom. Everything in this post was using Dropbox Android client version 1.2.4, which was published to the market on the 18th of August, 2011. Any desktop comparisons were using v1.1.40.

A couple of weeks ago I was playing around with my Dropbox account on my phone. I was trying to work out how secure my data is on my phone, and what would happen if it were stolen. When looking in the Dropbox app preferences, I noticed a feature that said “passcode,” which allows you to place a passcode on your Dropbox. So that in essence, you can’t access the Dropbox account from the phone without that passcode.

If my phone was lost or stolen, at the moment I would presume that everything on my SD card has been compromised. That said, I don’t have much on my SD card other than Music, Photos and a select few files downloaded from Dropbox. The files that I have on my phone from Dropbox aren’t particularly¬†important¬†files, or at least ones that I can live with being compromised (such as my KeePass database, as it’s encrypted.) What I’m more concerned about is people being able to download more important files from my Dropbox account when they have my phone. This is where I thought the passcode would come in handy.

There’s a problem with the passcode though. Most people using the passcode on Dropbox probably don’t have a passcode for their phone (and why should they? They can already access my SD card, it’s more or less my Dropbox account that I’m concerned about.) This means that any one who has access to the phone could access all features, except Dropbox.

The problem occurs when,¬†because¬†all features are available to a¬†thief, the¬†thief¬†can place the phone into Dev mode, hook it up to their computer, and extract the settings database, and view it in a SQLite viewer. As a proof of concept, I set my passcode to “1234.” See the screenshot below…

Yep, that’s right. Passcode is stored in plain text. The thing to note is, if there is no lock on the phone, this information is easily accessible with just the Android SDK and a USB cable. As mentioned before, people likely to be using the Dropbox passcode lock are those who haven’t locked their phone with a passcode or pattern, since if you have, there is no need for the Dropbox passcode.

I believe this will give people a false sense of security. I was hoping, with the passcode, and I lost my phone, I’d be able to think to myself “all my data on my SD card has been compromised, but that’s OK, because they can’t download any more files from my Dropbox.”

There are also concerns with the way that Dropbox ¬†handles the authentication of devices, as described in an article entitled¬†Security researcher warns over Dropbox authentication security flaw. I myself have been able to test this, and confirm independantly that, if given access to a computer for a short period of time, it’s possible to lift the preferences database and duplicate those preferences onto another computer, completely undetectable (it won’t show up as another device.) The CTO say’s this isn’t an issue¬†because¬†if the system has already been¬†compromised, then the attacker may as well grab all the data they want whilst they’re in there.

I see 2 problems with the statements the CTO made:

  • This allows for continual access to data even after the system has been cleaned, providing the user doesn’t think to unlink the computer from their Dropbox account.
  • It requires less time with the computer to lift the configuration file, since it’s only a few kilobytes. Basically, if you physically have access to someone’s computer and are searching for confidential informaton, it would be easier to spend a minute or two lifting the configuration file, then spending longer searching for the file and then copying it to a USB drive, or copying their entire Dropbox file (which for some people can be gigabytes in size.) All of this takes time, and basically getting the configuration file is the smallest thing to grab.
(The other thing is, that article was posted on April 2011, and it said that “Ferdowsi said that the design of the Dropbox client may be improved in the light of Newton’s research.” I managed to independantly confirm this issue in November 2011, 7 months after that statement was posted. I am using Dropbox version 1.1.40) (as per the email from Dropbox, this has been fixed)
From what I have seen with the Android preferences, it may be possible to do a similar thing as described in the above article, that is to duplicate the database from one Android device to another. I do not have another Android device to test this on at the moment. This creates an even bigger issue, which is similar to the second point above: someone only needs your phone for 5 minutes to take all your data. You may not even know that data has been compromised.
Responsible Disclosure
I emailed Dropbox from their “Contact Us” page on their website on the 6th of November 2011 notifying them of this issue. I also mentioned that I will publish my results on the 20th of November 2011 (AEST,) in the spirit of responsible disclosure, as to give them enough time to fix this issue if they so wish.
Everything I have done is in good faith, in an aim to improve security in one of my favorite pieces of software, with what I believe to be a flaw that gives a false sense of security.

Response to Responsible Disclosure Email
I received an email from them on the 15th saying that this issue I have bought up will be forwarded to their mobile development team. Dropbox also “recommends that users follow good security practices to protect your computers and devices, which does include pass coding your phone.” They did not indicate they wished me to refrain or delay from posting this, which I said I would on the 20th of November unless asked to delay (which I clearly said in my original email to give them time to fix the issue.)

They also informed me that the issue I linked to regarding their Windows desktop client has been fixed in version 1.2.48 (which I was not using in my tests.)