В последнее время актуальность юзерлендных руткитов снизилась из-за практически гарантированного детекта, поэтому далее речь пойдёт о детектировании руткитов, использующих драйвера. Другие варианты кернелмодных рукитов пока так же останутся без внимания, однако изложенные ниже принципы могут быть использованы, я думаю, во всех возможных случаях.

Известные антируткиты ищут модифицированный код, скрытые структуры данных и т.п. По этим косвенным признакам делаются выводы о наличии в системе скрытого драйвера. Последние находки в дикой природе показали нестойкость такого подхода. Например ascesso попросту удаляет файл и таким образом разбор структур NTFS остаётся не у дел. Так же ходят байки о недетектируемых новых версиях Rustock C & D (хотя лично я не считаю их ничем более, поскольку Rustock на самом деле имел не буквенную, а цифровую нумерацию версий).

Не хочу уводить разговор в сторону недетектируемых существующими инструментами хуков, но всё же попробую показать, что распространённый подход не безупречен и в теории. Существует понятие "наблюдаемое поведение программы" (или "побочный эффект"). Это то, что видит пользователь как результат работы программы. В случае руткита наблюдаемым поведением будет скрытие объектов. А хуки\патчи и весь остальной 0day код руткита — это всего-лишь средства для достижения результата. Как следсивие мы имеем 2 проблемы: хуки могут быть установлены не для скрытия; один и тоже побочный эффект может быть достигнут разными путями, если инструмент не позволяет анализировать их все, то это останется незамеченным.

Если детектировать руткит по его наблюдаемому поведению, этих проблем можно избежать. У руткита оно, на первый взгляд, такое:
1. драёвер загружается, в этот момент он видим в системе;
2. драйвер каким-то образом делает себя невидимым в системе.
Делать подобный анализ программным образом довольно сложно, требуется эмуляция или песочница. А главный недостаток — когда руткит себя скрыл, его можно и "потерять".

Но можно сделать несколько проще, если вспомнить, что руткит на самом деле запускается "в цикле":
1. составляем список видимых драйверов в системе;
2. фильтруем по этому списку после ребута системы;

Что бы это беспроблемно заработало на самом деле, нужно учесть еще некоторые нюансы, но впринципе уже можно попробовать http://files.rsdn.ru/45067/zenadriver.0.25.src.rar
Исходники (только для MSVC2005) открыты, ИМХО пора уже выходить из каменного века — в security, о котрой пишет Шнайер, принято использовать публичные и как следует отпинанные обществом алгоритмы защиты.

Если кто-то решится запускать — перед этим лучше отключить все аппаратные звуковые устройсва в дистпетчере, иначе будут проблемы с эксплорером из-за карантина легитатимных драйверов, но всё должно решаться ребутом или восстановлением контрольной точки.

Ну а кавычки в теме — в память об ADinf

GN>1. драёвер загружается, в этот момент он видим в системе;
Руткит может грузить до нас. Более того — скажу по секрету уже довольно обкатана технология патча ntoskrnl.exe
GN>2. драйвер каким-то образом делает себя невидимым в системе.


Кстати, про rootkit revealer тут все надеюсь слышали?

добавлю еще способ более красивого детекта: делается Boot-cd под линухой, который монтирует и снимает снимки NTFS разделов и реестра (дада, самба уже давно умеет с ним работать). После чего делаются аналогичные действия из под винды и diff между снимками.

здесь на сходную тему доклад Symantec. Но это еще больше телодвижений, я пытаюсь автоматизировать процесс. Вообще ИМХО вариант подобного должен присутствовать непосредственно в ОС и в некотором роде есть в Висте.

Здравствуйте, <Аноним>, Вы писали:

А>Руткит может грузить до нас.

Да много кто может, я не отрицаю... Когда увижу, поверю, что это реально используется.

А>Более того — скажу по секрету уже довольно обкатана технология патча ntoskrnl.exe

Как раз собираюсь добавить проверку подписей.

А>Кстати, про rootkit revealer тут все надеюсь слышали?

Это к чему?

Лучше сделай благое дело в обмен на сорцы — напиши, детектит ли тебя

А>>Кстати, про rootkit revealer тут все надеюсь слышали?
GN>Это к чему?
Ну просто прога есть примерно такого же назначение от Руссиновича, правда она вроде такого не делает с загрузкой винды.. малоли..

GN>Лучше сделай благое дело в обмен на сорцы — напиши, детектит ли тебя
А я в лагере "хороших"

Здравствуйте, <Аноним>,

Да, действительно используется похожий на RootkitRevealer принцип. Есть один нюанс — у меня сравнение идет с системойй где руткит еще не активен. Поэтому пока работает.

А>А я в лагере "хороших"

"Когда в Поднебесной все узнали, что такое прекрасное, тогда и появилось безобразное"

Здравствуйте, Аноним, Вы писали:


А>Руткит может грузить до нас. Более того — скажу по секрету уже довольно обкатана технология патча ntoskrnl.exe
Это очень легко обнаружить.

А>Кстати, про rootkit revealer тут все надеюсь слышали?
Не самая сильная программка в этом смысле...

А как данный подход различает динамически выгружаемые драйвера и рк? У меня сложилось впечатление, что данный подход будет хорошо работать только в антивирусной лаборатории, обычных пользователей — замучает .

По поводу кода:
немножко не хватает комментов , тем более, что плюсовый код несколько отличается от традиционного "ддкашного" стиля.

А>>Руткит может грузить до нас. Более того — скажу по секрету уже довольно обкатана технология патча ntoskrnl.exe
DOO>Это очень легко обнаружить.
это если руткит не подсовывает драйверам при обращению к файлам и страницам памяти оригинальный ntoskrnl

Здравствуйте, Аноним, Вы писали:

А>>>Руткит может грузить до нас. Более того — скажу по секрету уже довольно обкатана технология патча ntoskrnl.exe
DOO>>Это очень легко обнаружить.
А>это если руткит не подсовывает драйверам при обращению к файлам и страницам памяти оригинальный ntoskrnl

Хм... О такой изощренности я как-то и не подумал...

GN>здесь на сходную тему доклад Symantec. Но это еще больше телодвижений, я пытаюсь автоматизировать процесс. Вообще ИМХО вариант подобного должен присутствовать непосредственно в ОС и в некотором роде есть в Висте.
Просто фишка в том что загрузчик ОС сам по себе может быть заменен руткитом даже в бут секторе винта. И выступать супервизором при последующей загрузки висты или чего угодно еще даже не особо заботясь об этой системе — не юзая ее апи и тп — тихонько зашиться в последней странице памяти, спрятать ее от известнх способов определения объема памяти на уровне железа, навесить свой обработчик на сетевую карту "завиртуализовов" ее таким образом. Свой tcp/ip стек и вуаля.

Здравствуйте, Аноним, Вы писали:


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

Бут сектор это не самый интересный метод... Вот зашиться в firmware винта или какой-нибудь PnP-шной карточки — это да


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

DOO>Бут сектор это не самый интересный метод... Вот зашиться в firmware винта или какой-нибудь PnP-шной карточки — это да
Запросто. Но на материнках бывает делается аппаратный переключатель защиты FLASH ROM, а видюху и веник можно поставитьк акую нить экстремально неизвестную, или опять же аппаратно ограничить возможность перезаписи флэш

DOO>Именно поэтому все руководящие документы по ИБ требуют наличие системы контроля целостности, которая активизируется раньше ОС и контролирует все, в том числе firmware.
Вопрос только в том как эта система контроля целостности отличит загрузчик ос от руткита
Единственное — подписать его сертификатом который наглухо зашит в железо. И даже не в FLASH, а в неперепереписываемое ПЗУ.
Вот вам документик о том как ломали X-Box, дабы лишить веры в непогр.. невзламываемость аппаратных решений) http://web.mit.edu/bunnie/www/proj/anatak/AIM-2002-008.pdf

Здравствуйте, TarasCo, Вы писали:

TC>А как данный подход различает динамически выгружаемые драйвера и рк?

Пока никак (и это основная проблема, поскольку сюда попадаю некоторые звуковые драйвера). Часть файлов виндовс сама восстановит, остальные руками (но можно подумать об автоматизации). Я думаю для начала проверки подписей должно хватить, что бы не удалять такие драйвера, а потом оценить процент проблемных.

TC>У меня сложилось впечатление, что данный подход будет хорошо работать только в антивирусной лаборатории, обычных пользователей — замучает .

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

TC>По поводу кода:
TC>немножко не хватает комментов , тем более, что плюсовый код несколько отличается от традиционного "ддкашного" стиля.

В библиотеке точно надо, но там непонятно, можно ли копировать из MSDN А сам детектор показывал коллеге — единственный вопрос который у него возник по сорцам "почему подписи не проверяются?" Да и шифровка это, хеккиры принципиально не знают о классах

Здравствуйте, DOOM, Вы писали:

DOO>Бут сектор это не самый интересный метод... Вот зашиться в firmware винта или какой-нибудь PnP-шной карточки — это да

Есть достаточно надёжные методы детекта исполняемого кода в памяти (включая Shadow Walker), AFAIK появится в RKTrap следующем. да и врядли такое найдёт применение в мэйнстриме, там скорее придумают какой-нибудь хитро*опый изврат.

Здравствуйте, gear nuke, Вы писали:

ПОСКИПАНО

Ну идея то как бы уже стара, причем реальизована в разных варианциях, в какой то степени это можно отнести и к AVZ(bootcleaner у них зовется это), при рестарте системы запускается дравер его и удаляет все плохое, в принипе это вариация того что ты написал, просто в твоем подходе постоянная проверка на загружаемость драйверов(в ходе ожного рестарта даже), а там проверили список, уидили что в списке есть того кого нада удалить , ну и удалили.
Одно время я хотел даже для себя написать такую же вещицу, просто сделать при старте каждого драйвера запрос, грузить или нет. Но руки так и не дошли до этого.
Да и кстати как быть с пропатченными дровами, кои сейчас есть, патчат и ядро и tcpip.sys.
Данный подход по сути часть общей системы, сюда по любому нужно добавить проверку по хеш функции, ну т.е. грузить только хорошие дрова.

ЗЫ: Вспомнил еще у анхакми есть некое подобие, он сравнивает список дров в реестре при рестарте и после рестрата, псравнивая эти списки получишь скрытые ветки реестра с дравами.

Вот из этой же области

Здравствуйте, Denwer, Вы писали:

D>Вот из этой же области

Только этот платный мегабайтный монстр практически бесполезен даже с прошлогодним rustock 1.2

Здравствуйте, Denwer, Вы писали:

D>в какой то степени это можно отнести и к AVZ(bootcleaner у них зовется это), при рестарте системы запускается дравер его и удаляет все плохое, в принипе это вариация того что ты написал, просто в твоем подходе постоянная проверка на загружаемость драйверов(в ходе ожного рестарта даже), а там проверили список, уидили что в списке есть того кого нада удалить , ну и удалили.

То есть они по блэк-листу фильтруют? Блэклисты вообще не надежный подход (так сделано и в combofix), поскольку можно просто поменять имя.

D>Одно время я хотел даже для себя написать такую же вещицу, просто сделать при старте каждого драйвера запрос, грузить или нет. Но руки так и не дошли до этого.

Запросы возможно тоже надо добавить будет, но по-моему идеально было бы — запустил и получил результат (пусть и после нескольких ребутов, но автоматически)

D>Да и кстати как быть с пропатченными дровами, кои сейчас есть, патчат и ядро и tcpip.sys.
D>Данный подход по сути часть общей системы, сюда по любому нужно добавить проверку по хеш функции, ну т.е. грузить только хорошие дрова.

Подписи будут проверяться.

D>ЗЫ: Вспомнил еще у анхакми есть некое подобие, он сравнивает список дров в реестре при рестарте и после рестрата, псравнивая эти списки получишь скрытые ветки реестра с дравами.

Не детектит ascesso.