Атака DNS Spoofing DNS spoofing — это. Пишем плагин к Microsoft DNS server для защиты от IDN spoofing Что такое dns spoofing

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

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

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

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

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

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

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

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

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

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

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

Подмена 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-серверу злоумышленника;

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-заражение, пользователям не следует проходить по неизвестным ссылкам и регулярно проверять свой компьютер на наличие вредоносных программ. Всегда делайте это, используя программу, установленную на вашем компьютере, а не онлайн-версию, которая также может быть подменена.

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

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=" :