The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Новый способ внедрения rootkit в Linux ядро

15.04.2009 12:59

Anthony Lineberry подготовил для конференции Black Hat Europe, проходящей в Амстердаме с 14 по 17 апреля, доклад (PDF, 100 Кб) с демонстрацией нового способа внедрения RootKit-кода в работающее ядро Linux системы. Суть метода основана на использовании интерфейса /dev/mem для прямой подстановки злонамеренного кода в области памяти ядра с организацией переброса управления непосредственно из любого участка кода. Например, возможно внедрение обработчиков нужных системных вызовов, не использующих какие-либо стандартные методы перехвата, что существенно усложняет обнаружение rootkit-а и значительно упрощает его код.

Ранее rootkit обычно оформлялся в виде замаскированного модуля ядра, перехватывающего управление через LSM интерфейс или таблицу прерываний. Кроме того, для перехвата управления предлагалось задействовать отладочные функций процессора, интегрировать код в монитор виртуальных машин, внедрить код в BIOS (через перепрошивку Flash) или использовать уязвимость в CPU Intel и запустить код в режиме SMM, более привилегированном, чем код ядра ОС, выполняющийся в нулевом кольце защиты (Ring 0).

Новый метод основан на идее Silvio Cesare, предложившего более 10 лет назад простой способ для накладывания патчей на Linux ядро без остановки работы системы, через прямое изменение частей ядра посредством /dev/mem интерфейса для доступа к физической памяти.

  1. Главная ссылка к новости (http://www.darkreading.com/sec...)
  2. OpenNews: Уязвимость в процессорах Intel, позволяющая выполнить код на уровне SMM
  3. OpenNews: Для Linux выпущен руткит принципиально нового типа
  4. OpenNews: На конференции EUSecWest будет представлен первый rootkit для Cisco
  5. OpenNews: Прототип руткита работающего как виртуальная машина
  6. OpenNews: Концепция руткита, интегрируемого в BIOS
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/21271-kernel
Ключевые слова: kernel, rootkit, patch, memory
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (39) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 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 относительно честных способов незаметной загрузки руткитов...
     
     
  • 2.4, Андрей (??), 14:30, 15/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    +1
     

  • 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.

     

  • 1.7, geekkoo (ok), 14:49, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Здорово!

    А ядро менять целиком таким способом можно?

     
     
  • 2.9, darkk (?), 15:01, 15/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Можно. Но такая фигня получится %-)
     
     
  • 3.35, maximnik0 (?), 02:48, 16/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Можно. Но такая фигня получится %-)

    Не все выйдет .Механизм смены ядра на горячию уже давно встроен в ядро .
    Помоему в алте 4.0 (бета ) или что то около этой версии даже использовался этот миханизм ,init  только там нестандартный ,не помню номера .Многие жаловались что зависает и установка не заканчивается ,но на моей машинке ядро перезагружалось  .


     
     
  • 4.40, darkk (?), 08:55, 16/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Не все выйдет .Механизм смены ядра на горячию уже давно встроен в
    >ядро .

    Если речь про kexec, то он с точки зрения пользователя от перезагрузки отличается мало. Или уже что-то новое появилось?

     
  • 2.47, sluge (??), 11:07, 17/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    да, можно
    самый простой способ cat /dev/rand > /dev/mem
     

  • 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

     
     
  • 2.53, jcoder (?), 05:01, 09/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >достаточно старый

    Мягко сказано. Ему лет 10-12.

     

  • 1.17, Аноним (-), 17:24, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    больше хаков в ядре - лучше для развития линукса. появятся еще более непробиваемые hardened дистры
     
  • 1.18, klalafuda (?), 17:27, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/

    да уж куда дальше то непробиваемее.. ;)

    // wbr

     
  • 1.21, Аноним (-), 18:59, 15/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    вот ещё интересная инфа по этой теме
    http://www.phrack.org/archives/58/p58_0x07_Linux%20on-the-fly%20ker
     
  • 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. Какое счастье от взлома единственного сервака, кроме как бездарно подефейсить какую-нибудь веб-страничку и радостно написать об этом в журнал "Хакер"?

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

    Что может делать этот зловредный код? Например, патчить ядра, раскладываемые в собираемый дистрибутив сборочным сервером...

     
     
  • 2.30, pavlinux (ok), 23:20, 15/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Вы чем слушаете???? Как внедрить-то ??? Без прав UID=0;
     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю, такие машины не имеют входа извне локалки, так что заДОСаный лог-сервер -- очень яркий признак того, что внутри сети нелады, а это противоречит тактике взломщика.
     

  • 1.41, Аноним (-), 09:46, 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 ?
     
  • 1.52, mastedm (?), 00:33, 25/05/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нифига метод не новый - это раз.

    И два - он не работает.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Ideco
    A-Real
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру