Актуальные методы спуфинга в наши дни. Атака DNS Spoofing DNS spoofing — это Защита от днс спуфинг

IDN spoofing - это генерация доменных имён «похожих» на выбранное, обычно применяемая с целью заставить пользователя перейти по ссылке на ресурс злоумышленника. Далее рассмотрим более конкретный вариант атаки.

Представим, что атакуемая компания владеет доменом organization.org, и внутри этой компании используется внутренний ресурс portal.organization.org. Цель злоумышленника -получить учётные данные пользователя, и для этого он присылает ссылку через e-mail или используемый в компании мессенджер.

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

Абсолютной «защиты от дурака» тут придумать не получится, но можно пробовать перехватить эту атаку на этапе разрешения имени через dns-запрос.

Для защиты нам понадобится последовательно запоминать встречаемые имена в перехваченных dns-запросах. В компании пользуются её внутренними ресурсами, значит мы достаточно быстро обнаружим в запрос на portal.organization.org. Как только мы встретили имя «похожее» на ранее встречавшееся, мы может подменить dns-ответ, вернув ошибку вместо ip-адреса атакующего.
Какие могут быть алгоритмы определения «похожести»?

UTS39 Confusable Detection (http://www.unicode.org/reports/tr39/#Confusable_Detection) Юникод - это не только ценный мех таблица символов, но ещё и куча стандартов и рекомендаций. В UTS39 определен алгоритм нормализации unicode строки, при котором строки, отличающиеся омоглифами (например русская „а“и латинская „a“) будут приведены к одинаковой форме
Слова отличающиеся перестановками внутренних букв. Довольно легко спутать organization.org и orgainzation.org
Замена домена первого уровня. Первый уровень имени обычно не несёт никакого смысла и сотрудник компании увидев «organization» может проигнорировать разницу в.org или.net, хотя тут возможны исключения

Вероятнее всего корпоративным сервером будет не bind, который стандарт скорее для web-хостеров или провайдеров, а microsoft dns server из-за повсеместного использования active directory. И первая проблема, с которой я столкнулся при написании фильтра к microsoft dns server – API для фильтрации dns-запросов я не нашёл. Эту проблему можно решать разными способами, я выбрал инжект dll и IAT хук на api работы с сокетами.

Для понимания методики будет необходимо знание PE-формата, подробнее можно прочитать, например, . Исполняемый файл состоит из заголовков, таблицы секций и самих секций. Сами секции – это блок данных, который загрузчик должен отобразить в память по относительному адресу (Relative Virtual Address – RVA), и все ресурсы, код, прочие данные содержатся внутри секций. Также внутри заголовка присутствуют ссылки (RVA) на ряд необходимых для работы приложения таблиц, в рамках этой статьи будут важны две –таблица импорта и таблица экспорта. Таблица импорта содержит список функций, которые необходимы для работы приложения, но находятся в других файлах. Таблица экспорта – это «обратная» таблица, в которой содержится список функций, которые экспортируются из этого файла, либо, в случае export forwarding, указывается имя файла и имя функции для разрешения зависимости.

Инжект dll будем делать без всем надоевшего CreateRemoteThread. Я решил использовать PE export forwarding – это давно известный приём, когда для того, чтобы загрузится в нужный процесс, в каталоге с exe-файлом создаётся dll с именем равным имени любой dll из таблицы импорта exe-файла (главное не использовать HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs). В созданной dll копируется таблица экспорта из целевой dll, но вместо указателя на код экспортируемой функции, нужно записать RVA на forward-строку вида «endpoint!sendto». Сам microsoft dns server реализован в виде сервиса HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS, который находится в %systemroot%\system32\dns.exe

Итоговый алгоритм инжекта в dns сервер будет таким:

Создаём каталог %systemroot%\system32\dnsflt (можно любой другой, нахождения каталога именно в system32 необязательно).
Копируем туда %systemroot%\system32\dnsapi.dll – это dll из которой dns.exe что-то импортирует, можно выбрать любую другую “не knowndll”.
Переименовываем скопированную dll в endpoint.dll - это имя будем использовать в forward-строке.
Берём нашу инжектируемую dll и дописываем в неё правильную таблицу экспорта, копируем нашу dll в %systemroot%\system32\dnsflt
В реестре в ключе HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS меняем в ImagePath новый адрес бинарника %systemroot%\system32\dnsflt\dns.exe
Создаём симлинк из %systemroot%\system32\dnsflt\dns.exe в %systemroot%\system32\dns.exe

А зачем последний шаг? Дело в том, что в windows есть встроенный firewall, и, по умолчанию, в windows server право слушать 53 порт есть только у приложения %systemroot%\system32\dns.exe. При попытке запустить его из другого каталога прав на доступ к сети не будет. А зачем я его вообще копировал? Для того, чтобы минимизировать воздействие на всю систему и не трогать оригинальный dnsapi.dll. Получается, что если уметь создавать symlink на приложение, то можно получать его сетевые права. По умолчанию, права на создание symlink есть только у администраторов, но достаточно неожиданно обнаружить, что выдав пользователю право на создание symlink, ты даёшь ему возможность обходить встроенный firewall.

После того как загрузились внутрь процесса из DllMain, можно будет создать поток и установить перехват. В самом простом случае наш dns сервис будет сообщать клиенту ip-адрес для имени через отправку UDP-пакета с 53 порта через фукнцию sendto из ws2_32.dll. Стандарт предполагает возможность использования 53 TCP-порта, если ответ слишком большой, и очевидно, что перехват sendto в этом случае будет бесполезен. Однако, обработать случай с tcp хоть и более трудоёмко, но можно аналогичным способом. Пока расскажу самый простой случай с UDP. Итак, мы знаем, что код из dns.exe импортирует из ws2_32.dll функцию sendto и будет использовать её, чтобы ответить на dns-запрос. Для перехвата функций тоже достаточно много разных способов, классический это сплайсинг, когда первые инструкции sendto заменяются на jmp в свою функцию, а после её завершения осуществляется переход на сохранённые ранее инструкции sendto и далее внутрь функции sendto. Сплайсинг будет работать даже если для вызова sendto будет использован GetProcAddress, а не таблица импорта, но если используется таблица импорта, то вместо сплайсинга проще использовать IAT-хук. Для этого нужно найти в загруженном образе dns.exe таблицу импорта. Сама таблица имеет несколько запутанную структуру и за деталями придётся ходить в описание PE формата.

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

Итак, мы установили перехват и начали получать данные. Прототип функции sendto выглядит так:

Int sendto(_In_ SOCKET s, _In_ const char *buf, _In_ int len, _In_ int flags, _In_ const struct sockaddr *to, _In_ int tolen);
Если s – это сокет на 53 порту, то по указателю buf будет лежать dns-ответ размером len. Сам формат описан в RFC1035 , я кратко опишу, что нужно сделать, чтобы добраться до интересующих данных.

Структура сообщения в стандарте описана так:

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

Struct DNS_HEADER { uint16_t id; // identification number uint8_t rd: 1; // recursion desired uint8_t tc: 1; // truncated message uint8_t aa: 1; // authoritive answer uint8_t opcode: 4; // purpose of message uint8_t qr: 1; // query/response flag uint8_t rcode: 4; // response code uint8_t cd: 1; // checking disabled uint8_t ad: 1; // authenticated data uint8_t z: 1; // its z! reserved uint8_t ra: 1; // recursion available uint16_t q_count; // number of question entries uint16_t ans_count; // number of answer entries uint16_t auth_count; // number of authority entries uint16_t add_count; // number of resource entries };
Секцию Question придётся разобрать для того, чтобы добраться до Answer. Сама секция состоит из такого количества блоков, которое указано в заголовке (q_count). Каждый блок состоит из имени, типа и класса запроса. Имя закодировано в виде последовательности строк, каждая из которых начинается с байта с длиной строки. В конце находится строка нулевой длины. Например, имя homedomain2008.ru будет выглядеть так:

Секция Answers выглядит похожим образом: блок состоит из имени, типа, класса, ttl и дополнительных данных. IP-адрес будет содержатся в доп. данных. С разбором имени возникает ещё одна сложность. Видимо, для уменьшения размера сообщения, вместо длины метки, можно встретить ссылку на другую область данных. Закодирована она так: если 2 старших бита длины равны 11, то следующий байт, а также младшие биты длины, следует интерпретировать как смещение в байтах относительно начала сообщения. Дальнейший разбор имени нужно совершать, перейдя по этому смещению.

Итак, мы перехватили нужное API, разобрали dns-ответ, теперь нужно принять решение: пропускать дальше этот ответ или вернуть ошибку. Для каждого имени, которое ещё не присутствует в базе, из ответа нужно проверить, является ли оно «подозрительным» или нет.
Будем считать «подозрительным» такие имена, для которых результат функции skeleton из Unicode Technical Standard tr39 совпадает с результатом от любого из имён из базы, или те имена, которые отличаются от присутствующих в базе перестановкой внутренних букв. Для реализации проверок будем хранить 2 таблицы. Первая будет состоять из результатов skeleton для всех имён из базы, во вторую таблицу запишем строки, которые были получены из строк базы путём удаления первого и последнего символа из каждой метки кроме первого уровня, а затем сортировки оставшихся символов каждой метки. Теперь, если новое имя входит в одну из двух таблиц, то считаем его подозрительным.

Смысл функции skeleton в определении похожести двух строк, для этого для каждой строки производится нормализация символов. Например, Xlœ будет преобразовано в Xloe, и таким образом, сравнивая результат функции, можно определить похожесть unicode-строк.

С примером реализации описанного выше можно ознакомится на github .
Очевидно, что изложенное решение на практике предоставить нормальную защиту не может, т. к. помимо мелких технических проблем с перехватом, есть ещё большая проблема с детектированием «похожих» имён. Было бы неплохо обработать:

Комбинации перестановок и омоглифов.
Добавление\замену символов не учитываемых skeleton.
UTS tr39 не исчерпывается skeleton, можно ещё ограничивать смешивание наборов символов в одной метке.
Японскую полноширинную точку и другие label separator.
А так же такие прекрасные вещи, как

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

Как работает DNS-заражение или DNS-спуфинг

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

Риски

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

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

Оригинал: 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). Другие статьи этой серии.

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

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