Добрый день Будучи простым русским.
неважно кем, я обычно статьи не пишу, а читаю их спокойно (мы, неважно кто, любим тишину).
Однако недавно мое внимание привлекло обилие англоязычных статей о (не)безопасности уважаемого сервиса Mega. Поскольку в русскоязычной среде вопрос обсуждается менее бурно, решил предложить вашему вниманию небольшой дайджест публикаций о «скандальных интригах и расследованиях», которые в последнее время крутятся вокруг уф-службы.
Товарищ Дотком.
Должен сразу предупредить, что данная статья не содержит оригинальных исследований, то есть моих собственный мнения о криптографии в Меге, а лишь стремится проинформировать русскоязычного читателя о состоянии зарубежной дискуссии по этой теме.
Так, ArsTechnica одной из первых подняла тему Мегабезопасности, в публикации с забавным названием « Megabad: краткий обзор состояния шифрования Mega Несмотря на то, что статья не смогла избежать ряда нелепых журналистских ошибок (большая часть которых теперь исправлена и увековечена только в комментариях), автор справедливо отметил ряд довольно крупных огрехов со стороны Меги:
- Слабость генератора случайных чисел, используемого Mega при создании пары RSA (создатель Cryptocat Надим Кобейси долго и гневно перебирал их генератор в Твиттере)
- Общая сложность системы и некоторая неоднозначность документации
- Явное указание дедупликации в TOS ( «Наша служба может автоматически удалить часть данных, которые вы загружаете, или предоставить кому-либо доступ к тому месту, где она определит, что эти данные являются точной копией исходных данных, уже имеющихся в нашей службе.
В этом случае вы получите доступ к этим исходным данным» )
Дело в том, что обычно возможность дедупликации зашифрованных текстов достигается за счет конвергентного шифрования (аналогичный подход используется в сервисе Bitcasa, а также, в чуть более сложной форме, в распределенной файловой системе Tahoe-LAFS).
Суть этого подхода заключается в том, что шифрование реализуется так, что одни и те же открытые тексты порождают одни и те же зашифрованные тексты (иногда с некоторыми оговорками).
С одной стороны, это может быть по-своему хорошо, поскольку позволяет реализовать дедупликацию.
Но с другой стороны, конвергентное шифрование может стать настоящим ударом по столь драгоценной конфиденциальности, поскольку позволяет заинтересованным лицам узнать, существует ли на сервисе дубликат определенного файла, при условии, что он у них самих уже имеется в незашифрованном виде ( если вы понимаете, о чем я.
).
И это нехорошо.
Очень плохо.
Позже, комментируя статью « Исследователи предупреждают: новое зашифрованное облако Mega не выполняет свои обещания по мегабезопасности В Forbes сооснователь Mega Брэм ван дер Колк заявил, что дедупликация происходит на уровне отдельных файлов и возможна только в тех случаях, когда пользователь «загружает тот же файл, зашифрованный тем же ключом» или при импорте существующего файла с помощью файлового менеджера.
Однако в комментариях пользователей к статье быстро стали звучать возражения, связанные с тем, что оба этих сценария, скорее всего, будут очень редкими, а значит, такого рода дедупликация экономически нецелесообразна и вряд ли стоит затраченных на ее написание усилий.
специальный (и, в общем-то, не простой) код. Так что ситуация с дедупликацией остается немного странной.
Помимо обсуждения дедупликации, статья Forbes содержит и довольно резкие комментарии (в частности, вышеупомянутый Надим Кобейси рассказал Forbes следующее: «Честно говоря, у меня сложилось впечатление, что я это программировал сам, в 2011 году, будучи пьяным» ).
Особо следует отметить точку зрения Мэтью Грина (профессора криптографии Института информационной безопасности Джонса Хопкинса), который осудил всю практику шифрования с использованием одного лишь JavaScript — «Проверка самого себя Javascript — это все равно, что пытаться подтянуть себя за бутстрепы.
Ничего не получится» .
Интересно, что Грин не первый, кто говорит о фундаментальной уязвимости браузерной криптографии javascript — тезис о ненадежности таких систем был изложен еще в 2011 году.
специалисты Matasano Security .
Они вежливо, но жестко раскритиковали Мегу и их коллеги из SpiderOak , публикуя очень интересную статью об особенностях основ «Мега Криптографии».
В нем они указывают на крайнюю слабость самодельной функции получения ключа, используемой командой Dotcom при преобразовании пароля в мастер-ключ, используемый для дальнейшего шифрования асимметричного ключа (кстати, некоторые уже это сделали).
придумал утилиту для перебора хешей паролей Мега , которые содержатся в ссылке подтверждения регистрации) и уязвимость процедуры аутентификации к атакам повторного воспроизведения.
SpiderOak обещают продолжить изучение архитектуры Mega с обязательной публикацией (возможно, пикантных) результатов.
И напоследок, на десерт добрые прохожие из командыfail0verflow обнаруженный , что в механизме проверки компонентов страницы, используемом Mega (тот самый механизм, о фундаментальной ненадежности которого говорил Мэтью Грин) есть откровенно хрестоматийная ошибка — вместо криптостойкой хэш-функции используется SBC-MAS. Для тех, кто не особо разбирается в криптографических извращениях, наверное, стоит пояснить, что SBC-MAS — это код аутентификации сообщения (а не хэш в строгом смысле этого слова), и использовать его в качестве хеша вредно для здоровье (пользователей), поскольку позволяет «сильному» противнику (например, оператору CDN) украсть ключи пользователя.
Mega отреагировала на уязвимость, обнаруженную с помощьюfail0verflow, чрезвычайно быстро и в настоящее время использует SHA-256. Однако наличие столь грубого промаха со стороны сервиса, который гордится своей «криптографией», не может не беспокоить.
Ну вот, пожалуй, и все на сегодня.
Возможно, в будущем я продолжу публиковать научно-популярные обзоры скандальных интриг и расследований, связанных с безопасностью различных сервисов (не только Меги).
[УПД] В ответ на жаркие дебаты Mega организовала программу финансового стимулирования «ответственных свидетелей» и планирует выплачивать вознаграждения за найденные ошибки.
Баги, которые позволяют
- удаленное выполнение кода на сервере Mega (включая SQL-инъекцию)
- удаленное выполнение кода в клиентском браузере (XSS и т.п.
)
- скомпрометировать модель криптографической безопасности, манипулировать данными и ключами
- обход контроля доступа, несанкционированная перезапись и уничтожение ключей и пользовательских данных
- поставить под угрозу данные пользователя, если почтовый ящик, связанный с учетной записью, будет захвачен
Вкусный? Не совсем… Есть и ограничения, а именно: мега не будет платить за ошибки, требующие для использования очень больших вычислительных мощностей (что разумно), ошибки, носящие условно академический характер (что неразумно , ибо как завещал тов.
Шнаер, «Атаки всегда становятся лучше; они никогда не становятся хуже» ), а также уязвимости RE/DOS (что, мягко говоря, странно, ведь подобные атаки никоим образом не относятся к той категории проблем, о которых нормальному владельцу веб-сервиса хотелось бы знать «после факта приложение») и атаки, требующие (неопределенно) большого количества запросов к серверу.
Откровенно настораживает отношение Меги к проблеме недостаточной энтропии при генерации ключей, которую Мега отнесла к «академическим» проблемам и потребовала «показать реальную уязвимость» (На всякий случай напоминаю, что «неслучайные» ключи RSA это очень серьёзно).
К сожалению, криптографические проблемы невозможно решить методическим самовнушением об «отсутствии реальной уязвимости»… Мега также аккуратно обошла вопрос о возможной идентификации хранимых зашифрованных текстов (то есть идентификации контента без расшифровки, с использованием механизма дедупликации или других архитектурных особенностей), особенно владельцами копии открытого текста (ну вы понимаете, о ком я говорю).
) В целом все это оставляет неоднозначное впечатление – хотя сумму в 10 000 евро и нельзя назвать маленькой, условия мероприятия оставляют некоторый неприятный осадок.
Теги: #Мега #Мега #mega.co.nz #Ким Дотком #Криптография #безопасность #безопасность веб-приложений #скандальные интриги #расследования #информационная безопасность #Криптография
-
Логично, Но Незаконно
19 Oct, 24 -
Работа С Телом
19 Oct, 24
