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

ICANN отложила ротацию корневого ключа DNSSEC на неопределённое время. Первоначально, фактическую ротацию планировали провести 11 октября этого года. В качестве причины указаны данные о недостаточном распространении нового KSK (корневого ключа) по резолверам. Напомню, что корневой ключ (RSA, разрядностью в 2048 бит) в DNSSEC не менялся с момента внедрения технологии в глобальной DNS, то есть, с 2010 года. О механизме ротации при запуске просто забыли. За это время такой алгоритм ротации был предложен и утверждён согласно процессу IETF (RFC 5011), но теперь ICANN при помощи другого технологического механизма (RFC 8145) и косвенных данных обнаружила, что алгоритм ротации не работает.

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

Очередное обновление технического описания TLS, которое я поддерживаю и дополняю. Добавлено: подробное описание ряда ключевых атак на TLS (многие из них нашумели – POODLE, Logjam, весьма изящная DROWN и др.), подробное описание шифра ChaCha20 (вероятно, будет альтернативным для AES шифром в TLS 1.3). Текст довольно специальный (я, впрочем, уверен, что некоторые разделы будут понятны и полезны не только специалистам, но и тем, кто просто интересуется темой). Описание – здесь: https://tls.dxdt.ru/tls.html

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

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

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

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

Обновил раздел “Избранные записки” – добавил ссылки на восемь новых.

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

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

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

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

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

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

В инфраструктуре DNSSEC существует самый верхний ключ – KSK корневой зоны. К этому ключу ведут все (штатные) цепочки валидации DNSSEC, соответствующие общепринятой структуре DNS с единым корнем. Главный корневой ключ не менялся с момента запуска DNSSEC в 2010 году: спроектировать и согласовать механизм замены ключа каким-то образом забыли. Сейчас такой механизм появился, и начался процесс подготовки ротации KSK корня DNS: 11 июля в корневой зоне опубликован новый ключ (KSK) – KSK-2017. Так как новый KSK подписан действующим, можно произвести его замену автоматически, используя только DNS. Алгоритм описан в RFC 5011. То есть, если валидирующий резолвер поддерживает RFC 5011, то можно ожидать, что он автоматически заменит старый ключ на новый. Тем не менее, лучше заранее проверить, что резолвер смог получить новый ключ и включил его в список доверенных. Фактическая замена ключей (rollover) намечена на осень этого года (11 октября 2017) – до этого момента нужно убедиться, что ваш резолвер сможет использовать новый ключ, иначе валидация, спустя какое-то время после ротации, полностью сломается.

KSK-2017 можно добавить в резолвер и в ручном режиме, например, скопировав значение ключа из корневой зоны и проверив подписи. Информация о корневых ключах также доступна на сайте IANA.

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

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

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

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

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

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

И, конечно, если секретные ключи у сторон есть, то они могут построить скрытый канал связи, не только на базе трафика видеотрансляции, но и многих других носителей, в том числе, на базе текстовой информации – различаться будет только скорость обмена.

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

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

Естественно, возможны варианты, когда для успешной авторизации требуется ответить на не известный заранее вопрос или, скажем, повернуть голову влево и моргнуть правым глазом. Но так как речь идёт об удобстве использования, вряд ли станут внедрять даже такие элементарные методы интерактивной идентификации. Тем более, что они малоэффективны.

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

Биометрическая идентификация должна использоваться только в качестве дополнения к другим методам, и проводить её должен тоже человек (пусть и с применением “технических средств”).

В марте прошлого года я писал про направление атак, связанное с датчиками систем управления техпроцессами:

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

Эта тема, действительно, быстро развивается. Например, на Black Hat заявлен доклад как раз про устройства мониторинга уровня радиации, где речь должна идти и о беспроводных датчиках.