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

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

Представьте, что такой беспилотник появился. Он доставляет десять-пятнадцать килограмм груза. Так как от летательного аппарата требуется способность преодолевать сильный порывистый ветер, не бояться осадков, перепадов температуры, то, понятно, что это уже серьёзный аппарат. Который, при благоприятной погоде, может за пять-семь минут, по хитрой траектории, виляя между домами и меняя высоту, внезапно доставить свои десять-пятнадцать килограмм “нагрузки” к какому-нибудь режимному объекту, которых на территории столицы (например), несколько десятков. А если таких коммерческих беспилотников в воздухе сотня? Проблема, верно? И кто даст разрешение?

Так что нашествию коммерческих беспилотников-курьеров в крупных городах препятствует один фактор: сперва должны появиться эффективные средства прикрытия от них режимных объектов.

Лаборатория “Касперского” продолжает развивать тему глобальной шпионской киберактивности. В этот раз – операция Red October, обширная сеть кибершпионажа против дипломатических и государственных структур.

Цитата:

Как и когда эта операция была обнаружена?

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

Кто предоставил вам вредоносные файлы?

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

А вот – схема с инфографикой.

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

И, да, конечно, нельзя забывать про зловред Stuxnet, обнаруженный в 2010 году, и направленный против конкретного аппаратного обеспечения.

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

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

Так вот, есть ещё одно важное отличие между DANE+TLS (SSL) и чисто TLS (SSL). В случае с DANE, для того чтобы воспользоваться предоставляемыми возможностями и мимикрировать под “безопасный сайт” злоумышленнику нужно зарегистрировать другой домен. (Взлом цепочки управления DNS тут не рассматриваем.) Да, домен может быть визуально похож на адрес атакуемого сайта, как в хрестоматийном примере yandex.ru и yanclex.ru, но это другой домен. В случае же с имеющейся инфраструктурой удостоверяющих центров, выдающих SSL-сертификаты, злоумышленник может получить сертификат для того же самого домена. Что, кстати, не исключает тем более беспроблемного получения сертификата для условного yanclex-а. То есть, благодаря особенностям DNS, отличие DANE принципиальное – нельзя зарегистрировать и разместить в глобальной DNS второй домен, точно совпадающий с атакуемым. А вот выпустить без ведома администратора домена SSL-сертификат для него – можно. Естественно, с существенными оговорками, но, опять же, без взлома цепочки доверия. Свежее доказательство – история с TURKTRUST.

Это преимущество DANE.

TURKTRUST – удостоверяющий центр (УЦ), выпустивший левые сертификаты промежуточных УЦ, – публикует некие технические подробности, объясняя, как такое произошло. Это самая правильная реакция.

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

Google сообщает, что 24 декабря они при помощи Chrome обнаружили в Сети очередной “левый” сертификат для *.google.com (дополнение: и не только для *.google.com, но и для множества других адресов гугловских сервисов). Сертификат был выпущен “промежуточным” удостоверяющим центром (УЦ), действовавшем от имени TURKTRUST (это известный признанный УЦ, его корень наверняка встроен и в ваш бразер).

Занимательно объяснение TURKTRUST, которое приводят в блоге Google:

“TURKTRUST told us that based on our information, they discovered that, in August 2011, they had mistakenly issued two intermediate CA certificates to organizations that should have instead received regular SSL certificates.”

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

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

Буквально вот только что в корневой зоне DNS появилась DS-запись для ключа зоны .ru. То есть, теперь DNSSEC в .ru есть и работает.

В зоне .ru вчера появились записи DNSKEY, в которых опубликованы ключи KSK и ZSK для зоны, с соответствующей подписью. Следующий шаг – появление DS-записей (тоже с подписями) в корневой зоне DNS. Что, как обещают, должно случиться до конца года.

Координационный и технический центры российских национальных доменов готовятся к введению DNSSEC в .ru – это основной домен из трёх (su, рф, ru). Вот, пишут, что сгенерировали ключи и положили их на изолированный компьютер (air gap, да). Подписать .ru обещали до конца этого года. Так что можно, в принципе, готовить серверы и свои зоны. (Я dxdt.ru уже подписал; вот значение для DS – 12E833887648F73B80E06CC86252E025FFE5F75F.)

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

У DANE, впрочем, есть некоторые особенности, – скорее, негативные, – которые связаны с тем, что для обеспечения управления доверием используется DNS. Причём, фактически, важную роль играет административная структура этой системы, а не чисто техническая.

Предположим, что кто-то желает перехватить соединение с веб-сайтом, работающим по HTTPS, не вызвав каких-то предупреждений в браузере и подозрений у пользователя. Предположим, что DANE выступает в качестве замены инфраструктуры SSL. Тогда, для незаметного перехвата, достаточно получить управление серверами имён, поддерживающими домен, в котором находится атакуемый сайт. Серверы можно взломать. Или просто изменить на свои. Существенный момент: потребуется перехватить и управление записями DNSSEC в зоне уровнем выше, либо заполучить секретный ключ, с помощью которого подписывается зона. При правильном сопровождении домена – сделать это непросто. Однако нельзя исключать, во-первых, взлома панели управления регистратора, а, во-вторых, того, что на каком-то этапе какой-то провайдер DNS может “посотрудничать” с “заинтересованными лицами”.

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

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

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

(Напомню, что в спецификации DANE учтены случаи использования SSL-сертификатов, выданных удостоверяющими центрами, которые могут входить в существующую “браузерную” инфраструктуру; а могут и не входить, да.)

Для дальнейшего тестирования DNSSEC и сопутствующих инструментов я сделал пару сломанных зон. Особенно радикально сломана dotsu.su – там в зоне .su указан зарезервированный код алгоритма для DS-записи, а внутри зоны содержатся “сильно кривые” записи DNSKEY. Так, при попытке обработки dotsu.su – успешно падал онлайн-инструмент VeriSign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com/), сейчас, после того, как я написал в техническую поддержку, всё исправили.

Есть вторая зона broken.nox.su, третьего уровня, там пока просто отсутствуют DS-ы в зоне уровнем выше (nox.su), что является более мягким вариантом. Update: теперь для broken.nox.su добавлена DS-запись, которая не соответствует никакому ключу в зоне (ключей там нет, собственно), так что адреса в broken.nox.su с DNSSEC резолвиться не должны.

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