Anthony Lineberry подготовил (http://www.dtors.org/index/main/95) для конференции Black Hat Europe (http://www.blackhat.com/html/bh-europe-09/bh-eu-09-main.html), проходящей в Амстердаме с 14 по 17 апреля, доклад (http://www.dtors.org/papers/malicious-code-injection-via-dev...) (PDF, 100 Кб) с демонстрацией нового способа внедрения RootKit-кода в работающее ядро Linux системы. Суть метода основана на использовании интерфейс /dev/mem для прямой подстановки злонамеренного кода в области памяти ядра с организацией переброса управления непосредственно из любого участка кода ядра.
Например, возможно внедрение обработчиков нужных системных вызовов, не использующих какие-либо стандартные методы перехвата, что существенно усложняет обнаружение rootkit-а и значительно упрощает его код. Ранее rootkit обычно оформлялся в виде замаскированного модуля ядра, перехватывающего управление через LSM интерфейс или таблицу прерываний. Кроме того, для перехвата управления для руткита предлагалось...URL: http://www.darkreading.com/security/vulnerabilities/showArti...
Новость: https://www.opennet.ru/opennews/art.shtml?num=21271
Надеюсь, что на этот раз ядро патчить не прийдется чтобы руткит заработал ?
> Надеюсь, что на этот раз ядро патчить не прийдется чтобы руткит заработал?Придётся, конечно. Этот root kit именно это и делает -- патчит ядро через /dev/mem. Системному администратору нужно всего одну команду подать -- "chmod 666 /dev/mem" :)))
>делает -- патчит ядро через /dev/mem. Системному администратору нужно всего одну
>команду подать -- "chmod 666 /dev/mem" :)))Вот только если хаксор как-либо отхватит рута, обнаружить его потом будет довольно нетривиально.Лишний пример того как любую даже самую хорошую фичу можно поюзать и с неблаговидными целями.Системному администратору соответственно надо прежде всего не щелкать клювом.И вообще мне так кажется что есть еще с полдюжины не очень очевидных но простых способов подгрузить руткит разных ОС.Что у нас там следующее?Руткиты через DMA?Руткиты в видеобиосе? :)
DMA??? :) Где-то проскакивало сообщение о возможности внедрения в систему через IEEE1394 именно благодаря возможности работать с DMA, предусмотренной протоколом интерфейса. Причём в этом случае нам никаких прав иметь не нужно, нужны лишь доступ к атакуемому хосту и включённый на нём порт. Так что остались только руткиты в видеобиосе.
>только руткиты в видеобиосе.Кстати вон в соседней новости - рассказы про багу udev позволяющую проапгрейдиться до рута.Очень мило, как раз в тему - теперь поставить руткит может и просто лузер с птичьими правами иной раз :)
Остап знал 500 относительно честных способов незаметной загрузки руткитов...
+1
А что есть клоуны которые для сервера включает поддержку /dev/mem и дают всем рутовый пароль?
>А что есть клоуны которые для сервера включает поддержку /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.
Здорово!А ядро менять целиком таким способом можно?
Можно. Но такая фигня получится %-)
>Можно. Но такая фигня получится %-)Не все выйдет .Механизм смены ядра на горячию уже давно встроен в ядро .
Помоему в алте 4.0 (бета ) или что то около этой версии даже использовался этот миханизм ,init только там нестандартный ,не помню номера .Многие жаловались что зависает и установка не заканчивается ,но на моей машинке ядро перезагружалось .
>Не все выйдет .Механизм смены ядра на горячию уже давно встроен в
>ядро .Если речь про kexec, то он с точки зрения пользователя от перезагрузки отличается мало. Или уже что-то новое появилось?
да, можно
самый простой способ cat /dev/rand > /dev/mem
по умолчанию права на /dev/mem вроде как 640.
очередной "руткит", рассчитанный на админа-идиота.
>по умолчанию права на /dev/mem вроде как 640.
>очередной "руткит", рассчитанный на админа-идиота.Даже по самому слову видно, что руткит это инструмент для оставления бэкдора после получения рутового доступа к системе. Как этот рут получен неважно, обманом или взломом незакрытой дыры в ядре, руткит уже совершенно другой этап работы атакующего.
там же русскими буквами написано "руткит", т.е. использовать его нужно, когда уже есть права рута в системе и нужно их скрыть от настоящего админа
>очередной "руткит", рассчитанный на админа-идиота.Гм, если б руткит можно было втулить от юзера - это был бы вообще пи$#ец.Реальный такой пи$#ец.Потому что большая часть админов вообще не знала бы что делает их машина в данный момент =)
в винду можно втулить руткит вообще удалённо через очередную кривость в rpc и dcom(которые особо и не нужны), но ничего, все пользуют
>в винду можно втулить руткит вообще удалённо через очередную кривость в rpc
>и dcom(которые особо и не нужны), но ничего, все пользуютОй, не надо о этих протоколах.На мое мнение RPC - это что-то типа удаления гланд через попу автогеном.При том еще и геморное если надо его через нат или файрвол пропихнуть.А насчет линуха - не ну такого вопиющего пиндеца как ремотный эксплойт ядра я так сходу не припоминаю за ближайшее время но в принципе не стоит сбрасывать возможность подобного эксплойта со счетов.Все-таки ядро у линуха достаточно большое и полностью проаудитить его нелегко.В основных сетевых подсистемах надеюсь, более менее проблемы вылвили но в конце концов, людям свойственно ошибаться.
ну подобный метод ковыряться в ядре, нужно признаться, достаточно старый. хотя и вполне рабочий :)// wbr
>достаточно старыйМягко сказано. Ему лет 10-12.
больше хаков в ядре - лучше для развития линукса. появятся еще более непробиваемые hardened дистры
да уж куда дальше то непробиваемее.. ;)// wbr
вот ещё интересная инфа по этой теме
http://www.phrack.org/archives/58/p58_0x07_Linux%20on-t...
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/mempavel@amd64:~> cat /etc/group | grep kmem
kmem:x:9:
И как туда внедрять?
Народ, вы мелко смотрите. Почитайте, что ли, манифесты этого Black Hat. Какое счастье от взлома единственного сервака, кроме как бездарно подефейсить какую-нибудь веб-страничку и радостно написать об этом в журнал "Хакер"?Идея в том, чтобы на скомпрометированном сервере как можно дольше выполнялся несанкционированный код, и притом это никак нельзя было заметить. Предлагаемый способ хорош тем, что после подчистки логов на машине не будет СОВСЕМ ничего, указывающего на факт взлома -- а главное, на то, что код злоумышленника продолжает работать! Ни изменённых файлов, ни лишних процессов, ничего. Все контрольные суммы сойдутся.
Что может делать этот зловредный код? Например, патчить ядра, раскладываемые в собираемый дистрибутив сборочным сервером...
Вы чем слушаете???? Как внедрить-то ??? Без прав UID=0;
>Вы чем слушаете????Я читаю.
>Как внедрить-то ??? Без прав UID=0;Вот я и говорю: мелко смотрите. Думаете, вся цель нормального взломщика состоит в получении прав UID=0? Это не так сложно, как кажется, особенно если не ограничиваться чисто спортивными попытками добыть рута исключительно программным путём за fixnum время.
Black Hat -- люди серёзные, они разговаривают не об этом, а о том, что делать после.
GRKERNSEC_KMEM здесь помогает, да.
>после подчистки логов на машине не будет СОВСЕМ ничего, указывающего на факт взломаИнтересно, а если есть в сети машина, относительно независимая, которая только и делает, что дублирует логи с других систем.
На ней же не удастся логи "почистить"?
>Интересно, а если есть в сети машина, относительно независимая, которая только и
>делает, что дублирует логи с других систем.Хорошая идея. правильная.
>На ней же не удастся логи "почистить"?Её придётся заДОСить. Задача тем самым усложняется.
Думаю, такие машины не имеют входа извне локалки, так что заДОСаный лог-сервер -- очень яркий признак того, что внутри сети нелады, а это противоречит тактике взломщика.
>да уж куда дальше то непробиваемее.. ;)Говорили раньше пользователи Лисы. :)
Практика, правда показала, что как только она набрала критическую массу пользователей, по дырявости она, глобально, перегнала Осла. Да, патчи быстрее появляются, но быстрое появление новых дыр "компенсирует" это небольшое преимушество (не говоря уже о том, что "быстрое появление" (в том числе патчей) нередко соседствует с пословицей "быстро хорошо не бывает" (чем быстрее появилось, тем хуже оттестировано ("одну дыру убрали, десять добавили"))).
Посему, про надежность и не пробиваемость не надо...
Есть подозрение, что ядро, как и Тормозила, в случае набора критической массы простых пользователей (серваки это совершенно другое) будет много дырявее виндового (В Винде, если сидеть не под Админом, тоже вполне безопасно...)...
>Винде, если сидеть не под Админом, тоже вполне безопасно...)...от кидо тебя это не спасет :)
Про дыропад (вполне возможно, что много круче виндового) в следствии увеличения критической массы простых пользователей сказано выше (в посте, на который ты ответил). :) Кто его знает, не появится ли, когда-нибудь, Кидо дя Линя (коли критическая масса простых юзеров будет)?...
Как бы для этого PAX придумали
http://en.wikipedia.org/wiki/Address_space_layout_randomization
Одну единственную машину 100% не защитишь, но предотвратить массовое заражение можно.А в винде можно и WriteProcessMemory попробовать использовать, или в Memory Manager Routines что нибудь подобрать.
Убирать /dev/mem, какой в этом смысл?
Загрузи свой модуль, он запустится в адресном пространстве ядра, сделает и оставит такой же руткит. А потом выгрузи его.Если ты уже получил рута то ты бог в системе.
Логи попробовать делать remote с записью на болванки, если появилась запись что логирования былы отключено, бить тревогу. Но здесь много тонкостей.
По поводу получения рута...Вот, к перимеру, один способ наметился: https://www.opennet.ru/opennews/art.shtml?num=21291 . А когда его исправят, то, думаю, еще, чего-нибудь, найдут...
Правильно-ли я понял, что опция STRICT_DEVMEM появилась только в 2.6.25 (по умолчанию NO) => в RHEL,CentOS по умолчанию YES ?
Нифига метод не новый - это раз.И два - он не работает.