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

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

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

Пишут про перехват 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, да).

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

(Кстати, об особенностях мультиплексирования HTTP/2 регулярно забывают, что приводит к попыткам ограничить поток HTTP-запросов для проксирующего веб-сервера, который работает по HTTP/2, “силами iptables” по TCP-соединениям.)

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

Есть занятный, пусть и не самый точный, способ определения того, что какой-то глобальный и маршрутизируемый IP-адрес соответствует anycast-узлу: нужно измерить время ответа (ICMP) при помощи утилиты ping, но сделать это из двух базовых точек, заведомо находящихся в существенно разных регионах, а потом измерить ping между этими точками. Если сумма для времени от точек измерения до измеряемого узла существенно меньше, чем время между базовыми точками, то, скорее всего, тут присутствует anycast. Это неравенство треугольника, и оно тут при помощи anycast нарушается.

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

Один из самых старых способов скрытого получения доверенного доступа к не менее скрытым сервисам в Интернете (как IP-сети) это port knocking (метод “секретного портового стука”). Суть метода изложить не трудно: скрываемый сервис работает на закреплённом за ним номером порта, но доступ для TCP-соединений (например) к этому номеру порта открывается только для тех IP-адресов, которые выполнили установленный набор попыток подключений по другим номерам портов. Чуть более развёрнутое объяснение для тех, кто не сетевой инженер (опять же, используем TCP): TCP-соединение – это соединение “точка-точка”, на каждом из концов соединению соответствует IP-адрес и номер порта, где номер порта, можно считать, это просто 16-битное число; например, 10.11.12.13:14395 -> 10.101.102.103:22 – соединение клиента с номером порта 14395 на серверный номер порта 22 (это обычный номер для SSH); предположим, что доступ на сервере по порту 22 закрыт межсетевым экраном (брандмауэром), то есть, попытка соединения на этот номер порта будет проигнорирована сервером; но если некоторый клиент с IP 10.11.12.13 выполнит попытки TCP-подключения на другие номера портов сервера по заданной ключевой последовательности: 1011, 1022, 1033, то брандмауэр, который фиксирует у себя попытки подключения, откроет подключения по номеру порта 22, но только для соответствующего IP-источника.

Естественно, все номера тут могут быть любыми (из допустимых интервалов). Метод весьма полезный, я его использую для открытия доступа к шлюзам, ведущим в некоторую “закрытую” сеть: совершенно необязательно открывать конкретный сервис на конкретном узле, с тем же успехом можно открыть туннель.

Почему-то данный метод и известен не столь широко, как можно подумать, да и нередко его необоснованно относят к способам защиты из разряда Security through obscurity (“Безопасность через неясность”, в одном из переводов), которые, как бы, “заведомо слабые”, что как раз и есть хороший пример неверного обобщения “принципа Керкгоффса”. Однако данный метод хорош, если используется по назначению и в верном контексте. А если излишне настойчиво обобщать, то и авторизация SSH по ключу может показаться “безопасностью через неясность” – действительно, а как если бы он знал значения байтов секретного ключа и их последовательность? Впрочем, это лирическое отступление.

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

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