LINUX.ORG.RU

Kiddy — модуль ядра Linux для защиты от скрипт-кидди

 , , ,


0

2

Kiddy – модуль для ядра Linux, разработанный с целью снижения рисков эксплуатации (некоторых) уязвимостей ядра.

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

Например, вот как это сделано для CVE-2017-1000112. Там же можно видеть, что идентификация версии ядра осуществляется с использованием uname.

Разработанный модуль является простым в реализации и позволяет:

  • менять идентификацию ядра;
  • ограничивать доступ к журналу ядра (dmesg);
  • ограничивать доступ к некоторым файлам в /proc, также содержащим идентифицирующую информацию;
  • ограничивать доступ к файлам и папкам, потенциально содержащим идентифицирующую информацию;
  • менять идентификацию версии ядра, доступную через vDSO.

В процессе сборки модуль позволяет использовать т.н. «пресеты», реализующие различную логику изменения идентификации. Например, используя пресет «windows» можно получить следующее поведение:

До загрузки модуля

$ ./misc/id.sh
** UNAME identidty leaks
 - uname -r
   2.6.32-754.35.1.el6.x86_64
 - uname -v
   #1 SMP Sat Nov 7 12:42:14 UTC 2020
 - uname -a
   Linux localhost.localdomain 2.6.32-754.35.1.el6.x86_64 #1 SMP Sat Nov 7 12:42:14 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
** PROCFS identidty leaks
 - /proc/cmdline
   ro root=/dev/mapper/VolGroup00-LogVol00 rd_NO_LUKS no_timer_check console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16  rd_LVM_LV=VolGroup00/LogVol01 rd_LVM_LV=VolGroup00/LogVol00  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
 - /proc/version
   Linux version 2.6.32-754.35.1.el6.x86_64 (mockbuild@x86-02.bsys.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC) ) #1 SMP Sat Nov 7 12:42:14 UTC 2020
 - /proc/sys/kernel/version
   #1 SMP Sat Nov 7 12:42:14 UTC 2020
 - /proc/sys/kernel/osrelease
   2.6.32-754.35.1.el6.x86_64
which: no hostnamectl in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/vagrant/bin)

После загрузки модуля

$ ./misc/id.sh
** UNAME identidty leaks
 - uname -r
   Windows
 - uname -v
   NT 4.0
 - uname -a
   Linux localhost.localdomain Windows NT 4.0 x86_64 x86_64 x86_64 GNU/Linux
** PROCFS identidty leaks
 - /proc/cmdline
   \EFI\Microsoft\Boot\bootmgfw.efi
 - /proc/version
   Windows NT 4.0
 - /proc/sys/kernel/version
   NT 4.0
 - /proc/sys/kernel/osrelease
   Windows
which: no hostnamectl in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/vagrant/bin)

Скрипт-кидди не пройдут!

>>> Подробности

★★

Проверено: hobbit ()
Последнее исправление: CYB3R (всего исправлений: 5)

Эмм, я либо дурачок либо достаточно глянуть имя дистра в условном /etc/os-release и перепробовать максимум десяток таблиц на соответствие тем ядрам которые актуальны для дистра.
А если иметь табличку контрольных меток по ядрам то можно быренько пробежаться по ней и понять версию.

rukez ★★★★
()

Троллинг скрипткидди какой-то...
Но боюсь, что такая идентификация и нормальный софт может поломать

mittorn ★★★★★
()
Ответ на: комментарий от rukez

/etc/os-release можно также добавить в список блокируемых на доступ файлов, а если перепробовать 10 таблиц, то есть неиллюзорная вероятность подвесить систему, вместо того, чтобы получить на ней рута =)

i82 ★★
() автор топика
Ответ на: комментарий от mittorn

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

i82 ★★
() автор топика

Напугали ёжика голой попой. Security by obscurity не работает.

К тому же эра script-kiddy канула в лету в тоже время, что и fidonet, лет 20 назад.

Сейчас эра ботов.

beastie ★★★★★
()
Ответ на: комментарий от beastie

Сейчас эра ботов.

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Бот просто не доберётся до /proc и uname. Это уже надо прорвать не первый десяток защит и получить шел, чтобы заюзать такое.

А как защита от того, кто уже имеет шел-доступ – это как-то мимо кассы. Обосрались уже раньше.

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 2)

Ну хорошо, наверное... А что, lkrg уже не торт, что бы еще что-то понадобилось? Я как-то Солару больше верю :)

gns ★★★★★
()
Ответ на: комментарий от gns

На самом деле, данный проект явился следствием попытки реализовать определённый набор функций в lkrg, на что в итоге у меня не хватило желания/терпения:

https://github.com/lkrg-org/lkrg/pull/150

Кроме того, функциональность модуля Kiddy предельно простая и, в отличие, от lkrg её можно быстро оценить и, при необходимости, оперативно подправить =)

i82 ★★
() автор топика

oh shit~

>>> fp=open('/boot/vmlinuz-linux','rb')
>>> data.find(b'6.8.1')
17164
>>> pos=data.find(b'6.8.1')
>>> data[pos:pos+100]
b'6.8.1-arch1-1 (linux@archlinux) #1 SMP PREEMPT_DYNAMIC Sat, 16 Mar 2024 17:15:35 +0000\x00\x00\x932\x00\x00I2\x00\x00\x9b2\x00\x00'
rtxtxtrx
()
Ответ на: комментарий от rtxtxtrx

Кто же мог-то подумать, что сам бинарь версию ядра содержит ряяяяяяяяя. Сначала нужно епта самому из обосранных штанишек вырасти, а потом со «скрипт-киддисами» бороться, а то у многих есть иллюзия, что овладение цэпэпэ их делает сверхчеловеками, а не такими же недопрограммистами как 1сники и тп

rtxtxtrx
()
Ответ на: комментарий от i82

не буду я твою вирусню ставить, там 100% троян зашит, потом стану частью ботнета, который в том же телеграме говном спамит

rtxtxtrx
()
Ответ на: комментарий от rtxtxtrx

Да не бро, я почему уточняю, потому что к /boot доступ блокируется. Вот и думаю - или я чего-то не доглядел, или ты. Выходит что второе.

i82 ★★
() автор топика
Ответ на: комментарий от rtxtxtrx

Ну ты на практике покажи, как ты будешь идентифицировать ядро при загруженном модуле. Я с радостью добавлю защиту от того, что ты найдёшь. Или ты просто так, языком почесать?

i82 ★★
() автор топика
Ответ на: комментарий от i82

я просто версию системды посмотрю, посмотрю год, вот и год версии ядра на сервере, или посмотрю время изменения файлов в корне… но оно не нужно. рут твой не нужен абсолютно. нужно в базы залезть чтобы вытянуть креды от карточек, персональные данные и продать их нигерийским мошенникам, а для прочих целей, например, чтобы поднять прокси или сканировать сеть рут не нужен, гошные утилиты берешь качаешь, собранные с CGO_ENABLED=0, там все потроха внутри… не знаю отчего этот модуль защищает

rtxtxtrx
()
Ответ на: комментарий от rtxtxtrx

Вот сразу видно профессионала - креды от карточек в базах, нигерийские мошенники, ага =)

i82 ★★
() автор топика
Ответ на: комментарий от beastie

А как защита от того, кто уже имеет шел-доступ – это как-то мимо кассы. Обосрались уже раньше.

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

i-rinat ★★★★★
()
Ответ на: комментарий от gns

Возможность в заранее написанном коде легко и точно определить сборку ядра повышает вероятность успешного обхода LKRG, так что функциональность Kiddy нам было бы неплохо включить в одну из будущих версий LKRG. Спасибо @i82 за эксперименты в этом направлении.

solardiz
()
Ответ на: комментарий от i-rinat

По большей части так и есть. Вреда от попыток избежать утечки данных по сторонним каналам куда больше чем пользы. Отобрать высокоточные таймеры у скриптов и накидать туда життеров легко, а вот у нативного кода уже нет. ИМХО на устройстве конечного пользователя лучше признать что если у есть исполнение кода - то это уже геймовер, чем пытаться строить ещё с десяток барьеров. RCE в процессе-рендерере имеет большой шанс получить доступ к чужим текстурам через GPU, давайте отберём у браузера GPU, да и CPU через KVM виртуализируем...
Это конечно не касается многопользовательских серверов, где исполнение кода даётся разным пользователям и ограничение сторонних каналов им уже имеет смысл, как и защита от детекции версии для ботов и школьников.

mittorn ★★★★★
()
Последнее исправление: mittorn (всего исправлений: 1)
Ответ на: комментарий от beastie

К тому же эра script-kiddy канула в лету в тоже время, что и fidonet, лет 20 назад.

Спорное утверждение. Их стало поменьше, но всё ещё много, и остались самые упорные. Всё ещё такие же ничего не знающие и не понимающие, но готовые тратить уйму своего времени.

CrX ★★★
()
  • ограничивать доступ к журналу ядра (dmesg);
  • ограничивать доступ к некоторым файлам в /proc, также содержащим идентифицирующую информацию;
  • ограничивать доступ к файлам и папкам, потенциально содержащим идентифицирующую информацию;

Ждём портирования винлокеров на линукс! \ö/

mord0d ★★★★★
()
Ответ на: комментарий от i-rinat

Про бровзеры – это да. Раньше такого не было. ;)

beastie ★★★★★
()
Ответ на: комментарий от Aceler

Вывод rpm блокируется за счет возможности добавить каталоги с базой данных и логами в списки блокировки. Например, /var/cache/{yum,rpm}.

i82 ★★
() автор топика
Ответ на: комментарий от Aceler

Не, ну rpm для обновления софта от рута запускается же, а для рута поведение Kiddy прозрачно.

i82 ★★
() автор топика

какая-то гротескная реализация

kto_tama ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Именно так и сделано, список папок и файлов для ограничения доступа легко редактируется (пресеты)

i82 ★★
() автор топика
Ответ на: комментарий от pascal

Не осилил раст, но идея интересная =)

i82 ★★
() автор топика
Ответ на: комментарий от i82

У пользователя может быть индикатор обновлений.

Aceler ★★★★★
()
Ответ на: комментарий от i82

PackageKit :-)

В редхате из коробки. Сам демон запускается от рута, клиент от пользователя связывается с ним через d-bus.

Aceler ★★★★★
()

Любители ставить софт через wget | curl оценят. И пользователи САПРов, когда там чеки операционки улетят в ад.

ncrmnt ★★★★★
()
Ответ на: комментарий от Aceler

Надо смотреть. Похожая ситуация была с hostnamectl, который с systemd по d-bus как раз общается. Но это я решил, возможно и в случае с PackageKit будет работать без модификаций.

i82 ★★
() автор топика
Ответ на: комментарий от ncrmnt

Там САПР сразу Windows будет видеть, так что всё ок.

i82 ★★
() автор топика
Ответ на: комментарий от rtxtxtrx

Падажи, а почему /boot в принципе доступен юзерам даже на чтение? У него по-умолчанию umask=0077, то есть юзеры не должны видеть его содержимое. На это помнится даже системда ругается варнингами (смотрите журнал), так как в разделе есть чувствительная информация типа файла random-seed. Если он world-readable, то это дыра в безопасности конкретно вашей системы.

greedyskoof
()
Ответ на: комментарий от i82

простой вопрос, элементарный скрипт на сях, собранный на каком-то стареньком дебиане (чтоб точно работал в современных дистрибутивах), как тут например, https://stackoverflow.com/questions/46280456/check-kernel-version-at-runtime-... что напишет? Я твой троянец ставить не хочу чтоб проверять что там.

peregrine ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.