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

Вновь приходится слышать утверждения, что невозможно “вывести из строя комплекс ПВО” при помощи передачи в адрес его РЛС особого сигнала помехопостановщиком. Мотивировка примерно такая: “РЛС служит только для измерения расстояния до цели, воздействовать на комплекс через неё невозможно; вычислительные машины комплекса не подключены к Интернету, их тоже не достать”. В реальности, к сожалению, всё не так просто. Я уже писал на эту тему ранее, в этот раз добавлю пару детальных примеров.

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

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

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

Современные комплексы ПВО, оставаясь системами реального времени, имеют достаточно сложные и, в какой-то мере, гибкие программы управления. Но если речь идёт о старых советских комплексах, например о тех же классических “Буках”, то они работают по жёсткой и весьма простой временной диаграмме, что сильно упрощает получение атакующей стороной данных о том, в каком состоянии находится комплекс, что он будет делать в следующую миллисекунду.

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

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

(Кстати, записка по теме – активация аппаратных закладок.)

Опять повторяется история с перехватом управления доменом известного ресурса, с последующей сменой серверов имён и перенаправлением всего трафика на сайт атакующих. Вчера такая штука произошла с доменом The New York Times. Причём, из-за кеширования DNS, перенаправление происходило долгое время после того, как правильную адресацию в домене восстановили. Понятно, что атака позволила перехватить и электронную почту, работающую в домене. А это, в свою очередь, первый шаг к перехвату аккаунтов в разных других сервисах, при помощи “напоминалок паролей”.

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

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

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

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

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

Сейчас проходит очередная массовая атака на сайты, работающие под CMS WordPress. В этот раз она сводится к POST-запросам по адресу /wp-login.php. Видимо, это следы попытки подбора паролей. Отличие этой атаки в том, что запросы приходят с очень большого числа IP-адресов, что несколько затрудняет блокирование. Похоже, атака касается только сайтов в домене .ru (но тут нет уверенности). Поток запросов велик, кто-то активировал ботнет: например, на одном из сайтов я сейчас вижу около 20 POST-запросов в секунду.

Кстати, прошлая массовая атака была устроена несколько хитрее.

В связи с ростом интереса к перехвату “всего и вся” структурами NSA, часто стали упоминать HTTPS. Думаю, полезным будет некоторый небольшой популярный обзор HTTPS, как раз с точки зрения его прослушивания. Ниже, кроме HTTPS, фигурируют такие связанные понятия, как TLS/SSL, SSL-сертификат.

Итак, ряд базовых моментов.

1. HTTPS – это HTTP, работающий по “защищённому каналу”. Технологии, служащие для создания такого канала для HTTPS, называются TLS (SSL). TLS используется не только HTTPS. Обычно предполагается, что трафик, передаваемый по упомянутому каналу, может быть доступен третьей стороне, которая, однако, не должна иметь возможность раскрыть сами передаваемые данные (“защита от прослушивания”, реализуется шифрованием; заметьте, впрочем, что HTTPS можно устроить без шифрования, но это будет являться ошибкой).

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

3. SSL-сертификаты не связаны с собственно шифрованием данных HTTPS, но они позволяют создать зашифрованный канал. Однако такой канал может быть создан и без использования сертификата. Функция SSL-сертификата, применительно к HTTPS, состоит лишь в удостоверении связки некоторого имени ресурса и некоторого открытого ключа. В качестве имени ресурса обычно выступает доменное имя (пример: dxdt.ru). То есть, при помощи серверного SSL-сертификата, клиент (обычно – браузер) может удостовериться, что соединяется именно с обладателем секретного ключа из пары, открытая часть которой указана в сертификате. Этот процесс часто называют аутентификацией сервера. Если специально задаться целью, то несложно реализовать TLS-соединение с проверкой SSL-сертификата, но вообще без шифрования.

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

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

6. Для большого класса добротных, стойких криптосистем, широко используемых сейчас в TLS на практике, возможно восстановление сеансового ключа из записанного трафика, при условии, что атакующая сторона имеет в своём распоряжении секретный серверный ключ (это ключ из той пары, открытая часть которой указывается в сертификате сервера). Это означает, что однажды получив секретный ключ сервера (не сеансовый!), кто-то может расшифровать накопленные ранее записи HTTPS-сеансов между клиентом и сервером. Упомянутый ключ может быть раскрыт разными способами: например, его можно скопировать с сервера, если есть доступ, или он может просто оказаться нестойким (такое случается не так редко, как можно подумать).

7. Если генерация секретного сеансового ключа проводится по алгоритму Диффи-Хеллмана, то наличие серверного секретного ключа никак не помогает восстановить его из записанного трафика. Однако на практике далеко не все TLS-серверы используют соответствующие алгоритмы.

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

9. Возможность выпустить SSL-сертификат для атакуемого домена никак не помогает расшифровать HTTPS-трафик, идущий в этот домен, даже если трафик записывается. Это так потому, что SSL-сертификат не содержит секретного серверного ключа (и, очевидно, сеансовых ключей). Более того, процедура выпуска сертификата не требует передачи секретного ключа в удостоверяющий центр (передаётся только открытый ключ), поэтому у удостоверяющего центра секретного ключа нет.

10. Тем не менее, валидный SSL-сертификат, выпущенный для атакуемого домена, позволяет провести незаметную для пользователя атаку типа “человек посередине”. Для этого требуется, чтобы между атакуемым пользователем и сервером существовал управляемый атакующим узел, активно перехватывающий трафик. Этот узел выдаёт себя пользователю за легитимный сервер, предъявляя тот самый валидный сертификат. Пассивное прослушивание канала не позволяет раскрыть HTTPS-трафик подобным образом – наличие сертификата или секретных ключей УЦ никак тут не помогает.

11. Перехват HTTPS-соединения может быть автоматизирован – существуют специальные узлы-прокси (SSL-прокси), которые выполняют такой перехват на лету, в том числе, генерируя нужные сертификаты. В такой прокси должен быть загружен сертификат и секретный ключ, позволяющие подписывать другие сертификаты (например, годится так называемый промежуточный сертификат УЦ, выпущенный для этих целей).

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

13. “Человек посередине” не работает для HTTPS при наличии некоторых дополнительных мер: например, установление TLS-соединения требует взаимной аутентификации, и перехватывающему узлу недоступен клиентский секретный ключ (либо ключи УЦ, удостоверяющего клиентский ключ); или – пользовательский браузер ведёт реестр отпечатков открытых ключей сервера, которым он доверяет; или – пользователь применяет дополнительные источники сведений о разрешённых ключах и сертификатах, которые недоступны для подмены на перехватывающем узле (таким источником может служить DNS, либо другая база данных).

14. Все (хорошо – подавляющее большинство) сколь-нибудь массовые сервисы используют так называемый SSL termination: то есть, пользовательский HTTPS-трафик в зашифрованном виде доходит только до пограничного прокси, где благополучно транслируется в HTTP, который дальше ходит по внутренним (в логическом, а не техническом смысле) сетям сервиса в открытом виде. Это стандартная практика, так как тотальный HTTPS, с ростом числа клиентов, быстро превращается в неподъёмную, плохо масштабируемую технологию. Если система инспекции трафика находится внутри сетей сервиса, за таким пограничным SSL-прокси, то никакой HTTPS ей не мешает. Внутренний трафик распределённых сервисов с легкостью ходит между узлами и дата-центрами по арендованным у крупных операторов каналам связи в открытом виде, такой трафик может прослушиваться, хотя для пользователя он выглядит как HTTPS-соединение.

15. Если на компьютере пользователя присутствует троянская программа, имеющая доступ к браузеру, то HTTPS также оказывается бесполезным, так как данные могут копироваться вовне до того, как попадут в зашифрованный канал.

Вот.

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

Бороться с таким положением дел можно, кроме прочего, с помощью построения дополнительной открытой системы аудита сертификатов, назависимой от УЦ и доступной для использования каждому, кто заинтересован в дополнительной проверке полученных с сервера сертификатов. При поддержке Google развивается как раз такая система: Certificate Transparency (CT). Основные задачи, которые могут быть решены при помощи CT: затруднить выпуск SSL-сертификатов для домена, невидимый администратору этого домена; позволить администратору домена узнать, какие сертификаты для его домена были выпущены; оградить клиентское программное обеспечение от доверенного использования неправомерно выпущенных сертификатов. Решается всё при помощи ведения лога, содержащего описания сертификатов. Подробности есть на сайте.

Mozilla опубликовала новую политику управления корневыми сертификатами, входящими в дистрибутив браузера. В новой версии включили пункт, ставший реакцией на скандалы с удостоверяющими центрами (пункт 3 в разделе Enforcement Policy). Речь там о потенциальном исключении корневого сертификата УЦ из браузерного списка доверенных, если станет известно, что удостоверяющий центр выпустил сертификат для того или иного домена не убедившись, что получатель сертификата действительно этим доменом управляет.

Опубликованный текст политики, в итоге, содержит ссылку на требования CA/Browser Forum (CAB-форум – это сообщество, в рамках которого производители браузеров взаимодействуют с УЦ), а не прямое упоминание процедур проверки контроля над доменом. Но, в принципе, требования CAB-форума как раз и состоят в необходимости проведения такой проверки. Так что, по крайней мере формально, удостоверяющий центр, содействующий выпуску SSL-сертификатов для “чужих доменов”, рискует вылететь из списка доверенных. (Напомню, что упомянутые сертификаты служат для перехвата HTTPS-трафика, адресованного любому домену, в прозрачном для пользователя режиме.)

В качестве попутного результата исследования связки TLS и DNSSEC сделал под адресом 1d.pw (краткий домен, кстати) веб-сервер, поддерживающий TLS/SSL (с сертификатом, выпущенным “хорошо известным УЦ”, а также с современными серверными штуками вроде TLS 1.2, OCSP stapling и Strict Transport Security). Домен, естественно, подписан DNSSEC и содержит запись DANE, указывающую на используемый сертификат. В отличие от dane.nox.su – здесь SSL-сертификат не самоподписанный.

Роскомнадзор утвердил “Рекомендации по ограничению операторами связи доступа к сайтам в сети Интернет с запрещенной информацией”. Сами рекомендации тоже опубликованы на сайте (формат Word .DOC – хотя, конечно, хотелось бы видеть RTF, ну да ладно). Кратко: блокировать рекомендовано не по IP, а по URL, только “на сетях доступа”, то есть, за исключением транзитного трафика. Выделение URL должна проводить система DPI. Собственно, вариант весьма разумный, и, да, это те рекомендации, которые публиковались раньше. Теперь посмотрим, как их будут внедрять.

(А VPN, HTTPS и прочие штуки – давайте оставим за скобками.)

Намечается очередная новинка в области безопасности систем GSM. На этот раз речь об удалённом внедрении программного кода в SIM-карту телефона. Краткая суть: современные SIM-карты могут содержать специальные JAVA-приложения, реализующие ту или иную дополнительную функцию телефона. Обновления этих приложений производятся при помощи отправки специальных SMS, которые должны проходить проверку достоверности.

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

Наверное, самое неправильное применение авторизации, работающей только по биометрическим данным, это автоматическая платёжная система. Тем не менее, поток объявлений о подобных устройствах не затихает. Вот, скажем, сайт “Компьютерры” сообщает:

Недавно финская компания Uniqul объявила о запуске платежной системы на основе распознавания лиц клиентов. Для того чтобы расплатиться за покупку или услугу с помощью нового терминала, не потребуется ни документов, ни кредитных карт: достаточно будет улыбнуться в камеру.

Замечательно. Там, впрочем, упоминается пин-код, что минимально улучшает ситуацию. В чём проблема с подобным автоматическим использованием биометрии? В том, что биометрические данные нельзя ни изменить, ни отозвать, и их очень сложно скрыть. Лицо клиента сфотографировать намного проще, чем обратную сторону его пластиковой карты. И, в отличие от карты, “заблокировать” или изменить лицо весьма непросто (это если вообще допускать возможность такой блокировки/изменения). Речь, конечно, о лице добропорядочного пользователя системы, чьи биометрические данные были скомпрометированы.

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

Я, кстати, писал об этом почти семь лет назад.