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

Ещё немного о навигации: из NASA сообщают, что успешно на практике использовали рентгеновские пульсары для определения положения аппарата в космическом пространстве. В качестве приёмника сигналов послужила рентгеновская обсерватория NICER, установленная на борту Международной космической станции, а сам эксперимент называется SEXTANT (Station Explorer for X-ray Timing and Navigation Technology).

Логика работы данного прототипа навигационной системы такая же, как описана в научной фантастике: периодические сигналы пульсаров обладают высокой стабильностью, соответственно, если их правильно подобрать, то можно вычислять положение приёмника. Что и продемонстрировали для МКС – отклонение (радиус) получилось лучше 10 миль, для космической навигации вполне достаточно (обещают улучшить).

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

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

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

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

Google намеревается в браузере Chrome резко ограничить доверие SSL-сертификатам, выпущенным удостоверяющим центром Symantec. Это касается и других брендов Symantec: GeoTrust и Thawte, главным образом, а также прочих “партнёрских” линеек. Речь идёт о принудительном снижении допустимого срока валидности (не более девяти месяцев – коммерческие сертификаты обычно выпускаются на год и более, это одна из их важных особенностей) и отключении EV-статуса (“расширенная проверка”, самые дорогие сертификаты). Это реакция на выявленные нарушения политик и требований к работе УЦ.

Исследователи из Google и института CWI продемонстрировали первую практическую коллизию для криптографической хеш-функции SHA-1. SHA-1 уже несколько лет считается недостаточно стойкой, но, тем не менее, до сих пор широко используется (в том числе, в SSL-сертификатах, несмотря на все ограничения). На специальном сайте shattered.it можно скачать два файла PDF, которые отличаются содержанием, но имеют одинаковое значение SHA-1 (каждый может проверить самостоятельно). Несмотря на сложность реализации этой конкретной атаки, которая потребовала больших вычислительных мощностей (они нашлись у Google), SHA-1 теперь можно окончательно признать нестойкой. Это весьма важное достижение – казалось, что SHA-1 простоит ещё пару лет.

Вместо SHA-1 следует использовать, например, хеш-функции семейства SHA-2: SHA-256 и др.

Что касается обсуждений про китайские МБР, которые, якобы, размещаются вблизи от границы с Россией. На начальном этапе полёта баллистическая ракета очень уязвима. Кроме того, чем ближе к границе, тем ближе можно разместить средства превентивного уничтожения ракетных комплексов (ещё до запуска), да и наблюдать их перемещения, подготовку к пуску – тоже проще.

Очередной раз попались выпущенные Symantec TLS-сертификаты для доменов, администраторы которых эти сертификаты не запрашивали (*.example.com, test.com и пр.) Как уточняет Symantec – сертификаты выпустила одна из компаний-партнёров, и это были тестовые сертификаты. То, что они тестовые – вполне очевидно из состава полей, но при этом сертификаты валидные. Сертификаты были выпущены в 2015 и 2016 годах, сейчас те, что обнаружились, отозваны.

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

Известная история гласит, что Интернет создавался для обеспечения связи в ситуации, когда большая часть сетей разрушена, выведена из строя (это только одна часть истории, но сейчас речь о другом). У DARPA есть программа TUNA (Tactical Undersea Network Architecture), цель которой – получение средств, позволяющих быстро наладить связь на больших расстояниях в море, при условии, что имеющиеся сети разрушены. Концепция подразумевает налаживание радиосвязи, но с использованием оптических линий между опорными узлами. То есть, в море выпускаются буи (например, сбрасываются с самолёта), между которыми под водой протягивается плавучая (это важно – кабель не опускается на дно) оптоволоконная линия, которая, как пишут, должна проработать до 30 дней. В новости по ссылке выше упоминают разработку лаборатории Вашингтонского университета – буй, который вырабатывает электричество, используя энергию морских волн.

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

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

Избранный Президент США, оказывается, предложил заменить F-35 на “сравнимые” F/A-18 Super Hornet. Ссылка на Twitter (похоже, это теперь официальный инструмент информирования):

Based on the tremendous cost and cost overruns of the Lockheed Martin F-35, I have asked Boeing to price-out a comparable F-18 Super Hornet!
(На основании громадных затрат и перерасхода средств на Lockheed Martin F-35, я запросил у Boeing расценки на сравнимый F-18 Super Hornet!)

Занимательное развитие супердорогой программы F-35. При этом принципиальных проблем с тем, чтобы установить на F-18 бортовое оборудование, сравнимое по характеристикам с F-35, нет. Самолёт, в качестве платформы, позволяет. Естественно, подобный проект обновления уже есть – он называется Advanced Super Hornet. В него, помимо общего уменьшения радиолокационной заметности, входит даже закрытый подвесной “отсек” для вооружения, который предлагалось размещать вдоль фюзеляжа. (Решение, конечно, несколько странное.) Однако более дешёвая платформа может нести больше ракет “за те же деньги”. При этом два самолёта, вообще говоря, оказываются более гибким решением, чем один, пусть и существенно менее заметный в некоторых конфигурациях, зато капризный и требующий немалых затрат на повседневное обслуживание.

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

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

О том, что найти секреты DH в произвольной короткой, 1024-битной группе, можно, если у вас есть достаточно мощный, но доступный на уровне современных технологий, компьютер и вы предвычислили нужную “арифметическую структуру” группы, известно довольно давно. Сейчас решение продемонстрировали на практике, подтвердив, что если правильно выбрать модуль, то объём вычислений ещё сокращается на несколько порядков.

Для того, чтобы атака сработала, требуются типовые группы. В более строгом случае, с подготовленным модулем, используемую группу нужно прямо задать. (Более мягкий вариант – работает с любой заранее известной 1024-битной группой, но для каждой потребуется большой объём предварительных вычислений и большой объём памяти для хранения результатов.)

Самое занимательное, что с типовыми группами проблем как раз нет. Например, в Рунете (.RU, .РФ) около 280 тыс. имён аресует узлы, поддерживающие HTTPS/TLS и классический вариант DH, которые используют всего две различных группы с разрядностью 1024 бита. Одна – это группа по умолчанию из mod_ssl, а вторая, насколько я понимаю, из настроек по умолчанию модуля SSL в nginx. Обе группы, очевидно, потенциально уязвимы. (Пояснение, 12/10/16: я скорректировал текст – изначально было написано, что 280 тыс. серверов, но речь идёт о числе доменов – имён TLS-хостов.)

Про то, что генерация общего секрета по протоколу Диффи-Хеллмана вовсе не является эквивалентом симметричных ключей, которые “есть только на узлах”, я не раз писал ранее. Например – в записке про извлечение секрета DH из трафика.

1.

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

2.

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

3.

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

4.

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

5.

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

6.

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

7.

Инфраструктура сертификатов и УЦ в современном Интернете развивается. Как раз в сторону повышения прозрачности. Соответственно, внедрение MitM будет быстро обнаружено. Для того, чтобы подтвердить факт MitM, тот или иной пользователь может просто опубликовать (отправить, скажем, в Google или в, условный, Facebook) подменный сертификат. Этот сертификат пользователю легко извлечь – в браузере, например, для этого есть функция экспорта. Подделать такой сертификат не выйдет (ну, если бы некий пользователь решил дезинформировать Google), потому что он обязательно содержит электронную подпись, которую можно проверить.

(Про перехват HTTPS я подробно писал в другой заметке.)