На первый взгляд схема шифрования, показанная в общих чертах на скриншоте выше, действительно выглядит надежно. Приватный ключ генерируется на основе пароля пользователя и случайного набора цифр и хранится только на клиенте. Его производные в дальнейшем применяются для шифрования файлов, так что даже сам хостинг, правоохранительные органы или злонамеренный атакующий, получивший доступ к инфраструктуре, не могут увидеть содержимое этих файлов. На практике выяснилось, что пусть обойти систему шифрования и не легко, но есть надежный способ расшифровать файлы. Для этого достаточно, чтобы пользователь авторизовался на сервисе не менее 512 раз.
Как и любая работа по криптографии, данное исследование изобилует сложными терминами. Но базовое объяснение проблемы такое: в Mega позаботились о защите данных, но недостаточно хорошо защитили ключи шифрования. Была смоделирована атака, когда либо администрация хостинга хочет расшифровать файлы, либо контроль над инфраструктурой захватили третьи лица. Теоретически можно представить и атаку типа Man-in-the-Middle. Ключевой ошибкой алгоритма шифрования стало то, что серверное и клиентское ПО Mega принимает данные, зашифрованные неверным ключом, и пытается работать с ними вместо того, чтобы просто отбросить.
В результате появляется возможность провести атаку типа . Таким текстом-приманкой может стать идентификатор сессии. Контролируя серверную инфраструктуру, можно выбрать произвольное значение идентификатора, зашифровать его с помощью неверного ключа и отправить клиенту. Клиент попытается расшифровать значение с помощью правильного приватного ключа и отправит результат обратно на сервер. Результат такой работы позволяет определить базовые параметры приватного ключа, а именно — значение простого числа, которое было использовано при его генерации. Точнее, каждый запрос позволяет определить, что секретное большое число больше или меньше произвольно выбранного перед началом атаки. 1023 подобных сессии, и мы можем узнать точное значение.
Оптимизация процесса атаки (в том числе с использованием криптографического ) позволяет сократить количество попыток до 512. Подведем итог: если пользователь 512 раз авторизовался на сервисе, и все это (достаточно длительное) время сервис был скомпрометирован, гипотетические организаторы атаки получают в свое распоряжение ранее им неизвестный приватный ключ.
Дальше исследователям удалось доказать, что приватный ключ действительно позволяет сгенерировать производные ключи, которые используются для шифрования файлов, и расшифровать приватную информацию. Можно также «подкинуть» компрометирующие документы в аккаунт пользователя так, что они будут неотличимы от тех, что он загрузил сам. После получения копии исследования представители Mega начали работать над патчем, который также выпустили на прошлой неделе, сопроводив его достаточно подробным . Патч делает невозможной проведение предложенной атаки (как — не уточняется, возможно, теперь клиентское ПО действительно отбрасывает некорректно зашифрованные данные).
Все закончилось хорошо? Не совсем! Во-первых, исследователи разработали другой способ, никак не зависящий от первого, реализующий так называемую . Этот способ требует еще больше взаимодействий клиента с сервером (конкретно — 131 072). Во-вторых, исследователи на основе фактов делают вывод, что отдельными патчами проблему до конца не решить, требуется масштабное обновление инфраструктуры.
Почему? Предположим, что все это время в компании Mega был инсайдер, который знал о данной (непростой) уязвимости и мог в течение длительного времени (512 авторизаций!) проводить атаку на конкретных пользователей, в результате чего смог реконструировать приватные ключи. Уязвимость закрыли, но ключ-то не изменился! Это значит, что злоумышленник-инсайдер по-прежнему имеет доступ ко всем существующим и новым файлам, которые скомпрометированный пользователь загружает на сервер.
Принудительно сменить ключ шифрования всем пользователям нельзя: они потеряют доступ к уже загруженным файлам. Получается, требуется масштабная операция, когда все пользователи Mega скачивают свои файлы, генерируются новые ключи, а потом файлы загружаются обратно. При максимальной утилизации всего интернет-канала Mega в 1000 гигабит в секунду на обновление 1000 петабайт файлов (уже сохраненных в Mega) уйдет полгода!
То есть эту конкретную проблему они решили, а что насчет других уязвимостей, которые могут быть найдены в будущем? Нужно реализовать абсолютно иную архитектуру, позволяющую решать проблемы «на лету», эффективно и с сохранением данных пользователям обещаний. Набор таких технологий существует и называется «аутентифицированное шифрование с присоединенными данными», или . Но здесь у ученых и бизнеса, похоже, разошлись мнения. Бизнес тоже можно понять: судя по всему, применение сквозного шифрования «по науке» потребует, по сути, построить новый сервис параллельно существующему и потом поддерживать оба. При этом обнаруженная атака, хоть и реализуема на практике, остается маловероятной: потребовались бы серьезные ресурсы в течение длительного времени, чтобы действительно что-то расшифровать. И не для всех пользователей, а для кого-то одного.
Что еще произошло:
Издание TechCrunch об уязвимости в (только этого нам и не хватало) «умных джакузи» — горячих ваннах с пузырьками, зачем-то подключенных к Интернету. Уязвимость была тривиальная: разработчик джакузи использовал сторонний сервис сбора статистики и случайно забыл закрыть панель администратора.
Исследователи «Лаборатории Касперского» активность APT-группировки ToddyCat, атакующей цели как в Европе, так и в странах Азии. Группа использует уникальное вредоносное ПО, а в декабре 2020 года атаковала серверы Microsoft Exchange при помощи неизвестного эксплойта.
Еще одно исследование «Лаборатории Касперского» подробно тактику наиболее известных группировок, занятых вымогательством при помощи шифрования данных.
Выпущенный на позапрошлой неделе набор патчей для продуктов Microsoft, как выяснилось, внес ошибки в работу Windows на архитектуре ARM. Для решения проблемы был внеочередной патч, восстанавливающий в том числе возможность авторизации на серверах Azure Active Directory.
