I have long been an evangelist of Dropbox… Of course some of the time I am only looking to enhance my referral status and increase my own free Dropbox storage space but as every (worthwhile) application of the iPad allows connection with your Dropbox folder, it has almost become and essential addition to my core working.
I started listening to the Security Now Podcast on the TWIT network ( http://www.twit.tv/sn ) recently and I came across some worrying news over the security of using the Dropbox application that I thought was worth spreading ans sharing.
Dropbox encryption issue
First and foremost, in episode 297 we were aleerted to the change to the Terms of Service of using Dropbox where the company disclosed that if the American security services required access to a users Dropbox folder then they would decrypt the files and hand them over. Up till that point, users were under the impression that not only were the files transferred securely but they were also stored securely too. Essentially this is true but in this case Dropbox has the hash key required to decrypt files and this is unsalted so any Dropbox employee can look at your files even though they state that they wont except for support purposes but all it takes is one bad apple in the Company to expose someones personal information
The answer to this problem is of course for you to have your own key and pre-encrypt your secure files before sending them up to Dropbox using such tools such as Truecrypt (all OS’s) or Bitlocker (Windows Vista and above) to create a secure folder inside your synchronised folder. Another tool was suggested in episode 299 which is still in Beta right now and for Windows only currently there is which will encrypt ans sync on the fly without having to have the likes of truecrypt running a virtual folder on your drives. Heres hoping that this comes out for other OS’s soon including the iPad.
Config.db security and Dropbox authentication issue
The second worrying thing is something that I hope Dropbox fix real quick now is a possible desktop security issue highlighting the need for ensuring that your machine is made secure each time you leave your desk. I think he put this quite well so I’m not going to rearrange his words in my style so here’s the word for word text from his transcript.
Now, the other issue that came up was a question of their authentication. Someone named Derek Newton, who is a security researcher, was poking around in Dropbox-like applications, and he just decided he would take a look and see what they left behind, what was left behind after they installed. What he found was that, specifically in the case of Dropbox, there is a single file called config.db, which is an SQLite database file, which contains the email address, the dropbox_path, that is, where the Dropbox folder is on your system, which is being synchronized to the Dropbox in the cloud, and the host_id. Any SQLite DB-compatible client is able to open this file and look at it.
And what he determined by experimentation is that the only thing that identifies you to Dropbox is the host_id. There is no other lockage of that file to a given system. And so what he posted - and again, I learned about this from people saying in Twitter, hey, Steve, what do you think about this? And this has been a constant flow for the last couple weeks. And I mentioned last week that I hadn't had a chance to dig into this, but I would, to look into it and verify it. So I did want to follow up for everyone who's been wondering.
So what this means is that, if you weren't protecting this file, or if anything got onto your system which was able to grab this file through social engineering attack or spyware or malware, whatever, if you lost control of that file such that it was in any way exfiltrated from your control, then that file can be installed on any other system. And that provides the sole authentication of you, the instance of you, to Dropbox such that, with no other information, no username, password, no logon, anything, that authenticates that new system. And there is - it doesn't appear as a new machine in the set of machines that you have authorized to use. It's merely a clone of that first one, which then has full access, unencrypted access, to your Dropbox contents. Which to me says these guys aren't really looking at security.
I mean, on one hand we know now that they can decrypt the contents of our Dropboxes. And this could clearly have been done in a way that was more secure. Even if you change, if the user changes his username and password, that doesn't invalidate the host_id. It still functions. And so if somebody had it, their connectivity survives across a user changing his username and password. So it's just they really could have easily done a much better job of hashing username and password into this, tying it in some fashion, for example, to the serial numbers of the hard drives on the system. I mean, just anything to make it more difficult than simply one file which you can put on any machine anywhere, and suddenly it's authenticated just as solidly as the system it came from.
The transcript of this podcasts relating to the above can be found at http://www.grc.com/sn/sn-297.htm and http://www.grc.com/sn/sn-299.htm
You can read Derek Newtons Blog post on the authentication security issue at: “http://dereknewton.com/2011/04/dropbox-authentication-static-host-ids/