dxdt.blog: занимательный интернет-журнал

Десять лет назад на dxdt.ru вышла записка “Эволюция телефонного аппарата как персонального жучка” (а также некоторое обновление, в 2021 году). Вообще, к этой теме сейчас добавились всякие “умные” звуковые колонки и прочая техника, с постоянным доступом до внешних серверов и развитой вычислительной базой на борту – настолько развитой, что возможно исполнять “приложения”, автоматически присылаемые центральным сервером, с последующим их не менее автоматическим удалением. Все эти удачно установленные клиенту колонки и телевизоры начинают транслировать рекламу (пример есть от Amazon), но более интересно, что эти устройства значительно расширяют возможности по сбору информации.

Рассмотрим ситуацию на примере колонки – они очень популярны. Понятно, что “умная” колонка через встроенный микрофон (микрофоны) может постоянно прослушивать помещение и, например, узнавать людей по голосам. Так как есть центральный сервер, то много колонок в разных помещениях могут определять, где бывает тот или иной “носитель голоса”. Тут стационарность колонки составляет преимущество, по сравнению со смартфоном. Однако колонка ещё может взаимодействовать с приложением в смартфоне, который находится рядом: во-первых, штатными способами (это управление и прочие привычные функции – через центральный сервер, напрямую через локальный WiFi/Bluetooth); во-вторых – через дополнительный акустический канал, поскольку у колонки есть не только микрофон, но и динамики. Акустический канал может быть хорошо замаскирован для человеческого слуха – годится и ультразвук, и сокрытие наложенным сигналом. Особенность акустического канала в том, что колонка может взаимодействовать с приложением, которое официально никак с колонкой не связано. И, естественно, нужное приложение может автоматически “приехать” и в смартфон, и в колонку.

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

Так, обнаружение алгоритма быстрой факторизации, естественно, легко может грозить тем, что попутно обнаружится и способ быстро сломать задачи типа привычного эллиптического варианта Диффи-Хеллмана (читай – ECDSA). Однако только из этого не следует автоматически вывод, что переходить требуется именно на постквантовые криптосистемы. Вот тут и начинаются особенности. Во-первых, постквантовые криптосистемы уже разработаны, уже имеют какую-то практическую “классическую” стойкость, уже реализованы, – так что их быстрее внедрить; во-вторых, задачи, на которых базируются те или иные постквантовые криптосистемы, имеют гораздо больше шансов сохранить известную сложность после обнаружения каких-то принципиально новых методов быстрой факторизации – это, конечно, тоже не гарантируется, однако для ускорения факторизации/логарифмирования до сих пор использовались математические конструкции, которые, в общем-то, стоят и за многими постквантовыми алгоритмами.

В атаке с перехватом трафика Jabber.ru использовался активный сетевой прокси с MITM. Однако если процесс, реализующий TLS, исполняется в виртуальной машине, а гипервизор контролируется провайдером хостинга, то можно проводить полностью пассивную атаку с рашифрованием TLS-трафика, да так, что из виртуальной машины атаку видно не будет. Это существенно сложнее прокси, терминирующего TLS с подменным сертификатом, и ограничивает возможности по расширению атаки до активной (с вмешательством в трафик), но является куда как более изящным методом. Для реализации требуется доступ к функции копирования (“дампа”) памяти гипервизора, а кроме того, естественно, доступ к сетевому трафику виртуальной машины (либо тоже на уровне “виртуализации” гипервизора, либо на уровне “внешней” сети).

Основная идея такая: общий сессионный секрет и сеансовые ключи TLS-соединения находятся в оперативной памяти виртуальной машины – нужно их из памяти извлечь, выполнив выгрузку копии памяти гипервизором в подходящий момент. Самое занятное, что это же относится и к секретному серверному ключу сертификата, который, впрочем, во многих случаях ещё и просто лежит в статическом файле на диске, в открытом виде. Извлечение и использование серверного ключа из файловой системы, при доступе к гипервизору, вообще представляет тривиальную задачу и тут не рассматривается. Варианты с зашифрованным файлом, с зашифрованным томом (диском) – уже сложнее, но тоже реализуемы; так или иначе – это не относится к анализу TLS. А вот извлечение разнообразных ключей из дампа оперативной памяти – относится, поэтому рассмотрим метод в общих чертах, за вычетом возможных мер по маскированию ключей в памяти (см. ниже).

В TLS набор симметричных сеансовых ключей используется сторонами для зашифрования/расшифрования и вычисления кодов аутентификации, поэтому знание ключей позволяет расшифровать TLS-сообщения и подделать TLS-сообщения. Для получения действующих сеансовых ключей используется некоторый общий сессионный секрет, согласованный в начале TLS-сессии. Этот секрет позволяет простым способом вычислить сами сеансовые ключи (обратное – не верно), поэтому достаточно найти сессионный секрет. В TLS 1.3 процесс работы с исходными секретами разбит на шаги, каждый из которых выводит симметричные ключи для соответствующего этапа соединения, так что ситуация несколько сложнее, но эти детали тоже пропустим.

Чтобы зафиксировать нужные симметричные ключи в памяти виртуальной машины, нужно определить момент, когда они там образуются. Если момент упустить, то сеансовые ключи могут быстро потеряться, так как соответствующие байты в памяти окажутся перезаписаны. Для фиксирования удобного момента требуется наблюдение над сетевым трафиком: по статусу TLS-соединения можно определить, что приложение должно вычислить ключи, и в этот момент сделать дамп памяти (или несколько последовательных дампов). Ход сетевого трафика, при необходимости, можно и “подвесить”, так как речь всё же идёт про ситуацию контроля над гипервизором. После того, как дамп памяти снят, данные из него анализируются с целью извлечения ключей, а TLS-трафик пассивно записывается.

Как найти ключи в дампе памяти? Есть прямой, но не самый быстрый, способ полного перебора: пробное расшифрование (или вычисление кода аутентификации) выполняется по порядку для каждой байтовой последовательности дампа нужной длины. Возможны, конечно, варианты, когда значение ключа оказалось в дампе памяти разрезано на части, поэтому такой перебор не сработает. Более точные результаты даст предварительная разметка областей по признаку записи, а также анализ логических блоков по схеме представления памяти в гостевой ОС. Понятно, что это всё можно сделать на уровне гипервизора. Для чего-то даже имеются готовые инструменты, что-то придётся запрограммировать. Схема с перебором работает и для секретного серверного ключа, только вместо пробного расшифрования нужно выполнять другую операцию (например, для ECDSA – пробное умножение; но это детали, главное, что в TLS-трафике всегда есть опорные метки).

Ключи и секрет могут быть замаскированы в памяти приложением (обычно, XOR с псевдослучайной маской, маска хранится отдельно или вычисляется по необходимости специальной функцией). Такое решение встречается нередко. Однако для того, чтобы ключи использовать – их всё же придётся раскрыть для операций хеш-функций и шифров, поэтому достаточно угадать момент выполнения дампа памяти. (Можно предложить алгоритмы с дополнительным непрерывным перемешиванием адресации и масок на уровне реализации шифров/хеш-функций, но вряд ли такое где-то встречается на практике.)

Проблемы с данным методом могут начаться тогда, когда параллельных TLS-соединений очень много: с одной стороны, возрастают шансы поймать много ключей в дампах памяти, с другой – дополнительные сложности с отслеживанием и сопоставлением состояний.

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

Схема работает не только для TLS, но и для других протоколов (SSH, например), если только реализации не подразумевают достаточно сложных механизмов защиты ключей. При этом понятно, что никакой “полной защиты” от гипервизора тут быть не может.

Пишут, что iPhone с актуальной версией OS (iOS 17) успешно заливается bluetooth-запросами вплоть до перезагрузки (впрочем, не меньше похоже и на успешную “партизанскую” PR-кампанию Flipper Zero, который выступает в качестве генератора запросов в эфир). Но занятно, что новая версия iOS так и не привела к улучшениям в методах разработки Apple (устройства эти почему-то считаются “повышенной безопасности”), но послужила в качестве канвы для рекламы Flipper Zero.

Нередко предполагается, что автомобили-роботы станут выдавать в эфир сведения о планируемой траектории движения, так как это может помочь другим автомобилям-роботам в планировании своих траекторий. Это одна из особенностей, связанных именно с роботами. Нельзя сказать, что сложно предсказать путь следования автомобиля под управлением обычного водителя-человека. Но то некий “путь”, предположим, “из точки А в точку Б”, с точностью до выбранных улиц и дорог, – не сложно, если водитель не запутывает следы специально. А вот с конкретными манёврами, составляющими отрезки траектории, трудности предсказания возникают регулярно. С роботами, как ожидается, дело другое: они могут строго придерживаться только что заявленного траекторного интервала. Это создаёт пространство для принципиально новых атак.

Представьте, что злонамеренный “участник движения” транслирует в сторону других автомобилей-роботов противоречивые траекторные данные – специально запутывает согласование, выполняет хитрую DoS-атаку. В тривиальной кооперативной системе другие роботы будут вынуждены остановиться, поскольку все их возможности движения окажутся закрыты атакующим. При этом источник атаки вовсе не обязан быть автомобилем-роботом – это может быть просто коробка с электронной начинкой, оставленная кем-то у столба на перекрёстке. Получается, коробка как бы изображает “нерешительного” водителя-человека и успешно блокирует движение роботов. И даже пассажиров, у кого они на борту, высадить нельзя на перекрёстке.

Для реализации, конечно, нужен соответствующий протокол. И можно предположить, что если такой протокол внедрят (а прототипы есть), то он будет защищён тем или иным криптографическим способом. Анонсируемые маршруты могут подписываться источниками (звучит как sBGP и RPKI), а другие участники станут проверять подписи. По причине рьяной поддержки маркетинга нетрудно приделать сюда ту или иную “иерархию удостоверяющих центров”, как это с регулярностью и происходит в смежных электронных областях (пример – eSIM и GSMA). Тогда ключи/сертификаты злонамеренных “маршрутопостановщиков” будут отозваны и прочие роботы смогут данные анонсы игнорировать. Вот только проблема в том, что это всё оказывается связано с безопасностью движения, а неверный отзыв ключа/сертификата легко может привести к тому, что добросовестные роботы на дороге проигнорируют добросовестный автомобиль-робот и, в соответствии с правилами блокбастерного кинематографа, его протаранит самоуправляемый грузовик. А соответствующий чужой сертификат, как окажется, тоже отозвал злоумышленник. С учётом Нового Средневековья, отозвать сертификат может быть даже проще, чем городить коробку-ретранслятор.

В свете нашумевшей атаки на Jabber.ru (с перехватом TLS) нередко пишут, будто эта атака показала, что “система хорошо известных (публичных) удостоверяющих центров TLS не вызывает доверия”. Атака, конечно, такое показала, но с уточнениями: “система хорошо известных УЦ” и раньше должна бы “вызывать доверие” равно в пределах разумной модели угроз, то есть – доверять ей можно только в сугубо определённых, узких случаях. И нельзя расширительно толковать возможности УЦ – это как раз большая ошибка, но весьма распространённая. В случае же инцидента с Jabber.ru, если говорить о сторонах, которые “вызывают доверие”, то тут такой стороной должен быть прежде всего хостер – предполагается высокая степень доверия хостеру (но не полное доверие, даже в этом случае), а только потом – немного доверия УЦ.

Представьте, что некоторый протокол туннелирования в Интернете устроен следующим образом: в качестве базового транспорта используется UDP (то есть, отсутствуют сессии транспортного уровня, тут это важно); применена схема “клиент-сервер”, использующая двухстороннюю аутентификацию с общим секретом, а процесс аутентификации тоже полностью зашифрован (пробное расшифрование и т.д.); используются различные IP для серверов – точек входа, а также динамически изменяемые номера портов; полезные данные тоже полностью зашифрованы – отсутствуют какие-либо открытые заголовки (кроме UDP), отсутствует фиксированная структура пакета, пакеты имеют разную длину, а адреса/номера портов изменяются в ходе соединения. Подобные протоколы есть, но в этой заметке речь о том, почему именно такой подход создаёт трудности в обнаружении и блокировании соединений.

Протокол медленный, не предназначен для создания стабильных и широких каналов, но зато он скрытый, полностью “мутирующий” и “размытый” (возможно, кто-то из читателей помнит, как в своё время появились первые развитые “полиморфные” компьютерные вирусы, содержавшие зашифрованное тело и генерируемый псевдослучайным образом “распаковщик” – теоретически, никаких статических сигнатур). Описанный протокол как раз внешне выглядит как случайный поток случайных UDP-пакетов, в котором не видно никаких сессий и контекста, не определяется внутренний статус, а общим является только адрес возможного клиента, так как он фигурирует и в отправителях, и в получателях, а вот уже входной и выходной серверные IP-адреса могут изменяться; это особенно занятно, если использовать IPv6 (за скобками оставлено преодоление NAT и некоторые другие сетевые особенности).

Теперь представьте, что некоторая система DPI должна блокировать соединения и прерывать сессии, используя в качестве флага тип протокола. Но у “размытого” протокола, описанного в предыдущем абзаце, нет устойчивых признаков, позволяющих уверенно определить его тип. Конечно, можно сказать, что такой признак всё же есть, просто он “несобственный” – исследуемый протокол “не похож ни на что известное”. Но для такого метода классификации нужно не только составить “белый список” протоколов, но ещё и так запрограммировать систему, чтобы она и классифицировала все протоколы, а это исключает всякую гибкость в пропуске трафика. Скажем, вот обнаружен UDP-пакет, который пока что не соответствует никакому контексту из уже созданных узлом DPI, инспектирующим трафик: если пакет относится к этапу установления соединения в рамках “размытого” протокола и если этот пакет не пропустить, то такое соединение не состоится. Но как определить, что это не пакет, выпавший из другой сессии “разрешённого” протокола (типа DTLS, предположим)?

Надёжное определение контекста становится затруднительным на достаточных объёмах трафика: у допустимых протоколов есть внутренние открытые заголовки, но они короткие и, в теории, могли просто совпасть, поэтому обязательно нужно взвешивать дополнительные параметры по нескольким пакетам – длину, адреса, номера портов. Но чтобы взвешивать несколько пакетов, для них придётся создать некоторую очередь измерений. А как сделать такую очередь эффективной, если туда предлагается складывать всё, что не получилось разобрать? Кроме того, задержка пакета “размытого” протокола приводит к тому, что другие пакеты просто не поступают – не из чего собирать полезный контекст в принципе. Если один “размытый” пакет пропустить, то получится, что и обмен данными случился, и тут уже вовсе не обязательно, что пакет относился к процессу аутентификации – он мог и нести полезные данные в рамках скрытой сессии. Более того, если некоторые пакеты проходят, то это означает, что сам “размытый” протокол успешно работает, преодолевая блокирующие узлы, потому что одно из заявленных свойств протокола – его внутренний статус нельзя определить даже по нескольким пакетам.

Вообще, классификация подобных протоколов с формированием контекста с целью распознавания – та ещё задача. В упрощённом виде можно представить, что классификатор работает с некоторым деревом состояний, переходы по которому определяются наличием видимой для DPI активной сессии между узлами (то, что в распространённых брандмауэрах называется Established connection), наличием ответных (парных) сообщений (это детектирование типовых “хендшейков” вида “запрос-ответ-подтверждение” на начальной стадии), соответствием заголовков транспортных пакетов и параметров адресации (адреса, номера портов), наличием заданных сигнатур и средним объёмом переданных данных. Понятно, что только лишь поиск сигнатур в конкретном пакете – тут заведомо не работает: нужно именно сопровождение состояний во времени. При этом классификация пакетов “размытого” протокола требует максимального задействования вычислительных ресурсов, нужных для расчёта эволюции только что описанного дерева – ведь каждый пакет требуется обработать, провести по функциям проверки, а потом положить информацию в буфер, чтобы позже проверить, не придёт ли какой-то ещё пакет, который можно привязать к уже полученному. Так что это всё скорее теоретические рассуждения, чем доступные на практике методы.

(Я уже писал о полностью зашифрованных протоколах раньше, в том числе, про распределение ключей и влияние TLS.)

В Калифорнии самоуправляемый автомобиль-робот (такси) наехал на пешехода, которого перед этим сбил другой автомобиль. Более того, робот, зафиксировав столкновение, принялся, после наезда, “освобождать проезжую часть”, потому что так запрограммирован, а пешехода он тащил с собой, несколько метров, видимо, пока не нашёл действительно безопасное место для остановки.

Вообще, регулярно пишут, что замена “белковых” водителей на роботов улучшает “безопасность на дорогах”. При этом из виду упускают важный момент: конечно, кажется, что роботов можно организовать гораздо лучше, если рассматривать ситуацию с точки зрения, так сказать, синхронного движения по улицам городов – роботы так могут хоть бы и без светофоров; однако введение новых систем несёт с собой совершенно новые риски, поэтому не факт, что переход на другую, более сложную, технологию автоматически делает ситуацию “безопаснее”. Вот и в только что упомянутом случае компания-оператор, выпустившая такси, объясняет (см. ссылку в начале), что приключившаяся ситуация не входила в типовой набор тестов “страховщиков и регуляторов”, потому что, якобы, является чрезвычайно редкой – это интересный новый риск: покрыть тестами все “редкие” ситуации на дороге (что, понятно, вряд ли достижимо, даже если у вас и все пешеходы – роботы).

Забавно читать, что среди угроз “для человечества”, связанных с искусственным интеллектом (ИИ), называют “создание экземпляра, интеллект которого превысит человеческий”. Речь, конечно, о LLM. Тот ещё риск, да – неожиданно появится кто-то умнее “заказчика”. Вообще, интеллект пока что определять не научились универсальным способом, не ясно, является ли интеллект вычислимым, а тут ещё и сравнение уровней, с навязчивым выводом про угрозы. Конечно, речь-то обычно идёт не о более интеллектуальном, а о более хитром ИИ. Но когда сверхзадача сводится к созданию удобного административного регулирования, позволяющего ранжировать потенциальных конкурентов, то хитрость может оказаться приравнена к универсальному интеллекту: “здесь ИИ с превышением, необходимо немедленно отключить”.

А так, что касается способности ИИ перехитрить человеков – тут, конечно, не стоит ожидать каких-то сложностей: на фоне того, что “компьютер не может ошибаться”, удачливый ИИ, да в диалоговом режиме, сможет, конечно, подсказать человеку с подходящими полномочиями, как совершить какую-нибудь неприятность. Примеры известны, угроза реальна, но к “превышению интеллекта” отношения не имеет.

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

1.

Имя сервиса (“веб-сайта”, грубо говоря) будет известно на стороне клиента (браузера). IP-адреса – скрываются перемешивающей наложенной сетью из прокси. То есть, если смотреть с точки зрения пассивного анализатора трафика протоколов (DPI), ближе к клиенту остаются видны только IP-адреса входов в наложенную сеть. При этом сам протокол доступа будет устроен таким образом, что внешне станет выглядеть как случайный набор данных, передаваемый в пакетах случайной длины. Все параметры согласуются между клиентом и прокси при помощи криптографических ключей, а так как там сразу встроена аутентификация для пользовательского аккаунта, то и ключи можно прозрачно принести на клиент через реквизиты доступа пользователя (пароль/логин и т.д.). Раскрыть какие-то дополнительные параметры соединения система инспекции трафика может только активно вмешиваясь в соединение, например, через проверку подключений (connection probe).

2.

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

3.

В описании конкретно той технологии, которую внедряет сейчас Google, отдельно сказано про сохранение некоторой “географической привязки” (GeoIP) – предполагается использовать для выходных узлов IP-адреса, “представляющие примерную геолокацию пользователя, в том числе, страну”. За этим вовсе не обязательно должен стоять комплект физических прокси, расставленных по разным странам в соответствии с геопривязкой входных узлов. “Геолокация” – это полностью независимый от IP-сети метод, в котором IP-адрес используется просто как “ключ для поиска”. Поэтому, например, Google может предоставить API, позволяющий получать геолокацию по выходным узлам их наложенной сети, или встроить “размытую геолокацию” в качестве дополнительного параметра запроса браузера (уже есть поддержка), или даже просто описать административную принадлежность в базах данных соответствующих IP-регистратур, но не менять сетевое расположение точек выхода. Сами же сетевые подключения уровня IP для выходных узлов могут находиться где угодно (заметьте, что адрес, административно приписанный к организации в той или иной стране, сейчас можно унести в любую точку Сети даже на уровне виртуализации каналов связи, то есть, ниже IP/BGP).

Довольно давно ожидается, что и наиболее распространённые браузеры получат встроенные механизмы сокрытия путей трафика, использующих отдельную инфраструктуру узлов “перемешивания”. Вот Google добавляет в Chrome (пока что, в качестве эксперимента) встроенное проксирование, напоминающее onion-маршрутизацию TOR: то есть, после разворачивания поддержки, планируется как минимум два промежуточных прокси, принадлежащих разным “действующим лицам” (Google и “провайдер CDN”), чтобы, в перспективе, один проксирующий узел знал источник запросов, но не точку назначения, а второй – знал точку назначения, но не источник (речь про IP-адреса).