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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описанная Пракашем атака основывается на используемом в Facebook механизме смены пароля. Желая изменить его, пользователь должен сообщить администрации свое имя, имя учетной записи, а также адрес электронной почты и номер телефона. На этот номер высылается 6-значный цифровой код, ввод которого и позволяет сменить пароль.

Нетрудно догадаться, что этот 6-значный код был подвержен простому перебору: попытки подбора блокировались только в основной системе авторизации, а тестовые площадки – позволяли проверять коды без ограничений. Сам по себе замечателен тот факт, что программная система Facebook не разделяла должны образом базы авторизации пользователей между тестовым и рабочим окружением, но вполне разделяла сами системы авторизации, урезая защиту (при тех же паролях; да, понятно, что пароли там вряд ли можно разделить, но это не означает, что нужно отказаться от части средств их защиты).

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

Автомобиль-робот Google недавно снова попал в ДТП, понадеявшись, как пишут, на то, что ему уступит дорогу автобус, управляемый человеком (ага, не тут-то было!). Считается, что если на дороге остались только автомобили-роботы, то количество ДТП резко снизится. Например, в случае с автобусом, который не уступил полосу попавшему в затруднительное положение автомобилю, роботы смогли бы быстро и, что особенно важно, однозначно, договориться, обменявшись сигналами. Хорошо известны протоколы, которые позволят роботам уступать друг другу даже в том случае, когда правила дорожного движения этого прямо не предписывают.

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

ICANN опубликовала документ (PDF), описывающий план по замене действующего корневого ключа KSK глобальной DNS на новый (ротацию KSK). Корневой KSK – это ключ, удостоверяющий данные в корневой зоне (он используется не напрямую, а через ZSK – ключ подписи зоны, но это детали). DNSSEC запустили в корне DNS в 2010 году без утверждения процедуры ротации главного ключа. Сейчас такая процедура появилась.

В кратком изложении план выглядит так: в апреле этого, 2016, года запустят процесс генерации нового KSK; в январе следующего (2017) года этот новый KSK должен быть опубликован в корневой зоне, при публикации он будет подписан действующим KSK; в апреле 2017 года новый KSK заменит старый при подписи ZSK, а спустя несколько месяцев – старый KSK будет отозван и, следующим шагом, удалён из DNS. Кроме того, в январе 2017 новый KSK должен быть опубликован другими способами, не в DNS.

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

Сейчас для корневого KSK используется RSA-2048. Замены алгоритма или длины ключа при первой ротации не запланировано (одна из основных претензий к DNSSEC – криптосистема RSA и малая длина ключа).

Шумная история: Apple отказывается помочь ФБР подобрать пароль разблокировки для конкретного аппарата iPhone. В предписании судьи сказано, что требуется как-то модифицировать программную (а возможно – аппаратную, но упор сделан на программную) часть конкретного устройства, чтобы можно было простым перебором раскрыть пароль (вероятно, речь об обычном цифровом пароле, который пользователи устанавливают на аппарат). В штатной конфигурации iPhone может удалить пользовательские данные (точнее: удалить ключ и сделать остальные данные недоступными) после нескольких неверных попыток ввода пароля.

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

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

В рамках проекта КЦ и ТЦИ “Домены Россиии” (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” обнаружили тысячу уязвимостей, скорее всего никак не повлияло на наличие или отсутствие уязвимостей в другой, не менее распространённой, операционной системе, в которой уязвимостей нашли пока что только сотню. (Хотя, в последнем случае можно предположить, что разработчики второй системы чему-то научились на опыте авторов первой, да и залатали дыры заранее; но, к сожалению, практика показывает, что это скорее фантастика, чем реальность.)