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

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

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

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

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

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

Заразить автомобильный компьютер зловредной программой сложно. Внедрить “троянца” в смартфон владельца – задача несколько проще. Забавный сюжет из ИТ-новостей ближайшего будущего: новый зловред, распространяющийся под ОС смартфонов, нацелен на владельцев автомобилей Land Rover – при приближении владельца к автомобилю, зловред перехватывает управление и заставляет машину пятиться подальше от хозяина.

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

В доменной зоне .RU среди самых популярных названий УЦ, выдавшего серверный SSL-сертификат, неожиданно лидирует COMODO ECC Domain Validation Secure Server CA 2. Лидерство – по числу уникальных серверных сертификатов, которых, под доменами .RU, обнаруживается более 7 тыс.

Этим именем (COMODO ECC…) обозначается промежуточный SSL-сертификат, ключи от которого используются для подписывания клиентских, серверных сертификатов. Главная особенность сертификата в том, что он использует механизм электронной подписи ECDSA – на эллиптических кривых (то есть, используется не самая распространённая криптосистема RSA, а другая, как считается, более прогрессивная в плане длины ключей и используемых примитивов). Сертификат с криптографией на эллиптических кривых позволяет использовать эту криптографию и на сервере. Если у вас сертификат с подписью RSA, то сервер также должен использовать только RSA для генерации подписи, иначе браузеры не смогут корректно установить соединение.

Занятно, что виновником прогресса эллиптической криптографии в Рунете оказался сервис CloudFlare – именно он поддерживает большинство из тех сайтов, серверы которых отдают “эллиптические” сертификаты. Соответствующий промежуточный сертификат УЦ в CloudFlare используют для автоматической генерации на лету нужных валидных (признаваемых браузерами) сертификатов для клиентов. Так как CloudFlare на одних и тех же узлах обслуживает большое количество разных сайтов, необходимо использовать технологию SNI, чтобы определить сайт, к которому происходит обращение. А чтобы браузер не выдавал предупреждение – в составе сертификатов присутствуют все имена, которые поддерживает данный сервер: они перечислены в поле расширений SAN (Subject Alternative Name).

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

В работе исследователей, которые обнаружили уязвимость TLS Logjam, обсуждается возможность вычисления системами АНБ дискретного логарифма в некоторых группах, используемых в различных реализациях алгоритма Диффи-Хеллмана. (Задача дискретного логарифмирования, для правильно выбранных параметров, является вычислительно трудной, на этой трудности и основана практическая полезность протокола Диффи-Хеллмана.) Например, в решениях VPN, использующих IPsec (а это распространённая практика), для генерации общего ключа служат группы, заданные в рекомендациях (RFC). То есть, параметры известны заранее, это позволяет сильно ускорить процесс вычисления логарифма, выполнив предварительные вычисления.

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

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

Занятно, что в Microsoft уже некоторое время используют неподходящий SSL-сертификат для windows.microsoft.com: предъявляемый сервером сертификат выпущен для *.windows.microsoft.com, а это имя, естественно, не подходит, так как работает только для четвёртого уровня. Такая вот неразбериха.

В свете недавно выявленной уязвимости TLS – Logjam возник интерес к отличиям различных версий и реализаций алгоритма Диффи-Хеллмана. Вообще, современное состояние дел с криптографией в Интернете таково, что вместо небольшого набора простых и понятных протоколов, используется огромная куча спецификаций, в которых, по историческим причинам, наворочено много разных тонкостей. Одна из таких тонкостей – отличие шифронаборов, содержащих в своём обозначении DH, от шифронаборов с DHE (добавлен суффикс E).

DH – обозначает Диффи-Хеллмана. E – Ephemeral (почему-то сейчас в переводе используют “эфемерный”, хотя лучше подошло бы “краткосрочный” или “единовременный”). Обычно пишут, что вариант DH – не обладает прогрессивной секретностью (то есть, записанный ранее трафик можно раскрыть через какое-то время, если удалось получить секретный ключ сервера), а DHE – обладает. В чём же различия?

Вспомним, что алгоритм Диффи-Хеллмана использует следующие общие параметры: P – модуль (большое простое число, задающее группу, в которой производятся вычисления – (mod P), дальше это обозначение опускаю); G – “генератор” (число, элемент выбранной группы). Это публичные параметры. Условный “открытый ключ” сервера образуется при помощи вычисления A = G^a, где a – секретная часть ключа (экспонента). Клиент выбирает своё значение b, вычисляет B = G^b и передаёт на сервер. Для получения общего секрета сервер и клиент вычисляют, соответственно, s = B^a = (G^b)^a = G^(ba) и s = A^b = (G^a)^b = G^(ab). Обратите внимание на параметры со стороны сервера: P,G,A.

В случае реализации DH предполагается, что параметры сервера (P,G,A) – заранее подписаны неким внешним ключом, что позволяет клиенту проверить их подлинность. Это означает, что параметры фиксированы от сессии к сессии, а сервер может использовать только одну экспоненту (a), которая соответствует G^a = A. Самое важное, что фиксируется именно экспонента a – сервер должен её сохранять в долговременной памяти, так как она связана с открытой частью ключа A. Есть старые рекомендации, предписывающие включать параметры DH в состав сертификата. Впрочем, на практике такие вещи не встречаются. Понятно, что если секретные ключи сервера, а именно – значение a, оказались раскрыты, то они позволят вычислить сеансовые ключи (s) для всех записанных сессий, так как теперь аналитику известна величина a и он может определить s = B^a = G^(ab) (значение B – сохранено в записи трафика, так как его в открытом виде передаёт клиент). Очевидно, что точно так же можно раскрыть трафик, если аналитику известен секретный параметр на стороне клиента (b) – например, этот параметр утёк из браузера.

Итак, основная особенность: в случае DH – заранее предполагается, что секретный параметр алгоритма Диффи-Хеллмана сохранён на диске и может быть доступен третьим лицам. Дело в том, что само по себе использование одинакового параметра для разных сессий никак не гарантирует его раскрытия.

В случае DHE – как минимум a и G^a = A – генерируются сервером заново для каждой сессии, и, как считается, значения не сохраняются на долгое время. А для того, чтобы клиент мог провести аутентификацию параметров, они подписываются ключом сервера (тот же ключ используется в SSL-сертификате). Это нормальный современный вариант использования алгоритма Диффи-Хеллмана в TLS.

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

Чтобы не пропадал домен pwd4.me и выпущенный для него SSL-сертификат – сделал там одностраничный генератор паролей (который, хоть и использует Web Crypto API, – а поэтому работает только в современных браузерах, – но может быть признан лишь “учебным”). Кстати, HTTPS в подобных сервисах необходим, чтобы обезопасить пользователей от инъекции Javascript-кода.

(Update: 11/05/2026 – сервис более не доступен.)

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

1) атакующий должен иметь возможность активно перехватывать TLS-соединение. То есть, между клиентом и сервером должен находиться активный перехватывающий узел, не просто умеющий делать DPI, но работающий с весьма сложной логикой: нужно находить в TCP-трафике сообщения TLS, декодировать их, “завешивать” сессии, подменять информацию в пакетах;

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

3) атакуемый TLS-сервер должен поддерживать заведомо устаревшие “экспортные параметры” алгоритма Диффи-Хеллмана.

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

Что, конечно, не отменяет пользы от привлечения внимания к дефекту протокола. Есть шанс, что в TLS 1.3 что-то поправят (вероятно, добавив новых дефектов, так как в сторону упрощения спецификация пока что идёт с большим трудом).

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

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

В Wired.com статья, рассказывающая о том, как Крис Робертс (Chris Roberts) попытался вмешаться в управление авиалайнером, находившимся в воздухе, с борта этого лайнера, и теперь агенты ФБР изъяли у Робертса компьютерное оборудование, которое собираются “обыскать”.

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

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

В общем, таки не зря запрещали раньше пользоваться компьютерной техникой на борту, не зря. Просто, теперь забыли о реальных причинах, стоявших за вводом столь “абсурдного требования”.

Подобные истории приходилось слышать не раз, но вот встретилась запись выступления журналиста NBC (Matthew Cole, англ.) на конференции Black Hat USA 2013, где он рассказывает о том, как итальянские правоохранительные органы раскрыли группу агентов ЦРУ, используя данные об их звонках в местной сети GSM.

События происходили в 2003 году. То есть, агенты не только использовали обычные мобильные телефоны для связи внутри группы, да ещё и обменивались ими, но и засветили разные SIM-карты, в том числе ту, которая была зарегистрирована на местную резидентуру ЦРУ (не прямо, конечно, но под очевидным прикрытием “консульства”). Данные из логов контроллеров GSM о том, кто, когда, откуда и кому звонил, позволили итальянским следователям вычислить участников группы, потому что они данные о звонках образовывали структуру, говорившую саму за себя. Первую ниточку нашли просто взяв список телефонов, выходивших на связь неподалёку от места проведения операции (похищение человека), в условленное время.

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

(Ссылка найдена в блоге Шнайера.)