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

В продолжение записки про наложенные сети Google для браузера. Внедрение таких перемешивающих технологий, конечно, заметно изменит ландшафт для систем фильтрации и блокирования (с DPI), которые будут внешними (относительно google-сетей). Внутри, понятно, возникнут своя фильтрация и блокирование, в точном соответствии с концепцией “Битвы за банхаммер“. Но снаружи останутся видны только IP-адрес клиента и IP-адрес входного узла Google – это важный момент: адрес не какого-то HTTPS-сервера или прокси, а сервиса доступа к вебу от Google. При этом протокол доступа у всех клиентов будет одинаковый.

Браузеры очень распространены, это один из основных источников трафика обычных пользователей – если привычный браузер перестанет работать “из коробки”, то, для таких пользователей, это окажется эквивалентно исчезновению доступа к Интернету. Однако, чтобы использовать наложенную сеть, программа-клиент не обязательно должна быть браузером: механизм доступа конкретно к браузеру не привязан – там достаточно универсальное туннелирование. Впрочем, похоже, что будет требоваться Google-аккаунт и аутентификация при доступе, но этот момент тоже переносится в другие приложения.

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

Много публикаций про систему ИИ от Google, которая предсказывает погоду. Интерес СМИ широкого профиля и журналистов тут вполне понятен: комбинация “Google, AI, weather/climate”, в направлении “Технологии”, сейчас одна из мощнейших. Исходная статья достаточно занятная, учитывая “хайп”: там рассказывается, что методы машинного обучения, использующие массив исторических данных погодных измерений, позволили сделать систему предсказания погоды, которая, по некоторым параметрам, превосходит имеющиеся “детерминированные” системы “численного моделирования”. Однако если вы захотите взглянуть на минимально содержательные детали, о которых там речь в действительности, то читать нужно не “заглавную статью”, а Supplementary Materials (но 132 страницы с таблицами и картинками, да).

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

Нейросеть с ИИ YaGPT2 (сайт ya.ru) на вопрос “По какому коридору идёт Штирлиц?” отвечает, что Штирлиц идёт по “коридору власти” (и выдаёт какие-то пояснения про то, что Штирлиц – это персонаж художественных произведений). Это, конечно, не тест Тьюринга, но как тест на знание некоторых культурных реперов – вполне себе используется. Ответ YaGPT2 в 2023 году выглядит, так сказать, несколько странно, потому что не особенно-то отличается от “говорилок”, доступных и десять-пятнадцать лет назад (это когда “преобразуем входной вопрос в SQL-запрос”).

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

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

В атаке с перехватом трафика 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, например), если только реализации не подразумевают достаточно сложных механизмов защиты ключей. При этом понятно, что никакой “полной защиты” от гипервизора тут быть не может.

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

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

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

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

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

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

Есть ещё такой аспект в практическом использовании систем “текстового” ИИ, типа ChatGPT: некоторые пользователи думают, что когда они задают этой системе “задание” написать текст по некоторой теме, то ИИ собирает информацию, проверяет предмет через “поисковые системы” и извлекает данные из “научных статей”.

Собственно, именно на этой интерпретации основана идея, что ИИ “заменит учёных” (оно, конечно, опрос “воображаемого эксперта”, как метод, для некоторых СМИ вполне может если и не заменить, то сильно облегчить, это факт). Чуть более маркетинговое толкование на этом же направлении приводит к предложению использовать ИИ для получения “краткого пересказа” статей.

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

А так, конечно, “компьютер не может ошибаться“.

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

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

В продолжение предыдущей записки о том, что Google успешно строит наложенную сеть для защищенного доступа своего браузера к веб-ресурсам. Интересно, что у Google информация о том, какие ресурсы посещал пользователь браузера, естественным образом сохраняется, поскольку для доступа к сети потребуется google-аккаунт. Не обязательно, чтобы историю прямо выдавал только браузер – собирать данные можно и при помощи веб-счётчиков Google Analytics, которые установлены едва ли не повсеместно.

Другой занимательный аспект: может даже так получится (из-за блокирования точек входа и отдельных веб-ресурсов в национальных сегментах, например), что для доступа к более или менее “глобальному” вебу потребуется аккаунт Google.

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

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

1.

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

2.

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

3.

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

Пишут про перехват TLS-трафика сервиса Jabber.ru, без ведома администраторов: это практическая атака, судя по подробному описанию – там всё как положено: MITM в TLS и подмена серверного сертификата на тоже валидный. Как пишут, выпуск сертификата, скорее всего, проведён при помощи перехвата трафика, идущего на оригинальный сервер – подменные сертификаты попали в CT-логи, в описании есть на них ссылки (это сертификаты Let’s Encrypt, конечно).

Вообще, побороться с подобной подменой, когда возможен перехват трафика на уровне хостера (а это практически всегда так), весьма сложно. Единственный более или менее эффективный способ – прямая авторизация серверных ключей клиентом по отпечаткам, однако, это сложно, плохо масштабируется, ну и так далее. (Отмечу, что применительно к Jabber/XMPP – есть схемы с защитой точка-точка, между пользователями – OMEMO, например). Certificate Transparency (CT), CAA и подобные технологии, направленные на УЦ, от таких атак не особо защищают: CT, несомненно, полезно, но часто работает постфактум, потому что, как минимум, нужно клиентам проверять метки в сертификатах; и это, если вообще считать, что CT тут работает – технически, выпустить быстрый подменный сертификат УЦ может без меток логов, ничто этому не мешает; да и метки можно сделать без публикации в логах, если есть ключи от этих логов; но, конечно, это всё существенно усложняет процесс. Что касается CAA-записей: да, это полезно, но для УЦ, технически, отказаться от проверки CAA ещё проще, чем проигнорировать CT-логи и SCT-метки.

(Ссылка: описание инцидента от OpenNet на русском.)

Дополнение: понятно, что УЦ, в такой конфигурации атаки, ни при чём – УЦ не имеет возможности в рамках сетевых протоколов отличить подменный узел от настоящего с точностью, превышающей перенаправление сетевого трафика в локальной сети хостера; естественно, автоматически выпускаемые TLS-сертификаты для веба не могут служить инструментом защиты от подобных атак, это и не планировалось, никакие CT тут не помогут; возможность активного и полного перехвата трафика с подменой – автоматически приводит к возможности выпустить TLS-сертификат с соответствующим именем хоста через УЦ TLS; перехват трафика – позволяет подменить данные и при DNS-проверке, это даже в чём-то проще, но перехватывать нужно трафик к DNS-серверам и/или от них (и не должно быть поддержки DNSSEC, да).