Сравнение 3х популярных мессенджеров для безопасного общения.

Безопасность уже давно не является чем-то из разряда инструментов разведчиков. Теперь это суровая реальность и если не беспокоится об этом то можно легко стать жертвой как мошенников так и просто быть заваленным не нужной рекламой и спамом. Сегодня мы расскажем вам о 3х популярных программах для безопасного общения и сравним их. 

 В этой обзорной статье мы представим результаты независимого исследования и дадим свой ответ, какой мессенджер безопаснее.

О каких мессенджерах пойдет речь?

Сразу оговоримся, что отбор мессенджеров для нашего обзора производился на основе анализа существующих открытых исследований защищенности мессенджеров, их популярности в России и их позиционирования на рынке.

По итогам оценки и изучения мнений экспертов отрасли наша команда выбрала три мессенджера, ориентированные на защиту данных пользователей:

  1. Signal — некоммерческий проект Open Whisper Systems
  2. Telegram — некоммерческий проект Telegram FZ-LLC
  3. Wickr Me — коммерческий проект Wickr Inc с бесплатной версией

Для исследования мессенджеров использовали последние версии, доступные на момент исследования в App Store и Google Play.

Мессенджеры устанавливались на смартфоны с iOS версии 13.3.1 и Android версии 7.1.2, при этом на смартфонах заранее были получены права суперпользователя (jailbreak для iOS и root-доступ для Android).

Как сравнивали мессенджеры?

Теперь вкратце расскажем о методике проведенного анализа защищенности. На рисунке ниже отображена схема формирования оценки по каждому мессенджеру.

Для проведения анализа мы выбрали три основные категории:

  1. Открытость сообществу
  2. Архитектура
  3. Основная функциональность

В категории «Открытость сообществу» оценивались:

  • наличие отчетов внешних аудиторов (в том числе наличие bug bounty-программ)
  • доступность исходного кода мессенджера для исследователей (клиентская и серверная часть, протокол шифрования)
  • наличие доступной и подробной документации для пользователей мессенджера

В этой категории не проводятся технические проверки, а полученный результат основан на оценке специалистов-участников проекта. Максимальная возможная оценка для мессенджера в этой категории — 12 баллов.

В категориях «Архитектура» и «Основная функциональность» оценка складывалась на основе результатов технических (инструментальных) проверок, которые проводились по стандарту OWASP Mobile Security Testing Guide.

В категории «Архитектура» после проведения инструментальных проверок мы получили оценку:

  • защищенности данных мессенджера (например, конфигурационные файлы, необходимые для работы мессенджера)
  • защищенности каналов связи (например, реализация передачи данных на сервер мессенджера)
  • защищенности резервных копий (например, файлы приложения, создаваемые как мессенджером, так и операционной системой смартфона)
  • защищенности данных профиля пользователя (например, логин пользователя, местоположение)

При наличии недостатков в какой-либо из проверок максимальный балл категории снижался, а максимальная возможная оценка — 200 баллов.

В категории «Основная функциональность» оценивалась корректность работы следующих функций мессенджеров:

  • обмен сообщениями (включая файлы различных форматов)
  • совершение видео- и аудиовызовов

Максимальная оценка в этой категории — 120 баллов.

Таким образом, максимальная итоговая оценка мессенджера может составить 332 балла и складывается в следующем отношении:

Если вам интересно узнать больше — полную информацию о методологии проведенного анализа защищенности можно найти здесь.

Сразу оговоримся, что в границы нашего исследования не вошли:

  • анализ исходного кода: он доступен не для всех мессенджеров.
  • исследование серверной части мессенджеров: оно может включать инвазивное воздействие и требует письменного согласия на проведение данных работ.
  • криптографический анализ используемых алгоритмов шифрования и reverse engineering мессенджеров: эти работы займут намного больше времени, чем было отведено на проект, поэтому не будем отбирать хлеб специалистов-криптографов.

И что получилось?

Пришло время поделиться результатами исследования: как видно на диаграмме ниже, наибольшее количество баллов набрал Wickr Me — 304 из 332 возможных:

В таблице отражено, как складывалась оценка каждого мессенджера:

Давайте рассмотрим лидеров в каждой категории и найденные недостатки, после чего немного детальнее рассмотрим каждый из них.

Открытость сообществу

Лидеры в этой категории — Signal и Telegram — набрали одинаковое значение, 10 баллов. Репозитории мессенджеров содержат исходный код приложения и протоколы, доступные для исследования всем желающим. Однако мессенджеры держат закрытой серверную часть приложения, поэтому не получили максимальную оценку.

Wickr Me набрал меньше баллов, так как мессенджер не раскрывает исходный код.

Архитектура

В этой категории есть общий для мессенджеров недостаток — возможность обхода биометрической аутентификации. Эксплуатируя этот недостаток, можно получить доступ к данным пользователя мессенджера.

Лидером в категории «Архитектура» является Wickr Me, который содержит меньше выявленных недостатков, чем у конкурентов.

Signal и Telegram набрали меньше баллов, так как «небезопасно» хранят чувствительные данные мессенджера и профиля пользователя на клиентской стороне.

Из плюсов следует отметить, что все мессенджеры поддерживают E2EE-шифрование передаваемых данных, поэтому оценка Certificate pinning не проводилась.

Основная функциональность

Эту категорию можно расширять до бесконечности, но у нашей команды не было цели исследовать все реализованные фичи, и мы остановились на изучении основной функциональности мессенджеров и их безопасности:

  • обмен сообщениями
  • совершение аудио- и видеозвонков

Примечание: не рассматривалось использование в корпоративной среде.

Лидерами данной категории стали Wickr Me и Telegram, набрав максимальное количество баллов.

Версия мессенджера Signal под платформу Android содержит недостаток обработки исключений, который приводит к остановке приложения (то есть мессенджер сразу закрывается), поэтому Signal набрал меньше баллов в этой категории.

Информация о найденных недостатках

Мы описали общие результаты исследования, а теперь перейдем к более технической части. Ниже описаны некоторые детали выявленных недостатков мессенджеров.

Напомним, что все выявленные недостатки были обнаружены на устройствах с root-доступом (или к устройству применен jailbreak).

Первый недостаток, характерный для всех трех мессенджеров (для обеих платформ) — это возможность обхода описанной выше биометрической аутентификации. Дальше мы рассмотрим этот недостаток для каждой платформы.

Возможность обхода биометрической аутентификации

Современные смартфоны поддерживают несколько механизмов аутентификации, и один из возможных — это биометрическая аутентификация при помощи Touch ID или Face ID. При включенной функции биометрической аутентификации устройство сканирует отпечаток пальца (или лицо) и сравнивает с эталонным, заранее занесенным в систему.

iOS

У всех приложений, в том числе мессенджеров из нашего списка, для платформы iOS биометрическая аутентификация пользователя осуществляется при помощи Local Authentication Framework с использованием функции evaluatePolicy класса LAContext. Рассмотрим работу биометрической аутентификации немного подробнее.

Как выглядит биометрическая аутентификация для пользователя?

При нажатии на логотип мессенджера отображается диалоговое окно аутентификации, которое запрашивает у пользователя подтверждение действия, например, изменение настроек, покупку и т.д. с помощью биометрической аутентификации (Touch ID/Face ID).

В зависимости от того, как закончился процесс биометрической аутентификации, функция evaluatePolicy возвращает значение («true» или «false»), которое используется далее для управления приложением (например, открывается мессенджер или нет).

В чем заключается недостаток?

У всех исследуемых мессенджеров недостаток реализации биометрической аутентификации состоит в том, что пользователь аутентифицируется лишь на основе результата функции evaluatePolicy («true» или «false») и мессенджер не использует системные механизмы авторизации при доступе к значениям из защищенного хранилища Keychain. Более подробно о локальной аутентификации можно узнать в Mobile Security Testing Guide: здесь и здесь.

Как устранить недостаток?

Один из способов устранить описанный недостаток — создать в защищенном хранилище Keychain запись, которая будет содержать некоторый секрет (например, упомянутый ранее аутентификационный токен). При сохранении записи в Keychain необходимо задать соответствующие атрибуты, например, kSecAccessControlTouchIDAny или kSecAccessControlTouchIDCurrentSet.

Далее, чтобы получить значение этой записи, нужно будет обязательно успешно пройти локальную аутентификацию (в зависимости от заданных настроек доступа в Keychain — с помощью Touch ID/Face ID или ввода парольной фразы). Использование Keychain с необходимыми атрибутами сохраняемых в нем объектов позволит снизить возможность получения доступа к данным мессенджера.

Android

Описанный выше недостаток характерен и для мессенджеров платформы Android, поэтому мы рассмотрим работу биометрической аутентификации немного подробнее.

В приложении для платформы Android биометрическая аутентификация пользователя осуществляется с использованием классов FingerprintManager (не используется с Android 9), BiometricPrompt, BiometricManager.

Процесс биометрической аутентификации для пользователя на платформе Android выглядит абсолютно так же, как и на iOS.

В чем заключается недостаток?

Недостаток реализации биометрической аутентификации исследуемых мессенджеров для платформы Android аналогичен недостатку для iOS — не используются возможности операционной системы и устройства: мессенджеры не запрашивают системную авторизацию пользователя через KeyStore. Таким образом, потенциальный злоумышленник может подменять результат выполнения процедуры аутентификации для ее обхода.

Как устранить недостаток?

Для устранения данного недостатка в приложении рекомендуется использовать симметричные/асимметричные криптографические ключи (класс KeyGenerator), при инициализации которых вызывать функцию setUserAuthenticationRequired (true). Вызов данной функции позволяет получить доступ к значениям соответствующих криптографических ключей только после успешного прохождения процесса локальной аутентификации. Ключи при этом используются для шифрования некоторого секрета, например, аутентификационного токена в приложении.

Хранение чувствительной информации в локальном хранилище

Еще один обнаруженный недостаток — небезопасное хранение чувствительных данных в локальном хранилище — характерен для двух из трех мессенджеров.

Ниже мы привели примеры небезопасного хранения чувствительной информации в локальном хранилище, которые встречаются у некоторых мессенджеров платформы iOS:

  • передаваемые файлы, а также кэшированные изображения из чатов в открытом виде;
  • ключ шифрования базы данных мессенджера в Keychain. Поскольку не используется локальная аутентификация для доступа к значениям из Keychain (см. «Возможность обхода биометрической аутентификации»), хранение ключа шифрования базы данных мессенджера в Keychain снижает уровень защищенности данных;
  • файлы конфигурации мессенджера, в которых присутствуют параметры, использующиеся для шифрования;
  • IP-адрес устройства в лог-файлах мессенджера;
  • сообщения чатов в открытом виде в базе данных мессенджера.

Если говорить про мессенджеры на Android, небезопасное хранение чувствительных данных тоже встречается, например:

  • файлы конфигурации мессенджера, в которых присутствуют параметры, использующиеся для шифрования, а также информация о номере телефона пользователя;
  • сообщения пользователя (в том числе черновики) в открытом виде;
  • контактная информация пользователей мессенджера, с которыми переписывался владелец устройства.

Как устранить недостаток?

Для устранения данного недостатка рекомендуется пересмотреть архитектуру и способы хранения чувствительных данных мессенджера.

Еще раз напомним, что вышеуказанные чувствительные данные мессенджера недоступны без использования root-доступа (или jailbreak) на устройстве.

Некорректная обработка исключений

Данная уязвимость относится только к платформе Android и мессенджеру Signal.

При исследовании основной функциональности мессенджеров осуществлялась отправка файлов разных форматов. В результате был найден один сценарий, при котором отправка файла вызывала остановку в работе мессенджера со следующей ошибкой: «Signal has stopped».

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

Как устранить недостаток?

Чтобы избавиться от данного недостатка, нужно реализовать проверку формата файла, который пользователь выбирает для отправки.

Ответы разработчиков

Обо всех описанных выше недостатках наша команда сообщила разработчикам мессенджеров. На момент публикации мы получили ответ от двух из трех мессенджеров (Signal и Telegram), третий на наши вопросы так и не ответил.

Разработчики поблагодарили нашу команду за предоставленную информацию и сообщили, что не считают выявленные недостатки уязвимостью, поскольку исследуемые версии мессенджеров используют для защиты данных мессенджера штатные механизмы защиты информации операционной системы. Используемые механизмы не позволяют эксплуатировать выявленные недостатки, а использование на устройстве root-доступа (или jailbreak) остается на усмотрение пользователя.

Тем не менее, мессенджеры могут реализовать проверку наличия root-прав на устройстве и уведомлять об этом пользователя устройства для снижения риска потенциальной компрометации данных.

Вывод

Мы провели сравнительный анализ защищенности трех мессенджеров, позиционирующих себя как безопасные, и выяснили, что все мессенджеры имеют ряд общих недостатков, а у Signal и Telegram также выявлены недостатки реализации хранения чувствительной информации в локальном хранилище.

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

По итогам всех проверок лидером нашего исследования стал мессенджер Wickr Me, который набрал 304 балла и у которого выявлено меньше всего недостатков.

Вывод прост: абсолютно безопасных мессенджеров нет, но мы надеемся, что благодаря этому исследованию вы сможете сохранить конфиденциальность и повысить безопасность своего общения, зная обо всех подводных камнях выбранного вами сервиса.

Click to rate this post!
[Total: 2 Average: 3]

Специалист в области кибер-безопасности. Работал в ведущих компаниях занимающихся защитой и аналитикой компьютерных угроз. Цель данного блога - простым языком рассказать о сложных моментах защиты IT инфраструктур и сетей.

1 comments On Сравнение 3х популярных мессенджеров для безопасного общения.

Leave a reply:

Your email address will not be published.