В конце прошлого года исследователи из швейцарского университета ETH Zurich опубликовали работу, в которой описали семь уязвимостей в мессенджере Threema. Этот мессенджер при передаче сообщений использует сквозное шифрование, то есть содержание переписки в идеальных условиях должно быть доступно только отправителю и получателю. Threema позиционируется как одно из наиболее защищенных средств коммуникации в Сети. Естественно, что информация об уязвимостях в таком инструменте привлекла внимание. На прошлой неделе разработчики мессенджера опубликовали отзыв на исследование, в котором раскритиковали не обнаруженные проблемы, а, скорее, их интерпретацию.


В любом случае все обнаруженные уязвимости в протоколе шифрования закрыты. Более того, публикация исследования совпала с релизом нового протокола коммуникации в Threema — Ibex. Он предположительно решает фундаментальный недостаток старого протокола: в нем не была реализована концепция прямой секретности (forward secrecy), при которой взлом ключей для определенной сессии не позволяет расшифровать более раннюю или более позднюю переписку. Критика работы со стороны Threema отчасти обоснована, и оценить ее лучше всего на примере двух самых серьезных проблем, выявленных исследователями из ETH Zurich.

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

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

Вторая теоретическая атака выглядит еще интереснее, ее подробно (но простыми словами) описал разработчик Threema здесь. В ней используется платная фича мессенджера, позволяющая приобрести кастомизированный идентификатор. Это открывает возможность ассоциировать с этим новым идентификатором произвольный публичный ключ, который может совпадать с публичным ключом сервера Threema. Если заставить жертву отправить специально подготовленное сообщение (которое может выглядеть примерно так: u9j6ߓ'jjखԻ^߃1כW:-́;ܡRA) пользователю с кастомным идентификатором, аккаунт жертвы может быть частично скомпрометирован. А именно: атакующий сможет перехватывать метаданные сообщений (но не их содержимое) и не доставлять некоторые из них пострадавшему пользователю.

То странное сообщение, которое надо отправить жертве и заставить ее переслать подготовленному пользователю, — это и есть публичный ключ. Чтобы его узнать, нужна большая вычислительная мощность: потребуется арендовать примерно 8 тысяч процессорных ядер на 24 часа. Атака не всегда срабатывает, поэтому для надежности надо заставить жертву отправить «мусорное» сообщение больше 200 раз подряд. А также для атаки надо оплатить кастомизированный идентификатор, что еще больше усложняет проблему. Короче говоря, по всем разумным критериям эта атака на практике не реализуема.

Разница в интерпретации результатов работы понятна. У исследователей в принципе нет задачи найти обязательно работающий способ взлома Threema. Они скорее указывают на теоретические недостатки примененных в мессенджере протоколов шифрования, которые действительно имели место. Это важно: продукт, основным преимуществом которого является защита коммуникаций, должен соответствовать актуальным научным разработкам в области шифрования данных. Другого способа проверить истинность заявлений разработчика о «максимальной защите ваших данных» нет. У Threema при этом есть не менее очевидная претензия к исследователям: они подают результаты своей работы как серьезный недостаток защищенного мессенджера, что достаточно далеко от реальности. Ученые беспокоятся о правильной модели безопасности при шифровании данных — бизнесмены переживают из-за испорченной репутации. Средства защищенного общения должны подвергаться подобным аудитам. В идеале технологии шифрования должны оцениваться до внедрения в продакшн. Исследование не нашло каких-либо действительно серьезных дыр в Threema, но закрыты они были путем внедрения нового протокола, который пока никто не изучал.

Что еще произошло:

В роутере Asus RT-AX82U обнаружена и закрыта уязвимость, позволяющая обойти процесс авторизации пользователя.

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

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

Комментарии (3)


  1. aborouhin
    16.01.2023 19:25
    +2

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

    А разве нет способов, позволяющих прочитать RAM заблокированного и затем изъятого / украденного, но не выключенного телефона? Фокус с морозилкой уже неактуален на современных версиях систем? Если такая возможность всё же есть - это вполне себе уязвимость.


    1. fk0
      18.01.2023 14:48
      +2

      Зависит от нюансов. У некторых процессоров данные расположенные во внешней RAM -- шифруются. Как раз против таких фокусов (или чтоб после ребута там ничего ценного не оставалось). У некоторых т.н. POP-память, припаиваемая прямо поверх процессора. Тут с морозилкой немного сложно. Я бы скорей думал о софтовых способах. А там сейчас по памяти лазает непонятно кто и так... И все ключи сложили в одно место, чтоб не по всей памяти искать, а компактно (https://static.linaro.org/connect/yvr18/presentations/yvr18-414.pdf)


  1. fk0
    18.01.2023 14:45
    +1

    Все эти чудо-юдо мессенджеры с регистрацией через смс (для привязки паспортных данных) и центральным сервером (куда можно прийти и попросить распечатать что нужно) только и созданы чтоб подслушивать и подсматривать. Там нельзя доверять серверу, нельзя доверять ПО, нельзя доверять единственному издателю ПО. В такой системе обязательно есть где-то есть "особенность" для негласного получения данных.

    PGP/GPG и любое средство публикации сообщений (заполненная спамом группа юзнета, IRC, tumblr, публичная группа в телеграме, вконтакт...) работает намного лучше. Автор просто пишет сообщение, кодирует и публикует. Публикует так, что прочитать мог кто угодно, без логина и пароля. И даже чтоб из кеша гугла прочитать можно было. Получатели периодически просматривают интересующие ресурсы (желательно без явной подписки) и извлекают кодированные сообщения, те которые могут декодировать (обладают нужным ключём) -- предназначены им. Остальные просто откидываются. Процесс автоматизируется не сложным образом любым script kiddie.

    Выше описана простейшая схема организации наложенной сети простейшими подручными методами. Принципиально, что связь отправитель-получатель -- не видна в явном виде. Публикация может быть нацелена на группу получателей (не помню, можно ли так в PGP, но в x509 с помощью openssl -- точно можно).

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

    Осталось автоматизировать. Только такое никому не нужно. Потому, что нельзя ни подслушивать, ни подсматривать, ни передавать третьим лицам обезличенную информацию (до первого JOIN из двух нужных баз). Ни выполнять требования законодательства.