![image](https://habrastorage.org/storage/habraeffect/0a/b6/0ab60c5bd658f079d98531c2a8b0cabb.jpg)
Итак, неделю назад Derek Newton сделал запись Dropbox authentication: insecure by design в своем блоге. Запись довольно объемная, так что я постараюсь сжато передать основные мысли автора.
Под Windows (Дерек использует Windows, но уверен, что все описанное будет работать везде) Dropbox сохраняет настройки, списки файлов/директорий, хешей и т.п. в нескольких файлах, формата SQLite. Эти файлы лежат в %APPDATA%\Dropbox. Рассмотрим главную базу данных, непосредственно относящуюся к конфигурации дропбокса: config.db. Открыв ее в любой программе просмотра SQLite файлов можно увидеть, что в базе только одна таблица (config) с несколькими полями. Рассмотрим три из них:
- email: электронная почта владельца аккаунта. Удивительно, но этот адрес никак не задействован в процессе авторизации и может быть изменен на любое значение (отформатированного как валидный email адрес) без каких-либо последствий.
- dropbox_path: определяет, где находится папка, синхронизируемая с Dropbox.
- host_id: назначается системе после первой авторизации. Никогда не меняется впоследствии.
После экспериментирования с файлом (модификация данных и т.п.) стало ясно, что Dropbox для авторизации использует только значение host_id. Проблема заключается в том, что файл config.db портативен и абсолютно не связан с системой. Получается, что если вы получите доступ к этому файлу (либо просто строке host_id) вы получите полный доступ к файлам до тех пор, пока привязка системы к аккаунту не будет удалена через веб-интерфейс Dropbox’а. Копирование файла config.db на другую систему (возможно придется еще изменить dropbox_path на правильный) и запуск Dropbox немедленно синхронизирует эту систему с аккаунтом без уведомления пользователя и даже не внося новую систему в список доверенных в веб-интерфейсе (даже если новая система имеет другое имя). Более того, host_id остается валидным даже после того, как пользователь изменил пароль.
Далее Дерек логично замечает, что раз имеется доступ к файлу config.db, то скорее всего доступ есть и непосредственно к файлам дропбокса, а значит не такая уж это и серьезная уязвимость. Все так, но перед злоумышленниками открываются довольно неплохие перспективы:
- Может быть разработан относительно простой “таргетированный” вирус, направленный на добывание host_id у интересующих злоумышленника личностей с последующим доступом к файлам, либо их заражению.
- Даже если вирус будет обнаружен на скомпрометированной системе, нормальные шаги по обеспечению безопасности (удаление вируса, изменение пароля, переустановка системы и т.п.) не предотвратят доступ к файлам жертвы. Пользователю нужно будет вручную удалить скомпрометированную систему из списка доверенных на сайте дропбокса.
- Передача лишь файла config.db (размером в несколько килобайт) в большинстве случаев менее заметна, нежели передача непосредственно файлов из папки дропбокса. Доступ же к файлам дропбокса возможен на расстоянии, даже когда пользователь выключил компьютер.
Дерек предлагает три варианта обеспечения безопасности, довольно очевидных, впрочем:
- Не используйте Dropbox. Это самый простой, но не самый приемлемый способ, разумеется.
- Защищайте ваши данные: используйте шифрование для важных файлов, хранящихся в дропбоксе и держите в секрете ключ доступа к ним (например глупо будет хранить его в папке дропбокса либо на той же системе)
- Следите за списком авторизованных девайсов и не ленитесь удалять те, которые больше не планируете использовать.Также обращайте внимание на поле “Last Activity” в списке “My Computers” в веб-интерфейсе дропбокса. Если увидите, что к файлам был доступ тогда, когда его быть не должно — сразу удаляйте эту систему из доверенных.