ru.nethack

 
 - RU.NETHACK -------------------------------------------------------------------
 From : Andrey Sokolov                       2:5020/400     27 Dec 2004  22:41:13
 To : All
 Subject : пропустил: о реверсивных троянах -- часть 3
 -------------------------------------------------------------------------------- 
 

 Hi All,
 
 Путь второй
 
 Любой транспорт, основанный на сокетном слое (грубо говоря, любые нормальные
 транспортные операции, осуществляемые по протоколам tcp и udp через tcpip.sys)
 скрывать весьма затруднительно.
 
 Сокеты -- это тяжёлые объекты ядра, и основная масса их тяжести заключается в
 широком спектре возмоожностей как управления этими сокетами (многослойная
 модель Winsock SPI, опции, пять моделей ввода-вывода и так далее), так и
 статистического анализа. За более детальной информацией следует обратиться к
 соответствующей части украденных исходников Windows, которые отражают, в
 частности, взаимоотношение между WinSock2 API и WinSock2 SPI. Искать истину
 можно также в процессе фиксирования системных и библиотечных вызовов
 каким-нибудь отладчиком уровня ядра, поддерживающим символьные разыменования,
 это широко описано в книге "Hедокументированные возможности Windows 2000".
 
 Собственно, возможностями статистического анализа (как посредством специально
 для этого предназначенных IP Helper API, на основе которой, например, работает
 netstat, так и рядом других, которые ближе к DDK) и пользуются всевозможные
 следилки вроде Active Ports и персональные фаерволлы вроде популярных Agnitum
 Outpost и Антихакер каспера.
 
 Короче говоря, когда мы хотим принять соединение (или udp-дейтаграмму) или
 осуществить соединение, открывается порт. Явно или не явно (например, при
 вызове connect() после socket(), сисколл bind() вызывается неявно), но порт
 открывается и становится прозрачным и совершенно очевидным любому локальному
 процессу.
 
 Стало быть, это палево. Которое, впрочем, обходится в "пути номер один"
 привязкой этого палёного порта к "хорошему" процессу. Однако, соединение всё
 равно присутствует и очевидно. И фаерволлы не лыком шиты: Agnitum Outpost,
 например, в последних своих версиях перехватывает и блокирует вновь
 создающиеся процессы со взведённым битом SW_HIDE в опциях окна, а также
 препятствует срабатываниям CreateRemoteThread(). Со всем этим можно бороться,
 но это "путь номер один", это игра по правилам фаерволла.
 Путь номер два -- это поиск маршрутов, которые не предусмотрены локальными
 системами защиты. Ибо, как сказал один товарищ из нашей сети, по поводу
 svchost.exe, "ну, это крест, принимаемый с выбором в пользу win xp".
 
 Итак, если переть в лоб, то изыскания в области не предусматриваемых
 персональными фаерволлами способов транспорта наверняка лежат где-то ниже
 уровня драйвера персонального фаерволла. Стало быть, очевидным (наиболее
 адекватным и само собой разумеющимся) решением транспортной проблемы было бы
 создание собственного драйвера (который можно загружать перед осуществлением
 транспорта и выгружать после его осуществления), реализующего часть
 функциональности tcpip.sys. И, следовательно, не конфликтующим с оригинальным
 драйвером tcpip.sys и с драйвером персонального фаерволла, контролирующим
 взаимоотношения tcpip.sys со слоем NDISv5.
 
 Чтобы внести ясность в этот вопрос, нарисую -- очень грубым, зато простым
 образом -- ну... скажем так... сетевую архитектуру замечательной операционной
 системы MicroSoft R Windows R, в данном случае, линейки
 2000/XP/2003/и/так/далее (в системах 95, 98, ME и NT работает другая версия
 NDIS и архитектура немного другая):
 
 CODE
 
 wininet.dll или что-либо другое
 использующее сокетный слой
 WinSock(2) API
 один или несколько слоёв WinSock(2) SPI
 (используется всевозможными врапперами,
 продвинутыми статистическими анализаторами,
 локальными проксевателями и так далее, и тому подобное)
 
                                                   userspace
 ----------------------------------------------------------------------
                                                   kernelspace (ring3)
 
 tcpip.sys
 
                          драйвер персонального фаерволла контролирует
              <---------- взаимодействие NDISv5 и tcpip.sys, не пропуская
                          плохой трафик к tcpip.sys от от tcpip.sys
 
 NDISv5
 NIC
 витая пара или медная пара
 Опишу на словах:
 
 1) итак, положим, объект ядра "сокет" создан. совершается системный вызов,
 скажем, из пользовательской программы, которая хочет отправить удалённой
 стороны пачку данных. делается send(), ну и, в соответствии с предпринимаемой
 моделью ввода-вывода, процесс начинает ожидать возврат этого вызова.
 
 2) данные враппятся на уровне SPI (который, по дефолту, лишь отсчитывает
 статистику, но может автозапроксёвывать траффик, если установлена программа,
 которая враппит любой траффик на корпоративный прокси-сервер, например). 
 
 3) из SPI делается уже стандартный, понятный tcpip.sys'у системный вызов в
 ядро. тысяча тактов, и процесс уже в кернелспейсе, и tcpip.sys начинает
 обрабатывать этот системный вызов. например, предположим, что соединение
 установлено.
 
 пачка данных фрагментируется на IP-пакеты в соответствие со значением MTU,
 настраиваются IP и TCP-заголовки, совершаются всякие там SYN/ACK-приращения,
 просчитываются всякие там контрольные суммы CRC16 и так далее, и очередь
 пакетов (или один пакет) идёт в NDISv5.
 
 Вообще, вся эта работа происходит асинхронно, и всё это моё словоблудие
 означает очень мало и не описывает и малой толики той работы, которую делает
 tcpip.sys. И, тем более, не отражает то, как tcpip.sys это делает. Hо для
 простой схемы моё рассуждение вполне сносно: суть отражается.
 
 Hу вот, tcpip.sys говорит NDIS'у v5: "уважаемый, я хочу, чтобы эта группа
 пакетов была отправлена на этот сетевой адаптер (в соответствии с таблицей
 роутинга". Ага, если данные идут на локалхост, tcpip.sys всё равно делает этот
 обмен через NDISv5 и, по идее, драйвер персонального фаерволла может
 контролировать даже сокетный обмен через 127/8.
 
 4) Драйвер персонального фаерволла "сидит" на интерфейсе между tcpip.sys и
 NDISv5 и отфильтровывает каждый пакет в соответствии с микропрограммой BPF
 (Berkeley Packet Filtering), которая говорит ноль, если пакет надо дропнуть
 или один, если пакет можно пропустить.
 
 5) NDISv5 -- это вобщем-то и не программа даже, и не какой-то особенный
 драйвер. Это стандратный интерфейс MS R Windows R. Короче говоря, это
 абстракция. Это интерфейс, по которому tcpip.sys общается с низким уровнем.
 
 6) Драйвер NIC (Network Interface Card), получая новый пакет, отсчитывает для
 него чексумму CRC32 уровня EtherNet и отправляет кадр в сеть. Соответственно,
 драйвер NIC обрабатывает события возникновения нового кадра в сетевом
 адаптере, проверяет его CRC32 уровня EtherNet и отправляет кадр NDIS'у.
 
 Если NIC работает в нормальном режиме, то NDIS'у отправляются только те кадры,
 Destination MAC Address которых соответствуют собственному или
 широковещательному.
 
 Если же NIC работает в неразборчивом режиме (promiscuous mode), то NDIS'у
 отдаются все кадры без исключения.
 
 Триггеровать промискуитетный режим очень просто даже из юзерспейса, есть
 соответствующие опции на сокетном слое.
 
 Вообще, сетевая архитектура MS R Windows R -- вещь непростая, но изучить её
 можно без особых напрягов, по следующим трём направлениям:
 
 1) можно читать книгу "Программирование в сетях MicroSoft Windows R" от
 микросовт пресса, авторы Э. Джонс и Д. Оланд, написанного там вполне хватит,
 чтобы понять в общих чертах взаимоотношения между WinSock2 API и WinSock2 SPI.
 Далее, можно читать оригинальную микросовтовскую документацию по WinSock2 SPI
 версии 2.2.2
 
 2) можно изучить драйвер WinPCap/PacketX (http://winpcap.polito.it/), который
 очень просто и изящно иллюстрирует часть "tcpip.sys -- витая пара". Сам
 драйвер для трояностроения использовать нельзя: он сидит слишком "высоко",
 работает параллельно tcpip.sys (над NDISv5) и, стало быть, входящие
 EtherNet-кадры копируются и в оригинальный tcpip.sys, и в этот драйвер. с
 другой стороны, доступные исходные коды и неплохая документация (в том числе и
 матчасть) делают эту работу очень привлекательной.
 
 3) взаимоотношения между юзерспейсом и кернелспейсом, а также науку об
 исследовании этих взаимоотношений можно прочесть в книге "Hедокументированные
 возможности Windows 2000".
 
 Резюмируя всё описанное выше, можно отметить следующее: совершенно очевидно,
 что драйвер для транспорта в обход персонального фаерволла должен находиться
 ниже NDISv5. Это должна быть другая BPF-микропрограмма, которая фильтрует
 входящие кадры EtherNet прежде, чем они попадут в NDISv5.
 
 Это решение сработает. Hо это геморройное решение. Если заняться его
 реализацией, то можно будет обнаружить его патологическую системную
 зависимость. Более того, придётся делать такие плохие вещи, как проход в
 нулевое кольцо защиты, чтобы заниматься филигранным битхаком уже работающих
 NDISv5 и сетевых адаптеров, через которые нужно будет отправлять данные
 физически.
 
 И я, вобщем-то, к такому решению не склоняюсь. И поэтому заведу последнюю
 часть: путь два с половиной.
 
 --- ifmail v.2.15dev5.3
  * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор