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

Отвлечённая литературная реплика про Новое Средневековье. При наблюдении над СМИ широкого профиля, которые относятся к разным логическим сегментам глобального мира, полезно выделять не сами события (как упоминания) или их различное описание, а процесс, соответствующий одновременному проявлению конкретного события (которое в этом случае чётко и узнаваемо обозначается) в СМИ разных логических сегментов. Это нередко даёт ценные понятийные инварианты. И только на следующем, втором уровне находится “дополняемость” оценочных/эмоциональных реперов, присутствующих в связанных с событием публикациях. Например, дополняют одна другую “негативная оценка” и “нейтральная” или “позитивная” и “нейтральная” (“негативная” и “позитивная” – не дополняют, как ни странно).

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

Суперпозиция на омонимах может быть развита вплоть до демонстратора важных онтологических принципов, стоящих за квантовыми вычислениями. Фраза “личинка заблокировала собачку в замке” содержит заметно более одного значения среди возможных. Однако, если сопроводить фразу “настроечным” текстом, значение схлопывается в конкретный вариант.

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

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

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

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

Десять лет назад на dxdt.ru появлялось, например, краткое упоминание про гиперзвуковой самолёт (а может – беспилотник) SR-72:

SR-72 должен достигать скоростей порядка M=6. Запланирована комбинированная двигательная установка, включающая турбореактивный двигатель, служащий в роли основного до скорости M=3.

На сайте Lockheed Martin страница уже недоступна, но, вроде как, аппарат SR-72 всё ещё продолжает находиться в “процессе разработки”.

В октябре 2023 года вышло немало записок на dxdt.ru, так что некоторые снова можно отметить дополнительно:

“Сжатие языковых структур” и кусочки “Илиады” – небольшой занимательный экскурс в различные версии фрагментов “Илиады” и их трансляцию через превращения основного текста в ходе линии времени;

Port knocking как инструмент управления доступом к скрытым сервисам – использование секретных последовательностей в качестве ключа для авторизованного доступа. Если данный технический вариант достаточно хорошо развить, то он вполне предотвращает разное “простукивание сервисов” со стороны сканеров, определяющих точки доступа: самый известный вариант – SSH;

Неравенство треугольника в Интернете и anycast – простой, геометрический и понятный, но не самый точный, способ определения anycast-узлов;

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

Споткнувшаяся симуляция Вселенной – странные рассуждения о вложенных вселенских гипервизорах и квантовом моделировании.

(Кроме того, в октябре вышло ежегодное обновление технического описания TLS.)

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

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

Личинка заблокировала собачку в замке.
(1) Из-за перекоса.
(2) В одной из комнат.

(Развитие темы: “Квантовые вычисления для филологов“.)

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

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

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

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

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

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

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

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