@bypasser read-only
Пользователь
2 февраля 2013 в 18:12

Разработка → Mega: обзор (не)безопасности из песочницы

Добрый день!
Будучи простым российским… неважно кем, я обычно не пишу статьи, а тихонько их читаю (мы, неважно кто, любим тишину). Однако, недавно мое внимание привлекло обилие англоязычных статей о (не)безопасности милого душе сервиса Mega. Поскольку в русскоязычной среде вопрос обсуждается менее бурно, я решил предложить вашему вниманию небольшой дайджест публикаций о «скандалоинтригах и расследованиях», недавно завертевшихся вокруг сервиса ув. тов. Доткома. Сразу должен предупредить, данная статья не содержит original research, сиречь моего собственного мнения о криптографии в Mega, а лишь стремится проинформировать русскоязычного читателя относительно состояния зарубежной дискуссии на эту тему.

Итак, одной из первых тему безопасности Меги подняла ArsTechnica, в публикации с забавным названием «Megabad: A quick look at the state of Mega’s encryption». Несмотря на то, что статье не удалось избежать ряда нелепых журналистских ляпов (большая часть которых на настоящий момент уже исправлена, и увековечена лишь в комментариях), автор справедливо отметил ряд довольно крупных огрех со стороны Mega:

  • Слабость генератора случайных чисел, используемого Mega при создании RSA-пары (создатель Cryptocat, Nadim Kobeissi, долго и зло проходился по их генератору в твиттере)
  • Общая сложность системы и некоторая амбивалентность документации
  • Явное указание на наличие дедупликации в TOS («Our service may automatically delete a piece of data you upload or give someone else access to where it determines that that data is an exact duplicate of original data already on our service. In that case, you will access that original data»)

Важность последнего пункта стоит обсудить особо. Дело в том, что обычно возможность дедупликации шифртекстов достигается путем конвергентного шифрования (похожий подход используется в сервисе Bitcasa, а также, в несколько более сложном виде, в распределенной файловой системе Tahoe-LAFS). Сущность данного подхода состоит в том, что шифрование реализовано так, чтобы одинаковые открытые тексты давали одинаковые шифртексты (иногда с некоторыми оговорками). С одной стороны, это может быть по-своему неплохо, так как позволяет реализовать дедупликацию. Но с другой стороны, конвергентное шифрование может довольно здорово ударить по столь драгоценной privacy, поскольку позволяет заинтересованным лицам узнать, есть ли на сервисе дубликат некоего файла, при условии что у них самих он уже есть в незашифрованном виде (если вы понимаете о чем я…). А это нехорошо. Очень нехорошо.
Позднее, комментируя статью «Researchers Warn: Mega's New Encrypted Cloud Doesn't Keep Its Megasecurity Promises» в Forbes, сооснователь Mega Bram van der Kolk заявил, что дедупликация происходит на уровне отдельно взятых файлов и возможна только в случаях когда пользователь «загружает тот же файл зашифрованный тем же ключом» или при импорте существующего файла с помощью файл-менеджера. Однако, в пользовательских комментариях к статье довольно быстро стали звучать возражения, связанные с тем, что оба эти сценария скорее всего будут весьма редкими, а значит, подобного рода дедупликация является экономически нецелесообразной и вряд ли стоит усилий по написанию специального (и, в общем-то, непростого) кода.
Так что ситуация с дедупликацией остается немного странной.

Помимо обсуждения дедупликации, статья Forbes содержит несколько довольно-таки резких комментариев (в частности, упомянутый выше Nadim Kobeissi заявил Forbes следующее: «если честно, у меня сложилось впечатление что это программировал я сам, в 2011 году, будучи при этом пьяным»). Особо следует отметить точку зрения Matthew Green (профессора криптографии в Институте Информационной Безопасности им. Джона Хопкинса), осудившего всю практику шифрования силами одного лишь яваскрипта в целом – «Верификация javascript'ом самого себя подобна попытке подтянуть себя вверх за шнурки. Ничего не выйдет». Интересно, что Green не первый, кто заговорил о фундаментальной уязвимости браузерной javascript-криптографии – тезис о ненадежности таких систем был изложен еще в 2011 году специалистами из Matasano Security.

Вежливо, но сурово раскритиковали Мегу и их коллеги по цеху из SpiderOak, опубликовав очень интересную статью об особенностях основ «Мега криптографии». В ней они указывают на крайнюю слабость самопальной функции деривации ключа, примененной командой Доткома при преобразовании пароля в мастер-ключ, используемый для дальнейшей шифрации асимметричного ключа (кстати, кое-кто уже состряпал утилиту для брутфорса хешей Меговских паролей, которые содержатся в ссылке подтверждения регистрации) и уязвимость процедуры аутентификации к реплей-атакам.

SpiderOak обещают продолжить изучение архитектуры Mega с обязательной публикацией (вероятно, сочных) результатов.

Ну и наконец, на сладкое, добрые прохожие из fail0verflow team обнаружили, что в механизме валидации компонентов страницы, используемом Mega (том самом механизме, о фундаментальной ненадежности которого говорил Matthew Green) имеется откровенно хрестоматийная ошибка – вместо криптостойкой хеш-функции используется СВС-МАС. Для тех, кто не очень знает толк в криптографических извращениях, стоит наверное пояснить, что СВС-МАС является аутенфикационным кодом сообщения (а отнюдь не хешем в строгом смысле слова), и использовать его в качестве хеша вредно для здоровья (пользователей), ибо позволяет «сильному» оппоненту (например, оператору CDN) осуществить хищение пользовательских ключей.
Mega отреагировали на найденную fail0verflow уязвимость крайне оперативно, и в настоящий момент используют SHA-256…Однако, наличие такого грубого ляпа у сервиса, гордящегося своей «криптографичностью», не может не тревожить.

Ну вот наверное и все на сегодня.

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

[UPD]
В ответ на разгоревшуюся дискуссию, Мега организовала программу финансового поощрения «ответственных прохожих», и планирует платить награды за найденые баги.

На награду могут претендовать баги, позволяющие
  • удаленное выполнение кода на сервере Мега (включая SQL-injection)
  • удаленное выполнение кода в клиентском браузере (XSS-ки и.т.п.)
  • скомпрометировать криптографическую модель безопасности, манипулировать данными и ключами
  • обойти управление доступом, осуществлять несанкционированную перезапись и уничтожение ключей и пользовательских данных
  • подвергнуть угрозе пользовательские данные в случае захвата привязанного к аккаунту почтового ящика

Награда может достигать 10 000 евро.

Вкусно? Не совсем…

Есть еще ограничения, а именно: мега не будет платить за баги, требующие для использования очень больших вычислительных мощностей (что разумно), баги носящие условно-академический характер (что неблагоразумно, ибо как завещал тов. Шнаер, «Attacks always get better; they never get worse»), а также RE/DOS-уязвимости (что, мягко говоря, странно, ибо такие атаки ну никак не относятся к категории проблем, о которых нормальный хозяин веб-сервиса хотел бы узнать «по факту применения») и атаки требующие (неопределенно) большое количество запросов к серверу.

Откровенно настораживает отношение Меги к проблеме недостаточного количества энтропии при генерации ключей, которую Мега отнесла к «академическим» проблемам, и потребовала «показать реальную уязвимость» (На всякий случай напоминаю, что «недослучайные» RSA ключи это весьма серьезно). К сожалению, криптографические проблемы нельзя решить путем методичного самовнушения про «отсутствие реальной уязвимости»…

Также мега аккуратно обошла вопрос относительно возможной идентификации хранимых шифртекстов (то есть идентификации контента без расшифровки, силами дедупликационного механизма или других архитектурных особенностей), в особенности обладателями копии плейнтекста (ну, вы понимаете, о ком я)

В целом, все это оставляет смешанное впечатление — хотя сумму в 10 000 евро маленькой назвать нельзя, условия мероприятия оставляют некоторый неприятный осадок.
@bypasser
карма
41,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • +8
    «Скандалоинтриги и расследования» — чем не название для нового хаба.
    • +2
      странно, что тега нет :)
      • +9
        пофиксил
    • 0
      Можно сократить — «скандалоисследования»
  • +1
    Странно, что не упомянули в топике о security bug bounty на $13,500 — thenextweb.com/insider/2013/02/01/kim-dotcom-puts-up-13500-bounty-for-first-person-to-break-megas-security-system/
    • +4
      Просто когда статья писалась, сумму еще не объявили. Потом статья лежала в песочнице, и как только добрый прохожий дал мне инвайт, я ее сразу запостил.

      Могу дотачать [UPD] в конце, только вот разберусь получше в условиях (За что именно платить будут. Просто если за любой security-баг, то это много. А если за баг, позволяющий красть ключи/идентифицировать файлы/ итп. то это сущие гроши)
    • 0
      дотачал [UPD]. Условия bounty немного скользкие, а уж про RNG я и вовсе молчу
  • +6
    А учитывая биографию Доткома — он уже кидал партнёров и клиентов сливая их данные «кому надо», я бы держался от «Меги» подальше.
    • +11
      Правильная Криптография™* должна защитить юзеров даже если хозяин сервиса полный негодяй и агент Кровавой Гебни ;-)

      _______
      *В вакууме
      • 0
        К правильной криптографии нужна цепочка анонимных прокси, чтобы Мега не смогла выдать ваш IP.
        • +1
          Разумеется. Я собственно на это «вакуумом» и намекал
  • +2
    Извините, что немного не по теме. Но почему с Мегой нормально работает только Хром? На днях разместил там пару файлов для своих знакомых, так никто не смог скачать… у всех Оперы и Фаерфоксы либо тупят на 10-15%, либо показывают 100% и ничего не происходит. Сам сижу на Фаерфоксе, попробовал скачать — 100% и ничего. Поставил Хром — 100% и предлагает сохранить файл…
    П.С. Версии Фаерфоксов и Опер либо последние, либо даже тестовые… но все равно ни в какую.
    • +1
      Во всем виноват Чубайс File System API

      Остальные браузеры такие гитики не умеют. Да, Дотком не стал ждать пока требуемый функционал станет стандартом.

      P.S.:
      Помните как в начале 90х игры запускали, да «чтоб с звуком» :)?
      • 0
        Скоро появятся сторонние клиенты
        • +2
          Со сторонним клиентом не интересно.

          «Mega-через-сторонний-клиент» — это такой странноватый SpiderOak.
      • +1
        <Офтопик>
        Спасибо за ссылку.
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
    • 0
      Вверсия flash-плеера для firefox последняя, mega предлагает его обновить — на него же.
      Был позарез нужен файл, залитый именно на mega — пришлось ставить chrome.
      Непорядок!
      Скачал — снес — забыл!
  • +13
    Мне кажется криптография в меге вовсе не для надежной защиты данных, а только затем, чтоб к ним правообладатели не приставали, теперь они могут честно сказать, что понятия не имеют что у них хранится.
    • 0
      Нуууу… это если дедупликация у них и правда «как вещает van der Kolk» (только толку от такой экзотичной дедупликации с гулькин нос, ибо пользователей которые «знают толк в импорт-экспортных извращениях» будет немного)

      А если дедупликация у них «как у других криптолюдей» (т.е. «как у Bitcassa» ;-) ) то правообладатели очень даже пристанут (но зато место получится сэкономить).

      И вообще, в прошлый раз они запалились не только и не столько потому, что Кровавая Гэбня доказала «наличие» незаконного контента (найти доказательства наличия онного контента в новой, крипто-меге, поверьте, будет не так уж и сложно, особенно если добрые люди сначала зальют его туда, а потом выложат ссылку-с-ключом), а еще и потому что много и не по делу болтали в email (ну и «контент» недотирали, если верить Гебне)
  • +2
    я думаю Мега — только первая ласточка, демонстрация принципа. решения, которые будут использовать проверенное шифрование и с возможностью хостить где угодно и как угодно — не за горами.
  • 0
    Я думаю со временем допилят, это в их интересах.
    Ну и как вариант, другие начнут делать конкурентные сервисы.
    • 0
      Вообще, если честно, мое несколько поверхностное предварительное впечатление от криптографии в Mega.co.nz сводится к тому, что основная проблема носит фундаментальный, я бы сказал стратегический характер.

      Дело в том что Мегачка весьма сложно устроена — заметно сложнее чем «типовой» файловый хостинг (а онные, как понимаете, даже в самой «наивной» реализации отнюдь не фунт изюма). С точки зрения создания «безопасной» и «надежной» системы это не есть гут, ибо вероятность сбоя системы пропорциональна числу «узлов», в которых сбой (ошибка) может произойти. Сложность архитектуры, следовательно, имеет тенденцию к антагонизму по отношению к «безопасности» системы («навороченное — навернется!») а также к усилиям по устранению недоработок (чем сложнее устроено, тем сложнее анализировать).

      А вообще идея криптовать в javascript… она красивая, хоть и очень спорная с строгих позиций «серьезной» безопасности.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      oops :)
      привычный вывих — все время пишу их с двумя «с»
  • 0
    Эти сволочи не сделали восстановление пароля. Случись что — и песец рулю. В моём случае после полугодового перерыва мега отказывается принимать пароль (копипащу, так что гарантированно правильный). И чо?

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