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

DARPA заказывает новую программу POSYDON, результатом которой должно стать построение в океане опорной навигационной сети для подводных аппаратов. В качестве подрядчика выбрали Draper (это известная Лаборатория Чарльза Старка Дрейпера, вышедшая из Массачусетского технологического института).

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

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

Что касается подводной передачи навигационных сигналов, то, естественно, вряд ли будет использована радиосвязь, по понятным причинам. Акустический сигнал под водой может распространяться на достаточно большие расстояния. Так что, учитывая возможности по цифровой обработке и то, что для передачи навигационных данных не требуется большая информационная ёмкость, схема вполне реальна. Другое дело, что для противодействия могут быть использованы помехопостановщики.

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

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

Как сказано в статье, система представляет собой базовую станцию, которая принимает телефонные аппараты в зоне действия, расшифровывает данные и анализирует их. Подобные решения сейчас можно реализовать на базе открытого ПО и открытого аппаратного обеспечения. Например, годится пакет OpenBTS и подходящий модуль SDR (Software-Defined Radio). Проблему представляет прозрачность перехвата: для неё требуется участие “целевого” оператора связи. Но, вообще говоря, по причине отсутствия в GSM аутентификации сети в сторону абонентского устройства, возможны и варианты без участия оператора, однако они будут выглядеть топорно, а кроме того, у перехватываемого оператора должны возникнуть вопросы.

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

Систему можно установить только на территории компании, поэтому она никак не помогает в случае, когда сотрудник вышел поболтать в кафе. А если речь идёт о защите некоторого помещения или территории, то сложившаяся практика такова: устанавливается запрет на использование телефона, то есть, его либо нужно отключить, либо – вообще сдать на хранение при проходе КПП. Так или иначе, возможность использования связи GSM в защищаемом помещении блокируется. Это, действительно, предотвращает утечки.

Positive Technologies подтвердили известную вещь: при помощи перехвата SMS можно получить доступ к аккаунтам мессенджеров, даже тех, которые продвигаются как особенно защищённые. В ответ появляются статьи, где пишут, что сами мессенджеры всё равно защищённые, это виноват транспорт, канал связи (все показывают в сторону операторов). Например, подзаголовок статьи The Register гласит: WhatsApp, Telegram secure – but the transport isn’t (хотя цитаты в самой статье об этом не говорят).

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

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

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

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

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

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

Исследователи реализовали программу, которая распространяется между промышленными микроконтроллерами Siemens SIMATIC S7-1200 – есть публикация, описывающая принцип работы червя. Схема, отчасти, напоминает старые времена, когда небольшие вирусы распространялись между ПК, под управлением MS-DOS – правда, для появления действительно массовых вариантов потребовалось внедрение Windows, тогда появились решения, распространяющиеся без малейшего участия пользователя, просто передавая пакеты по сети. Собственно, описанный в статье червь для микроконтроллеров именно так и действует. А главная особенность в том, что для распространения не требуется ПК.

Предполагается, что микроконтроллер подключен к внутренней сети посредством Ethernet (такой порт имеется): программа сканирует IP-адресное пространство, пытаясь установить соединение TCP по известному номеру порта, который соответствует проприетарному протоколу Siemens. Если удалось установить соединение, то червь проверяет, не заражён ли уже найденный контроллер, а если нет, то копирует туда свой код. Для передачи кода используется протокол Siemens, предназначенный для управления контроллерами. Дело в том, что архитектура предполагает возможность удалённого обновления микропрограмм. В штатном режиме обновление проводит центральный управляющий узел, однако никакой аутентификации не предусмотрено (приходится признать, что это обычная ситуация), поэтому таким узлом может прикинуться всякий другой, в том числе, инфицированный червём микроконтроллер.

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

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

В общем, поле промышленных систем (АСУ ТП) – непаханое, и тут отлично подходят методы атак, которым 15-20 лет.

Очень смелое заявление для SpaceX – они собираются доставить тяжёлый аппарат на Марс не позднее 2018 года (ссылка на Washington Post, там, соответственно, вся статья построена на историческом противопоставлении космических достижений США и СССР). 2018 – слишком близко. Конечно, новые методы проектирования и имеющийся задел мог ли бы помочь, но пока что это выглядит нереальным сроком.

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

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

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

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

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

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

День Космонавтики. Традиционная ракета.

(А. Леонов, А. Соколов, «”Восток” направляется на старт».)

В бета-версии “Яндекс.Браузера” появилась поддержка DNSCrypt. Посмотрим, как она работает. Для активации – нужно включить опцию “Всегда использовать … DNSCrypt” в настройках браузера (опция, похоже, доступна только в версии под Windows). После этого браузер начинает использовать сервер “Яндекс.DNS”, с IP (в моём случае) 77.88.8.78, отправляя запросы DNSCrypt по UDP на номер порта 15353. Сессия DNSCrypt, согласно протоколу, начинается с отправки пакета, содержащего в открытом виде имя сервера и версию протокола: 2.dnscypt-cert.browser.yandex.net. Данный запрос необходим для получения сертификата сервера и генерации криптографического контекста, который далее будет использоваться клиентом и сервером для шифрования запросов/ответов. Вообще, протокол DNSCrypt не ставит задачи сокрытия самого факта использования DNSCrypt, поэтому может быть легко блокирован с использованием системы DPI. Трафик DNSCrypt “Яндекс.Браузера”:

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

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

Про перехват TLS я уже писал, например, применительно к HTTPS, а также касательно некоторых технических особенностей, обеспечивающих прозрачность перехвата TLS. Продолжим тему технических деталей. Пусть требуется пассивно читать трафик TLS, сервис-провайдер готов участвовать, но не имеет возможности предоставить внешний API для доступа к ключам, как быть? Есть известное решение, но оно требует некоторого бэкдора.

Идея состоит в том, чтобы значение ключа можно было восстановить из самого защищённого трафика. Напомню, что трафик TLS защищается при помощи симметричного шифра и сеансового ключа. В современных реализациях сеансовый ключ генерируется сторонами по протоколу Диффи-Хеллмана (классического или на эллиптических кривых), который и обеспечивает защиту сессии. Какие секретные параметры нужно знать, чтобы вычислить сеансовый ключ? Такой параметр лишь один – это экспонента Диффи-Хеллмана (DH), используемая сервером (или экспонента клиента). Действительно, если прослушивающая канал сторона знает экспоненту (являющуюся в протоколе Диффи-Хеллмана секретным ключом сервера), то она может вычислить общий сеансовый ключ так же, как это делает сервер или клиент. Осталось понять, как можно передать значение экспоненты, например, с сервера “в эфир”, чтобы не догадались те, кто канал не должен прослушивать. Для этого в TLS есть целый ряд способов. Самый простой – это поле ServerRandom, которое содержит случайное значение длиной в 32 байта (256 бит) и передаётся в открытом виде. В этом поле может быть передано состояние генератора псевдослучайных чисел, который используется для выбора значения секретного значения протокола Диффи-Хеллмана. Зная состояние генератора – третья сторона сможет определить это секретное значение.

Осталось придумать, как сохранить в секрете возможность прослушивания – чтобы расшифровать данные мог только тот, “кому следует”. Для этого оператору сервера передаётся открытый ключ (например, в качестве типового параметра настроек), который он использует для зашифрования состояния генератора, перед тем, как передать его в поле ServerRandom на всеобщее обозрение. Кстати, 256 бит – это слишком мало для RSA, но вполне достаточно для эллиптических кривых, поэтому в качестве механизма защиты может использоваться какая-нибудь разновидность криптосистемы Эль-Гамаля на эллиптических кривых. Считается, что именно этот способ предполагался на роль бэкдора в нашумевшем случае DUAL_EC_DRBG. Естественно, зашифрованный параметр в ServerRandom практически неотличим от случайного числа – чтобы что-то понять, нужно знать секретный ключ, который неизвестен даже серверу-источнику перехватываемого трафика. (Передача ключей в ServerRandom – не единственный способ.)

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

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

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

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

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

И, видимо, весьма интересную статистику может построить “Яндекс”, сопоставляя запросы DNS с данными “Яндекс.Метрики”, установленной на просматриваемых пользователем сайтах.