|
ru.nethack
- RU.NETHACK -------------------------------------------------------------------
From : Andrey Sokolov 2:5020/400 27 Dec 2004 22:41:14
To : All
Subject : о реверсивных троянах -- часть 3.1
--------------------------------------------------------------------------------
Hi All,
федошный гейт обламывается на попытке зохавать слишком длинные сообщения :(
поэтому он проглотил часть 3, и мне придётся распилить её на две части.
*****************************************************************************
Путь второй
Любой транспорт, основанный на сокетном слое (грубо говоря, любые нормальные
транспортные операции, осуществляемые по протоколам 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 и архитектура немного другая):
--- ifmail v.2.15dev5.3
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
