Книга: Домены. Все, что нужно знать о ключевом элементе Интернета
Заверено подписью
Заверено подписью
Итак, у DNS есть множество хорошо известных специалистам проблем безопасности. Однако наиболее важная – это проблема с достоверностью адресной информации, что неудивительно, ведь определение адресов веб-узлов – из того класса задач, для решения которых, собственно, DNS и создавали. Выше мы разобрали показательный пример с подделкой адресной информации на DNS-сервере, которому вынуждены доверять пользователи конкретного интернет-провайдера. Однако это лишь одно из воплощений проблемы, самое очевидное.
На первый взгляд может показаться, что для «подсовывания» конечному клиенту DNS дефектной информации об адресах узлов злоумышленник должен контролировать используемый атакуемым компьютером сервер DNS, ну, или по крайней мере находиться в одной сети с атакуемым компьютером. Но на практике дела обстоят гораздо хуже. Особенности реализации обмена запросами и ответами в DNS позволяют злоумышленнику атаковать даже весьма удаленные от его узла системы, и успешные атаки клиентских машин вовсе не требуют контроля над DNS-серверами. Однако в таком случае реализация атаки усложняется и требует параллельной работы нескольких «хакерских сетевых механизмов», которые, впрочем, хорошо изучены и отработаны.
Другими словами, у «злых хакеров», хорошо владеющих интернет-технологиями, есть возможность направить по ложному адресу даже те пользовательские компьютеры, которые подключены к Интернету через добросовестных провайдеров, чьи сетевые администраторы следят за работой своих DNS-серверов. Более того, существует целый класс атак на DNS, которые используют особенности меж-серверного взаимодействия внутри системы доменных имен. Здесь непосредственной целью являются сами DNS-серверы (а точнее – данные в их адресных таблицах), но конечная задумка практически всякой такой атаки – введение в заблуждение либо компьютеров конечных пользователей, либо других серверов (не имеющих отношения к DNS). Для чего? Обычно для того, чтобы получить доступ к закрытым информационным ресурсам, перехватить пароли для управления теми или иными сервисами, считать из удаленной и обособленной (в организационном плане) компьютерной сети какие-либо данные.
Атаки через уязвимости DNS могут быть чрезвычайно эффективны. Тем не менее системной защиты от них в Интернете пока нет (2013 год), она только вводится в строй. Впрочем, неверно думать, будто специалисты лишь недавно разгадали уязвимости DNS. О фундаментальных недостатках этого механизма адресации известно уже много лет, можно сказать, с самого рождения DNS.
Возникает вопрос: почему за все эти годы не внедрили какие-нибудь исправления протоколов, корректирующие ситуацию? Ответ на этот вопрос такой: только недавно практический ущерб от уязвимостей DNS стал выглядеть весомым в глазах достаточного числа специалистов, продвигающих и внедряющих новые интернет– технологии. Ранее возможные затраты на внедрение изменений в работе DNS в сумме с риском вовсе потерять связность доменной системы имен в процессе изменения протоколов легко перевешивали практический вред от использования уязвимостей. Другими словами, довольно сложно убедить инертное провайдерское сообщество Интернета (у членов которого, будем говорить прямо, проблемы безопасности конечных пользователей не являются первоочередными) ввести ту или иную новую сложную технологию в дополнение к хорошо работающей и простой или вместо нее. Нужно заметить, что внедрение в DNS всякой функциональности «управления доверием» значительно усложняет систему, повышает требования к оборудованию и обслуживающему персоналу. То есть в конечном итоге защита DNS напрямую связана с прибыльностью провайдеров.
Впрочем, это лишь одна часть проблемы. Другая часть, не менее важная, имеет отношение к политическим факторам, как и следует ожидать в Глобальной сети. Подробнее о них – чуть ниже, а сейчас остановимся на том решении проблем безопасности DNS, непосредственное внедрение которого в Глобальной сети начато в 2010 году.
Итак, для реализации «более безопасной DNS» используется технология DNSSEC. Она позволяет, с одной стороны, удостоверять данные в адресных таблицах и, с другой стороны, дает в руки конечным клиентам средства для проверки достоверности сообщаемой тем или иным сервером адресной информации. DNSSEC – расширение DNS, подразумевающее внесение изменений в структуры данных, используемые доменной системой, и в программное обеспечение, реализующее функции DNS на серверах и клиентах. Важнейшим моментом здесь является внедрение системы именно на клиентских компьютерах, на компьютерах обычных пользователей. Такое возможно, например, на уровне браузера или операционной системы.
В рамках этой книги мы не станем подробно изучать криптографические механизмы, лежащие в основе DNSSEC, чтобы не перегружать читателя технической информацией. Однако для понимания принципов работы одного из главнейших обновлений DNS нужно в самых общих чертах представить себе основные понятия новой системы. Такие знания тем более полезны, что DNSSEC использует стандартные подходы, встречающиеся в большом количестве других современных систем безопасности.
Несколько десятков лет назад криптографами были разработаны методы, позволяющие создавать так называемые цифровые подписи, удостоверяющие подлинность заданного набора данных. Предположим, что у нас имеется запись о соответствии имени домена и IP-адреса. В рамках DNSSEC в строгое соответствие этой записи ставится специальная последовательность байтов, представляющая собой цифровую подпись. Главная особенность «подписывания» заключается в том, что есть простые и, самое главное, публично доступные (открытые) методы проверки достоверности подписи, а вот генерирование подписи для произвольных данных требует наличия секретного ключа в распоряжении подписывающего. То есть проверить подпись может каждый участник системы, а подписать что-либо, используя доступные вычислительные ресурсы и за разумное время (это очень важное дополнение), – только обладатель секретного ключа. На первый взгляд, это может показаться парадоксальным. Тем не менее именно так работают асимметричные системы шифрования с открытым ключом, лежащие в основе алгоритмов цифровой подписи.
Попробуем разобраться на очень простом примере. Следует иметь в виду, что этот пример лишь похож на операции в рамках DNSSEC, а не описывает их в деталях. Предположим, администратор зоны fort.test.ru хочет удостоверить с помощью цифровой подписи данные об адресации, хранящиеся на его DNS-сервере. У администратора есть пара ключей: секретный и открытый (публичный). Используя секретный ключ и данные об адресации (можно считать, что эти данные представляют собой простой компьютерный файл) в качестве исходных данных, администратор генерирует новый файл, содержащий цифровую подпись, соответствующую секретному ключу и исходным данным. Получив значение цифровой подписи (а она представима в виде набора байтов), администратор размещает эту подпись в публичном доступе вместе с адресной информацией.
Нужно заметить, что в теории подписи у различных наборов исходных данных могут совпадать, однако на практике используют алгоритмы, сводящие вероятность такого совпадения к минимуму. По крайней мере, простые пользователи могут надеяться на то, что вероятность минимальна.
Теперь для других участников, использующих DNSSEC, доступна информация об адресации и связанная с этой информацией цифровая подпись. Для проверки подписи используется открытый ключ из пары, принадлежащей администратору, который также опубликован. Для проверки, которая выполняется по специальному, известному всем участникам DNSSEC алгоритму, используются файл данных об адресации, файл с соответствующей цифровой подписью и открытый ключ. Заметьте, что открытый ключ дает возможность проверять достоверность подписи, но не позволяет за разумное время вычислять новые подписи для измененных данных. Важная особенность цифровой подписи в том, что при изменении подписываемых данных изменяется и сама подпись, поэтому просто скопировать подпись от одних данных и «прицепить» ее к другим не получится.
Если злоумышленник на каком-либо этапе обработки запросов с использованием DNSSEC изменил данные о соответствии доменов и адресов, то ему также потребуется изменить цифровую подпись, сопровождающую данные запросов, а для этого необходимо знание секретного ключа. Таким образом, потребитель адресной информации из DNS (или внутри DNS) может проверить достоверность данных с помощью подписи и не принимать к сведению недостоверные данные. Проблема решена? Не совсем.
Все бы хорошо, но, если чуть тщательнее обдумать предложенную только что схему, можно найти неприятный момент. Предположим, злоумышленник не только изменил адресную информацию, но еще и подписал ее, используя собственный секретный ключ, а соответствующий открытый ключ (для проверки подписи) подсунул ничего не подозревающей жертве вместе с обманными данными DNS. И вообще, каким образом получатель адресной информации может убедиться, что тот, кто ему эту информацию передает, действительно уполномочен управлять данным доменом? Может, отвечающий сервер подставной? Сама по себе верность цифровой подписи не гарантирует того, что достоверно и содержание заверенных этой подписью данных. Выходит, даже внедрив «хитрые» подписи, мы остались все при тех же проблемах доверия?
Так и есть: одними подписями обойтись не удается. Требуется механизм, позволяющий удостоверять полномочия источников этих подписей. В DNSSEC для создания этого механизма должна использоваться естественная иерархия прав, уже существующая в доменной системе имен. То есть на базе системы делегирования прав администраторам доменов, о которой подробно рассказано несколькими главами выше, создается механизм подписывания ключей. Так, достоверность источника ключа для какого-либо домена удостоверяется с помощью цифровой подписи, исходящей от вышестоящего «удостоверяющего центра», подпись этого центра удостоверяет другой, стоящий еще выше в иерархии, а в итоге образующаяся «цепочка доверия» сводится с корневому домену и корневому ключу. Этот ключ должен быть распространен по всем участникам DNSSEC независимо от DNS. Например, он может быть встроен в операционные системы. Корневой ключ – главный ключ всей системы, позволяющий проверить достоверность любой подписи на всех прочих уровнях, – принадлежит той организации, которая отвечает за достоверность DNS в целом, и поэтому, строго говоря, этот ключ не может являться частью DNS.
DNSSEC позволяет участникам системы самим настраивать «цепочки доверия» и решать, какому именно удостоверяющему центру они готовы верить «на слово», без дополнительных проверок. В каких-то сетевых архитектурах конечным центром доверия может являться вовсе не корневой центр всего Интернета, а, скажем, некоторый локальный сервер. Но для всего Интернета важен именно общепринятый корневой центр.
DNSSEC уже внедрена во многих доменах первого уровня. Есть немало доменов уровнем ниже, внутри которых также используется DNSSEC. Однако совершенно преждевременным было бы говорить, что DNSSEC развернута, до тех пор пока не «подписаны» корневые серверы имен, соответствующие корневому домену. (Как я рассказывал ранее, таких серверов 13, и в настоящий момент они в административном плане контролируются ICANN.)
Именно с «подписыванием» корневых серверов были связаны политические проблемы в управлении Глобальной сетью. Они сводятся к довольно простому вопросу: у кого ключ?
Из соображений безопасности секретный ключ, с помощью которого подписывается информация в вершине иерархии доверия, должен являться самой охраняемой частью системы. Однако любое изменение в файлах корневой зоны требует использования секретного ключа для генерирования новой подписи. Изменения же вносятся весьма часто, а многие из них носят чисто технический характер.
До внедрения DNSSEC контроль над верхушкой иерархии DNS был более размазан. Да, фундаментальные решения принимала ICANN после согласования с соответствующими подразделениями Минторга США. Техническую сторону обеспечивают технические службы (например, корпорация VeriSign или такая организация, как IANA). При этом сами 13 корневых серверов вовсе не являются тринадцатью физическими компьютерами, а представляют собой большое количество сложных многокомпьютерных систем, разбросанных по дата-центрам разных стран. Понятно, что в управлении этими базовыми узлами DNS так или иначе задействовано большое количество различных телекоммуникационных компаний.
После того как состоялось подписание корневых серверов, управление DNS получило еще одну строгую криптографическую процедуру, однозначно привязанную к корневому ключу. Корневую зону DNS окончательно подписали в ночь с 15 на 16 июля 2010 года. Конечно, после завершения многомесячной и довольно сложной процедуры поэтапного развертывания технологии на корневых серверах. Открытые ключи для проверки подписей DNSSEC опубликованы на сайте IANA (https:// data.iana.org/root-anchors/). Таким образом, несмотря на существенные административные сложности, Минторг США, компания VeriSign и службы ICANN в 2010 году успешно завершили развертывание DNSSEC в корневой зоне.
Споры вокруг того, кому должен достаться «главный ключ», кто будет подписывать данные, а кто станет генерировать новые ключи, шли довольно долго. В итоге утвердили следующую схему. Существует два ключа – самый главный KSK (Key Signing Key – ключ для удостоверения ключа) и чуть менее «главный» ZSK (Zone Signing Key – ключ для подписывания зоны). KSK удостоверяет ZSK, а уже последний используется для удостоверения данных в корневой доменной зоне. Достоверность ZSK можно проверить, используя открытую часть KSK.
ZSK генерируется и находится в распоряжении корпорации VeriSign, которая и подписывает с его помощью адресную информацию в корневой зоне. KSK – генерируется ICANN, на специальной церемонии. И структуры ICANN же подписывают ZSK, делегируя таким образом технические полномочия VeriSign. Заметьте, что ключи меняются через определенное время. ZSK – чаще, KSK – реже, так как он несколько более защищен и используется для удостоверения меньших объемов данных.
Процедура генерации криптографических ключей по причине своей важности для Интернета, а также из-за того, что криптография сама по себе несет некий отпечаток таинственности, в первый же год работы DNSSEC в корневой зоне породила множество искаженных пересказов в СМИ. Например, летом 2010 года едва ли не каждый новостной канал распространил сенсационное сообщение о том, что «собрана шестерка программистов, которые в случае глобальной неисправности смогут перезагрузить Интернет с помощью особого ключа». В чем же реальная суть процедуры, или, если хотите, церемонии, генерации этого самого «особого ключа»?
Собственно, по состоянию на 2013 год KSK вообще ни разу не менялся – для этого просто забыли предусмотреть процедуру. Да, и такие провалы случаются в истории DNS, несмотря на участие в проектировании действующей версии системы множества признанных специалистов. Вполне возможно, что процедуры смены (ротации, как говорят специалисты) KSK все же разработают в ближайшие годы. И ключ изменится. Хотя кто знает – не исключены и более пессимистичные варианты.
Действительно, заботясь о хорошем информационном фоне и придавая процедурам «ужесточения» управления DNS нужную степень прозрачности, в ICANN изначально прибегли к помощи экспертного сообщества, сформировав несколько групп «хранителей ключа».
Команда экспертов, выступающих представителями интернет-сообщества, включает в себя 21 человека в «основном составе», плюс 13 человек – «скамейка запасных». Назначение команды – обеспечивать процесс генерации и сопровождения ключей, подписывающих корневую зону DNS, выступая фактически в роли доверенных контролеров;
Внутри этой команды есть две группы по семь человек, каждая закреплена за одним из двух дата-центров, в которых генерируют составляющие ключа KSK и используют его для подписания других ключей; люди из этих групп хранят ключи, необходимые для получения паролей от криптосервера. Интересно, что речь тут идет о «физических» ключах от сейфовых ячеек, в которых находятся пароли к криптосерверу.
Третья группа хранит смарт-карты с частями ключа, позволяющего расшифровать резервную копию секретного KSK в случае, если вдруг основная копия, находящаяся в криптосервере, исчезнет в результате какого-нибудь катаклизма. В резерве – семь человек с ключами «от криптосервера» (условно) и шесть – с частями ключей от резервной копии.
Как я только что рассказал, используют два ключа: KSK и ZSK. С помощью KSK подписывают ZSK, которым подписывается корневая зона. ZSK генерирует VeriSign, потому что эта компания технически отвечает за распространение корневой зоны DNS. По процедуре, новые ZSK «выкатываются» четырежды в год. Каждый новый ZSK должен быть подписан защищенным криптосервером, в котором содержится секретная часть KSK. В идеале никто из людей не знает секретной части KSK – она просто не должна покидать пределы криптосерверов в открытом виде. То есть четыре раза в год эксперты с ключами от криптосервера приезжают в дата-центр и отпирают криптосервер, тем самым разрешая этому устройству подписать новый ZSK. Те доверенные люди, что хранят смарт-карты с частями ключа, которым зашифрована резервная копия KSK, выезжают «на восстановление» не по графику, а только если основная копия утрачена. (Видимо, только этот момент, благодаря его драматургии, и привлек журналистов.)
Понятно, что, если действовать по процедуре, без держателей ключей от криптосервера подписать зону восстановленным из резервной копии KSK не получится. Более того, по существующей процедуре не выйдет вообще что-либо сделать с корневой зоной без участия VeriSign и Минторга США – какими ключами ни размахивай. Очевидно, что утрата секретного ключа KSK не приведет одномоментно к отключению DNS и краху DNSSEC. До момента истечения срока действия текущего ZSK даже изменения в зону можно будет вносить. А вот подписать новый ZSK утраченным KSK – не получится.
Ну а самое интересное, что в крайнем случае никто не помешает просто сгенерировать новый KSK силами ICANN, Минторга и VeriSign, равно так же, как это было сделано при развертывании DNSSEC. Впрочем, возникнет большая проблема с распространением этого нового KSK по клиентам. Ситуация поменялась из-за того, что проникновение DNSSEC за эти годы возросло: просто так опубликовать ключ на сайте не выйдет, система сломается. А добротная процедура ротации KSK включает использование старого ключа, он потребуется для удостоверения нового, так что терять ключи ICANN не стоит.
Мы уже коснулись важного момента, лежащего в основе множества атак злоумышленников, «ложного доверия» пользователей к адресу: рядовые посетители сайтов, пользователи других онлайн-ресурсов, связанных с доменами, склонны считать, что если они набирают в адресной строке то или иное доменное имя, то браузер приводит их именно на тот сайт, который они ожидают под этим именем увидеть.
Решая главную проблему «дырявости DNS», DNSSEC гарантированно создает множество новых проблем, ранее не существовавших. Это происходит прежде всего потому, что DNSSEC намного сложнее по сравнению с «классической DNS».
Уничтожая одни уязвимости, DNSSEC готовит почву для других. Разработчики системы, конечно, знают об этом. Уже понятно, что внедрение DNSSEC создаст новые возможности для атак типа «Отказ в обслуживании» (DoS), ведь криптографические процедуры защищенной DNS гораздо более ресурсоемки в вычислительном смысле. Злоумышленники при помощи отправки системам, поддерживающим DNSSEC, «дефектных» наборов данных смогут с большей относительно «классической» DNS легкостью занять все вычислительные ресурсы компьютера проверкой «бессмысленных» адресных данных.
Кроме того, существенную трудность представляет распределение ключей, необходимых для генерирования цифровых подписей. Со временем ключи устаревают, и требуется производить их замену. При этом замена должна происходить с высокой надежностью, и всем участникам системы необходима возможность узнать о том, что конкретный ключ прекратил свое действие.
Реализация сложных по сравнению с обычной DNS криптографических алгоритмов в программном обеспечении может быть выполнена с ошибками, что создаст поле для хакерских атак. Существуют и другие проблемы, о которых наверняка сейчас еще ничего не известно, и раскроются они лишь после повсеместного внедрения DNSSEC. Тем не менее при всех сложностях DNSSEC обещает значительно улучшить ситуацию с безопасностью в Интернете, создав платформу для «управления доверием».
На этом доверии сетевым реквизитам паразитируют так называемые фишеры.
Для обмана интернет-пользователей фишеры используют целый арсенал средств, на первом месте в котором – хитрости с DNS и именами доменов. Очень большой удачей для фишеров будет выполненный тем или иным способом перехват управления доменом, под которым размещен сайт банка. Мошенники заблаговременно готовят сайт-обманку, внешне неотличимый от официального сайта банка, и после получения управления доменом переводят домен на этот сайт-обманку. Клиенты банка, как и ранее, заходят на сайт, набрав в адресной строке браузера привычное имя домена (или воспользовавшись закладками браузера, что в данном случае имеет тот же эффект). Однако вместо настоящего сайта клиентов ждет сайт-обманка, обычно предлагающий ввести реквизиты для управления банковским счетом (мотивируется такая просьба самыми разными причинами: «обновление базы данных», «проверка и переучет пользователей системы онлайн-банкинга» и т. п.). Клиент, искренне полагая, что находится на официальном сайте банка, с легкостью делится нужными реквизитами с фишерами. Именно для осуществления подобных атак, весьма и весьма эффективных, фишеры прибегают к услугам хакеров, помогающих «угнать» домен.
Впрочем, угнать домен банка, даже и временно, удается далеко не всегда (но иногда удается). Поэтому фишеры используют другие способы, также основанные на доменных именах, но не требующие хитрейших хакерских «упражнений».
Например, фишеры регистрируют домены, по тому или иному «психологическому» аспекту похожие на домен атакуемого сервиса (а атака не обязательно проводится на банк). Скажем, для атаки на сервисы известной поисковой машины «Яндекс», размещающей свои «точки входа» под доменом yandex.ru, предназначался домен yanclex.ru. В этом случае использовалась графическая схожесть буквы d и последовательности букв cl. Для осуществления атаки с использованием графически похожего домена пользователям рассылают поддельные сообщения электронной почты, в данном случае якобы от «Яндекса», в тексте которых содержится приглашение зайти по указанной ссылке и ввести свои авторизационные данные. Здесь важную роль играет именно то, что пользователь не набирает адрес в строке браузера и не использует «браузерную закладку» для перехода на сайт «Яндекса», а кликает по предложенной ссылке, на глаз определяя ее как ведущую на «Яндекс».
Регистрация домена yanclex.ru вполне может вызвать некоторые подозрения у регистратора, хотя никаких правовых оснований для запрета регистрации подобного домена нет. Но встречаются и куда более изящные с технической точки зрения решения, не могущие даже вызвать подозрений до того момента, как начнется фишинговая атака. Например, в 2010 году фишеры очередной раз использовали старый механизм дезинформирования пользователя и атаковали интерфейсы некоторых интернет-сервисов с помощью довольно изящного алгоритма. (Как обычно, я не излагаю атаку во всех деталях и незначительно изменяю некоторые технические моменты – эта книга не о взломе чужих аккаунтов.)
Итак, в атаке задействовали обыкновенный домен в зоне .COM (эта зона, кстати, допускает весьма высокую степень «приватности» регистраций, затрудняющую в дальнейшем поиск злоумышленников правоохранительными органами). Суть атаки сводилась к регистрации домена уровнем ниже второго, но сходного по имени с доменом сервиса. Например, регистрировался домен twitter.com.
ffghfs.com. Здесь название домена второго уровня вообще не имеет значения, ставка делается на фрагмент twitter.com, имитирующий адрес известного сервиса микроблогов. На первый взгляд кажется, что пользователь легко отличит поддельный адрес от настоящего именно благодаря наличию избыточного «суффикса». Но не так все хорошо: злоумышленники использовали тот факт, что многие пользователи заходят в данный сервис с мобильных устройств (телефонов, коммуникаторов), в которых возможности по отображению адреса ограничены. Поэтому пользователи таких устройств, получив в специальном письме (или через систему обмена мгновенными сообщениями) некую ссылку, видели на экране только «начало» доменного имени в адресе URL: «http://www.twitter.c…» и предполагали, что соединяются со страницей известного им сервиса. Подготовить копию веб-интерфейса, запрашивающего пароль, и разместить ее под поддельным доменом – такая операция не представляет какой-либо трудности для интернет-мошенников.
Хитрость в том, что URL разбирается компьютером как положено по стандартам: то есть в области, определяющей адрес сервера, справа налево (терминальным – отделяющим адрес сервера от других элементов URL – тут является правый символ '/'). То есть, с точки зрения компьютера, вся строка адреса, начинающаяся с www.twitter.com, представляет собой адрес внутри домена ffghfs.com – а это никакой не «Твиттер»!
Беда в том, что о реальных свойствах и правилах «синтаксического разбора» интернет-адресов компьютерами знают только специалисты. Пользователи же вынуждены доверять своему «наивному сознанию».
Фишеры атакуют все функции, касающиеся работы пользователя с интернет-адресами. Так, пользователям свойственно вводить адреса сайтов – имена доменов, вручную набирая их в адресной строке браузера. При этом пользователь может сделать опечатку. За «доменами-опечатками» охотятся не только так называемые тайп-сквоттеры, но и фишеры.
Некоторые владельцы раскрученных торговых марок и посещаемых ресурсов щепетильно относятся к «доменам-опечаткам», заранее регистрируя их на себя. Другие, видимо, из-за недопонимания проблемы упускают момент, отдавая «опечатки» охотникам за доменами. Уходят «домены-опечатки» даже от известных ИТ-компаний, чей бизнес прямо связан с Интернетом. Например, в управлении у российской компании «1С-Битрикс» находится домен bitrix.ru, под которым размещен сайт известной в Рунете коммерческой системы управления сайтами (CMS) «Битрикс». При этом очевидный «домен-опечатка» biRTix.ru (из-за особенностей зрительного восприятия текста при беглом чтении этот домен неотличим от оригинала; «перестановка» специально выделена заглавными буквами) управляется вовсе не «1С-Битрикс» (по состоянию на 2013 год). Другой пример: компания «Яндекс» запустила сервис для веб-мастеров под доменом webmaster.yandex.ru. Менеджеры компании, прежде чем публично объявлять о запуске нового сервиса, не позаботились о перехвате «тайпсквоттерских» доменов. В результате очевидное доменное имя с опечаткой webmasteryandex. ru (без точки) оказалось под управлением опытных домейнеров.
Рост тайпсквоттерской активности в приобретении доменов наблюдается регулярно, как только какой-то новый (или не очень новый) интернет-проект вдруг обретает большую популярность. Например, как только в 2006–2007 годах набрал популярность проект «Одноклассники», размещенный под доменом odnoklassniki.ru, тут же началась регистрация десятков «доменов-опечаток», например odnoklasniki.ru, odnolkassniki.ru, ondoklassniki.ru и т. п.
Все эти опечатки могут так или иначе использоваться фишерами. Не обязательно для прямых атак. Возможны многоступенчатые схемы: сначала пользователя заманивают на «домен-опечатку», выдавая размещенный там поддельный сайт за настоящий; далее пользователю предлагают перейти по той или иной ссылке, ведущей на внешний ресурс. Поскольку пользователь полагает, будто находится на сайте известной ИТ-компании, ему будет значительно легче «обмануться» и, особенно не задумываясь, перейти по рекомендуемой ссылке на ресурс фишера, например изображающий официальный интернет-магазин той самой ИТ-компании.
Администратор домена должен принимать во внимание элемент подделки сайтов, особенно если речь идет о работе с важной пользовательской информацией, применять специальные дополнительные средства авторизации, позволяющие посетителю проверить достоверность сайта. Тем более что такие средства есть. Это системы SSL-сертификатов. SSL-сертификаты, используя криптографические методы, позволяют браузеру клиента проверить с привлечением независимых центров доверия, что сайт, с которым браузер соединяется, действительно является тем, за который себя выдает, и размещен под указанным в адресной строке доменом.
Рассмотрение систем подобной сертификации сайтов выходит за рамки данной книги. Отмечу только, что сертификат должен быть размещен вместе с защищаемым сайтом, а процедура генерации сертификата должна сделать его копирование весьма затруднительным (можно сказать, нереальным) для злоумышленников. Впрочем,
SSL-сертификаты лишь затрудняют деятельность по введению посетителей атакуемого сайта в заблуждение, но не делают ее невозможной.
Введение в строй многоязычных доменов, например кириллического домена РФ, создает новое пространство и для злоумышленников, которые обязательно начнут использовать особенности новых имен.
Для борьбы с самым очевидным вариантом фишинга, со смешением графически идентичных букв латиницы и кириллицы (типа буквы «эр» и буквы p – «пи»), в домене РФ запрещают использование латиницы вообще. Это очень разумно.
Но, как мы разобрались ранее, для кодирования отличных от латинской азбуки символов в имена, допустимые для DNS, используется специальный алгоритм Punycode. На вход этого алгоритма могут подаваться произвольные символы Unicode, а на выходе получается строка из латинских букв, дефисов и цифр (есть и обратное преобразование).
Кириллические домены верхнего уровня – это домены верхнего уровня. Но никто не запрещает использовать многоязычные имена в других доменных зонах, третьего уровня, скажем, и ниже. Punycode здесь также работает, а ограничения регистраторов доменов на смешивание символов нет. В большинстве случаев, практически важных для фишеров, преобразование алфавитов осуществляют браузеры. От введения дополнительного слоя преобразований безопасность пользователя в данном случае не может улучшиться, это очевидно. Ожидать, конечно, нужно и дыр в реализациях преобразований Punycode. Но с появлением и распространением домена РФ важнее умелое использование этих технологий в других доменных зонах.
В 2009 году я провел эксперимент, создав доменное имя, закодированное вот такими «кракозябрами»: xn-80adjurfhd. xn-click-uye2a8548c.dxdt.ru, что в перекодированном по таблицам Unicode виде смотрится так: проверка. рф?click. dxdt.ru. Здесь для имитации слеша использован специальный символ из таблиц Unicode с кодом 0х2044 (математический «знак деления»). Итоговый URL может быть вот таким: http://проверка. рф?click.dxdt.ru/ – мимикрия под проверка. рф, при этом реально домен находится в зоне. dxdt.ru, которой управляю я. Отличить сложно. Во многих браузерах в 2009–2010 годах – успешно работало. Правда, в 2010 году, например, в браузере Opera работа со смешанными многоязычными адресами уже была скорректирована и при переходе по данному URL выдавалась ошибка «Invalid URL», что неплохо. Позже подоспели и другие браузеры – Firefox, IE, Chrome, – исправив отображение подобных URL. Понятно, что на практике фишеры вместо проверка. рф могли использовать другие варианты исходных доменов, какие-нибудь известные бренды или названия банков.
У эксперимента с проверка. рф есть и второй результат: до сих пор, даже в начале 2014 года, ссылка на мою тестовую страницу выдается поисковой системой Google на первом месте по запросу «проверка. рф» (именно этого эффекта я и хотел добиться). При этом адрес в тизере поисковика (см. скриншот) выглядит просто идеально.
Читатель спросит: ну и что с того, что на первом месте? Подумаешь, поисковый запросто не самый, как говорится, интересный! Но дело в том, что очень многие пользователи Сети вводят адреса сайтов не в адресной строке браузера, а строке запроса поисковика. После чего просто переходят по первой ссылке. То есть в данном случае поисковик помог создать идеальную видимость работы домена проверка. рф в то самый момент, когда и самого домена РФ еще не было в DNS (я затеял этот небольшой опыт в ноябре 2009 года). Надо сказать, что демонстрация эффекта даже на бывалых системных администраторов производила впечатление: «Постой, постой! А как это? Не может быть!» – спрашивали они; и лишь через пару минут, поизучав ситуацию, понимали, что к чему. Что уж ожидать от рядовых пользователей. Так что в связи с появлением многоязычных доменов нас, к сожалению, ждет новый всплеск оригинального доменного фишинга.
В заключении этой главы еще раз подчеркну, что существенным подспорьем в решении проблем безопасности, очень актуальных для банковских сайтов и сайтов платежных систем, является заблаговременная регистрация всевозможных «доменов-опечаток».
Оглавление книги
