Pull to refresh

Mega: обзор (не)безопасности

Reading time 5 min
Views 94K
Добрый день!
Будучи простым российским… неважно кем, я обычно не пишу статьи, а тихонько их читаю (мы, неважно кто, любим тишину). Однако, недавно мое внимание привлекло обилие англоязычных статей о (не)безопасности милого душе сервиса 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 евро маленькой назвать нельзя, условия мероприятия оставляют некоторый неприятный осадок.
Tags:
Hubs:
+60
Comments 27
Comments Comments 27

Articles