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

С автономными такси-роботами возможны ситуации, когда это такси везёт пассажира куда-то “не туда” или, например, просто остановилось на дороге и не выпускает. Нетрудно предположить, что точно такие же ситуации возможны и в случае с такси, которым управляет водитель-человек. Однако вариант с роботами – отличается, и отличается столь же существенно, как и все подобные “автоматизации”, потому что автоматизация тут автоматизирует и атаки.

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

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

Так что роботы-такси вовсе не обязательно делают систему безопасной, поскольку возникают новые варианты атак и новые уязвимости.

В статье из 2019 года, посвящённой блокировкам и блокированию протоколов в Интернете, я писал вот что:

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

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

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

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

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

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

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

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

Часто попадаются в публикациях СМИ утверждения, что, якобы, это особенность “open source” в том, что в такие библиотеки и другое ПО включают “вредоносные возможности”. Но это не так. Модель распространения ПО никак не связана с возможностью добавления “вредоносного кода”: добавить такой код можно и в исходники, и в скомпилированный исполняемый код, а добавить что-то такое в скомпилированный код даже может быть проще, поскольку исходники ещё собирать кто-то будет и “зловредная нагрузка” может не собраться, собраться не так или не попасть в исполняемый код.

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

Естественно, трудности вызывает современное разделение по библиотекам и направлениям, которое приводит к тому, что возникает “развесистая” система зависимостей, за которой очень сложно, – даже невозможно, – уследить. Хрестоматийным примером тут является “экосистема” Node.js, где едва ли не под каждую элементарную подпрограмму делается отдельный “модуль”, а количество “вложенных зависимостей” очень велико. Но, естественно, речь не только про Node.js. Источники могут использовать самые разные правила добавления кода, а бывает так, что одиночная небольшая библиотека встроена в тысячи продуктов, которые тянут её код с собой. И вот, предположим, исходный репозиторий этот библиотеки оказался заброшен, а потом был взломан. Взломавший теперь получает возможность потенциальной инъекции произвольного кода в те самые тысячи продуктов. Но такая инъекция всё же может быть обнаружена.

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

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

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

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

Предположим, что пользователь оставил устройство, выданное для оплаты, в области, где использование финансовых средств разрешено, а сам куда-то переместился и пытается управлять устройством дистанционно, через те же самые “интернеты”. Что тут можно поделать? Напрашивается самый простой вариант: биометрическое подтверждение – чтобы предъявить свои биометрические показатели, предположим, пользователь должен быть рядом с устройством. Да, транслировать “через расстояния” сведения о биометрии можно, как можно и записать нужные “образцы” заранее. Однако, при правильной аппаратной архитектуре пользовательского устройства и при хорошей схеме протоколов авторизации платежей, сделать это станет весьма непросто: задача, скорее всего, перестанет иметь автоматическое решение для рутинных операций.

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

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

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

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

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

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

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

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

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

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

Сообщают, что “Яндекс” в своих навигационных приложениях начал как-то учитывать влияние спуфинга GPS, используя дополнительные данные (WiFi и пр.). Кстати, я в 2018 году писал, что “центральный сервер мог бы определять наличие GPS-спуфинга на основе анализа данных, поступающих от множества устройств”. Вообще, не ясно, занимается ли чем-то таким сервис “Яндекса”, но если у вас есть множество устройств и центральная точка сбора данных, то можно разные интересные вещи измерять.

Так, навигационное поле, формируемое гражданским сигналом GPS, можно достаточно точно рассчитывать для произвольной точки поверхности Земли, в том числе, с опережением или отставанием по времени. Для этого не нужно устанавливать приёмник в той точке, для которой выполняется моделирование. Да, тут необходимо подчеркнуть, что это всё за вычетом искажений, вносимых постройками и пр. – но, собственно, в этом и состоит интересная часть. К сожалению, от обычного смартфона не удастся получить детальной информации о сигнале GPS, как его видит приёмник, но, тем не менее, часть данных, коррелирующих с сигналом, всё же приходит. Смартфон может дополнительно собирать сведения о сигналах WiFi, о GSM, о передатчиках Bluetooh (и не только). Так вот, если у вас есть устройства “на местах”, которые приносят дополнительную информацию, а не только “координатные данные” GPS, то можно на центральном сервере выстраивать динамику изменения реального навигационного поля по сравнению с моделью, учитывающей только положение и состояние спутников. Это позволяет не просто получить корректирующую величину для всех участников системы, но также увидеть возникающие на местах пространственные дефекты и искажения с развёрткой по времени (то есть, не просто спуфинг), что весьма ценно.

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

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

И вот вся эта логика превращения контринтуитивности сейчас хорошо проявляется в том, как воспринимают очередные достижения генерирования текстов силами систем ИИ.

Из недавней записки цитата про ИИ:

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