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

Известно, что греческая буква “о-мега” это, в каком-то смысле, дважды буква “о-микрон”. Если точнее, то “о-микрон” – краткое О (“микро-о”), а “о-мега” – большое или долгое О. Занятно, что в некоторых старинных рукописных начертаниях омега как раз и записывается как два омикрона. Подтверждающий скриншот из манускрипта Urb.gr.15 (“Слова” Григория Богослова, десятый век):

Например, в конце второй (на скриншоте) строки, слово προθύμως – отчётливо видно, что буква ω построена в точности как пара склеенных ο. Такое же начертание омеги нетрудно обнаружить и в первой строке, в слове ἡμῶν (локализация границ самого слова, впрочем, может оказаться затруднительной, если оно не знакомо читателю). А вот пара “омикронов-окружностей”, придавленных сверху чертой – это тоже π.

При изучении скриншота может показаться, что там присутствуют некие “велосипедные” двойные омикроны в начале и в конце первой строки, но нет – это сигма и омикрон в слове ὅσοι.

Кстати, в палеографии этот вариант рукописного древнегреческого называется “минускулом типа bouletée”, а такая запись омеги – один из характерных признаков. (Наверное, скоро можно уже не отмечать записки про древнегреческий и палеографию как офтопики.)

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

DNS-серверы должны игнорировать регистр символов имени из состава запроса. Записи dXdT.RU. и dxdt.ru. – должны считаться совпадающими. Есть, впрочем, свои особенности: DNS-ответ включает в себя и имя из запроса, а одно из толкований требования об “игнорировании регистра” состоит в том, что если регистр игнорируется, то его можно игнорировать и в ответе. То есть, с одной стороны, ответ должен содержать имя в точно таком же формате, в каком оно поступило в запросе (обычно, так и происходит), с другой стороны, если считается, что при сравнении регистр не имеет значения, то имена dXdT.RU. и dxdt.ru. – равны, а поэтому можно в ответ смело писать dxdt.ru. (или DxDt.ru., например).

Тем не менее, регистр символов довольно давно предложено использовать в качестве носителя дополнительной информации – для рандомизации состава запроса. Это создаёт ещё один инструмент для защиты от атак на DNS, которые используют поддельные ответы, опережающие соответствующий запрос по времени. Подобная атака состоит, например, в том, что в адрес рекурсивного резолвера отправляется большое количество пакетов, имитирующих ответ на DNS-запрос от авторитативного сервера, но содержащих подменные данные, например, IP-адрес сервера злоумышленника в A-записи. (DNS использует UDP, поэтому такая подмена возможна на уровне транспорта.) Если рекурсивный резолвер не сможет отличить подменный пакет от настоящего, – который, хотя бы, соответствует запросу, – то в локальный DNS-кэш попадёт подставное значение, оно и будет передаваться узлам, использующим данный резолвер (это называется “отравление кеша”). Естественно, для того, чтобы атака сработала, резолвер должен ожидать ответ об атакуемой зоне, но это не так трудно организовать: есть очень популярные зоны, запросы об именах в которых регулярно возникают; кроме того, нужный запрос может быть отправлен в резолвер самим злоумышленником. Последний вариант хорошо подходит для популярных открытых сервисов DNS, таких, как Google Public DNS, где, как раз, рандомизация регистра букв широко используется (собственно, запросы со скриншота – пришли из этого сервиса).

Как рандомизация регистра символов помогает защитить DNS-ответы? Довольно очевидным способом: резолвер отправляет запрос, в котором символы имени указаны в разном регистре, тем самым кодируя некоторое битовое значение (понятно, что строчная буква может кодировать единицу, а заглавная – ноль); закодированное значение резолвер запоминает и проверяет совпадение регистра в полученном ответе. Тогда, если ответ сгенерировал кто-то, кто реально видел запрос, то этот кто-то сможет подставить правильный код в регистр символов. Схема не защищает от отправки ответа раньше настоящего авторитативного сервера (или вместо этого сервера), но от отправки ответа раньше запроса – защищает. Рандомизация параметров DNS-запроса, снижающая предсказуемость параметров ответа, реализуется в DNS и другими способами. Прежде всего, это номер порта источника (номер порта – 16-битное значение), кроме того, в запросе есть поле Transaction ID (ещё 16 бит). Регистр букв имени может добавить заметное количество значимых битов. Если, конечно, технология поддерживается на стороне авторитативных серверов. И если кто-то не решил “посигналить” строчными/заглавными в обратную сторону. В общем, много “если”. (Напомню, что полноценную защиту от подмены ответов предоставляет DNSSEC.)

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

Хорошо виден основной эффект: в результате замены, расстояние между байтами возрастающей последовательности увеличивается, а “статистика”, порождаемая алгоритмом (n+1), скрывается. Подобные таблицы замены относятся к основным элементам, используемым при построении современных шифров. Естественно, сама по себе таблица никакой стойкости не обеспечивает, но, например, решает важную задачу “быстрого” размывания последовательностей “близких” значений во входных данных. Значения для замены специально подбираются так, чтобы эффективно решать именно эту задачу. От таблиц замены зависит стойкость шифров, так что исследование их свойств имеет большое значение (в том числе, с точки зрения обнаружения возможных архитектурных бэкдоров), в частности, конкретно с таблицами “Кузнечика” связана целая серия работ, но это тема для другой записки. Возможно, я напишу подробное описание работы шифра “Кузнечик” для dxdt.ru. С цветными картинками. (“Магма”, второй шифр из соответствующих ГОСТ, – достаточно давно подробно описан.)

В 2018 году я разработал и опубликовал по адресу tls13.1d.pw тестовый сервер для проверки приложений, поддерживающих TLS 1.3. Строго говоря, тогда именно TLS 1.3 (в смысле обозначения версий) ещё не было, а был черновик спецификации, которую, в экспериментальном режиме, поддерживали некоторые распространённые клиенты, например, браузеры Chrome и Firefox. На серверной стороне дело обстояло похуже – поддержки в стабильных версиях распространённых веб-серверов не было совсем.

Сейчас TLS 1.3 стал типовой, очень распространённой версией TLS, используемой в вебе (и не только в вебе), поэтому, думаю, тестовый сервер больше не нужен: отключение tls13.1d.pw я запланировал на конец августа 2023 года (возможно, раньше).

Собственно, всякий современный TLS-сервер для HTTPS должен поддерживать TLS 1.3 в качестве основного, а TLS 1.2 – в качестве “запасного” варианта. Прочие версии можно отключить, ну, кроме весьма редких случаев, когда требуется совместимость с очень старыми приложениями – к сожалению, некоторым веб-сервисам приходится тянуть поддержку старых клиентов. Однако для остальных – можно даже оставить только TLS 1.3: этот протокол портировали на самые старые и экзотические системы. Кроме того, TLS 1.3, на данный момент, лучшая версия, которая архитектурно превосходит все предыдущие.

(Update, 09/09/2023: сервер пока что восстановлен и работает – подробности.)

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

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

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

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

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

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

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

Кстати, очередной пример, почему ssh forwarding не такой безопасный вариант использования ключей на удалённых системах, как может показаться: при желании, через ssh-agent обратно может приехать исполнение кода на локальной системе, впрочем, с некоторыми дополнительными “плясками” – CVE-2023-38408. Авторы, естественно, не забывают упомянуть ASLR, PIE и NX:

“Surprisingly, by chaining four common side effects of shared libraries from official distribution packages, we were able to transform this very limited primitive (the dlopen() and dlclose() of shared libraries from /usr/lib*) into a reliable, one-shot remote code execution in ssh-agent (despite ASLR, PIE, and NX)”.

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

Так, если взять в качестве примера привычную запись текста на естественном языке, то простой шифр алфавитной замены (“А” -> “Д”, “Б” -> “Э” и т.д.: буквы заменяются на буквы по перестановке того же алфавита, ключом является перестановка) не обладает только что описанным свойством: если попросить “коробочку” зашифровать слово “длинношеее”, то результат, очевидно, получится угадываемым (ну, конечно, в той степени, в какой вообще можно поверить в случайные биты).

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

Интересно, что внесение дополнительного слоя сохранения некоторых статистических характеристик является одной из теоретических областей создания алгоритмических закладок/бэкдоров в шифрах. Представьте блочный шифр. То есть, такой шифр, который на вход получает, предположим, строго 256 битов и 256-битный ключ, а выводит тоже строго 256 битов шифротекста. Многие современные шифры так работают. Если шифр идеальный, то вывод будет равновероятным, а для успешного поиска нужно будет перебирать, хотя бы, 2^255 вариантов.

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

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

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

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

На уровне IP есть источники сигнатур, сходные по происхождению с только что описанными. Это те же сдвиги времени доставки (в том числе, можно подсчитывать скорость изменения задержек – брать производную), а кроме того, можно предположить, что и в заголовках пакетов присутствуют сочетания значений (ID, опции и пр.), которые связаны с конкретным источником пакета, но, опять же, всё, что есть в заголовке, размывается в ходе передачи пакетов промежуточными узлами (и это даже без учёта NAT-ов).

TCP предоставляет некоторое количество новых сигналов: что-то можно специально добавить, да ещё и на разных этапах установления соединения (см. SYN-куки и т.д.), при этом сам процесс установления сессии позволяет выделить дополнительные особенности – сдвиги по меткам времени, характеристики из заголовков, взятые по разным сигналам. Отдельный новый базис TCP – это номера портов, а точнее, их изменение: тут экзотические методы использования, – вроде port knocking, – вообще могут позволить узнать конкретный источник сессии без всякой привязки к IP-адресу или к параметрам протоколов более высоких уровней.

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

Пишут, что в Сан-Франциско активисты блокируют автомобили-роботы при помощи пластиковых дорожных конусов, которые просто устанавливают на капот автомобиля: с конусом автомобиль ехать не может, вероятно, из-за проблем с обзором; а снять конус с капота – некому. Вообще, автомобиль мог бы сбивать такие помехи специальным водомётом, который водомёт ещё и для разгона зазевавшихся пешеходов полезен. Это, впрочем, оставлено на будущее. Процитирую свою недавнюю записку по теме:

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

(via)

Знаменитая компьютерная игра Another World, вышедшая в 1991 году, исполнялась на собственной виртуальной машине: то есть высокоуровневый код игры компилировался в специальный байт-код, команды которого уже исполняла реализованная для конкретной аппаратной платформы виртуальная машина. Такая архитектура позволяет удобным способом переносить программу между платформами, а так как с 1991 года технологии существенно развились, – особенно, в аппаратной части, – то не так давно Another World перенесли на FPGA, в чём тоже помог подход с виртуальной машиной (по ссылке – подробное описание, на английском).

(Найдено на Hackaday.com.)