Хак-форум Damaga готовится к сливу БД форума. Добавил функцию шифрования и удаление личной переписки

  • Автор темы Автор темы ADMIN
  • Дата начала Дата начала

ADMIN

Administrator
ADMIN
Регистрация
18 Окт 1989
Сообщения
1,408
Реакции
93
Баллы
48
☑ ДЕПОЗИТ
0$
Хакеры с форума Damaga пришли к выводу что защититься от взлома невозможно, и нужно быть готовым к тому, что база данных форума будет слита, поэтому предприняли меры защиты от такой утечки, путем добавления функции шифрования и удаление личной переписки из базы форума.
image-54-1024x470.png

Ниже описание с самого форума, источиник: http://damaga377*****.onion/forum/threads/58204/
Один из наших выводов будет таким, что скорее всего, на том или ином этапе развития форума, утечки базы избежать нельзя. Значит наша задача максимально её обесценить! Никаких айпи-адресов (мы в Торе), никаких емейлов, никаких старых ников, никакой коммерции с финансовыми идентификаторами. Но что делать с личкой? Шифровать!

Представляем вашему вниманию нашу систему шифрования и удаления форумной лички!

Обзор функциональности

[+]
Было создано полностью клиентское шифрование на основе либы OpenPGP.js в связке с Argon2id и DOMPurify.

[+] Алгоритм шифрования: X25519 (Curve25519/Ed25519).

[+] Реализованы Proof-of-Posession подпись, Commitment и их криптографическая проверка. Реализованы Safety Number(s) по схеме Signal / Matrix.

[+]OpenPGP паддинг и application based паддинг с использованием алгоритма Padmé для всех сообщений и файлов.

[+] Защита от XSS и сниффинга на нескольких уровнях:
  • Использование Trusted Types;
  • Cтрогая CSP (Content Security Policy) на страницах переписки;
  • DOMPurify в качестве санитайзера HTML;
[+] Реализована TOFU модель (Trust-On-First-Use) и её проверка.

[+] Доступен аудит ключей для каждого собеседника (история замены, подмены, удаления). Реализована обязательная верификация (ключа) второй стороны ПЕРЕД шифрованием.
image-23-1024x288.png

.
image-24.png

.
image-25.png

[+] Реализована функция удаления переписки:
* АВТО: вы задаете таймер при создании переписки, когда она будет удалена, опционально – от 1 минуты до 1 года, значение по-умолчанию – 10 дней;
image-26-1024x175.png

.
image-27-1024x67.png

* РУЧНАЯ: остается возможность ручного запроса на удаление переписки к вашему собеседнику (-ам), если собеседник (-и) игнорирует (-ют) запрос – переписка удаляется через 120 дней, если хотя бы 1 собеседник отменяет запрос – вы получаете уведомление об этом, а переписка остается в своем жизненном цикле.
image-28-1024x184.png

.
image-29.png

.
image-30.png

[+] Возможность исключить ваш ключ при шифровании исходящих сообщений. В этом случае отправленные сообщения никогда не будут доступны для вас (только для ваших собеседников). Пример: компрометация переписки через сессию + пароль = невозможность прочитать именно отправленные вами сообщения и файлы.
image-31.png

[+] Полная поддержка форумного форматирования: полужирный, курсив, подчеркнутый, зачеркнутый, размер шрифта, шрифт (может быть использован для определения ОС при утечке скриншотов пользователя), цвет текста, список, выравнивание, формат абзаца, ссылка, цитата, таблица, линия (hr), размытый текст, спойлер, код (без подсветки), инлайн код.
image-32-797x1024.png

[+] Убран функционал, мешающий или создающий возможности для компрометации зашифрованного общения: инлайн изображения, смайлики, предпросмотр, черновик, реакции на сообщения, медиа, сторонние изображения. Возможно использовать вложения.

[+] Добавлена поддержка шифрования и расшифровки вложений. Имена файлов скрываются для сервера, но для второй стороны сохраняется оригинальное название файла после расшифровки.

Внимание! В вложения можно загрузить что угодно, хоть .exe файл (в браузере он, конечно, не выполнится). Именно поэтому добавлено всплывающее предупреждение на все потенциально опасные расширения и все внешние ссылки.* РУЧНАЯ: остается возможность ручного запроса на удаление переписки к вашему собеседнику (-ам), если собеседник (-и) игнорирует (-ют) запрос – переписка удаляется через 120 дней, если хотя бы 1 собеседник отменяет запрос – вы получаете уведомление об этом, а переписка остается в своем жизненном цикле.
image-33-1024x878.png

.
image-34-1024x918.png

Вопросы

[?]
Почему именно OpenPGP.js?
Потому что это хорошая, популярная, проаудиченная и обкатанная либа, которую обновляют (например, её используют ProtonMail, Mailvelope и FlowCrypt).

[?]Почему не libsodium?
OpenPGP.js изначально создан для асинхронной доставки сообщений нескольким адресатам, в отличии от libsodium. Да, libsodium более прост в реализации без допущения ошибок и имеет WASM версию. Ставка сыграла в сторону OpenPGP.js из-за специфики форумного общения и понятности для большинства работы с PGP, а также прозрачности в либах и реализации шифрования – любой с легкостью сможет просмотреть JS файлы.

[?]Почему не самописная либа или использование альтернативного алгоритма, например ShangMi2?
Потому в команде нет Эйнштейна и Эпштейна. А ещё потому что китайская эллиптическая кривая SM2 обьективно хуже, медленнее, и возможно имеет или не имеет закладку из-за своей непрозрачности в выборе параметров.

[?]Почему не свой алгоритм?
Потому что в команде нет Николая Дурова (уже были вбросы о том, что шифрование в телеграме “взломали”). Если серьёзно – криптография, это вещь в которой очень легко ошибиться даже при настройке готовых алгоритмов, не говоря уже о создании собственных. Для создания собственного алгоритма необходима высшая компетенция, примерно 2-3 года и желательно команда, которая будет делать аудит этого в 90% случаев посредственного алгоритма.

[?]Почему не алгоритм RSA 4096?
Потому что X25519 (Curve25519/Ed25519) в ~60 раз быстрее, ФОРМАЛЬНО менее криптостойкий всего на 10-15 бит (но всё еще ~128 бит) и на выходе намного меньше размером.

[?]Почему не ML-KEM и другие постквантовые алгоритмы?
Потому что в OpenPGP.js пока не реализованы алгоритмы постквантовой защиты, а официальный RFC находится в статусе черновика. Если сделают – внедрим.

[?]Зачем нужен Argon2id?
Потому что это золотой стандарт современного хэширования паролей, практически нейтрализующий брут на видеокартах/асиках (делающий брут очень дорогим).

[?]Зачем нужен DOMPurify?
DOMPurify
– обкатанный и проаудиченный Cure53 санитайзер HTML от XSS атак, т.к. шифрование поддерживает *большое множество* форумного форматирования.


Особенности

[!]
В браузере хранится почти всё – зашифрованные приватные ключи, публичные ключи, пиннинги, commitment, фингерпринт, время. В зависимости от данных в браузере и формируются варны. Приватные ключи также зашифрованы через видоизмененный пароль пользователя и не передаются на сервер. Все данные в localStorage и sessionStorage дополнительно зашифрованы.

[!] Имеется серверная проверка на зашифрованное тело, на наличие всех собеседников (их ключей).

Что видно в базе:
  1. ID переписки.
  2. ID переписывавшихся.
  3. Количество сообщений.
  4. Публичный ключ.
  5. PoP подпись.
  6. Commitment.
  7. Шифротекст и зашифрованные файлы.
  8. Расширение загружаемого файла, если оно имелось на момент загрузки.
Чего никогда не видно в базе и не передаётся на сервер:
  1. Пароль.*
  2. Приватный ключ.*
  3. Локальные данные такие как верификация и отзыв траста для ключей (собеседников).
  4. Незашифрованный плейнтекст не сохраняется в базу, но всё ещё можно сделать HTTP запросы без включенного JS.
Скриншоты:
Таблица с ключами и др. данными
image-35-1024x566.png

Таблица с шифротекстом
image-36-1024x832.png

Список вложений из админки
image-37-1010x1024.png

Что будет, если нажать на “посмотреть в контексте” с админского аккаунта:
image-38-1024x83.png

* На XSS тоже было (псевдо) шифрование с использованием обычного AES256+SHA256, но оно было полностью сервер-сайд (хоть это и позволяло пользоваться им без JS), а пароли для переписок возвращались пользователю уже готовые, т.е. сервер уже имел в памяти/БД пароль – это абсолютно небезопасное архитектурное решение, полностю построенное на доверии к форуму. Таким образом, не видя серверную реализацию до сих пор невозможно понять:
  1. Имелось ли вообще шифрование, или это всё было буфаторией.
  2. Не снифились ли ключи/пароли.
  3. Были ли проблемы в реализации, позволяющие снифать ключи/пароли.
Логика работы

Шифрование основано на алгоритме X25519 (Curve25519/Ed25519), ключи генерируются (деривируются) от заданного юзером пароля+соли, это может быть 123 или же ?Túr¡º<'/±.¸p¼¹,àØÛ®ZF¶Kâqéw<úÀj´¦öèF©¿®À%mÓQ¤Ë3ÀÎrÏ%ixÕæõ²4ÂC+dXå°f}fF@bÊ'âªÿSð"?õå%Êæ\!9ÖAç.`ÃÚ®êZ{KÃL$bÚ<ÒßíâFÛNæ.}]!rh<pKÅzc.
image-39.png

Кнопка генератора надёжного и рандомизированного пароля (минимальная энтропия ~322 бита) находится рядом с формой ввода пароля:
image-40.png

Результат работы генератора паролей:
image-41.png

Как деривируется ключ и какую схему проходит пароль: Пароль + Соль -> Argon2id (WASM|Worker) -> [Worker: HKDF (Web Crypto API) -> DRBG -> NaCl -> OpenPGP.js]
Далее публичный ключ, фингерпринт, дата создания, commitment и PoP загружаются на сервер.

После ввода пароля и деривации ключа, инициатор переписки должен дождаться того же самого от своего собеседника (-ов) и верифицировать его (их) ключ (ключи).
image-42.png

.
image-43.png

При создании первого сообщения вы увидите текст с приглашением в зашифрованную переписку с ссылкой на эту тему и на тему обсуждения (в случае возникновения каких-то вопросов).
image-44.png

При вводе неправильного пароля, можно СБРОСИТЬ ключ.
image-45.png

При этом, у собеседника, сбросившего ключ, все старые сообщения будут недоступны:
image-46.png

У остальных же собеседников будут такие предупреждения о смене ключа:

1) Снова появится окно подтверждения ключа – там же можно будет заметить смену фингерпринта, смену Safety Number.
image-47.png

В этом окне можно НЕ верифицировать новый ключ – в таком случае шифроваться сообщения для данного ключа (пользователя) не будут:
image-48-1024x208.png

2) Появятся TOFU предупреждения на старые и новые сообщения:
image-49.png

3) Появится commitment предупреждение:
image-50-1024x207.png

4) Появится предупреждение о том, что ключ был сменён, а также красное предупреждение на все новые сообщения:
image-51-1024x472.png

.
image-52-1024x453.png

5) В историю изменений ключей будет добавлена запись:
image-53.png

Последний вариант – подмена ключа через БД.

Это может пригодиться для ситуации, где более двух человек в переписке: Розовый Мишонок, Дрявый Кувшин и Кончелыжник. Кончелыжника взломали или подменили ключ, Розовый Мишонок и Дрявый Кувшин не стали верифицировать его новый ключ, но продолжили писать в переписке. В это же время Кончелыжник имеет шанс доказать свою аутентичность (например через использование публичного ключа который В ПРОФИЛЕ), т.к. он всё еще может шифровать для ключей Розового Мишонка и Дрявого Кувшина).
 
Автоматический гарант это финансовая безопасность: Покупатель может быть уверен, что его деньги не попадут к продавцу до того, как он получит и проверит товар или услугу. Продавец, в свою очередь, защищен от не оплаты, так как гарант подтверждает наличие средств у покупателя до начала выполнения обязательств.
Назад
Сверху