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

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

Очевидно, что скоро подобные системы начнут продвигать на борт самолётов, как единственный эффективный способ борьбы с противовоздушными ракетами.

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

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

Вот, выходит, что ещё одно направление у РЭБ в “киберпространстве” возникает.

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

Для аудита можно использовать исходные коды. И их используют, потому что так удобнее. Есть разные автоматизированные инструменты и вообще – обкатанные подходы. Пример, который на слуху, аудит разработок Microsoft, для допуска к специальным компьютерам. Эта корпорация предоставляет исходники своих продуктов, на особых условиях.

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

Более того, известно, что вполне себе тщательно (но независимо) проверенный в “исходниках” компилятор, после применения к, опять же, проверенным исходным кодам, может дать на выходе (в исполняемом “бинарнике”) результат с неожиданными дырами и “закладками”. Добротный результат можно получить, если проверять совместно весь набор: и компилятор “в исходниках”, и “исходники” компилируемого продукта.

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

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

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

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

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

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

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

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

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

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

Так, адрес из примера графически имитирует домен второго уровня проверка.рф, используя для имитации символ деления из специальной таблицы unicode. Получается строка вот такого вида: http://проверка.рф⁄click.dxdt.ru/, где третья слева косая черта – это вовсе не “слеш”, как можно подумать, а сам домен находится в зоне .dxdt.ru. (которой управляю я), а не в .рф. Когда та заметка публиковалась, домен РФ ещё не работал (кириллическая ссылка на dxdt.ru – работала, конечно; чем впечатляла специалистов: “а как это так?” – спрашивали они). Сейчас зона .рф доступна. И поисковики индексируют сайты в ней.

Сейчас в google.ru по запросу “проверка.рф” первой выдаётся как раз ссылка на тестовую страничку http://проверка.рф⁄click.dxdt.ru/. При этом в тизере адрес записан именно в кириллическом виде, а не в нотации Punycode, с префиксом xn--, как должно бы было быть при смешении таблиц unicode в адресе. Что и требовалось доказать. Вот скриншот:

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

Как это исправить? Понятно, что Google должен смешанные адреса в тизерах показывать в Punycode – то есть, вот так: http://xn--80adjurfhd.xn--click-uye2a8548c.dxdt.ru/

В конце мая Google, наконец-то, реализовал доступность поиска по HTTPS – https://www.google.com/. Правда, пока не все поисковые направления работают по защищённому протоколу, например, не поддерживает HTTPS поиск по изображениям. Да и вообще всё в статусе беты. Тем не менее, это важный шаг.

Так, у Google нашлось достаточно вычислительных мощностей, чтобы перевести на HTTPS один из самых своих массовых сервисов: нужно учитывать, что вычислительные затраты на работу по шифрованному каналу заметно больше, если сравнивать с простым HTTP. При работе с многими миллионами запросов – проблема с дополнительной нагрузкой встаёт в полный рост.

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

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

В ближайшие годы на HTTPS перейдёт ещё больше сайтов. Вряд ли, конечно, защищённая версия быстро полностью вытеснит открытый протокол – ведь используют же до сих пор FTP. Но доля трафика HTTPS сильно вырастет. Собственно, уже и только трафик Google – заметная прибавка.

При этом криптография активно внедряется и на уровне DNS – это DNSSEC, – и на уровне IP (здесь планируется сертификация маршрутов и автономных систем, с подписыванием ЭЦП анонсов BGP – об этом, наверное, нужно отдельную записку написать). Новый Интернет должен сформироваться уже лет через пять. Помимо перехода на HTTPS, важным моментом будет проталкивание поддержки DNSSEC на клиентские машины.

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

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

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

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

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

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

Почему недостаточно хорошо работает этот “продвинутый” метод? Потому что отсутствует добротная аутентификация со схемой запрос-ответ. Не используется “обратная связь”, хотя она есть, как упомянуто в самом начале заметки.

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

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

Злоумышленник может организовать гипотетическую атаку типа “человек посередине”, пытаясь имитировать работу автомобильного блока в ответ на старт сеанса связи. Но так как, в отличие от GSM, здесь авторизация начинается только по нажатию кнопки владельцем автомобиля, успех – скорее призрачен. Хотя, есть варианты. Да и никто не гарантирует, что в конкретной реализации алгоритма не обнаружат дыр.

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

Итог: микроконтроллеры сейчас научились выпускать довольно мощные и очень компактные, с минимальным энергопотреблением. Микроконтроллеры при этом дешёвые. Алгоритмы защиты – известен. Вопрос такой: а защищены ли на практике все современные автосигнализации от перехвата команд?

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

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

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

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

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

Начинаем готовить WebHiTech-2010. Сайты уже упорядочены. Стараниями Артемия Ломова есть общая удобная точка входа WebHiTech.ru и сайты конкурсов по годам.

Сам конкурс намечен на осень. Награждение – где-то зимой.

Собственно, после развёртывания DNSSEC (пока в испытательном режиме), появились первые многоязычные домены (IDN) верхнего уровня в корневой зоне. Домена РФ среди них нет. Первые IDN верхнего уровня – на арабском. Это домены Египта, Саудовской Аравии и Арабских Эмиратов. Пресс-релиз ICANN – здесь.

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

Объяснение разработчиков процедуры – такое: использование кривого ключа гарантирует, что особенно продвинутые участники глобальной Сети не перейдут на полную поддержку DNSSEC раньше времени. Действительно, с “кривым” ключом использовать DNSSEC на практике смысла нет, поэтому клиенты не станут массово и полностью внедрять поддержку новой технологии, так как они не смогут в таком случае работать с DNS. А вот если бы корневую зону подписывали сразу проверяемым образом, то откат оказался бы очень проблемным делом: те, кто перешли на DNSSEC уже не смогли бы работать с Сетью, если бы поддержку DNSSEC отключили.