Что такое dns spoofing. Атака DNS Spoofing DNS spoofing — это. Extension 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 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 протокол. На данный момент, предложенные модели противодействия являются наиболее эффективными и их целесообразно использовать в комплексе для достижения максимально возможной защищенности.

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

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