Dropbox vulnerable initially?

In the past few days, articles with titles like “Dropbox is insecure”, “A serious vulnerability in Dropbox”, etc. have started to go around the Internet. I, as a dropbox user, decided to figure out what was the matter. Russian-speaking sources of information, as is usually the case, are full of loud statements in the spirit of “Everything is gone !!!!!!!!”, and the reference to the source should be considered a bad form. Under the cut, I will tell you how it really is.

So a week ago Derek Newton made a Dropbox authentication: insecure by design entry on his blog. The recording is quite voluminous, so I will try to briefly convey the author’s main thoughts.

Under Windows (Derek uses Windows, but I'm sure everything described will work everywhere) Dropbox saves settings, lists of files / directories, hashes, etc. in multiple files format sqlite . These files are in % APPDATA% \ Dropbox . Consider the main database directly related to the dropbox configuration: config.db . Having opened it in any SQLite file viewer, you can see that there is only one table ( config ) with several fields in the database. Consider three of them:

• email : account owner email. Surprisingly, this address is not involved in the authorization process and can be changed to any value (formatted as a valid email address) without any consequences.
• dropbox_path : determines where the folder syncs with Dropbox.
• host_id : assigned to the system after the first authorization. Never change afterwards.

')
After experimenting with the file (data modification, etc.), it became clear that Dropbox only uses the value of host_id for authorization. The problem is that the config.db file is portable and completely unrelated to the system. It turns out that if you get access to this file (or just the host_id line) you will get full access to the files until the system's link to the account is deleted via the Dropbox web interface. Copying the file config.db to another system (you may have to change the dropbox_path to the correct one) and running Dropbox immediately synchronizes this system with the account without notifying the user and not even adding the new system to the list of trusted users in the web interface (even if the new system has a different name ). Moreover, the host_id remains valid even after the user has changed the password.

Next, Derek logically notes that once you have access to the config.db file, then most likely there is access directly to the dropbox files, which means that this is not such a serious vulnerability. All right, but rather good prospects are opening up for attackers:

• A relatively simple “targeted” virus can be developed, aimed at acquiring host_id from personalities of interest to the attacker, with subsequent access to the files or their infection.
• Even if a virus is detected on a compromised system, normal steps to ensure security (removing the virus, changing the password, reinstalling the system, etc.) will not prevent access to the victim’s files. The user will need to manually remove the compromised system from the trusted list on the dropbox site.
• Transferring only a config.db file (several kilobytes in size) is in most cases less noticeable than transferring files directly from the dropbox folder. Access to dropbox files is possible at a distance, even when the user has turned off the computer.

Derek offers three security options that are pretty obvious, by the way:

1. Do not use Dropbox. This is the easiest, but not the most acceptable way, of course.
2. Protect your data: use encryption for important files stored in the dropbox and keep the access key secret (for example, it will be stupid to store it in the dropbox folder or on the same system)
3. Follow the list of authorized devices and do not be lazy to delete those that you no longer plan to use. Also pay attention to the “Last Activity” field in the “My Computers” list in the dropbox web interface. If you see that the files were accessed when it should not be - immediately remove this system from the trusted ones.