Почему-то много где громко пишут, что “обнаружена критическая неустранимая уязвимость процессоров Apple M1, раскрывающая криптографические ключи”, при этом имеется в виду новая “брендированная” атака Gofetch. Вообще, если почитать исходную работу, то речь там об очередном аппаратном “оракуле”, который использует, – опять же, очередной, – оптимизирующий компонент процессора: DMP (Data Memory-dependent Prefetcher), направленный на опережающее извлечение данных из памяти на основе косвенных “указателей” – то есть, значений, которые процессор считает записью адреса данных. Это популярное направление. Очень давно известно, что всякий подобный упреждающий механизм исполнения команд или извлечения данных порождает как минимум два побочных канала утечек (по записи и по чтению).

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



Комментировать »

В свежих версиях веб-сервера Nginx есть полезная (и довольно экзотическая) опция для настройки TLS: ssl_reject_handshake (on | off), о которой, оказывается, мало кто знает. Опция позволяет управлять прерыванием процесса установления TLS-соединения (“хендшейка”) на стороне сервера. С помощью “ssl_reject_handshake on;” можно отклонить TLS-соединение, если в клиентском ClientHello указано имя хоста (поле SNI), которого нет на стороне сервера.

Почему это удобно. Штатная работа веб-сервера по HTTPS подразумевает, что при установлении TLS-соединения клиент передаёт имя хоста, соответствующее DNS-имени веб-узла; например, для https://test.ru/ это будет test.ru. Однако никто не запрещает клиенту обратиться с другим именем хоста в SNI. Более того, на тот же самый IP-адрес, который соответствует веб-узлу под именем test.ru, может быть направлено другое DNS-имя (другой домен). Веб-браузеры, обращающиеся по такому имени, будут указывать его в SNI, а сервер, при прочих равных, не сможет найти не только соответствующий “виртуальный хост” в конфигурации, но и подобрать корректный TLS-сертификат. Однако какой-то TLS-сертификат для установления TLS-соединения серверу нужен и, без дополнительных мер, это приводит к тому, что сервер отвечает с “первым попавшимся” (буквально) серверным TLS-сертификатом из сконфигурированных.

Если на сервере всего один виртуальный хост/веб-узел (или настроены отдельные IP-адреса для отдельных веб-узлов), то ничего нового клиент не узнаёт. Однако если виртуальных хостов много, то ответ с произвольным сертификатом приводит к нежелательным утечкам имён: клиент получит сертификат, в котором будет указано имя другого сервиса, доступного на этом же узле (или несколько имён). Администраторы и даже DevOps об этом постоянно забывают.

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

Указание “ssl_reject_handshake on;” для default_server (для имени хоста по умолчанию) позволяет побороть только что описанную проблему: Nginx будет прерывать именно TLS-соединение, если клиент обращается с неверным именем хоста в SNI – это, что называется, технически строгий способ. Браузер, в таком случае, выведет сообщение о недоступности узла, а не предупреждение о несовпадении имён, которое пользователи привыкли преодолевать при помощи кнопки “Всё равно продолжить”.



Комментировать »

В свежих версиях браузера Chrome на сторону серверов Google предлагается передавать информацию о запрашиваемых URL в реальном времени – это такое “улучшение для безопасности”, развитие давно работающей технологии Safe Browsing, но с некоторыми занимательными особенностями.

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

Google Safe Browsing and Proxy
(Image: Google.)

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

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



Комментировать »

В конце 2022 года я добавил в DNS для dxdt.ru HTTPS-запись, которая тогда была описана в черновике RFC. В ноябре 2023 года черновик стал RFC 9460, где определяется способ публикации в DNS дополнительной информации о параметрах подключения к сервисам, связанным с данным именем. Например, это могут быть параметры для TLS/HTTPS, в том числе, ключи (см. ECH). Особенность использования DNS тут в том, что параметры можно получить до подключения, это, в свою очередь, позволяет устанавливать скрытые подключения.



Комментировать »

The New York Times рассказывает (там много букв), как в Штатах водители современных “подключенных” автомобилей (то есть, автомобилей, у которых есть привязанное приложение с интернет-подключением) внезапно обнаружили, что очень подробные данные об их поездках передаются “скоринговым агентствам”, а статистика потом прямо влияет на стоимость страховки (“опасное вождение” и тому подобные эффекты). Данные, при этом, передаются через производителей автомобилей.

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

(via)



Комментировать »

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

Например, венозный рисунок ладони, считываемый некоторой аппаратурой, – он, может, разный у каждого человека, но сравнение-то будет выполняться после обработки “картинки” этого рисунка по некоторому алгоритму. Алгоритм, предположим, “сжимает” геометрический рисунок до 64 битов идентификатора, используя именно важные элементы (пересечения, фрагменты сетки, углы и пр., это тут не так важно). Получается что-то вроде хеш-функции или “функции сжатия”. В идеальной ситуации даже одно минимальное отличие рисунков должно давать другой код. При этом, конечно, возникает идея сделать не просто хеш-функцию, а такую хеш-функцию, которая ещё и обладает нужной локализацией, то есть, “близкие” рисунки дадут “близкие” значения. Кстати, такие функции сжатия или хеш-функции называются Locality-Sensitive Hash (LSH). Они удобны далеко не только в обработке биометрии. Однако есть побочные эффекты. С одной стороны, подходящая локализация поможет добавить ещё один слой устойчивости к ошибкам считывания, но, с другой стороны, может выдавать ложное положительное срабатывание.

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

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

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



Комментировать »

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

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

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



Комментировать »

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

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



Комментарии (5) »

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

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

Отчасти проблема решается настройкой агентов в пассивный режим: агент мониторинга больше не обращается на центральный сервер за командами и инструкциями, но присылает отчёты о состоянии локальной вычислительной среды в одностороннем порядке, с заданной периодичностью. Это вполне себе типовая настройка, но используют её не так часто.

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

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



Комментировать »

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

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

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

Суть ROP – в выделении набора “гаджетов”, представляющих собой кусочки исполняемого кода, оканчивающиеся командой RET (return и пр. – то есть, “возврат”, передача управления по адресу, взятому из стека). “Гаджеты” – это достаточно произвольные фрагменты из разных мест исходной программы, главное, чтобы конкретный гаджет выполнял нужные действия. Утрированный пример: какой-то гаджет может увеличивать значение заданного регистра на единицу (A: ADD AX, 1; RET;), а другой – записывать значение из регистра в память, по адресу, заданному тоже регистром (B: MOV [AX], DX; RET;). Тогда, разместив в подготовленный стек нужное количество вызовов первого гаджета (A), можно получить нужное значение адреса, куда, при помощи второго гаджета (B), запишется то или иное значение (загрузить это значение в регистр-источник можно третьим гаджетом).

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

Закладки вообще непросто обнаруживать. Но обнаружить такое решение ещё сложнее, даже если анализировать постфактум дампы памяти, взятые в момент срабатывания. А представьте, что к чисто программной части добавлена недокументированная аппаратная составляющая – эффективность и степень маскировки увеличиваются в разы.



Комментировать »

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

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

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

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



Комментировать »