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

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



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

Обновил страницу “Избранные записки“.



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

Описание того, как в iMessage внедрили вариант постквантовой криптосистемы Kyber1024, Apple сопровождает иллюстрацией, на которой популярные мессенджеры ранжированы по степени “защиты” пользовательских сообщений криптографическими методами. Telegram находится на самом низком, нулевом уровне (Level 0 – защиты E2E нет), вместе со Skype и др. – см. скриншот ниже.

Messengers and Levels



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

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

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

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

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

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



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

Затихшая OpenAI

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



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

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



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

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

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

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

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

(Май 2017 г.)



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

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

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

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

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

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

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



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

Забавный заголовок новости на SpaceNews.com: “AI company developing software to detect hypersonic missiles from space” (“ИИ-компания разрабатывает программное обеспечение для обнаружения гиперзвуковых ракет из космоса”). Думаю, понятно, почему заголовок забавный: это, фактически, художественный пересказ ключевого события из фантастической кинематографической ленты (даже из разных лент), так как речь-то в сообщении про заказ от штатовского SDA – профильного военного агентства.

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



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

Воскресное чтение манускриптов. В этот раз – пара иллюстраций из инструкции по созданию метательных машин от Герона Александрийского (первый век н.э), в версии манускрипта Vat.gr 1164 (а это уже 11 в., тысячу лет спустя) из Ватиканской Апостольской библиотеки. Схема баллисты:

Ballista

Подробный чертёж важной детали (περίτρητα), которая обеспечивала крепление механической обвязки вокруг “торсиона” (текст со скриншота – относится к другому чертежу):

Peritreta

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



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