Пользователь
0,0
рейтинг
14 апреля 2011 в 13:33

Разработка → Dropbox уязвим изначально?

imageВ последние несколько дней по интернету стали ходить статьи с заголовками вроде “Dropbox небезопасен”, “Обнаружена серьезная уязвимость в Dropbox” и т.п. Я, как пользователь дропбокса, решил разобраться, в чем же тут дело. Русскоязычные источники информации, как это обычно бывает, пестрят громкими заявлениями в духе “Все пропало!!!!!!!!”, а ссылку на первоисточник указывать считают дурным тоном. Под катом я расскажу, как дело обстоит на самом деле.

Итак, неделю назад 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 (размером в несколько килобайт) в большинстве случаев менее заметна, нежели передача непосредственно файлов из папки дропбокса. Доступ же к файлам дропбокса возможен на расстоянии, даже когда пользователь выключил компьютер.


Дерек предлагает три варианта обеспечения безопасности, довольно очевидных, впрочем:

  1. Не используйте Dropbox. Это самый простой, но не самый приемлемый способ, разумеется.
  2. Защищайте ваши данные: используйте шифрование для важных файлов, хранящихся в дропбоксе и держите в секрете ключ доступа к ним (например глупо будет хранить его в папке дропбокса либо на той же системе)
  3. Следите за списком авторизованных девайсов и не ленитесь удалять те, которые больше не планируете использовать.Также обращайте внимание на поле “Last Activity” в списке “My Computers” в веб-интерфейсе дропбокса. Если увидите, что к файлам был доступ тогда, когда его быть не должно — сразу удаляйте эту систему из доверенных.
Владимир @Freeborn
карма
34,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (124)

  • +15
    1b. Не держать на Dropbox-е «очень секретную» информацию.
    • +14
      Секретную информацию можно шифровать…
      • +39
        … нужно…
        • +22
          А лучше, по возможности, скрывать сам факт наличия таковой.
          Этот метод более устойчив к методикам терморектального криптоанализа, столь популярным в России, ближнем и дальнем зарубежье.
          • +4
            да, например, писать секретные данные белым шрифтом %)
            • +35
              Кто-то еще пытался выделить полностью сообщение alemiks'а? Я думал там будет текст белого цвета :)
      • 0
        или использовать Dropbox на Линуксе :)
        • +6
          Думаете проблема украсть config.db на линуксе? Люди получают рут доступ до систем взламывая их, а тут всего лишь скопировать один файл, чтобы получить доступ до файлов аккаунта пользователя Dropbox?
          • +11
            … думаю что намного тяжелее украсть с линукса чем с винды
            • +9
              В массовом плане этого просто никто делать не будет, но если атака индивидуальная, то не думаю что есть большая разница.
            • +15
              Это зависит не от ОС, а от пользователя этой ОС.
            • +11
              ну вот в той же убунте домашняя директория юзера по умолчанию создается с правами 755
              (в отличии от той же федоры где 700)
              ну и представьте что вы разделяете свой комп ещё с кем-то и вот этот кто-то спокойно может получить доступ к этому файлу из своего аккаунта.
              • +8
                chmod 600 ~/.dropbox/* && chmod 700 ~/.dropbox
                Страно что они по умолчанию не такие
              • 0
                Если не ошибаюсь, может помочь
                umask 0077
              • 0
                скорее всего у этого кого-то также рутовый акк или он в судоерах убунты…
          • –7
            Если стырить config.db — легко, то какая проблема в том, чтобы стырить и файлы в папке дропбокса? Тогда и статья ниочем
            • +3
              В статье есть ответ:
              фаил в несколько килобайт проще передать чем 2 гб из папки dropbox
            • +4
              Вы не дочитали статью.
            • +1
              После того как вы стырили config.db, у вас всегда будет свежий контент жертвы.
          • +2
            Для прочтения самого файла необязательно даже права root-пользователя, достаточно «r» в правах доступа к файлу.
      • +1
        В любом случае, шифрование — неплохая дополнительная мера безопасности при работе с Dropbox.
        Под Linux существуют готовые рецепты автоматического шифрования.
    • 0
      Проблема в том что многие бэкапы там держат, и смысл его использовать если как раз таки бэкапы под угрозой?
      • 0
        А аккаунт от любого другого обменника, хранилища уже взломать нельзя? Точно также всё уязвимо. Шифровать информацию надо, вот и всё.
        • 0
          я отвечал на: «1b. Не держать на Dropbox-е «очень секретную» информацию.»
  • +5
    У меня дропбокс был на рабочем компе и на буке. Потом починил домашний старый комп, завел и там бокс, забыл пароль, восстановил и удивился, что на буке и рабочем компе бокс не запросил новый пароль…
    • +26
      Вот тут-то и надо было начинать панику :)
    • +17
      вы на редкость спокойный человек :)
    • 0
      Вот так продашь ноутбук, просто удалив dropbox и данные, или, скажем, накатив новую установку поверх старой без форматирования, а новый владелец, установив dropbox, получит сюрприз.
      • +1
        Вы не поверите, сколько сюрпризов я встретил на 5 продаваемых ноутах с залоченой виндой, загрузившись на них с флешки с линуксом… Дропбокс отдыхает.
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            Вообще мне кажется вполне логичным при продаже ноутбука полностью ворматировать жесткий диск и переустановить систему. Жаль, об этом думают мало людей.

            ЗЫ: В одном ноутбуке я кстати даже нашел в приводе диск с портэйбл-версией программы банкинга и ключами авторизации… ) Но, так как я честный, диск был уничтожен. )
            • 0
              Даже если подумают, то этого может оказаться недостаточно — дефолтное форматирование винта в винде быстрое, если склероз не изменяет…
          • –9
            Отвратительно.
            • НЛО прилетело и опубликовало эту надпись здесь
          • +16
            — Пруфпик или не было!
          • +19
            Простите, у меня последнее время проблемы со зрением, поэтому я не вижу ссылок на фото и видео. Можете их продублировать более крупным шрифтом? Спасибо.
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                А там еще и подруги были? :)
                • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    > «Чего ты улыбаешься, видишь, ты мне нравишься»

                    Девочки решили подзаработать в интернете?
      • –1
        Никто не мешает удалить этот хост из списка прилинкованных на сайте дропбокса.
        Почему Дропбокс должен это делать за нас? Нужно тоже нести некую ответственность за свои действия.
  • +4
    Будем надеяться, что отреагируют и привяжут ключи к железу.
    • +2
      :)
      • +19
        Чёрт, картинка опять съелась:(

        a-comics.ru/users/kaita/cad/2011/02/20110209ru.jpg
        • +2
          Каждого представителя сони к игре? Бред! К приставке нужно.
  • +4
    Еще можно пропатчить код дропбоксового клиента, чтоб он лез за файлом с другим именем и искал в нем не host_id, а тоже что-то другое. Это несложно и вполне эффективно. Правда, повторять придется после каждого обновления — это минус.
    • +41
      Элегантный способ заколотить шуруп утюгом.
      • 0
        Ну или не делать ничего и ждать, пока они там в своем дропбоксе соблаговолят дать отвертку.
      • 0
        Микроскопом, шеф, микроскопом!!!
  • +2
    >… Также обращайте внимание на поле “Last Activity” в списке “My Computers” в веб-интерфейсе
    > дропбокса. Если увидите, что к файлам был доступ тогда, когда его быть не должно —
    > сразу удаляйте эту систему из доверенных
    На этот случай DropBox даже RSS предлагает. Подписываемся и контролируем.
  • 0
    М-да, не ожидал такой халатности в плане безопасности от разработчиков популярного сервиса.
  • +4
    Односторонняя подача информации. То что вы перевели заметку Дерека, это хорошо. Но там самое интересное — это обсуждение, в котором высказываются (в том числе и компетентными людьми, включая разработчиков Dropbox) аргументы «за» и «против» того, можно ли считать это серьезной уязвимостью.

    В итоге Дерек признает, что здесь, подобно многим онлайн-приложениям, имеет место компромисс между безопасностью и удобством для массового пользователя. И если бы разработчики сместили этот баланс в сторону безопасности, многиие сценарии использования стали были бы невозможны, благодаря которым Dropbox и стал популярным. То есть он просто не выжил бы.
    • 0
      Компромисс между безопасностью и удобством — это обычное явление. Но, извините, не до такой же степени…
      • 0
        Ну прочтите оригинал до конца и предложите свой вариант.
        • 0
          В Ubuntu большинство паролей хранится в key-менеджере и разлочиваются при логоне в систему. Dropbox может, например, использовать key-менеджер если он доступен. В Ubuntu так делают многие программы.
          • 0
            Ну а host_id может быть зашифрован уже тем паролем, который хранится в key-менеджере или же не использовать host_id совсем, а вместо него опять же пароль в key-менеджере.
            • 0
              насколько я понимаю, проблема в кроссплатформенности, подобные же системы есть и в винде и думаю в macOS, но для каждой операционки придется писать свой мето аундификации…
              • +2
                Хахах, а вы видели заголовки *.h кроссплатформенных приложений или библиотек? :)
          • +1
            В винде тоже так можно. Так каков ваш сценарий, «при каждой авторизации спрашивать пароль у пользователя»?
            Такой сценарий многих не устроит; а для многих будет менее безопасным. Вы все-таки не прочитали.
            • 0
              Например при успешной авторизации заново генерировать host_id. Если они совпадать не будут — спрашивать пароль. Тогда после первой же авторизации злоумышленника host_id сменится. Жертве придется ввести пароль. После успешного ввода пароля жертвой host_id опять поменяется. Злоумышленнику придется снова его тырить.
              • +2
                Почитайте оригинал, ну пожалуйста.
            • +1
              "… хранится в key-менеджере и разлочиваются при логоне в систему" — это значит что пароль набирается один раз при входе в систему и это не пароль Dropbox-а, а пароль вашей учётной записи в ОС.
              • 0
                Если он разлочен, то его можно вытащить так же, как host_id из config.db? Это аналогично текущей ситуации.
                • +1
                  Так же логично, как если вы зашли в свою почту, то человек севший за ваш компьютер сможет её прочитать. Тут главный вопрос не в этом, а в том, что сейчас я могу скачать получить ваг config.db просто загрузившись с LiveCD или LiveUSB. Много времени это не займёт.
                  • 0
                    Так сами файлы же рядом лежат, зачем это все тогда? :) Для вас это может и главный вопрос, а Дерек об этом сценарии и не упоминал.
                    • +1
                      Имея id вы сможете следить за данными этого человека в течении долгого времени даже если он будет менять свой пароль, и это до тех пор, пока он этот id не деактивирует.

                      Ещё один важный момент про key-менеджер я не упомянул. key-менеджер знает какой программе к какому паролю можно давать доступ (так же как Firefox знает какому сайту какой давать пароль). Если пароль запросить какая-то другая программа, то система спросит разрешения дать доступ к такому-то паролю такой-то программе.
                      • 0
                        т.е. произвольная программа не будет иметь доступ к ID
                      • 0
                        А как этот key-менеджер идентифицирует программу? Дайте ссылок почитать.
                        • 0
                          В тонкостях я не разбираюсь, но вроде бы вот эта программа за хранение паролей отвечает в Ubuntu: live.gnome.org/GnomeKeyring
                          Там же есть полное описание API.
                          • +1
                            Упс...
                            What types of attacks does Keyring protect against?

                            * Stealing passwords from inactive (locked) keyrings.

                            What types of attacks are still possible?

                            * Passwords in an unlocked keyring being read by a malicious application that is running on the user's desktop.

                            • 0
                              Если вы хотели сказать «ага, вы были не правы!», то у вас получилось. Постараюсь удержать этот тред в конструктивном русле.
                              Только что проверил в Ubuntu 10.10 — система не задаёт лишних вопросов и отдаёт пароли при разлоченой системе, т.е. сейчас это не работает. Несколько версий назад Ubuntu спрашивала «разрешить доступ к брелоку вот этой программе?». Появились риторические вопросы. 1. Непонятно куда это делось и почему это убрали. 2. В API Keyring-га есть ACL. Опять же непонятно, почему он не используется.
                              • 0
                                Нет, сказать «вы не правы» не было моей целью, мне тоже было интересно, я ведь пользуюсь Ubuntu.

                                Как пишут сами гномовцы, чтобы реализовать такое, только их усилий недостаточно. Нужна поддержка со стороны других подсистем. И хотя работа в этом направлении ведется, на сегодня этот момент архитектурно не продуман.

                                Запрос на разблокировку брелока я видел, но названия программы там не указывалось (10.04).
                                • 0
                                  Ежедневно пользуюсь брелоком (10.10), спрашивает на выбор:
                                  — блокировать после логоффа
                                  — блокировать после N минут
                                  — блокировать после N минут простоя

                                  либо вообще автоматом разблокировать при логине и, видимо, до логоффа.

                                  Имя приложения никак не завязано, у меня два ежедневно используются, спрашивает только при запуске первого, не важно гуишное или консольное (в терминале)
  • +1
    Также обращайте внимание на поле “Last Activity” в списке “My Computers” в веб-интерфейсе дропбокса. Если увидите, что к файлам был доступ тогда, когда его быть не должно — сразу удаляйте эту систему из доверенных.

    Как же его увидеть, если
    и даже не внося новую систему в список доверенных в веб-интерфейсе (даже если новая система имеет другое имя).

    Как они так промахнулись, что даже после смены пароля аккаунт не выбивает. Вот это фейл.
    • 0
      Ваши компы были выключены, например, ночью, а доступ с одного из них типа был.
  • +2
    Пойду напишу скрипт который будет брутфорсить этот ключик пока случайно не попадет в чужой аккаунт, авось «повезет».
  • +38
    Ппц. Ребята видят OAuth авторизацию и удивляются, что после получения тикета, этот тикет можно скомутызить и отзывать его надо особым образом…
    Во-первых, %APPDATA% «защищена» средствами NTFS.
    Во вторых, вы всегда можете перемонтировать папку на защищённый девайс.
    В третьих, при таком «ФГМ» политики — интернета быть не должно, т.к. Fx (Opera, IE) все пароли держит в таких же файликах.
    В четвёртых, все «важные» документы должны, даже на «закрытом» компе, храниться в криптоконтейнерах…
    ЗЫ КГ/АМБФГМ
    • +3
      В третьих, при таком «ФГМ» политики — интернета быть не должно, т.к. Fx (Opera, IE) все пароли держит в таких же файликах.

      У броузеров есть такая фича, как master password

      В четвёртых, все «важные» документы должны, даже на «закрытом» компе, храниться в криптоконтейнерах…

      Есть документы средней важности. Утечка коих не критична, но неприятна. И они должны быть доступны из любого места, где скорее всего не будет вашего любимого шифровальщика.
      • 0
        Master password, по моему, есть не у всех (ie, chrome) по умолчанию не установлен, а если и установлен, то легко обходится.

        В чём проблема установить ваш любимый шифровальщик, положив его в dropbox. Тот же rar архив запароленный уже очень устойчивый криптоконтейнер.
    • 0
      Я обычно у таких папок, защищенных владельцем, меняю владельца и дело сделано.
      • 0
        Я и написал «защищена» в кавычках. ;-)
        • 0
          EFS никто не отменял.
          • 0
            У вас раздел с Users хранится в EFS? А если монтировать только папку %APPDATA%\Dropbox, то это уже второй способ…
            • +1
              Вы путаете BitLocker и EFS.
              • 0
                Приношу извинения, вы правы. :)
  • +16
    — Не думай.
    — Если думаешь – не говори.
    — Если думаешь и говоришь – не записывай.
    — Если думаешь, говоришь и записываешь – не подписывай.
    — Если думаешь, говоришь, записываешь, подписываешь – не удивляйся.
    • +1
      Ну да, не шифруете данные, хранимые черти где — ССЗБ.
  • 0
    Полностью согласен. Юзайте TrueCrypt и все будет хорошо.
    • 0
      Желательно вместе с токеном и параноидальным 256 символьным паролем.
  • 0
    Это, я может чего-то не понимаю, но зачем хранить секретные данные на каком-то там непонятногде дропбоксе? Я даже в гуглдокс ничего секретного не держу… ибо доступ к моим данным есть теоритически у каждого сотрудника отдела гуглдокс. Также обстоит дело и с дропбоксом.
    • +1
      Мы храним документы по некоторым хозяйственным (домашним) делам в Dropbox, т.к. это удобно. Но мне не хотелось бы, чтобы кто-то мог их прочитать, поэтому они зашифрованы.
    • +1
      Есть данные не секретные, но, скажем, личные. Для постороннего человека (сотрудников гугла например) они никакого интереса не представляют, а вот чтобы кто-то знакомый видел в принципе не хочется, но не настолько чтобы их шифровать нестандартными средствами ОС (а стандартными тут, насколько я понял, бесполезно). Вот для таких данных это серьезная уязвимость.
  • +1
    Кто бы подобный анализ для Wuala провел…
  • +9
    А напишите host_id для примера — чтобы посмотреть вообще как он выглядит.
    • +19
      Ваша фамилия случайно не Митник?
    • +12
      Выглядит как md5 хеш 32 значный. Мой host_id например такой: fa124dbf0… стоп… чего это я…
    • +14
      Если написать на хабре свой host_id — он автоматически скроется звездочками.
      Вот мой: ***************

      Пишите в комментариях ваш и убедитесь лично!
      • +7
        Прикольно, быстро они это доделали на Хабре — а ну, вот мой:

        ***************
        • +2
          Ух ты, работает! О_О
    • 0
      По виду — хеш md5.
  • –32
    Правильно, потому что нужно пользоваться Sugarsync, это аналог, более новый. www.sugarsync.com/referral?rf=ckrfgkwtf00jv
    Удобнее, и к тому же там больше места.
    • +17
      Всё бы хорошо, если бы не оставленный в ссылке референс-код :) Думаю, что если бы прямо написали об этом («заодно мне места добавите»), то реакция была бы у людей не такой отрицательной =]
    • +5
      Линукс не держит, только винду и макось :(
  • –1
    4. apparmor/selinux?
  • +5
    ну, кто первый напишет перебиралку host_id?
    • 0
      Тоже подумал о том, что же мешает сделать перебор md5-хэшиков? Думаю, что перебирать можно быыыыстро, с highload'ом в Дропбоксе всё в порядке :)
      • 0
        Я бы на их месте ограничивал количество запросов на аутентификацию с одного ип-а в единицу времени.
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Жесть. У меня с 2009 года сессии висят неэкспайрнутые, перебор вполне может сработать.
  • 0
    Автор ещё забыл отметить, что из значка в трее можно зайти на сайт и поглазеть на айпи владельца. Пароль с мыло, правда, поменять не получится.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      система write-only-once?
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          тем не менее
    • +2
      уже интересно!
      иак какой ваш хост ид?
    • +7
      Мне лично, не страшно что информация попадёт в третьи руки:
      1) Файлы помещены в зашифрованные контейнеры на флешку.
      2) Флешка помещена в свинцовый контейнер с десятизначным кодом
      3) Контейнер закопан на глубину 10м в мариинской впадине
      4) Сверху присыпано китовыми какашками для отвода глаз.

      Упустил несколько пунктов, да и выглядит всё не совсем так приятно как описал.
      Самое важное — не заляпаться в какашках :)
      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      а какой смысл менять расширения, если о большинстве форматов можно узнать из заголовков?
  • 0
    У меня в Dropbox для важных данных лежат шифрованные файлы-контейнеры для TrueCrypt.
    Да и нет у меня такой информации, которую будет жалко потерять или раскрыть.
  • +1
    Так, парни, признавайтесь, кто сколько ключиков уже сбрутил и чего интересного нашёл.
  • 0
    www.tarsnap.com/index.html — dropbox для параноиков.
    • 0
      + генератор для параноиков dl.dropbox.com/u/345095/pwd/index.htm
    • 0
      Заманчиво. Пользовались? Может напишете топик?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.