| 1.1, Аноним (-), 14:15, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Надеюсь, что на этот раз ядро патчить не прийдется чтобы руткит заработал ?
| | |
| |
| 2.2, Andrew Kolchoogin (?), 14:24, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Надеюсь, что на этот раз ядро патчить не прийдется чтобы руткит заработал?
Придётся, конечно. Этот root kit именно это и делает -- патчит ядро через /dev/mem. Системному администратору нужно всего одну команду подать -- "chmod 666 /dev/mem" :)))
| | |
| |
| 3.11, User294 (??), 15:49, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
>делает -- патчит ядро через /dev/mem. Системному администратору нужно всего одну
>команду подать -- "chmod 666 /dev/mem" :)))
Вот только если хаксор как-либо отхватит рута, обнаружить его потом будет довольно нетривиально.Лишний пример того как любую даже самую хорошую фичу можно поюзать и с неблаговидными целями.Системному администратору соответственно надо прежде всего не щелкать клювом.И вообще мне так кажется что есть еще с полдюжины не очень очевидных но простых способов подгрузить руткит разных ОС.Что у нас там следующее?Руткиты через DMA?Руткиты в видеобиосе? :)
| | |
| |
| 4.22, Арнаутов Сергей (?), 19:53, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
DMA??? :) Где-то проскакивало сообщение о возможности внедрения в систему через IEEE1394 именно благодаря возможности работать с DMA, предусмотренной протоколом интерфейса. Причём в этом случае нам никаких прав иметь не нужно, нужны лишь доступ к атакуемому хосту и включённый на нём порт. Так что остались только руткиты в видеобиосе.
| | |
| |
| 5.50, User294 (??), 13:23, 17/04/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>только руткиты в видеобиосе.
Кстати вон в соседней новости - рассказы про багу udev позволяющую проапгрейдиться до рута.Очень мило, как раз в тему - теперь поставить руткит может и просто лузер с птичьими правами иной раз :)
| | |
|
|
|
|
| 1.3, User294 (??), 14:25, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Остап знал 500 относительно честных способов незаметной загрузки руткитов...
| | |
| 1.5, Аноним (-), 14:33, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А что есть клоуны которые для сервера включает поддержку /dev/mem и дают всем рутовый пароль?
| | |
| |
| 2.29, слыш (?), 22:59, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
>А что есть клоуны которые для сервера включает поддержку /dev/mem и дают
>всем рутовый пароль?
А есть клоуны способные выключиь поддержку /dev/mem ?
grsecurity патч
config GRKERNSEC_KMEM
bool "Deny writing to /dev/kmem, /dev/mem, and /dev/port"
help
If you say Y here, /dev/kmem and /dev/mem won't be allowed to
be written to via mmap or otherwise to modify the running kernel.
/dev/port will also not be allowed to be opened. If you have module
support disabled, enabling this will close up four ways that are
currently used to insert malicious code into the running kernel.
Even with all these features enabled, we still highly recommend that
you use the RBAC system, as it is still possible for an attacker to
modify the running kernel through privileged I/O granted by ioperm/iop
If you are not using XFree86, you may be able to stop this additional
case by enabling the 'Disable privileged I/O' option. Though nothing
legitimately writes to /dev/kmem, XFree86 does need to write to /dev/m
but only to video memory, which is the only writing we allow in this
case. If /dev/kmem or /dev/mem are mmaped without PROT_WRITE, they wi
not be allowed to mprotect it with PROT_WRITE later.
It is highly recommended that you say Y here if you meet all the
conditions above.
| | |
|
| |
| |
| 3.35, maximnik0 (?), 02:48, 16/04/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Можно. Но такая фигня получится %-)
Не все выйдет .Механизм смены ядра на горячию уже давно встроен в ядро .
Помоему в алте 4.0 (бета ) или что то около этой версии даже использовался этот миханизм ,init только там нестандартный ,не помню номера .Многие жаловались что зависает и установка не заканчивается ,но на моей машинке ядро перезагружалось .
| | |
| |
| 4.40, darkk (?), 08:55, 16/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
 >Не все выйдет .Механизм смены ядра на горячию уже давно встроен в
>ядро .
Если речь про kexec, то он с точки зрения пользователя от перезагрузки отличается мало. Или уже что-то новое появилось?
| | |
|
|
|
| 1.10, NegatiV (ok), 15:49, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
по умолчанию права на /dev/mem вроде как 640.
очередной "руткит", рассчитанный на админа-идиота.
| | |
| |
| 2.12, uldus (ok), 15:58, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
>по умолчанию права на /dev/mem вроде как 640.
>очередной "руткит", рассчитанный на админа-идиота.
Даже по самому слову видно, что руткит это инструмент для оставления бэкдора после получения рутового доступа к системе. Как этот рут получен неважно, обманом или взломом незакрытой дыры в ядре, руткит уже совершенно другой этап работы атакующего.
| | |
| 2.23, 123456 (??), 19:57, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
там же русскими буквами написано "руткит", т.е. использовать его нужно, когда уже есть права рута в системе и нужно их скрыть от настоящего админа
| | |
| 2.25, User294 (??), 20:33, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>очередной "руткит", рассчитанный на админа-идиота.
Гм, если б руткит можно было втулить от юзера - это был бы вообще пи$#ец.Реальный такой пи$#ец.Потому что большая часть админов вообще не знала бы что делает их машина в данный момент =)
| | |
| |
| 3.26, аноним (?), 20:48, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
в винду можно втулить руткит вообще удалённо через очередную кривость в rpc и dcom(которые особо и не нужны), но ничего, все пользуют
| | |
| |
| 4.31, User294 (??), 23:36, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
>в винду можно втулить руткит вообще удалённо через очередную кривость в rpc
>и dcom(которые особо и не нужны), но ничего, все пользуют
Ой, не надо о этих протоколах.На мое мнение RPC - это что-то типа удаления гланд через попу автогеном.При том еще и геморное если надо его через нат или файрвол пропихнуть.А насчет линуха - не ну такого вопиющего пиндеца как ремотный эксплойт ядра я так сходу не припоминаю за ближайшее время но в принципе не стоит сбрасывать возможность подобного эксплойта со счетов.Все-таки ядро у линуха достаточно большое и полностью проаудитить его нелегко.В основных сетевых подсистемах надеюсь, более менее проблемы вылвили но в конце концов, людям свойственно ошибаться.
| | |
|
|
|
| 1.16, klalafuda (?), 17:21, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
ну подобный метод ковыряться в ядре, нужно признаться, достаточно старый. хотя и вполне рабочий :)
// wbr
| | |
| 1.17, Аноним (-), 17:24, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
больше хаков в ядре - лучше для развития линукса. появятся еще более непробиваемые hardened дистры
| | |
| 1.24, pavlinux (ok), 20:18, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
pavel@amd64:~> echo 1 > /dev/mem
bash: /dev/mem: Отказано в доступе
pavel@amd64:~> ls -la /dev/mem
crw-r----- 1 root kmem 1, 1 Апр 15 2009 /dev/mem
pavel@amd64:~> cat /etc/group | grep kmem
kmem:x:9:
И как туда внедрять?
| | |
| 1.28, FrBrGeorge (ok), 22:44, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Народ, вы мелко смотрите. Почитайте, что ли, манифесты этого Black Hat. Какое счастье от взлома единственного сервака, кроме как бездарно подефейсить какую-нибудь веб-страничку и радостно написать об этом в журнал "Хакер"?
Идея в том, чтобы на скомпрометированном сервере как можно дольше выполнялся несанкционированный код, и притом это никак нельзя было заметить. Предлагаемый способ хорош тем, что после подчистки логов на машине не будет СОВСЕМ ничего, указывающего на факт взлома -- а главное, на то, что код злоумышленника продолжает работать! Ни изменённых файлов, ни лишних процессов, ничего. Все контрольные суммы сойдутся.
Что может делать этот зловредный код? Например, патчить ядра, раскладываемые в собираемый дистрибутив сборочным сервером...
| | |
| |
| |
| 3.32, FrBrGeorge (ok), 23:37, 15/04/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Вы чем слушаете????
Я читаю.
>Как внедрить-то ??? Без прав UID=0;
Вот я и говорю: мелко смотрите. Думаете, вся цель нормального взломщика состоит в получении прав UID=0? Это не так сложно, как кажется, особенно если не ограничиваться чисто спортивными попытками добыть рута исключительно программным путём за fixnum время.
Black Hat -- люди серёзные, они разговаривают не об этом, а о том, что делать после.
GRKERNSEC_KMEM здесь помогает, да.
| | |
|
| 2.39, sy (ok), 07:38, 16/04/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>после подчистки логов на машине не будет СОВСЕМ ничего, указывающего на факт взлома
Интересно, а если есть в сети машина, относительно независимая, которая только и делает, что дублирует логи с других систем.
На ней же не удастся логи "почистить"?
| | |
| |
| 3.43, FrBrGeorge (ok), 10:43, 16/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Интересно, а если есть в сети машина, относительно независимая, которая только и
>делает, что дублирует логи с других систем.
Хорошая идея. правильная.
>На ней же не удастся логи "почистить"?
Её придётся заДОСить. Задача тем самым усложняется.
| | |
| |
| 4.44, waf (ok), 14:41, 16/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
Думаю, такие машины не имеют входа извне локалки, так что заДОСаный лог-сервер -- очень яркий признак того, что внутри сети нелады, а это противоречит тактике взломщика.
| | |
|
|
|
| |
| 2.48, sluge (??), 11:09, 17/04/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Винде, если сидеть не под Админом, тоже вполне безопасно...)...
от кидо тебя это не спасет :)
| | |
| |
| 3.49, unihorn (?), 13:13, 17/04/2009 [^] [^^] [^^^] [ответить]
| +/– |
Про дыропад (вполне возможно, что много круче виндового) в следствии увеличения критической массы простых пользователей сказано выше (в посте, на который ты ответил). :) Кто его знает, не появится ли, когда-нибудь, Кидо дя Линя (коли критическая масса простых юзеров будет)?...
| | |
|
|
| 1.42, Аноним (-), 10:14, 16/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Как бы для этого PAX придумали
http://en.wikipedia.org/wiki/Address_space_layout_randomization
Одну единственную машину 100% не защитишь, но предотвратить массовое заражение можно.
А в винде можно и WriteProcessMemory попробовать использовать, или в Memory Manager Routines что нибудь подобрать.
Убирать /dev/mem, какой в этом смысл?
Загрузи свой модуль, он запустится в адресном пространстве ядра, сделает и оставит такой же руткит. А потом выгрузи его.
Если ты уже получил рута то ты бог в системе.
Логи попробовать делать remote с записью на болванки, если появилась запись что логирования былы отключено, бить тревогу. Но здесь много тонкостей.
| | |
| 1.45, Аноним (-), 17:56, 16/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
По поводу получения рута...
Вот, к перимеру, один способ наметился: https://www.opennet.ru/opennews/art.shtml?num=21291 . А когда его исправят, то, думаю, еще, чего-нибудь, найдут...
| | |
| 1.46, Аноним (-), 21:00, 16/04/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Правильно-ли я понял, что опция STRICT_DEVMEM появилась только в 2.6.25 (по умолчанию NO) => в RHEL,CentOS по умолчанию YES ?
| | |
|
