Что такое dns spoofing. Пишем плагин к Microsoft DNS server для защиты от IDN spoofing. IDN Clones - техника, основанная на внешнем сходстве отображения доменных имен

Оригинал: Cyber Attacks Explained: DNS Invasions
Автор: Prashant Phatak
Дата публикации: 22 февраля 2012 г.
Перевод: А.Панин
Дата перевода: 8 декабря 2012 г.

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

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

Рисунок 1 отражает фундаментальные принципы работы службы разрешения сетевых имен. Когда приложение (такое, как браузер) хочет установить соединение с удаленной службой, оно совершает запрос IP-адреса у DNS-сервера. Этот запрос в форме пакета отправляется через порт UDP номер 53, после чего сервер возвращает ответ в форме пакета. (Следует помнить о том, что по причине ограничения размера данных в UDP-дейтаграмме 512 байтами, стек протоколов автоматически использует протокол TCP для осуществления запросов и приема ответов.) Когда клиент принимает ответ, он добавляет данные в свой локальный кэш, что позволяет ускорить последующие обращения к этому же домену. Элементы локального кэша автоматически уничтожаются после истечения их времени жизни (параметр TTL (Time to Live)).

Рисунок 1: Разрешение доменных имен

Система DNS использует такие типы записей, как A, CNAME, SOA, MX и другие. Хотя описание этих типов записей и выходит за рамки данной статьи, системным администраторам важно знать о том, когда и как их следует использовать, а перед их использованием должно проводиться исследование с точки зрения будущей безопасности системы. Перед тем, как рассмотреть атаки на систему DNS, нам необходимо рассмотреть два типа запросов - итерационные и рекурсивные.

• Итерационные запросы DNS : В то время, как клиент отправляет запрос DNS-серверу, желая получить информацию о домене, DNS-сервер может как располагать, так и не располагать информацией об этом домене. Если у DNS-сервера нет ответа, вместо завершения запроса, он отправляет имя высшего DNS-сервера, у которого может быть в распоряжении необходимая информация, клиенту. Обычно этот процесс называют перенаправлением DNS-запросов (DNS referral). Клиент отправляет запрос следующему (указанному) серверу; если у него нет ответа, он отправляет клиенту имя высшего сервера. Этот процесс продолжается до тех пор, пока клиент получает или IP-адрес, или сообщение об ошибке о невозможности выполнения запроса.
• Рекурсивные запросы DNS : В этом случае процесс начинается с того, что клиент производит запрос разрешения имени домена напрямую к DNS-серверу. Если у DNS-сервера нет ответа, предполагается, что он выполнит работу по обмену данными с высшими серверами вместо того, чтобы просто предоставить их имена клиенту. Снова, если высший сервер не обладает информацией для ответа на запрос, он переадресует запрос высшему серверу. Этот процесс продолжается до тех пор, пока запрос не доходит до корневого DNS-сервера, который должен обладать необходимой информацией и клиенту возвращается ответ, а в случае, если запрошенного имени не существует, клиенту возвращается сообщение об ошибке по цепочке серверов. В отличие от итерационного метода, рекурсивный запрос считается более агрессивным в получении результата.

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

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

Атаки на системы DNS

Было замечено, что системные администраторы тратят много времени на разработку систем безопасности для приложений, серверов и других компонентов инфраструктуры, но, к сожалению, имеют склонность забывать о системах безопасности для DNS-серверов. Рассмотрите рисунок 2, на котором показаны возможные слабые места DNS-серверов, которые делают делают их уязвимыми к атакам. Система DNS спроектирована таким образом, что большая часть обмена данными происходит по протоколу UDP, в ней не предусмотрено встроенной системы безопасности и нет встроенной поддержки аутентификации - все это делает ее более уязвимой к атакам, чем другие сетевые службы. Давайте рассмотрим несколько типов наиболее распространенных атак на DNS.

Рисунок 2: Возможные слабые места DNS-серверов

Модификация кэша DNS (DNS cache poisoning)

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

Например, если браузер пытается получить доступ к сайту с адресом http://www.cnn.com/, вместо IP-адреса CNN он получает адрес, установленный программным обеспечением взломщика, который обычно ведет на сайт, расположенный на сервере, принадлежащем взломщику, и содержащий вредоносное программное обеспечение или оскорбляющее пользователя сообщение.

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

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

Подмена DNS-сервера (DNS hijacking)

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

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

Спуфинг DNS-запросов (DNS spoofing)

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

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

Существует альтернативный способ этой атаки, называемый спуфингом идентификаторов DNS-запросов (DNS ID spoofing). Каждый DNS-запрос и ответ имеют уникальные идентификаторы, предназначенные для того, чтобы разделить между собой запросы, направленные DNS-серверу в одно и то же время. Эти уникальные идентификаторы зачастую формируются из MAC-адреса, даты и времени осуществления запроса и создаются стеком протоколов автоматически.

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

Перезакрепление DNS (DNS rebinding)

Эта атака также имеет название "закрепление DNS" ("DNS pinnig") и является особо сложной атакой. В ходе нее взломщик сначала регистрирует свое собственное доменное имя, затем устанавливает минимальное значение времени жизни записей, которое предотвращает попадание информации об этом доменном имени в кэш.

Атаки отказа в обслуживании в отношении DNS (DNS denial of service)

Как мы узнали из первой статьи серии, бомбардировка потоком UDP- или TCP-пакетов порта 53 с запросами может привести сервер к отказу в обслуживании. Другим методом проведения этой атаки является атака потоком пинг-пакетов или TCP SYN-сегментов. Главной идеей, стоящей за этими действиями, является максимальное использование ресурсов сервера (центрального процессора и оперативной памяти) для того, чтобы сервер перестал отвечать на запросы. Хотя DNS-сервера и защищаются межсетевыми экранами, в том случае, если UDP-порты DNS не заблокированы для доступа из недоверенных сетей, система разрешения доменных имен становится доступной для данного типа атак.

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

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

При другом типе данной атаки взломщик модифицирует кэш сервера DNS; вместо замены IP-адресов, соответствующих записям A или CNAME, модификации подвергаются доменные имена. Для усложнения ситуации длина каждого доменного имя может достигать нескольких сот или тысяч символов. Процесс синхронизации данных, начинающийся после внесения изменений, заключается в отправке множества килобайт данных с главного сервера имен нижестоящим серверам и в конце концов клиентам.

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

Защита систем на основе свободного программного обеспечения

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

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

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

Часто случается такое, что уязвимость в сторонней программе позволяет совершить проникновение на сервер разрешения имен. Хотя наиболее важные части сетевой инфраструктуры и защиены межсетевым экраном, унифицированными устройствами контроля (Unified Threat Management) и мощными антивирусными программами, часто необхдимо усилить защиту системой обнаружения проникновений (Intrusion Detection System). Она позволяет отражать атаки 2 и 3 уровней OSI, такие, как ARP-спуфинг, IP-спуфинг, атаки с использованием сниффера и другие типы атак.

Кроме важнейших мер предосторожности, описанных выше, существует несколько сложных методов, которые тоже следует применить. Как мы узнали ранее, каждый запрос имеет свой уникальный идентификатор и отправляется в UDP-пакете. К сожалению, из за особенностей проектирования стека DNS, описанных в стандартах RFC, эти идентификаторы легко предсказуемы, поэтому использование случайных чисел для формирования идентификаторов является хорошей идеей, помогающей предотвратить спуфинг-атаки. Аналогично,номер UDP-порта, на котором сервер разрешения имен принимает запросы и отвечает, также легко предсказуем и может быть изменен на случайно выбранный.

Для этих целей существуют программы с открытым исходным кодом, но при их использовании следует помнить, что они вносят небольшую временную задержку в процесс обработки запроса. Относительно новой и популярной технологией защиты является DNSSEC (Расширения безопасности DNS (DNS Security Extensions)). Она защищает клиенты и сервера от атак, при которых модифицируется кэш DNS, подписывая записи с использованием шифрования с открытым ключом. Работая аналогично SSL, запрашивающая данные и отвечающая стороны устанавливают доверенное соединение друг с другом, а как только оно установлено, начинается процесс разрешения имен.

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

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

Эта статья входит в серию статей о кибератаках, написанных тем же автором (Prashant Phatak). Другие статьи этой серии.

Подмена DNS (DNS Spoofing)

Система DNS (Domain Name System ) преобразует доменное имя (например, www.test.com) в его IP-адрес (например, 192.168.0.1) и наоборот. Данная атака использует технологию отправки фальшивых ответов на DNS-запросы жертвы. Атака основывается на двух основных методах.

Подмена DNS ID (DNS ID Spoofing)

Заголовок пакета DNS-протокола содержит идентификационное поле для соответствия запросов и ответов. Целью подмены DNS ID является посылка своего ответа на DNS-запрос до того, как ответит настоящий DNS-сервер. Для выполнения этого, нужно спрогнозировать идентификатор запроса. Локально это реализуется простым прослушиванием сетевого трафика. Однако, удаленно выполнить эту задачу гораздо сложнее. Существуют различные методы:

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

посылка нескольких сотен DNS-запросов в правильном порядке. Очевидно, что этот метод не очень надежен;

нахождение сервера, генерирующего прогнозируемые идентификаторы (например, увеличивающиеся на 1). Этот тип уязвимости присущ некоторым версиям Bind и системам Windows 9x.

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

Для проведения успешной атаки, злоумышленник должен контролировать DNS-сервер (ns.attaquant.com), авторитетный для зоны attaquant.com . Целевой DNS-сервер (ns.cible.com) предположительно генерирует прогнозируемые идентификационные номера (увеличивающиеся на 1 при каждом запросе).

Атака требует выполнения четырех шагов:

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

Изменение DNS Cache Poisoning

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

Используем те же данные, что и в предыдущем примере. Вот ключевые моменты этого варианта атаки:

послать DNS-запрос на разрешение имени www.attaquant.com DNS-серверу домена cible.com ;

целевой DNS-сервер шлет запрос на разрешение имени www.attaquant.com DNS-серверу злоумышленника;

DNS spoofing - это простой метод обмана dns системы, блок преобразования имён dns, использующий ложную информацию, полученную от хоста, который - не отвечает за ту информацию. Каждый пакет dns имеет 16 битный id номер, id номер это чась dns пакета которая разрешает идентифицировать каждый dns пакет, который идёт через порт 53 и так же запрос может быть больше чем один раз. id это единственный способ различить различные запросы dns, связанный с этим, которое серверы dns используют, чтобы определить каков первоначальный был запрос. В случае BIND, этот номер увеличивается на 1 уровень для каждого запроса. Нападение, подобное TCP seq id может быть сделано, хотя это более трудней. Даже если BIND не может кэшировать информацию которую вы посылаете, он передаст ответ к оригинальному хосту. В случае ircd сделает запрос на PTR в ответ к хосту, соединяющемуся с ним, пакет ответа может быть сформулирован, чтобы содержать дополнительную информацию, из которой ircd будет делать внутреннее кэширование. Для этой атаки нужен доступ root"a на сервере dns, ответственном за in-addr. arpa блок информации dns. Также, ircd может кэшировать только один домен. Существует ещё одна атака, т. к. id состоит из 16 битов. Пользователь смог бы перебрать весь idspace. Для того чтобы подделать свой dns допустим на DALNet"e, нужно послать 65000 сгенерированных запросов на ns сервер, как только компьютер получает ответ на запрос, нужно будет прочитать пакет, и в нём будет написан правильный id. Как только получите id, нужно найти какой ни буть "packet creation tool" чтобы сделать dns пакет. Остается только подделать dns пакеты, послать на ns. dal. net и получаете spoofing TCP соединение.

Общая постановка проблемы В связи с бурным ростом сети Internet, проблема защиты информационных ресурсов ставиться все более значимой. Если вы подключены к Internet, ваша система может быть атакована. Рассмотрим работу DNS. Внешнесегментная адресация осуществляется по IP-адресам, но обращения к серверам, как правило, осуществляется по доменным именам. В этой связи была создана система преобразования (сопоставления) доменных имен в IP адреса – DNS-серверов (Domain Name System). Эта система отвечает за нахождение IP-адреса удалённого хоста по его имени. Принцип функционирования DNS системы следующий – удаленный хост посылает на IPадрес ближайшего DNS-сервера специальный запрос, в котором указывает имя сервера, IP-адрес которого необходимо найти. Получив запрос, DNS-сервер просматривает свою базу данных на наличие запрашиваемого доменного имени. В случае если имя найдено, DNS-сервер возвращает ответ, в котором указывает искомый IP-адрес. В случае если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то DNS-запрос отсылается DNS-сервером на один из корневых DNS-серверов и описанная в этом пункте процедура повторяется, пока имя не будет найдено. Рассмотрим обобщенную схему работы ложного DNS - сервера: ожидание DNS-запроса; получив DNS-запрос, извлечение из него необходимых сведений и передача по сети на запросивший хост ложного DNS-ответа, от имени (с IP-адреса) настоящего DNS-сервера, в котором указывается IP-адрес ложного DNS-сервера; в случае получения пакета от хоста, изменение в IPзаголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на сервер (то есть, ложный DNS-сервер ведет работу с сервером от своего имени); в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на хост (для хоста ложный DNS-сервер и есть настоящий сервер).

Необходимым условием осуществления данного варианта атаки является перехват DNS-запроса. Это возможно только в том случае, если атакующий находится либо на пути основного трафика либо в сегменте настоящего DNS-сервера. Выполнение одного из этих условий местонахождения атакующего в сети делает подобную удаленную атаку трудно осуществимой на практике (попасть в сегмент DNS-сервера и тем более в межсегментный канал связи атакующему скорее всего не удастся). Однако в случае выполнения этих условий возможно осуществить межсегментную удаленную атаку на сеть Internet. Результатом данной атаки является внесение навязываемого соответствия между IP адресом и доменным именем в кэш DNS сервера. В результате успешного проведения такой атаки все пользователи DNS севера получат неверную информацию о доменных именах и IP адресах. Данная атака характеризуется большим количеством DNS пакетов с одним и тем же доменным именем. Это связано с необходимостью подбора некоторых параметров DNS обмена.

Как показывает анализ существующих приемов защиты, противодействие атакам может осуществляться следующими методами. Путем перевода работы DNS на работу по протоколу TCP Переход от UDP к TCP несколько замедлит систему. При использовании ТСР требуется создание виртуального соединения, а так же стоит учесть, что, конечные сетевые ОС вначале посылают DNSзапрос с использованием протокола UDP и в том случае, если им придет специальный ответ от DNSсервера, то тогда сетевая ОС пошлет DNS-запрос с использованием ТСР. Использование протокола ТСР усложнит атаку путем подмены пакетов, но замедлит работу. Путем анализа DNS трафика. Противодействовать атакам можно путем анализа трафика. На DNS-сервер постоянно посылаются ложные пакеты с ложными IP адресами. Если полученный ложный пакет совпал по значениям с запросом, то ложный IP принимается как истинный. Если перехвата пакета от сервера не произошло, то атака характеризуется большим количеством DNS пакетов с одним и тем же именем. Это связано с необходимостью подбора некоторых параметров DNS обмена. Анализируя DNS трафик можно игнорировать такие пакеты, что бы избежать подмены IP адреса.

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

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

Как работает спуфинг?

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

Как распознать спуфинг?

Наиболее просто распознать email-спуфинг вследствие того, что непосредственной мишенью является сам пользователь. Любое сообщение эл. почте, в котором от пользователя требуется личная информация, может быть попыткой спуфинга, в особенности, если запрашиваются учетные данные. Запомните, ни одна надежная частная или государственная организация не запрашивает персональные данные таким путем. Обратите внимание на адрес отправителя, чтобы убедиться в его легитимности. Тем не менее, пользователь практически никогда не узнает, что он стал жертвой IP или DNS-спуфинга, хотя привычка обращать пристальное внимание на детали и изменения привычного поведения сайта могут оказаться чрезвычайно полезны. Если сайт или его поведение вызывают малейшее сомнение, лучше отказаться от совершения запланированной операции, чтобы сохранить данные и финансовые средства в безопасности.

Как устранить спуфинг?

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

Как предупредить спуфинг

• Не отвечайте на сообщения, в которых вас просят прислать свои персональные или учетные данные
• Внимательно проверяйте адрес отправителя
• Обращайте внимание на странности в поведении или отличия в деталях привычных вам сайтов

Обезопасьте себя от спуфинга

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

Спуфинг довольно интересный метод атак, которым многие профессионалы в области ИБ пренебрегают. А зря, очень даже зря. Из данной статьи ты поймешь, насколько обманчив может быть этот многообразный мир. Не верь своим глазам!

WARNING

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

Intro

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

Прошлое и настоящее спуфинга

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

Первые IDN-клоны

Атаку с использованием IDN-омографов впервые описали в 2001 году Евгений Габрилович и Алекс Гонтмахер из израильского технологического института Технион. Первый известный случай успешной атаки, использующий данный метод, был предан огласке в 2005 году на хакерской конференции ShmooCon. Хакерам удалось зарегистрировать подставной домен pаypal.com (xn--pypal-4ve.com в Punycode), где первая буква а - кириллическая. Благодаря публикации на Slashdot.org к проблеме было привлечено внимание общественности, после чего как браузеры, так и администраторы многих доменов верхнего уровня выработали и реализовали контрмеры.

Итак, когда Сеть только зарождалась, большинство усилий программистов и разработчиков были направлены в основном на оптимизацию алгоритмов работы сетевых протоколов. Безопасность не была настолько критичной задачей, как сегодня, и ей, как часто это бывает, уделяли очень мало внимания. Как результат, получаем банальные и фундаментальные ошибки в сетевых протоколах, которые продолжают существовать и сегодня, несмотря на различного рода заплатки (ибо никакой заплатой не залатать логическую ошибку протокола). Здесь необходимы тотальные изменения, которые Сеть в существующем представлении просто не переживет. Например, в статье «Атаки на DNS: вчера, сегодня, завтра» (][#5 2012) я рассказывал о приводящих к катастрофическим последствиям фундаментальных уязвимостях в DNS-системах - использовании протокола UDP (который, в отличие от TCP/IP, является небезопасным, так как в нем отсутствует встроенный механизм для предотвращения спуфинга) и локального кеша.

Векторы

В зависимости от целей и задач векторы спуфинга можно разделить по направлениям на локальные (local) и сетевые (net). Именно их мы и рассмотрим в этой статье. В качестве объекта атак при локальном векторе чаще всего рассматривается непосредственно сама ОС, установленная на компьютере жертвы, а также определенного рода приложения, которые зачастую требуют дополнительного анализа в зависимости от ситуации. Объекты атак при сетевом векторе, напротив, более абстрагированны. Основными из них являются компоненты информационных систем, представленных как локальными, так и глобальными сетями. Рассмотрим основные виды спуфинга.

Spoofing TCP/IP & UDP - атаки на уровне транспорта. Из-за фундаментальных ошибок реализации транспорта протоколов TCP и UDP возможны следующие типы атак:

• IP spoofing - идея состоит в подмене IP-адреса через изменение значения поля source в теле IP-пакета. Применяется с целью подмены адреса атакующего, к примеру, для того, чтобы вызвать ответный пакет на нужный адрес;
• ARP spoofing - техника атаки в Ethernet-сетях, позволяющая перехватывать трафик между хостами. Основана на использовании протокола ARP;
• DNS Cache Poisoning - отравление DNS-кеша сервера;
• NetBIOS/NBNS spoofing - основана на особенностях резолва имен локальных машин внутри сетей Microsoft.

Referrer spoofing - подмена реферера.

Poisoning of file-sharing networks - фишинг в файлообменных сетях.

Caller ID spoofing - подмена номера звонящего телефона в VoIP-сетях

E-mail address spoofing - подмена адреса e-mail отправителя.

GPS Spoofing - подмена пакетов со спутника с целью сбить с толку GPS-устройство.

Voice Mail spoofing - подмена номеров голосовой почты с целью фишинга паролей жертвы.

SMS spoofing - метод спуфинга, основанный на подмене номеров отправителя SMS-сообщения.

Новейшие наработки в области спуфинга

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

Flamer и скандальный спуфинг сертификатов Microsoft

Microsoft Security Advisory (2718704) - Unauthorized Digital Certificates Could Allow Spoofing. Довольно интересная вещь была найдена в экземплярах нашумевшего шпионского бота Flamer: по результатам реверс-инжиниринга компонентов этого зловреда был обнаружен участок кода, отвечающий за проведение спуфинг-атак типа фишинг. Имитируя предоставление оригинальных сертификатов крупных компаний, бот проводил MITM-атаку, целью которой был перехват персональных данных пользователей корпоративной сети с последующей отправкой на сервер разработчиков. Этот спуфинг-инцидент получил Security Advisory #2718704 с рангом опасности High.

Спуфинг в ОС 1. Extension Spoofing - спуфинг расширения файла

Техника, увидевшая свет благодаря наработкам китайского исследователя в области информационной безопасности Zhitao Zhou. Суть данной техники заключается в использовании управляющего символа 0x202E (RLO) в имени файла, что позволяет изменить порядок символов при отображении названия файла в проводнике Windows (explorer.exe). Приведу пример использования этой простой техники:

Super music uploaded by 3pm.SCR

Файл 3pm.SCR представляет собой не что иное, как исполняемый файл, реализующий определенные функции (троянская программа. - Прим. редактора). Если в начале имени файла «3pm.SRC» вставить управляющий символ 0x202E (см. рис. 1), то порядок символов меняется на обратный и имя файла отображается в проводнике Windows уже иначе:

Super music uploaded by RCS.mp3

Для изменения иконки файла следует использовать любой редактор ресурсов (Restorator, Resource Hacker). Данная техника рассчитана на неосторожного пользователя, который может принять этот файл за песню и открыть двойным щелчком, тем самым запустив зловредную программу. К сожалению, данная техника не будет работать в программах - аналогах проводника, поддерживающих Юникод. Ниже приведен код на C#, который выполняет изменение имени файла, добавляя в начало управляющий символ 0x202E:

Public Sub U_202E(file As String, extension As String) Dim d As Integer = file.Length - 4 Dim u As Char = ChrW(823) Dim t As Char() = extension.ToCharArray() Array.Reverse(t) Dim dest As String = file.Substring(0, d) & u & New String(t) & file.Substring(d) System.IO.File.Move(file, dest) End Sub

2. File Name Spoofing - клонирование имени файла

Данная техника была представлена японским исследователем Yosuke Hasegawa на конференции Security-Momiji. Она основана на использовании символов нулевой длины (ZERO WIDTH Characters), которые никак не влияют на отображение названия файла (см. рис. 2). Ниже приведены все символы из этой категории:

U+200B (ZERO WIDTH SPACE) - U+200C (ZERO WIDTH NON-JOINER) - U+200D (ZERO WIDTH JOINER) - U+FEFF (ZERO WIDTH NO-BREAK SPACE) - U+202A (LEFT-TO-RIGHT EMBEDDING)

Помимо этого возможно использовать кодировку UTF для фальсификации имен существующих файлов. Данную технику часто применяет современная малварь. В поле моего зрения попадались образцы вредоносов, которые проводили такого рода атаки. К примеру, зловред TrojanDropper:Win32/Vundo.L (использовался для фишинга сайтов vk.com, vkontakte.ru, *odnoklassniki.ru) задействует именно эту технику.

Файл %SystemRoot%\system32\drivers\etc\hosts копировался в файл-«клон» hosts с UTF-символом «о» (0х043E), после чего оригинальному файлу hosts придавался атрибут скрытого файла и его содержимое перезаписывалось с добавлением следующих записей:

92.38.66.111 odnoklassniki.ru 92.38.66.111 vk.com 92.38.66.111 vkontakte.ru

Спуфинг веб-браузеров 1. Status bar / Link spoof

Принцип данной атаки заключается в динамической подмене адреса гипертекстовой ссылки (). К примеру, жертва наводит курсор мыши на ссылку, после чего в статусбаре браузера отображается адрес, по которому ведет данная ссылка. После клика на ссылку хитрый JavaScript-код подменяет в динамике адрес перехода. Мой знакомый исследователь, известный под ником iamjuza, занимался изучением и разработкой PoC для эксплуатации данной техники на практике, но его разработки не были универсальны и действовали только на конкретных браузерах. Проведя аналогичное исследование, я получил более удачные результаты, сумев добиться универсальности эксплуатации этой техники спуфера для всех браузерных движков. Proof-of-Concept опубликован на ресурсе 1337day.com . Техническая реализация выглядит следующим образом:

Method this.href=" :