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

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

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

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

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



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

Немного технологических параллелей. Предположим, что на сервер баз данных, через сеть, отправляются запросы добавления записей. При этом каждый запрос требует завершения транзакции – то есть, обратно клиенту должен прийти пакет, подтверждающий выполнение, после этого клиент может отправить следующий запрос. В условных терминах привычного SQL – это будут команды INSERT. Известно, что в такой схеме производительность, по числу добавлений в секунду, определяется сетевой задержкой. То есть, если пакет находится в пути 10 ms, то сервер должен дожидаться следующего INSERT 20 ms (потому что в обе стороны), а это гарантирует верхний предел в 50 записей в секунду, даже если сервер выполняет одну запись за 1 микросекунду (на несколько десятичных порядков быстрее).

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

Естественно, эта особенность действует не только для баз данных: ограничивающее влияние сетевых задержек на транзакционные схемы с подтверждением есть в TCP (где с этим явлением борются: см. TCP Fast Open), в TLS (здесь тоже борются: см. TLS Early Data/0-RTT и др.), и в других протоколах. Схема обобщается и на многие решения, которые не имеют отношения к интернет-протоколам.

Рассмотрим такой сценарий: РЛС, предназначенная для определения координат и скорости “быстрых объектов” на “существенном расстоянии”. Тривиальная импульсная РЛС, полагающаяся на отражения отдельных зондирующих импульсов в строгом порядке, оказывается в такой же ситуации, как и сервер баз данных выше (при том, конечно, что РЛС появились раньше таких серверов). Излучили короткий импульс – приняли отражённый сигнал, обработали, отправили очередной импульс – если время до цели 1 ms (300 км, примерно), то получается разрешающая способность наблюдения в 500 Гц, максимум. А если цель дальше, то будет меньше. Хуже всего, что отражённый сигнал вообще может не прийти обратно к точке излучения на нужном уровне. Но если импульсы отправлять чаще, не ждать отражения, или даже использовать непрерывный зондирующий сигнал, то ситуация, в теории, резко улучшается, как и в случае с сервером баз данных: можно обрабатывать отражённый сигнал с разрешением хоть в гигагерц. На практике, впрочем, возникнут проблемы, потому что РЛС – это не сервер баз данных. Принимать сигнал одновременно с излучением – весьма трудно, если не использовать разнесённые в пространстве антенны (бистатическая радиолокация). А увеличение частоты следования зондирующих импульсов требует использования более сложных алгоритмов кодирования и обработки, которые позволяют различать отражённые сигналы, соответствующие различным зондирующим импульсам. Это, впрочем, обычная задача для современных РЛС.



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

В браузере Chrome версии 122, вышедшей на днях, включена по умолчанию поддержка постквантовой гибридной криптосистемы TLS X25519Kyber768 (раньше данная возможность включалась вручную, через флаг). Данная криптосистема уже некоторое время поддерживается моим экспериментальным сервером TLS – посмотрим, увеличится ли количество подключений с X25519Kyber768: у этой криптосистемы на сервере повышен приоритет, но подключений пока что очень мало (естественно, там далеко не только браузеры в качестве клиентов).

(Кстати, так как популярный “Яндекс.Браузер” является клоном Chromium/Chrome, а TLS-стек там соответствует версии Chromium, то и в браузер от “Яндекса”, как я понимаю, поддержка постквантовой криптосистемы в TLS тоже приехала автоматически.)

(Update, 07/03/2024: оказывается, в последний момент выход передвинули на версию 124.)



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

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

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

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

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

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

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



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

Картинка из прошлогодней записки про таблицу подстановок:

S-boxes

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

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



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

Интересно, что Google Public DNS (8.8.8.8) при взаимодействии с зоной dnssec.pw, которую я на днях снабдил ключами с одинаковыми тегами, продолжает возвращать неконсистентные результаты, если спрашивать об отсутствующих в зоне записях. Например, при запросе TXT-записей в dnssec.pw теперь нередко приходят ответы со статусом SERVFAIL, “RRSIG with malformed signature…” – написано в пояснении. Однако есть и ответы со статусом NOERROR (примерно, половина, как ни странно), где, впрочем, пояснение тоже указывает на “RRSIG with malformed signature…”.

Возможно, конечно, что в данном сервисе на разных экземплярах узлов разное программное обеспечение, но есть и другое, несколько более занятное, объяснение: может так быть, что сервис ограничивает количество попыток проверки подписи для каждой итерации. В зоне четыре ключа ZSK, подпись RRSIG на NSEC – одна, на SOA – две. Соответственно, если у резолвера установлено некоторое предельное количество ошибок проверки подписи, то, когда предел достигнут, резолвер прекращает попытки перебора ключей и возвращает SERVFAIL. Если же ключ удалось угадать за меньшее количество попыток, то возвращается NOERROR. Подсчёт строк с сообщениями “RRSIG with malformed signature” в ответах – укладывается в эту гипотезу, но чтобы судить точнее – нужно собрать дополнительную статистику.



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

DNSSEC-подписи, удостоверяющие адресную информацию, размещаются в RRSIG-записях. Ссылка на открытый ключ, нужный для проверки подписи, в RRSIG записывается в виде 16-битного тега (KeyTag), который вычисляется по достаточно простому алгоритму от данных ключа. Соответственно, ключи публикуются в DNSKEY-записях. Можно ли специально подобрать несколько валидных ключей так, чтобы у них были одинаковые теги? Очевидно – можно (ключей много больше, чем тегов). И подбор совсем нетрудно сделать. Более того – даже сохранятся валидные подписи и, условная, “корректность” зоны с точки зрения DNSSEC. “Корректность” тут в кавычках потому, что, вообще говоря, несколько ключей с одинаковыми тегами не должны бы присутствовать в DNS-зоне, поскольку это нарушает логику ссылок из RRSIG. И хорошо бы в таком случае выводить ошибку валидации, но возможен более мягкий подход, который и используется.

Посмотрите, в качестве примера, на DNS-зону dnssec.pw – там я разместил несколько ключей (ZSK – Zone Signing Key), которые имеют одинаковые теги со значением 12345. Два ключа из четырёх ZSK задействованы в подписывании записей, а поскольку подписи можно проверять методом перебора ключей, то и RRSIG – валидируются, если валидатор резолвера справляется с ситуацией. Пятый ключ – это KSK, точка входа. Схема показана на картинке (ниже), которую сформировал весьма полезный сервис DNSViz. Повторяющиеся идентификаторы (id = 12345) выглядят занятно, однако количество вершин графа соответствует количеству ключей, а рёбра – соответствуют структуре подписей. Так что DNSViz не сломался:

dnssec-pw DNSSEC graph

Другой, не менее полезный, сервис для анализа DNSSEC – DNSSEC Analyzer – проверки для данной зоны тоже выполняет корректно, но в таблице результатов совпадающие идентификаторы могут запутать несколько больше, чем на графе GraphViz:

dnssec.pw DNSSEC status

Валидирующие резолверы должны справляться с подобной конфигурацией ключей, однако Google Public DNS (8.8.8.8) возвращает в статусе информацию о “некорректном формате RRSIG”, но ответ всё равно снабжается флагом AD (Authentic Data), обозначающим, что проверка подлинности DNSSEC прошла успешно – впрочем, это соответствует действительности: подписи и цепочка в зоне dnssec.pw сейчас верные.



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

В логах веб-сервера dxdt.ru тысячи записей о GET-запросах от некоторого ClaudeBot, как указано в User-Agent. Больше в User-Agent ничего не указано, хотя правила хорошего тона предполагают, как минимум, ссылку на страницу с описанием того, “что это, зачем и как оно приходит” – в HTTP это нетрудно сделать. Конечно, в User-Agent каждый может написать что вздумает, но данный ClaudeBot ещё и приходит за одними и теми же страницами (которые не изменялись), постоянно переключая IP-адреса. А IP-адреса там из пула AWS (амазоновский сервис), поэтому даже и обратная зона мало о чем говорит (ну, кроме того, что это AWS). Непонятно, имеют ли следы в логах, оставленные данным ботом, какое-то отношение к деятельности одноимённого продукта очередной AI/ИИ-компании, решения которой для российских пользователей заблокированы, но забавно уже то, что имя используется совпадающее; тем более, что на сайте компании не удалось найти ничего о том, как их боты оформляют свои запросы.



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

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

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

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

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

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

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



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

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



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

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

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

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



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