ru.nethack

 
 - RU.NETHACK -------------------------------------------------------------------
 From : Andrey Sokolov                       2:5020/400     27 Dec 2004  14:38:25
 To : All
 Subject : о реверсивных троянах -- часть 3.2
 -------------------------------------------------------------------------------- 
 

 Hi All,
 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)
 
 

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