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

В рамках проекта КЦ и ТЦИ “Домены Россиии” (statdom.ru) – мы добавили статистику TLS по российским зонам. (Официальная новость.) Приведено несколько основных отчётов, позволяющих понять, как развивается HTTPS: общая статистика, а также данные по алгоритмам и ключам. Данные собираются именно для HTTPS – то есть, это 443/tcp. Приведены результаты, начиная с июля прошлого года (2015). У меня на dxdt.ru есть некоторые данные по TLS/SSL в Рунете за 2011 год, это почти пять лет назад (да и методика сбора там другая). За это время, например, число самоподписанных сертификатов сократилось более чем в два раза: 52173 (тогда) против 23931 (сейчас). А ECDSA тогда просто не было.

Если посмотреть в выборку по корректным HTTPS-узлам (это узлы, вернувшие валидный сертификат, совпавший по имени), то видно, как стремительно растёт проникновение HTTPS: за семь месяцев в зоне .RU число HTTPS-узлов выросло почти, примерно, на 21 тыс. с 34205 до 55781. Из новинок: Let’s Encrypt – добавляет почти по тысяче в месяц, это видно в отчёте по Top 10 удостоверяющих центров.

Методика кратко описана на соответствующей странице statdom.ru.

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

Зловред Stuxnet, портивший иранские центрифуги на урановом производстве, был занесён в промышленную сеть на “флешке”. Реальность информационной безопасности на производствах, в типичных корпоративных сетях, такова, что если сеть вообще работает, то сейчас для проведения атаки не так уж и важно, подключена она к Интернету или нет. Главное, чтобы компьютеры были соединены между собой, а точка проникновения через наивный “воздушный зазор” (air gap) – найдётся. На практике, из-за человеческого фактора, отсутствие подключения к Интернету и массовое перемещение “флешек” – делают ситуацию хуже, потому что для атаки со стороны USB системы гораздо более уязвимы, чем для атаки из Интернета. (Интернет, кстати – всё равно всегда находится рядом, буквально в одном “хопе”: будь то смартфон или “нелегально” пронесённый 4G-модем, который подключен к компьютеру на рабочем месте. Поделать с этим ничего нельзя, так как отказываться от глобальной Сети, мягко говоря, невыгодно в стратегическом смысле.)

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

Кстати, что касается Windows XP, которая, якобы, “управляет британскими подводными лодками с ядерным оружием”: возможно, эта система и работает на каких-то компьютерах, находящихся на борту, но вряд ли чем-то на лодке управляет. Дело в том, что Windows XP – не является системой реального времени: с ней всегда были проблемы при попытках управления тем или иным оборудованием. Соответственно, встроенные системы используют другие ОС, обычно, это UNIX-подобные (из-за POSIX, но это детали) ОС реального времени.

Вообще, если речь идёт о системах из 90-х годов прошлого века (это означает, что разрабатывались-то они в конце 80-х), можно было бы поверить, что на борту есть управляющие вычислительные машины, работающие под MS-DOS. Это маловероятно, но такое можно представить, потому что под MS-DOS приложения реального времени работают хорошо, мне, в 90-х, приходилось такие видеть лично. Но XP – это что-то журналисты напутали (особенно, если учитывать, что система выпущена в 2001).

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

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

Основа практической работоспособности криптовалюты Биткоин – вычислительная мощность сети узлов-майнеров, которые вычисляют заголовки блоков. Если посмотреть на статистику по текущему распределению (предполагаемому) мощности сети на сайте blockchain.info, то нетрудно подсчитать, что около 60% этой мощности контролируют китайские пулы (AntPool, F2Pool и BTCC Pool). (Пулы – это объединения майнеров, действующих согласованно, и делящих полученную от майнинга биткоин-прибыль.)

Вообще, согласно протоколу, 60% мощности позволяют полностью контролировать сеть и, соответственно, саму валюту. Это довольно интересное положение дел. Пока, впрочем, каких-то активных контролирующих воздействий не заметно, ну, кроме странной ситуации вокруг увеличения размера блока (то есть, грубо говоря, увеличения числа транзакций, проводимых сетью в единицу времени).

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

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

Так как появились странные (невнятно сформулированные) слухи о недоступности DNS от Google из Рунета, я померил доступность при помощи сервиса RIPE Atlas – доступ есть, вот результат, на карте:

Измерение я проводил для 8.8.8.8, через 252 RIPE-зонда (probes), расположенных в Москве и ближайших регионах, в качестве запроса использовалось имя iana.org. Полученный адрес (верный) указан в легенде на картинке.

HPKP (HTTP Public Key Pinning) – технология, позволяющая привязать к серверу открытый ключ. Для этого служит специальное поле в заголовках HTTP. Я писал про HPKP на dxdt.ru ранее. Как и в случае практически любой технологии обеспечения информационной безопасности – интересно посмотреть, как реализация работает в деталях. Для этого я добавил HPKP на “тестовую площадку”: 1d.pw.

Напомню, кратко, как эта технология работает. При первом визите на сайт по HTTPS браузер запоминает отпечаток некоторого ключа, который передаётся в заголовке; это может быть отпечаток серверного ключа (так, например, сделано на dxdt.ru) или любого другого ключа, входящего в цепочку валидации сервера (можно добавлять ключи сертификатов удостоверяющих центров и так далее). При повторном соединении с сайтом по TLS браузер проверяет, что какой-то из ключей, предъявленных сервером, соответствует ранее записанному отпечатку. Если найти такой ключ не удалось, выдаётся сообщение об ошибке и соединение не устанавливается (именно этот вариант воспроизведён на тестовой площадке). Ситуация напоминает случай, когда браузер не смог провести успешную валидацию цепочки SSL-сертификатов, с той лишь разницей, что привязывание ключа позволяет защитить соединение от перехвата при помощи валидных сертификатов.

Отлаживать HPKP непросто. Запись отпечатка производится только в том случае, если браузер успешно установил соединение по TLS и получил ответ с корректно форматированным полем Public-Key-Pins – то есть, требуется работающий по TLS веб-сервер с валидным SSL-сертификатом. Для того, чтобы вызвать ошибку проверки отпечатка также требуется валидный сертификат: иначе браузер выдаст сообщение об ошибке раньше, чем доберётся до проверки отпечатков. При этом требуется серверный сертификат, выпущенный для другого ключа, отличающегося от “правильного”. Как-то узнавать браузер на сервере, чтобы имитировать подмену ключа, – не получится: проверка отпечатка происходит на самом раннем этапе установления TLS-соединения, ни куки-файлы, ни какие-то ещё данные “уровня приложения” к этому моменту переданы не будут. Идентифицировать по IP-адресу в наше время NAT-ов и прочих трансляторов – тоже неправильно.

Я поступил следующим образом. По адресу https://1d.pw/ откликается веб-сервер, который передаёт заголовок с отпечатком ключа и флагом, обозначающим, что отпечаток действителен для всех поддоменов (ниже я привожу поле Public-Key-Pins для 1d.pw полностью). А по адресу https://pin.1d.pw/ – откликается другой виртуальный хост, который использует другой серверный ключ (но в паре с валидным сертификатом). Если ваш браузер ещё не был на 1d.pw, то вы можете с его помощью успешно посетить pin.1d.pw. Однако если ваш браузер зайдёт на https://1d.pw/, то он запомнит отпечаток ключа. Если после этого попытаться открыть https://pin.1d.pw/, то должно появиться сообщение об ошибке (“невозможно установить защищённое соединение” или подобная формулировка) – это означает, что HPKP поддерживается браузером. Время жизни отпечатка указывается в поле Public-Key-Pins – для 1d.pw это 3600 секунд (или 1 час).

Вот заголовок HPKP:

Public-Key-Pins:pin-sha256=”afLVIYy6nD4LIkratYg295p89kYfqChllWQGYs7K8/A=”; pin-sha256=”K/QRriVzZo54i+9qeLPgP+22zWsL4rMZGFU9F0QJn/M=”; max-age=3600; includeSubdomains; report-uri=”http://hpkp-reporter.dxdt.ru/api/hpkp.pl”

Здесь есть ещё один интересный элемент – report-uri. Это адрес, по которому браузер передаёт сообщение о неудачной проверке отпечатка ключа (POST-запрос с данными в формате JSON). Я поднял отдельный обработчик для этих сообщений (планирую вынести его на другой домен и подключить, в том числе, к HKPK на dxdt.ru). Пока что данная функция работает только в Chrome, но это весьма распространённый браузер, поэтому, в теории, можно будет увидеть попытки перехвата TLS-соединений.

Посмотрим, как использование HPKP будет развиваться дальше.

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

During a recent internal code review, Juniper discovered unauthorized code in ScreenOS that could allow a knowledgeable attacker to gain administrative access to NetScreen® devices and to decrypt VPN connections.

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

В среду с доменом MIL (это зона для военных структур США) приключилась глобальная проблема: сломалась цепочка DNSSEC, так как опубликованная в корневой зоне DS-запись не соответствовала ключу KSK, опубликованному в зоне MIL. Это означает, что валидирующий резолвер должен выдавать ошибку валидации – и ресурсы, размещённые в зоне, для клиентов такого резолвера оказываются недоступны. Как минимум, нарушилась цепочка, ведущая к глобальному ключу IANA. Интересно, что мало кто проблему вообще заметил, а чинили более 12 часов (связано с кешированием и регламентом обновления зон). Возможно, конечно, что внутри пентагоновских сетей используется другой корневой ключ и другой набор DNS-записей для валидирования – соответственно, их резолверы продолжали работать. На мой взгляд, более вероятно, что DNSSEC там на рекурсивных резолверах просто не используют, как и практически во всём остальном мире.

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