В наше время большинство пользователей хранят файлы в том или ином облачном хранилище: Google Drive, Яндекс.Диск, Dropbox, OneDrive и т. д. Благодаря низкой стоимости такие сервисы очень популярны. Их аудитория оценивается более чем в 4 млрд человек, а объём хранимых данных — порядка экзабайта. Почти все провайдеры шифруют файлы на своих серверах. Но если сам провайдер скомпрометирован, такая система не обеспечивает никакой защиты.
Поэтому отдельные сервисы реализовали сквозное шифрование (E2EE), когда не сервер, а пользователь контролирует ключи шифрования.
В основном, эти сервисы предлагают услуги для коммерческих клиентов. Например, MEGA, Nextcloud, Sync, Tresorit, Seafile, Icedrive и pCloud. К сожалению, реальность далека от рекламных заявлений. Независимое исследование показало, что все перечисленные провайдеры страдают от уязвимостей и архитектурных изъянов.
Хотя сервисы со сквозным шифрованием занимают небольшую долю на рынке хранения данных, некоторые из них используются государственными службами и общественными организациями. Например, Nextcloud используют в правительствах Германии и Сербии, а также организации Amnesty International. Сервис Sync использует правительство Канады, Канадский Красный Крест, штаты Вермонт и Северная Дакота. В списке клиентов Tresorit значатся SAP, Pfizer и Allianz. И так далее.
Поскольку многие важные организации используют облачные хранилища E2EE, анализ их безопасности становится насущной проблемой. Например, недавно были обнаружены уязвимости у двух самых популярных провайдеров: MEGA и Nextcloud. В связи с этим возникает вопрос: есть ли на рынке провайдеры с лучшей защитой?
Новое исследование отвечает на этот вопрос скорее отрицательно. Оно также показывает недостатки, которые характерны для всех провайдеров и которые создают уязвимости в их протоколах.
Иерархия ключей у всех исследованных провайдеров. Стрелки со звёздочками указывают на связь «один-ко-многим». Весь ключевой материал, который не является производным от чего-либо другого, неявно генерируется с помощью соответствующей функции генерации ключей, источник
На диаграмме ниже отражена общая сводка по уязвимостям и утечкам у провайдеров облачной криптографии:
†Только в консольном клиенте. В большинстве браузеров реализована адекватная проверка открытых ключей, что предотвращает атаку
*Только после инъекции папок
**Злоумышленник может создать новый файл только из фрагментов других файлов, поэтому атака не совсем полноценная
В таблице слева направо перечислены следующие уязвимости:
- Использование неаутентифицированных секретных ключей (или их частей)
- Использование неаутентифицированных публичных ключей
- Несанкционированная смена протокола в сторону более слабого
- Утечка ссылок на файлы
- Неаутентифицированное шифрование
- Неаутентифицированное разбиение файлов на части (chunking)
- Изменение имён файлов и самих файлов
- Изменение метаданных
- Инъекция файлов
- Инъекция папок
- Утечка оригинальных данных (расшифровка)
- Утечка метаданных
- Утечка структуры папок
Уязвимости различаются по степени серьёзности. Наиболее серьёзными можно назвать те, в которых вредоносный сервер (то есть злоумышленник на скомпрометированном сервере) может внедрить свои файлы, подделать данные файла или получить прямой доступ к расшифрованной информации. Примечательно, что многие из раскрытых атак одинаково действуют на нескольких сервисах. Это показывает общие проблемы в криптографических конструкциях.
В целом, исследователи выявили десять классов атак. Результаты опровергают маркетинговые заявления провайдеров и ставят под сомнение функции сквозного шифрования в их сервисах.
Статья «Облачные хранилища со сквозным шифрованием на практике. Сломанная экосистема» ("End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem") от авторов из Швейцарской высшей технической школы Цюриха представлена на конференции ACM CCS 2024 в октябре 2024 года, а также опубликована на сайте «Облачные хранилища не работают» (https://brokencloudstorage.info/).
Комментарии (10)
aborouhin
12.01.2025 17:51Пробежался по оригинальной публикации по диагонали. Насколько из неё понял - авторы берут решения, предназначенные для построения частных файловых облачных хранилищ, а дальше почему-то анализируют реализуемость атак на пользовательские данные со стороны злонамеренного сервера. Что-то у меня в голове не складывается, в чём тут такая уж трагедия.
Если сервер у нас свой, доверенный, то злонамеренным он может стать только в случае взлома. При этом большинство описанных сценариев предполагают некую последовательность действий (изменение настроек сервера, данных и пр.), требующую длительного контроля за сервером. Сценарий печальный, но IMHO, компрометация пользовательских устройств куда более вероятна. Да и E2E шифрование в частных облаках в любом случае имеет довольно ограниченное применение, т.к. надо обеспечить общий доступ к данным и их надёжный бэкап. Так что всё равно в вопросе конфиденциальности большей части данных приходится полагаться на шифрование на стороне сервера.
А если речь о том, что проанализированный софт используется какими-то публичными облаками, - так ему не надо никаких уязвимостей содержать, злонамеренный администратор публичного облака что угодно изменит/перехватит/подменит/пр. сам.
Ну т.е. в целом на определённые мысли всё это навело, что мне в своём Seafile ещё надо бы помониторить дополнительно, - но ничего такого катастрофического, чтобы говорить, что прямо всё сломано, я не увидел.
mentin
12.01.2025 17:51По-моему это не про частные хранилища. Пробежал по ссылкам - вижу опцию self-hosting у Nextcloud, и у Seafile конечно открытый код можно у себя хостить. У остальных кажется только в их облаке, а если есть открытый код - то только клиентов.
aborouhin
12.01.2025 17:51Мне как раз из всего списка были знакомы Nextcloud и Seafile, последний сам использую. Глянул, да, другие действительно - публичные облака. Тогда вообще не понимаю, ни зачем совершенно разные решения сваливать в одну кучу, ни как оценивались сценарии атак для публичных облаков, серверная часть которых для нас - чёрный ящик.
В любом случае, использование публичного облака - это вопрос доверия и оценки регуляторных рисков в большей степени, чем технических. Если не нужны функции общего доступа, делегирования, централизованного бекапа и восстановления и т.п. - можно шифровать локально (не средствами ПО публичного облака, а сторонними программами). Если нужны - или селф-хостим всё это счастье, или выбираем по принципу "компанию X вряд ли взломают, они точно не будут рисковать своей репутацией ради такой мелочёвки как я, и в текущей политической ситуации вряд ли выдадут данные по запросам из той страны, где я веду деятельность" - и надеемся, что угадали :)
mentin
12.01.2025 17:51Так смысл правильного сквозного шифрования - оно позволяет пользоваться публичным облаком, не доверяя ему. Мне должно быть плевать что у них за серверная часть, и какие там риски (кроме конечно потери данных) - клиентское шифрование не должно давать серверу, чтобы там не происходило, узнать много больше чем самая общая метадата - примерные объемы файлов, число пользователей и так далее, или подделать файлы.
Как в мессенжерах с e2e, никто не выкладывает серверную часть, но валидация клиентской части позволяет проверить, что может а что не может сделать сервер.
Статья годная - как раз сделали валидацию клиентской части, нашли интересные и часто не тривиальные проблемы.
aborouhin
12.01.2025 17:51При оперсорсной клиентской части - ещё допустим, но и то там нужен очень нетривиальный анализ всех исходников (и уверенность, что бинарники, которые 99,999% пользователей скачают готовые, а не будут собирать сами, собраны из тех самых исходников).
Но я так понимаю, у публичных облаков из перечня исследованных и клиентские программы закрытые. И как бы они там хитроумно ни реализовывали E2EE, что в этом толку, если где-то параллельно приватный ключик пользователя утекает на сервер (не обязательно прямо всегда, а, скажем, только при получении от сервера запроса - так что анализом трафика тоже не выявить).
А если мы предполагаем, что со стороны сервера до наших E2E-зашифрованных данных хотят недобросовестно дотянуться - то очевидно, что такому недобросовестному, и при этом закрытому публичному облаку проще именно такой бэкдор и внедрить, чем извращаться с подменой данных, брутфорсом слабых шифров и т.п. по схемам, описанным в статье. К тому же, именно к такому решению его с определённой степенью настойчивости могут подталкивать регулирующие органы соответствующей юрисдикции...
dersoverflow
12.01.2025 17:51и взрослые вроде люди... зачем разбирать сказки?
галочка на UI - это просто галочка. шифруйте сами локально. только так.
mentin
12.01.2025 17:51Они все шифруют локально. Они все делают при этом ошибки, раскрывающие часть информации и/или позволяющие серверу подменить часть информации (несмотря не шифрование).
aborouhin
12.01.2025 17:51Речь о том, что шифровать локально надо не средствами ПО облачного провайдера, а сторонним ПО (в первом же комменте предложили вариант, но их много, скажем у rclone есть бэкенд crypt, который можно в цепочку перед любым облаком поставить).
Но тогда теряются все возможности по общему доступу и централизованному администрированию, выше в комменте написал подробнее.
Ozkolok
Cryptomator?
Torpilleur
ещё можно Duplicati