Ищем руткиты с помощью gdb

Непонятно, а что мешает пропатчить gdb?

На livecd который у меня в столе лежит как ты его пропатчишь ?

За@бешься ты патчить gdb.

Ты наивен как маленькая девочка.

bash->execve->/cdrom/gdb

Модифицированный execve тоже может посмотреть откуда берут файл

и подсунет нужный.

>На livecd который у меня в столе лежит как ты его пропатчишь ?

Пока лежит в столе - нельзя пропатчить не только gdb. ;-) А когда загружено на ram-диск, можно уже все подряд патчить.

А переименовать gdb?

strings или md5 покажут ослиные уши

это security through obscurity.

а зачем ? :)

Саныч, ты что параноик или вкалываешся?

Ни то ни другое, мне кажется. Подводит к простой идее - если ядро _уже_ сломано _правильно_ - то нельзя никакими методами из userspace определить этот факт. Разумеется, "правильно" сломать ядро - может оказаться сложно.

The matrix has got you, гыы

И это тоже:)

>Ты наивен как маленькая девочка.
>bash->execve->/cdrom/gdb
>Модифицированный execve тоже может посмотреть откуда берут файл
>и подсунет нужный.
А ты еще наивнее :)
Интересно, а как руткит сможет проинициализироваться, если загрузка полностью прошла с livecd? Если только в биос внедрится :)

>Интересно, а как руткит сможет проинициализироваться, если загрузка полностью прошла с livecd? Если только в биос внедрится :)

Ага, в процессор. KDE тебе в BIOS. Или хотя бы в ядро.

Малыш, bash он тоже на livecd.

Модификация таблицы системных вызовов - это уж как-то совсем пошло. Можно с неменьшим успехом поменять поля file_operations у всех зарегистрированных файловых систем.

Не просто has you! А прямотаки, матрица поимела тебя :)

все замечательно, но в 2.6 символ sys_call_table не экспортируется, это раз. два - если автор полагается на userspace диагностику - и /proc/kcore и /boot/vmlinuz могут быть подменены для скрытия следов rootkit. действительно сложно скрыть следы лишь в случае когда диагностика работает в kernelspace - но для этого должна быть включена возможность загрузки своих модулей.

wbr, anight

ооо, это ж техника прошлого века. время адор и прочих хукеров прошло. сейчас у блэкхэтов есть наработки
гораздо круче. почитывайте фрак, он упрощенное отражение реальности ;), тк скзть, сборник учебных примеров ;).
вон и в линуксе озаботились, стока тулов классных заделали -
селинукс - прям готовый визард для китов, заделал секполиси, криптанул и все - гдб сосет.Тот же хукер, аудит, крипто, дают стока возможностей.... а вы все сискалтейбл фачите ;). ее ж не експортят кстати в последнем линуксе, хотя найти не проблема.

О! Размещаем код ядра и константные структуры на куске памяти хадрварно необратимо лочащимся на readonly.

Угумс, а обновлять как будем?

ну, типа лочится после загрузки самим ядром когда всё ок. или админом - нажатием какой-нить секретной кнопки :)

Никогда не думал, почему файерволлы ломают?

а вот что ты такое предложил почитывать? можно чуть поподробней?

>Никогда не думал, почему файерволлы ломают?

Pochemu lomayut ? Dumayesh zaranee lomann?y ? hmmmm...

Да потому что ошибки есть почти в любой программе достаточного объёма. Файерволл защищает, только не факт, что в нём ошибок нет. Аналогично с R/O памятью после загрузки ядра.

да ну на копаться во всяких gdb
лучше сразу ядро пересобрать без поддерки модулей

> а вот что ты такое предложил почитывать? можно чуть поподробней?

phrack, электронный журнал, издающийся хакерами для хакеров.

www.phrack.org

>Ни то ни другое, мне кажется. Подводит к простой идее - если ядро _уже_ сломано _правильно_ - то нельзя никакими методами из userspace определить этот факт. Разумеется, "правильно" сломать ядро - может оказаться сложно.

Неа. Если ты знаешь _какой_ руткит ищешь, то его всегда можно найти (прим. автора: хотя спорно - в конце некоторые мысли).

С другой стороны, если ты знаешь, _как_ кто-то ищет руткит, ты всегда сможешь придумать способ его обмануть.

Вот. А остальные случаи - это кто кого переиграет, кому как повезет.

P.S.

А вообще, интересно существует ли "устойчивый к нахождению" руткит? Т.е по аналогии с криптографической устойчивостью (т.е утверждаем, что не зная пароля расшифровать текст не возможно, вероятность угадывания пароля в расчет не берем).

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

Т.е механизм такой. Действующие лица: А - Админ, Х - Хакер.

А: Разрабатывает супер-секурное ядро, отдает исходники Х. Х: Изучает ядро, разрабатывает руткит, устанавливает либо исходное ядро либо руткит (скрытно от админа). Заметим, что он может полностью заменить ядро на свое. Отдает исходники руткита А. А: Имея исходники руткита пытаемся его обнаружить. Считаем, что взаимодействие ограничено исключительно взаимодействием с ядром.

Количество тактов на команду, видимо, придется выкинуть из наблюдаемых параметров - по ним, наверное, всегда можно обнаружить, при "грамотно разработанном" ядре (грубо говоря, поскольку руткит будет "содержать" больше функциональности, то его функции будут выполняться большее число тактов). Аналогично, видимо, придется выкинуть из рассмотрения память.

Осталось только определить, какая функциональность обязательна в ядре, что такое руткит (т.е какой критерий руткит/не руткит), формализовать условие и можно решать задачу :)

Наверное, формализовать таким путем задачу не получится. Вы слишком увлеклись криптографией. Так же как криптография не решает в чистом виде задачи "защиты от копирования", также она не решает и задачи "защиты от взлома". Вообще она не работает когда и ключ расшифрования и алгоритм, и данные (все три компонента) находятся в руках взломщика (как бы не прятали ключ внутри кода - это бесполезно).

>Наверное, формализовать таким путем задачу не получится. Вы слишком увлеклись криптографией. Так же как криптография не решает в чистом виде задачи "защиты от копирования", также она не решает и задачи "защиты от взлома". Вообще она не работает когда и ключ расшифрования и алгоритм, и данные (все три компонента) находятся в руках взломщика (как бы не прятали ключ внутри кода - это бесполезно).

Я имею ввиду, если ключа нет, то, грубо говоря, пренебрегаем вероятностью его угадывания.

В случае с руткитом он может реагировать на определенную последовательность байт в пакете - если эта последовательность соответствует открытому ключу, забитому в код руткита. Поскольку закрытый ключ находится у взломщика, а получить его по открытому - невозможно (реально это, конечно, не так), то Админ не сможет сгенерировать сообщения для руткита, чтобы определить его существование/несуществование. Считаем, что Админ только наблюдает за системой, ничего не исправляя. Т.е открытый ключ руткита он видит (у него есть исходники руткита), но заменить его не может.

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

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

Ты не понял, это был пример. Это теоретическая задача. Т.е вопрос именно в принципе, возможно или нет. Вернее даже, точно известно, что это невозможно (если учитывать время исполнения/память), вопрос в том, при каких ограничениях/приближениях (например, такты не замеряем, закрытый ключ по открытому не вычисляем) эта задача имеет решение (задача создания принципиально необнаруживаемого руткита).

Вопрос теории. Так сказать для любителей теории алгоритмов, мат. логики, криптографии, и.т.д. :)

Вот ОНО - секретное оружие сисадмина! надо переименрвать ВСЕ файлы, тогда ни один рутшел не страшен! hier фтопку!

> Заметим, что он может полностью заменить ядро на свое.

Ага. На Win98 заменит. И пиздец тебе :)