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

Спустя примерно месяц, я вновь собрал SSL-сертификаты с серверов, на которые указывают домены .ru. Методика описана в прошлой записке по этой теме. Кратко повторю основные моменты: на первом этапе делается попытка определить адрес сервера (A-запись) для каждого из делегированных доменов (учитывая www.) в зоне .ru; из найденных серверов с уникальными IP выбираются те, у которых открыт 443-й порт (https); на заключительном этапе каждый из отобранных серверов опрашиваются на предмет SSL-сертификатов путём открытия https-сессии; собранные сертификаты разбираются при помощи OpenSSL.

В результатах “много цифр”, поэтому прячу под “Читать полностью”.

Читать полностью

Очень удобно, когда имя сети Wi-Fi (SSID) говорит само за себя, то есть, содержит прямое указание на “административную” принадлежность: avtosalon-gorod, bank-takoyto, cafe-apelsin. У удобства есть обратная сторона: всякие современные мобильные устройства, поддерживающие Wi-Fi, пытаясь найти знакомую точку доступа, передают в эфир имена сетей, к которым они раньше подключались.

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

(Кроме того, список известных устройству сетей, очевидно, годится для того, чтобы это устройство заманить в специально подготовленную сеть.)

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

К сожалению, в домене ru DNSSEC появится неизвестно когда, но точно нескоро. Другой российский (по факту) домен – su, – хоть и заявлен недавно на конференции ICANN как поддерживающий DNSSEC, на практике, насколько я смог выяснить, не позволяет воспользоваться защитными механизмами. Записи об su в корне DNS подписаны, но в самой этой зоне мне не удалось найти ни одного подписанного домена второго уровня. Более того, не подписан даже домен администратора SU – fid.su. Для рядового же пользователя проблема в том, что, на практике, отсутствует механизм “привязки” подписанной зоны второго уровня к ключам домена SU.

(Addon (17/11/11): как пишут из ТЦИ, реестр SU поддерживает работу с DNSSEC, но регистраторы пока не реализовали свою часть. Ждём.)

Вообще, подписать саму зону можно не прибегая к услугам администратора домена верхнего уровня (см., например, nox.su, который я подписал в порядке эксперимента – сами записи в зоне подписаны, но цепочка рвётся в .su, разместить там нужные данные сейчас не представляется возможным). “Привязка” доменов к единой цепочке выполняется с помощью специальных DS-записей (Delegation signer), вносимых в зону, уровнем выше удостоверяемой, для построения иерархии, ведущей к корневому ключу (кстати, опубликованному на сайте IANA). Если делать всё добротно, то данные DS-записей для подписывания должны передаваться минуя DNS, по другим каналам, подразумевающим некоторую аутентификацию отправителя – иначе теряется большая часть смысла в развёртывании DNSSEC. Стандартный путь проходит через регистраторов доменов.

Итак, для получения работающей конфигурации пришлось dxdt.ru и nox.su предпочесть домен tooktook.org, так как зона .org корректно подписана и размещение DS-записей в ней поддерживается крупными регистраторами (я воспользовался GoDaddy).

Функционирование каждого домена обеспечивают серверы имён (NS). Для tooktook.org я взял пару серверов с BIND 9.7.3 (это известная реализация DNS-сервера), который полностью поддерживает DNSSEC. На сайте ISC есть подборка инструкций по настройке DNSSEC в BIND-е. Я не стану приводить подробных деталей, потому что это будет офтопик, на мой взгляд (если что, то пишите вопросы в комментарии). Сам процесс создания подписанной зоны DNS несложен, и сводится к генерации нескольких ключей (закрытых и открытых), с последующим удостоверением с их помощью записей в файле зоны. В пакете с BIND есть все утилиты: dnssec-keygen, dnssec-signzone и т.п. То есть, на входе у вас текстовый файл зоны без подписей, на выходе – текстовый файл зоны, но уже с дополнительными записями (RRSIG, DNSKEY), содержащими подписи и открытые ключи для их проверки.

После того, как зона подписана, генерируем DS-запись (записи), содержащую значение хеш-функции от открытой части ключа (KSK), с помощью которого подписан ключ (ZSK), удостоверяющий записи в зоне. (Пара ключей используется для удобства их ротации и оптимизации процедуры подписывания зоны. И, да, можно сгенерировать DS-запись до подписывания зоны.) В случае с доменом tooktook.org я без каких-то трудностей разместил DS-запись при помощи клиентского веб-интерфейса GoDaddy. На удивление, весь процесс – генерация подписанной зоны, размещение записей, – занял примерно 20 минут, включая ожидание обновления информации в DNS.

Теперь tooktook.org подписан (проверить можно с помощью веб-интерфейса от VeriSign). Зачем? Следующий шаг – проверка на практике технологии, дополняющей, с помощью DNSSEC, механизмы использования SSL-сертификатов в браузерах и уже поддерживаемой в Chrome. Нужно же посмотреть, что нас ждёт в ближайшем будущем.

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

Update (25.11.11): в итоге капчу поменяли на ходу (видимо, накрутки давали о себе знать); новый вариант – reCAPTCHA, стандартное решение со словами.

Вот, кстати, с АМС “Фобос-Грунт” связь возможна в редких окнах. Для того чтобы бороться с подобными неприятными эффектами в отношении других аппаратов готовят специальные спутники-ретрансляторы. Например, “Луч-5А”, который, как пишут, доставили на Байконур:

Запуск ракеты космического назначения «Протон-М» с разгонным блоком «Бриз-М» и кластером из двух спутников – российского «Луч-5А» и израильского «Амос-5» (AMOS-5) запланирован на декабрь.

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

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

(Продолжаем выпускать блог dxdt.ru.)
При ближайшем рассмотрении, шумиха, поднятая в прессе касательно некоторого вируса в компьютерах штатовской военной базы, с которой управляют беспилотниками, – не более чем часть внутренней административной борьбы в ВВС США. Журналистам просто сдали некоторую “нужную” информацию. Сейчас на подходящем информационном фоне разыгрывают заготовленные карты. Внутри U. S. Air Force. То есть, внешний наблюдатель мало что сможет узнать. Но по результатам прессе сообщат что-то интересное.

На Сryptome выложен некий отчёт Fox-IT об аудите инфраструктуры DigiNotar, по следам взлома. Речь об августовском взломе удостоверяющего центра, когда были выпущены фиктивные SSL-сертификаты для *.google.com и других интересных ресурсов. Никаких технических подробностей в отчёте нет, но занятные моменты присутствуют.

Например, как пишут аудиторы про сети DigiNotar, критически важные сервера там были физически изолированы, но при этом доступны из локальной сети (видимо, имеется в виду некая общая корпоративная сеть, там не совсем понятно из текста) и объединены в единственный домен Windows (да, там использовали Windows, такое решение вполне возможно). Поломавший их специалист как раз и получил права администратора домена и, соответственно, за один раз обрёл доступ сразу ко всем нужным серверам. Удобно. При этом пароль от администраторской учётной записи был, что называется, угадываемым, а общего центрального логирования сетевой активности – не велось. (Вот так. Как обычно – искажённая модель угроз у админов корпоративной ЛВС привела к плачевным результатам.)

Ещё интересна хронология событий в случае с сертификатом *.google.com: 4 августа отмечают поток запросов на проверку отзыва этого сертификата (существует специальный протокол проверки, по которому работают современные браузеры), и только 29 августа сертификат реально отозвали. То есть, длительное время фиктивный сертификат мог работать без проблем.

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

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

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

Кстати, наверное, при повсеместном распространении и “исторической привычке” не возникнет особенных вопросов о том, как схема работает. Тем более, что всё открыто.

Обычно, перевод древних аналоговых технологий связи на цифровые рельсы выливается в сплошные преимущества: цифровая система может быть и гибче, и надёжнее, и безопаснее. Всё это верно и для радиосвязи. Но только в том случае, если реализация добротная. Очередное подтверждение, очень занятное: исследователи изучили цифровые системы радиосвязи стандарта P25, – используемые, например, спецслужбами США, – и обнаружили эффективные направления для активных атак.

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

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

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

В качестве аппаратуры для практической постановки помех исследователи применяют детскую радиоигрушку (да, именно так, не шутка), по цене $30 за комплект из двух устройств.

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

(Ссылка на научную работу найдена тут: schneier.com.)

О рисках, связанных с внедрением гипотетическим интернет-гигантом, браузера-шпиона: при верном планировании и качественной реализации плана, особых репутационных рисков нет, их преувеличивают. Такова реальность Интернета.

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

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

В продолжение темы про Chrome, который, якобы, переправляет в Google контент закрытых страниц из корпоративных интранетов: интересно подумать, как можно было бы устроить подобный шпионский браузер. Понятно, что едва ли Google что-то подобное делает, потому что не ясны стратегические выгоды: ну чего там интересного для массового пользователя можно найти в интранетах? Тем более, что и ссылку-то не покажешь: сервер же закрыт. В исходном вбросе, направленном на тематические СМИ, по той или иной причине не разработан технический аспект: то есть нет легенды, как именно Chrome “сливает инфу”. А ведь это был бы самый занимательный кусочек истории.

Что можно придумать? Понятно, что простое зеркалирование забранных с “секретного” сайта страниц на сервер Google – это неинтересный вариант. Хотя бы потому, что он обнаруживается совсем уж элементарно, с помощью систем мониторинга трафика. Использование зашифрованных каналов тут не поможет, потому что само наличие канала с трафиком демаскирует “шпиона”. Однако, можно “размазать” собранную информацию по многим транзакциям, передавая внутри каждой лишь небольшой фрагмент. Получается такой медленный и малозаметный канал.

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

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

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

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

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

Вообще, задача определения “секретных” страниц – тоже интересная (особенно, если нет связи с центром). И её что-то упустили из вида при обсуждении вброса на тему Chrome.

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

(Продолжение про риски и политику.)