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

Исследователи реализовали программу, которая распространяется между промышленными микроконтроллерами 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 с данными “Яндекс.Метрики”, установленной на просматриваемых пользователем сайтах.

ФБР отзывает предписание, требовавшее от Apple содействия во взломе аппарата iPhone: бюро утверждает, что с задачей справились без помощи Apple и данные из телефона получены. Конечно, интересно, как именно. Предполагается, что работу выполнил подрядчик, некая специализированная компания, нанятая ФБР – это обычная практика.

В качестве метода вполне мог сгодиться и программный подход: например, предположим, что программный код Apple некорректно проверяет подписи на полученных обновлениях или не контролирует целостность исполняемого кода. Если взглянуть на список уязвимостей iOS, то такое положение дел совсем не кажется невероятным (вспомните про знаменитый код Goto Fail). Взламывающий код можно внести в систему аппарата снаружи через сетевое соединение, либо подключившись напрямую к тому или иному контроллеру внутри (вариантов, на самом деле, немало: модуль GSM, датчики, дисплей и так далее). Естественно, нельзя исключать наиболее занимательный и высокотехнологичный вариант: аппаратное копирование криптомодуля (а в данном аппарате, как я понимаю, лишь физического блока памяти) с сохранением внутреннего состояния. Это можно проделать теоретически, но задача чрезвычайно сложна – на уровне отдельного научного проекта целой лаборатории из области прикладной физики. Так что, скорее всего, реальность – банальна: либо программная уязвимость, позволяющая обновить фрагмент прошивки, либо кто-то просто поделился ключами.

(Разумеется, на следующем маркетинговом шаге Apple начнёт шумно добиваться раскрытия подробностей взлома, чтобы “защитить приватность пользователей”.)

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

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

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

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

Атаки улучшаются, оборудование усложняется. Скоро мы увидим немало нового в этой, вполне практической, области.

Лирическое отступление.

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

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

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

– Никогда не доверяй пылесосам, – пробормотал Винсент, – особенно, если это пылесос-инсайдер.

Это я к тому, что у меня давно есть аккаунт в Facebook.com (требуется регистрация), где я иногда публикую разные наблюдения и записки, которые не совсем подходят для dxdt.ru. Фрагмент, приведённый выше, как раз оттуда. Основная часть моих записей там открыта, в режиме Friends only я пишу только совсем уж специальные сообщения (хотя, уровень доступа Public, в данном случае означает, что для просмотра всё равно необходим аккаунт в Facebook), поэтому – подписывайтесь, если это вам интересно.

Обновил список избранных записок.