Продолжение поста «Мессенджер MAX безопасен, но... смотря для каких задач!»⁠⁠6

Продолжение: а как можно сделать МАКС безопаснее? Можно ведь?

Все обнаруженные уязвимости и критичные технические детали были направлены команде MAX через официальную программу Bug Bounty на платформе Standoff 365 https://bugbounty.standoff365.com/programs/max. В статье намеренно опущены конкретные уязвимости и критические проблемы. Всё серьёзное — у разработчиков.

*** *** ***

После первого поста многим зашло, но некоторые написали примерно следующее: «Ну ты покритиковал, а что предлагаешь?».

Я посидел и подумал, а что я могу предложить? Можно ли сделать MAX реально безопасным для обычных людей, не ломая при этом то, что нужно государству?

Ответ: ДА можно.

Где-то это просто — буквально один компонент подключить. Где-то наивно и упирается в политику. Не хочу наговаривать на команды разработки современного РФ IT бизнеса, сделать можно... быстрее, а не за 2-3 года. Ладно, это отдельная тема для разговора.

Задача: МАКС должен быть безопасным, но при этом госорганы должны иметь доступ?

1. Зашифровать данные на устройстве

Решение существует и называется sqlcipher-android — https://github.com/sqlcipher/sqlcipher-android

Это шифрование базы данных, которое используется в индустрии уже много лет. Даже если кто-то скопирует файл базы, без этого конкретного телефона он бесполезен.

Мешает ли это госорганам? Нет. Сообщения на сервере остаются как были. СОРМ работает на серверной стороне, а не лезет в ваш телефон. Это защита от воров и мошенников, не от государства.

То же самое касается токенов авторизации и номера телефона, которые сейчас лежат в файлах без шифрования. Современный подход — Jetpack DataStore с шифрованием через Google Tink и хранением ключей в том же аппаратном модуле. Старый вариант (EncryptedSharedPreferences) уже признан устаревшим, но суть та же — данные на диске должны быть зашифрованы.

Я уверен, что разработчики MAX и сами это знают. Это не вопрос компетенции — скорее приоритетов. Но вот именно это стоило бы поднять в приоритете, потому что защищает от самых массовых угроз — вредоносных приложений (кражу телефона упоминать не стану, но тоже стоит, хотя кейс более редкий). Если мы конечно не хотим опять услышать очередную новость о СЛИВЕ данных в ближайшем будущем. (+ постараюсь не привязывать сюда политику - если вы понимаете о чём я).

2. Дать пользователю выбор: секретные чаты

Telegram сделал элегантный компромисс: обычные чаты доступны серверу (и, соответственно, по запросу — государству), а «секретные чаты» защищены сквозным шифрованием. Это по факту так работает. Тут можно бесконечно рассуждать "Телеграм точно сливает!" -- сливает? Не сливает? Доказано? Не доказано? По факту прямых пруфов нет. (именно речь про сквозняк).

MAX мог бы сделать так же. Обычные чаты — как сейчас, с транспортным шифрованием. Плюс опциональный режим «секретного чата» для тех, кому нужно обсудить что-то действительно приватное — медицинские вопросы, коммерческую тайну, личные переживания. -- ЭТО ДЕЙСТВИТЕЛЬНО станет достойным аргументом для внедрения MAX как государственного мессенджера на все уровни общества.

И тут самое интересное: MAX мог бы сделать свой протокол сквозного шифрования — полностью на российской криптографии. Вот, накидываю:

VKO ГОСТ Р 34.10 (RFC 7836) — для согласования общего секрета между собеседниками (протокол Диффи-Хеллмана на отечественных эллиптических кривых).

«Кузнечик» ГОСТ Р 34.12-2015 в режиме MGM — для шифрования сообщений с аутентификацией (256 бит, режим обеспечивает и конфиденциальность, и целостность).

«Стрибог» ГОСТ Р 34.11-2012 — для выработки ключей из общего секрета (KDF) и контроля целостности.

(простите, что длинно, но будет полезно для общего понимания)

Логика: при создании «секретного чата» телефоны собеседников генерируют эфемерные пары ключей, через VKO согласовывают общий секрет, из него через «Стрибог» выводят сессионные ключи, и дальше каждое сообщение шифруется «Кузнечиком» в режиме MGM. Для каждого сообщения — новый эфемерный ключ, чтобы компрометация одного ключа не раскрывала прошлые сообщения (так называемая «прямая секретность»). Плюс верификация собеседника через QR-код или числовой отпечаток — чтобы сервер не мог подменить ключи. В целом, можно сделать проще, без излишних усложнений и фантазий. Я не могу быть экспертом во всём.

Это не тривиальная задача — нужна грамотная криптографическая архитектура. Но все примитивы для этого существуют и сертифицированы. CryptoPro поддерживает все нужные алгоритмы. Полностью российское решение, соответствующее национальным стандартам. Безопасно? Да. Отечественное импортозамещение? Да.

Мешает ли это госорганам? Частично — но только для секретных чатов, которые пользователь явно выбирает. 99% переписок останутся в обычных чатах и будут доступны по закону. Зато пользователь получает выбор — и доверие к платформе. (Как бы я не был противником идеи, что государство не должно лезть в мои переписки, поэтому я сейчас пишу в реалиях 2026-го года. Пожалуйста, не хейтите меня за это).

Я понимаю, что это самый наивный пункт в списке. E2E в государственном мессенджере — это вопрос не технический, а политический.

3. Перестать собирать лишнее

В предыдущем посте я писал про MyTracker — встроенную аналитику от VK. Она умеет собирать номера телефонов, email, списки приложений, данные сенсоров, рекламные идентификаторы.

Вопрос не в том, собирает ли MAX всё это прямо сейчас. Вопрос в том, что SDK для этого уже встроен и может собирать что угодно по команде с сервера. Пользователь об этом не узнает и не может отказаться. ЭТО ВООБЩЕ ЗАКОННО? К слову, многие компании уже понесли тонны штрафов за это, даже имя согласия. РКН, вы это видели? Вы об этом в курсе?

Я отдаю себе отчёт, что MyTracker — это продукт VK Group, и его интеграция в MAX скорее всего не решение команды мессенджера, а корпоративная политика. Убрать его — значит пойти против компании. Но пользователь имеет право знать, что происходит, и иметь выбор. Давайте быть цивилизованным обществом.

Что предлагается:

Сделать аналитику opt-in. Спросить пользователя: «Хотите помочь улучшить MAX? Мы будем собирать анонимную статистику использования». Кто хочет — включит. Кто не хочет — его право. База.

Убрать определение IP через четыре сервиса. Один — понятно, для геолокации серверов. Четыре (ip.mail.ru, ifconfig.me, checkip.amazonaws.com, ipv4-internet.yandex.net) — перебор и жесть.

Не передавать номера телефонов в открытом виде при синхронизации контактов. Как минимум — хеширование с солью на стороне клиента. Это не идеал (пространство номеров невелико, и при утечке соли хеши обратимы), но уже лучше чем plaintext. В перспективе — криптографические протоколы Private Set Intersection или изолированные вычисления на стороне сервера. Это сложнее, но именно так работают мессенджеры, которые заявляют о приватности.

Снова вопрос: мешает ли это госорганам? Нет. Аналитика не имеет отношения к СОРМ. Контакты пользователя доступны через его аккаунт. Определение IP для оперативных нужд делается на уровне провайдера, а не через ifconfig.me.

4. Закрыть двери для чужих приложений

В ходе аудита обнаружилось несколько мест, где сторонние приложения на том же телефоне могут взаимодействовать с MAX без должной проверки. Это стандартные проблемы Android-разработки, описанные в OWASP Mobile Top 10 (~2024). https://owasp.org/www-project-mobile-top-10/ -- не знаю, насколько устарела информация, кажется, ещё довольно актуальна.

Вот что стоит сделать:

Ограничить доступ к внутренним компонентам приложения из внешних Intent. Сейчас некоторые экраны можно вызвать извне!

Добавить защиту от overlay-атак (tapjacking). Это когда мошенническое приложение рисует прозрачное окно поверх MAX и перехватывает нажатия. Начиная с Android 12, система частично блокирует такие наложения, но для критичных экранов (ввод PIN, подтверждение отправки) нужна дополнительная защита на уровне приложения. (явный открытый риск)

Ограничить JavaScript-bridge во встроенном браузере. Сейчас мини-приложения в WebView имеют расширенный доступ к нативным функциям. Стоит явно указать, что именно доступно. Нужна ревизия.

Снова вопрос! Мешает ли это госорганам? Нет. Это защита от мошенников и вредоносных приложений.

Вот это — тот пункт, где я уверен на 100%, что разработчики согласятся. Стандартная работа над качеством.

5. Обновить криптографию

MAX использует CryptoPro для ГОСТ-шифрования — это правильно для государственного мессенджера. Но в конфигурации обнаружена поддержка TLS 1.0 и TLS 1.1 — версий протокола, которые признаны устаревшими в 2021 году (RFC 8996) и уязвимы к известным атакам.

Решение простое: оставить только TLS 1.2 и TLS 1.3. Тем более что ГОСТ-шифр. стандартизированы для обеих версий — RFC 9189 для TLS 1.2 и RFC 9367 для TLS 1.3. CryptoPro поддерживает оба варианта. TLS 1.0/1.1 в 2026 году не просто «устарели» — их уже не принимают крупнейшие облачные провайдеры и CDN.

Также стоит перенести токены авторизации из HTTP-параметров (где они попадают в логи серверов) в заголовки запросов. А для привязки к устройству есть стандарт DPoP (RFC 9449) — токен криптографически привязывается к ключу в том же аппаратном модуле, о котором мы говорили выше. Украденный токен без этого ключа бесполезен. Вообще, идеально шифровать каждый критический элемент отдельно, с привязкой к сессии, но тут долгая дискуссия, не стану сейчас тратить на это время.

Этот вопрос ещё несколько раз встретиться ниже НАМЕРЕННО! Мешает ли это госорганам? Нет. Гигиена безопасности.

TLS 1.0/1.1 — это скорее всего наследие от CryptoPro, и тут MAX зависит от сторонней библиотеки. Но привязка токена к устройству и перенос из параметров в заголовки — это точно в их силах.

6. Открыть протокол для аудита

Telegram опубликовал спецификацию MTProto. Множество мессенджеров открыли исходный код. Это не ослабило их — наоборот, тысячи независимых исследователей проверяют код и находят ошибки до того, как их найдут злоумышленники. Почему мы не можем сделать также? Можем ведь.

MAX использует проприетарный бинарный протокол, который невозможно проверить извне. Это подход «security through obscurity» — безопасность через сокрытие — который в криптографии считается слабым решением.

Необязательно открывать весь код. Достаточно опубликовать спецификацию протокола и заказать независимый аудит у специализированной компании — как делают ведущие мессенджеры у NCC Group, Cure53, Trail of Bits. Для отечественного контекста — компании с лицензиями ФСТЭК/ФСБ на деятельность в области защиты информации: Positive Technologies, BI.ZONE, Solar Security и другие. Главное — чтобы аудит был независимым и результаты публичными.

А что ГОСОРГАНЫ? Открытый протокол не мешает серверному доступу. HTTPS тоже открытый протокол — и его используют все банки.

Будем реалистами: открытие протокола скорее всего не произойдёт — это затрагивает всю экосистему VK/OK. Но независимый аудит под NDA — вполне рабочий компромисс, который повысит доверие без раскрытия деталей. Летс-гоу дальше...

7. А что делать пользователям прямо сейчас?

Пока разработчики думают, вот что можете сделать вы сами.

Если у вас обычный телефон (без root):

- Геолокация и контакты -- на свой страх и риск.

- ВЫКЛЮЧИТЬ USB отладку. Настройки — Система — Для разработчиков — Отладка по USB. Если вы не разработчик, она вам не нужна. А с ней можно извлечь данные с телефона, просто подключив кабель.

- Не подключайтесь к чужим зарядкам и Wi-Fi без необходимости. Часть трафика MAX может идти без шифрования — мы это показали в первом посте.

- Не публикуйте invite-ссылки MAX в открытых источниках.

- Проверяйте активные сессии в настройках аккаунта.

8. Итого: что получится, если разработчики послушают

Если реализовать всё вышеперечисленное, MAX станет мессенджером, который:

а) Защищает данные на устройстве от малвари, кражи, ремонтников — шифрованием.

б) Даёт пользователю выбор между обычными и секретными чатами.

в) Уважает приватность — не собирает лишнее, спрашивает согласие.

г) Устойчив к атакам сторонних приложений — overlay, intent injection, WebView.

д) Использует современную криптографию — без дыр из 2010 года.

е) Может быть проверен независимо — открытый протокол и внешний аудит.

При этом:

- Обычные чаты остаются доступными для СОРМ.

- Серверная инфраструктура не меняется.

- Закон Яровой выполняется в полном объёме.

- Государство сохраняет доступ к данным в рамках действующего законодательства.

- Безопасность для граждан и доступ для государства — не взаимоисключающие вещи. Нужно просто разделить: что защищаем от мошенников (данные на устройстве) и что остаётся доступным по закону (данные на сервере).

P.S. Ребята из VK/MAX. Пользователи заслуживают безопасный мессенджер. У вас есть хорошая основа. Осталось доделать (реально можно, и не ГОДАМИ).

P.S.S.Технические детали уязвимостей направлены / будут направлены команде MAX через Bug Bounty на Standoff 365. (что-то уже было опубликовано, я ДАЛЕКО не первый).

P.S.S.S. Можете задавать прямые вопросы -- отвечу.

UPD 2.0 (Я забыл добавить кое-что интересное...)

MAX на самом деле сильно зависит от "западных решений".

Сервисные зависимости — реальная проблема:

Google Firebase (FCM) — push-уведомления. Каждый раз, когда вам приходит уведомление о новом сообщении, оно идёт через серверы Google в США. Google может отключить этот сервис для российских приложений в любой момент — как уже делали с другими сервисами под санкциями. Нет Firebase — нет пушей.

checkip.amazonaws.com — один из четырёх сервисов определения IP, о которых я писал выше.

Google Advertising ID и Google App Set ID — встроены через MyTracker. Идентификаторы устройств, которые генерирует и контролирует Google.

Библиотечные зависимости — менее критично, но стоит знать:

Facebook Fresco — open-source библиотека обработки изображений, изначально разработанная в Meta Platforms Inc. (деятельность компании признана экстремистской на территории РФ, решение Тверского суда г. Москвы от 21.03.2022). Сама библиотека — открытый код под лицензией Apache 2.0, работает локально, никуда данные не отправляет. Но для государственного мессенджера происхождение компонентов имеет значение.

Ирония ситуации: MAX создан как альтернатива Telegram, который «контролируется из-за рубежа». Но внутри MAX — Google и Amazon на уровне сервисов. А Telegram, к слову, имеет собственный fallback для push-уведомлений и может работать без Firebase.

Не то чтобы это дискредитирует MAX. Это нормальный технический долг, который накопился от TamTam. Но если MAX хочет быть по-настоящему суверенным — начать стоит с того, чтобы push-уведомления не шли через "Маунтин-Вью".

Такие дела.