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

в 14:12, , рубрики: Mega, Mega.co.nz, безопасность, безопасность веб-приложений, информационная безопасность, Ким Дотком, криптография, метки: , , , , ,

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

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

Автор: bypasser

Источник

Поделиться

* - обязательные к заполнению поля