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

Вот, кстати, первым источником уязвимостей в реализациях DNSSEC (это “безопасное” расширение DNS) будут рационализаторские решения. Технические центры крупных доменов захотят экономить ресурсы и поправят технологии так, как удобнее с точки зрения экономии. Поправки породят уязвимости.

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

Так что с DNSSEC будет то же самое – дыры подготовят рационализаторы.

Telnic для использования нового домена первого уровня TEL предлагает плагин к MS Outlook. Плагин, понятно, для того, чтобы сразу загружать контактные данные, размещённые под доменом .tel, в Outlook (обратную функциональность также обещают). Напомню, что TEL – он позиционируется как глобальное хранилище контактных данных, использующее для хранения этих данных DNS.

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

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

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

Возникает резонный вопрос, а что можно протолкнуть через DNS на клиентскую машину? Неспециалистам это кажется странным, но протолкнуть можно всё что угодно, только скорость будет не очень большая. Главное, чтобы на клиентской машине было ПО, готовое принимать данные через DNS-туннель.

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

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

Вот такие новые угрозы с новыми доменами.

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

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

Отношения Веба и TEL вообще сложные: хоть домен и позиционируется как “исключительно DNS”, администратору пришлось запустить proxy-сервис, который показывает содержание доменной зоны через Веб. См., например, nadya.tel браузером. Зачем? Да просто без подобного веб-туннеля массовой аудитории вообще нечего было бы показывать о домене. Ведь аудитория привыкла, что Интернет виден через веб-браузер – и только. Строки текста, возвращаемые (для тех, кто в курсе) dig – вообще непонятны. Приложения, извлекающие контакты из TEL через DNS, воспринимаются как “локальные адресные книги” и с Интернетом, в понимании пользователя, не связываются. Выходит, что TEL пытается бороться с Вебом. Весьма рискованная для TEL борьба.

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

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

Посмотрим, что там из TEL выйдет.

WebHiTech – это технологический конкурс веб-сайтов. Первый такой в Рунете. В прошлом году мы успешно провели первый из WebHiTech`ов. В этом году планируем очередной: WebHiTech-2009. То есть, конкурс должен стать ежегодным и регулярным. Правила, регламент – остаются практически без изменений, хотя некоторые нововведения по процедуре есть, но об этом несколько позже. Принимать заявки начнём осенью. В оргкомитете председательствует Артемий Ломов.

На данный момент главная новость такая: открыт сайт конкурса в новом дизайне. Пожалуйста, смотрите по адресу: http://www.webhitech.ru/. Кроме того, у конкурса обновлённый логотип.

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

Чтобы проще было разбираться, на всякий случай напомню, что же такое DNS. DNS – это такой сервис в Интернете, позволяющий преобразовывать символьные имена узлов в числовые IP-адреса, по которым и производится реальная адресация. (Ну и, вообще говоря, с помощью сервиса DNS специальным образом возможно осуществить и обратное преобразование: IP-адрес – в символьное имя.) Главный философский момент тут такой: DNS – именно сервис, работающий с помощью большого количества серверов, разбросанных по глобальному Интернету; напрямую к маршрутизации пакетов DNS не привязана – пакеты между узлами вполне ходят без всякой DNS, которую придумали-то для людей.

Вот.

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

2. DNSSEC позволяет победить такие вполне себе фундаментальные уязвимости в DNS, как, например, отравление кеша. Эти уязвимости позволяют нехорошим злоумышленникам перенаправлять пользователей Интернета на свои серверы, подменяя соответствие имён доменов и IP-адресов. Набрал мойбанк.ru, а браузер попал вовсе не на сервер банка. Кому-то может показаться, что более старые, чем Веб, уязвимости вовсе не так уж и опасны, они протухли. Но вот, скажем, если недавно продемонстрированную на практике возможность создания поддельного SSL-сертификата, вообще не отличимого от настоящего, прикрепить к отравлению кеша, то получится, что достаточно продвинутые злоумышленники могут клонировать сайт банка, снабдив его, в том числе, и валидным SSL-сертификатом. Даже крайне недоверчивый пользователь будет введён в заблуждение. Хорошо построенная атака может дать массовый эффект: пользователи крупного провайдера все как один пойдут вместо реального сервера банка на подставной, при этом в адресной строке браузера будет значиться правильный адрес, и SSL-сертификат не вызовет в браузере окон с предупреждениями.

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

4. Вот с ключами как раз и возникают основные хитрости. Как известно, для проверки подписи нужен открытый ключ, принадлежащий тому, кто подписывал. В случае DNS – тому лицу, которое сгенерировало данные об адресации в доменной зоне. Можно рассматривать всякие технические особенности и хитрости криптосистем RSA (и если это интересно, то можно написать серию заметок по теме), но самый важный вопрос всё равно более системный: как узнать, что претендующее на владение той или иной доменной зоной лицо, размахивающее через DNS-запрос открытым ключом и соответствующей подписью, действительно владеет этой зоной и уполномочено ей управлять? И вправду, может, это самозванец? То есть, опять вопрос сводится к такому: можно ли конкретной подписи доверять, если раньше этой подписи не попадалось и о её владельце особой информации нет? Это общий вопрос для систем аутентификации. В офлайне он издревле решается так: приглашают третью сторону, которой доверяют оба “участника сделки”. Если решение обобщить, то возникает некая структура доверия, которая может быть “плоской” (как, например, в системах PGP), но чаще бывает иерархической, сходящейся к некоторому корневому центру, который, в итоге, удостоверяет подписи всех остальных “участников соглашения”.

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

Вот.

Вообще, несколько подробнее про DNSSEC в популярном изложении можно прочитать в недавнем выпуске журнала “Доменные имена”, который в электронном виде можно взять на сайте RU-CENTER. На 69-й странице там начинается моя статья про DNSSEC.

(Если есть какие-то вопросы – прошу в комментарии, я, возможно, сделаю отдельный раздел про DNSSEC.)

***

Дополнения (2012):

О DNSSEC, в течение нескольких лет, я написал много других публикаций и реализовал несколько технологических демонстраций, например, такой демонстрацией является первый подписанный домен в зоне .su – nox.su.

Корневую зону глобальной DNS (общепринятой) подписали в ночь с 15 на 16 июля 2010 года. Связанные с этой процедурой домыслы прессы, падкой на криптосенсации, привели к возникновению забавного “мема” о “шестёрке программистов, которых уполномочили перезагрузить Интернет, если он сломается”. Естественно, в реальности всё обстоит сильно иначе.

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

Между прочим, уже работает новый домен верхнего уровня: TEL. Вот его администратора сайт: http://telnic.net/. TEL интересен прежде всего тем, что это некая попытка начать использовать DNS в плане “развития” ENUM.

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

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

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

Оказывается, “Яндекс” запустил “Ответы” – сервис, где эксперты отвечают на вопросы пользователей. Собственно, всё развивается очень логично и предсказуемо, см. мою старую записку по развитию “Яндекса”.

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

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

Update (07/02): Продолжение от The Register, сведения подтверждаются. (Вообще, SQL-инъекция – это, конечно, сильнейший удар по репутации, тут сказать нечего.)

Популярный сетевой червь Downadup (или Net-Worm.Win32.Kido, а также Conficker), между прочим, на практике демонстрирует разнообразие своего сетевого инструментария.

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

Кроме того, механизм сканирования сетей содержит “чёрный список” IP-адресов, принадлежащих компаниям, связанным с обеспечением компьютерной безопасности, – по этим адресам червь с попытками заражения не обращается.

Самое интересное, что W32.Downadup/Net-Worm.Win32.Kido ещё и умеет анализировать сетевую инфраструктуру. Алгоритм заражения, включающий несколько этапов, требует, чтобы заражаемая машина инициировала соединение через Интернет с заражающей и скачала к себе основной код вируса. Понятно, что брандмауэры, установленные в модемах и маршрутизаторах, обычно противятся такой активности локальных машин. Более того, заражённые машины вероятно располагаются за NATом. Поэтому код Downadup предварительно обнаруживает шлюзы в локальной сети, проверяет их настройки (всё через UPnP), организует себе такой канал, который шлюз будет пропускать в обратном направлении (из внешней сети вовнутрь) и уже с использованием этого канала заражает другие машины.

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

До сих пор в Интернете популярна авторизация по IP-адресу, например в тех же CMS (но не только). Например, помимо предъявления авторизационного куки-файла, для авторизации требуется, чтобы и запрос был с заданного IP-адреса, скажем с того же, с которого делался логин, породивший куку, или просто готовится “белый список” допустимых IP-адресов.

С одной стороны, это увеличивает “стойкость”, так как, на первый взгляд, если злоумышленник “угнал куки” или подслушал снифером пароль, то авторизоваться в системе со своей машины он не сможет, так как у этой машины, предположительно, другой IP-адрес.

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

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

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

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

Вновь приходится слышать от разработчиков CMS старую песню: “мы закрываем исходный код, потому что там наверняка уязвимости, а в закрытом коде найти их сложнее”. Речь о коммерческой CMS, о PHP, а “закрывают код”, понятно, с помощью Zend Optimizer.

А вот интересно разобраться, кому в действительности нужно, чтобы код был закрыт подобным образом. Разбираемся. Например, раз уязвимости есть (а они есть), то наверняка среди них полно шаблонных решений. Разработчики-то, собственно, нормальные, как и у других продуктов, поэтому нужно ожидать неистребимых SQL injection и далее по списку. То есть, обнаружению и использованию типичных уязвимостей закрытый код не помешал. Не удивительно – ведь от того, что код закрыт, дыры не исчезли, их просто хуже видно.

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

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

Итак, против кого работают “спрятанные дыры”? Оказывается, что только против добропорядочных веб-мастеров и админов, которые хотели бы поверхностно взглянуть, что же там внутри CMS, которую планируют поставить на свой любимый сервер. Хотя бы с целью оценить стиль, прикинуть возможности “адаптации”, а вовсе и не для поиска дыр. Для них создаются дополнительные трудности, вполне ощутимые.

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

Так вот. Требуйте открытых исходников CMS – проще будет эксплуатировать ПО.