Защита точек монтирования
Основной способ взаимодействия с Unix-машиной — через файловую систему. Следовательно, когда нарушитель получил доступ к системе, желательно ограничить его возможности оперировать доступными ему файлами. Одним из способов достичь этого является использование ограничивающих параметров монтирования.
Параметр команды mount — это флаг, управляющий доступом к файловой системе. Он передается программному коду ядра операционной системы в момент подключения файловой системы. Параметры монтирования могут применяться для того, чтобы файлы не были использованы как узлы устройств (device nodes), что, в свою очередь, исключит возможность исполнения двоичного кода и отменит действие SUID-бита (с помощью флагов nodev, поехес и nosuid). С использованием параметра го файловые системы могут монтироваться доступными только для чтения.Эти параметры указываются в командной строке запуском команды mount с флагом -о. Например, если имеется отдельный раздел для каталога /tmp, то есть третий раздел первого IDE жесткого диска, вы можете смонтировать его с помощью следующей команды:
# mount -о nodev,поехес,nosuid /dev/hda3 /tmp
Аналогично для /etc/fstab это будет выглядеть следующим образом: /dev/hda3/tmp ext3 defaults,ncdev,noexec,nosuid 1 2
Внимательно изучив требования к разбиению носителя на множество файловых систем, вы можете использовать параметры монтирования для увеличения объема работы, которую предстоит выполнить взломщику для проникновения в систему. Самый быстрый способ сделать это — распределить дерево каталогов на области, в которые можно записывать (для нормального функционирования системы), и области, для которых операция записи не нужна. Флаг «только для чтения» можно использовать в отношении любой части файловой системы, в которой содержание меняется редко. Хорошим кандидатом для этого может быть каталог /usr в зависимости от того, насколько часто обновляется системное программное обеспечение.
Понятно, что многие каталоги (такие, как /home) должны монтироваться с возможностью записи и чтения. Однако маловероятно, чтобы обычным пользователям многопользовательских систем понадобилась возможность запуска двоичных файлов SUID или создания файлов устройств в собственном домашнем каталоге. Следовательно, для размещения домашних каталогов пользователей могли бы создаваться отдельные файловые системы, монтируемые с обоими параметрами, nodev и nosuid. Кроме того, если вы определили, что пользователям не надо выполнять программы, хранящиеся в домашних каталогах, можно дополнительно использовать параметр поехес. Аналогичная ситуация возникает и с каталогами /tmp и /var, для которых крайне маловероятно, что какому-то процессу понадобится выполнить двоичные SUID- или He-SUID-файлы или обратиться к файлам устройств. Это усложняет для атакующего возможность установки «троянского коня» в общих каталогах, которыми являются /tmp и домашний каталог пользователя. Взломщик может установить программу, но не сможет запустить ее на выполнение при наличии или в отсутствие соответствующим образом установленных разрядов chmod. Обратите внимание на то, что работа служб, запущенньж в окружении chrootO, может быть нарушена, если параметр nodev указан для файловой системы, запущенной под enroot. Вот почему узлы устройств, такие как /dev/log и /dev/nuO, должны быть доступны в окружении chroot().
Существует несколько способов, с помощью которых взломщик все же может обойти ограничения монтирования. Например, параметр поехес в операционной системе (ОС) Linux может быть не охвачен использованием /lib/ld-linux.so для выполнения двоичных файлов, находящихся в таких файловых системах. На первый взгляд кажется, что такое поведение можно исправить, сделав Id-linux.so неисполняемым, но из-за этого неисполняемыми станут все динамически подключаемые двоичные файлы. Поэтому если только все программы, на которые вы полагаетесь, являются статически подключаемыми (что, вероятно, не так), то параметр поехес малопригоден в Linux. Помимо этого, взломщик, который уже обладает root-привилегиями, без труда справится с файловыми системами, смонтированными со специальными параметрами, поскольку зачастую он сразу же сможет их перемонтировать командой remount с параметром -о. Но за счет использования флагов монтирования вы можете легко ограничить возможности атак, доступных недружелюбному пользователю, пока он не получил привилегии корневого каталога.
Потенциальным способом для пользователя повысить уровень привилегий в системе является исследование уязвимости SUID- и SGID-программ. SUID и SGID используются законно в тех случаях, когда программам требуются специальные разрешения, превосходящие разрешения пользователя, запускающего их. Одной из таких программ является passwd. Она позволяет пользователю изменять пароль, но одновременно не позволяет ему изменять системный файл паролей. Вот почему она должна запускаться с root-привилегиями. Таким образом, если у программы установлен разряд SUID, это означает, что она может выполняться с привилегиями владельца файла программы. А когда установлен разряд SGID, программа будет выполнена с привилегиями владельца группы файлов.
Результат выполнения команды 1 s -1 в отношении двоичного файла, у которого установлен разряд SUID, будет выглядеть следующим образом:
-r-s--x--x I root root 16336 Feb 13 2003 /usr/bin/passwd
Обратите внимание: разряд выполнения (х) теперь имеет значение s, которое указывает, что это SUID-файл.
К сожалению, неверно созданные двоичные SUID- или SGID-файлы могут быть использованы для быстрого и простого повышения привилегий пользователя. Кроме того, взломщик, который уже получил root-полномочия, может спрятать SUID-файлы по всей вашей системе, чтобы оставить лазейку для последующего доступа. Это вынуждает нас сканировать систему на наличие двоичных SUID-или SGID-файлов. Это простая задача и она может быть выполнена с помощью такой команды:
# find / \( -perm -4000 -о -perm -2000 \) -type f -exec Is -la {} \;
Необходимо учесть один важный момент: является SUID-программа сценарием ядра или исполняемым файлом. Позже для кого-то может не составить труда изменить безвредный сценарий, превратив его в лазейку. Большинство операционных систем будет игнорировать любые SUID- или SGID-разряды в сценариях ядра, но, если вы хотите найти все SUID- и SGID-сценарии в системе, измените аргумент -exec в предыдущей команде и добавьте канал, так чтобы команда выглядела следующим образом:
# find / \( -perm -4000 -о -perm -2000 \) \ -type f -exec file {} \; I grep -v ELF
Теперь при обнаружении любого SUID- или SGID-файла будет запускаться команда file, которая определяет тип исследуемого файла. Если он является исполняемым, его проверит grep, в противном случае он будет выведен на экран с соответствующим сообщением. Большинство операционных систем использует ELF-формат исполняемых файлов, но если вы пользуетесь операционной системой, которая этого не делает (старые версии Linux, использующие a.out, и АIХ, использующие XCOFF), то вам придется заменить ELF в предыдущей команде grep двоичным форматом, используемым вашей операционной системой. Если вы точно не знаете, что ищете, запустите команду fi lе в отношении любого двоичного исполняемого файла, и она выдаст строку, которую вы искали.
Вот пример выполнения команды file в отношении двоичного файла в ОС Mac OS X:
$ file /bin/sh /bin/sh: Mach-0 executable ppc
Следующим шагом вперед является создание с помощью с г on очереди команд для запуска один раз в день и перенаправления результатов ее выполнения в файл. Например, представленный далее вариант использования crontab должен сканировать файлы, у которых установлен разряд SUID илл SGID, сравнивать текущий список со списком, полученным днем ранее, а затем отправлять электронное сообщение о различиях между ними владельцу crontab (все это должно вводиться одной строкой):О 4 * * * find / \( -perm -4000 -о -perm -2000 \) -type f \> /var/log/sidlog.new && diff /var/log/sidlog.new /var/log/sidlog && mv /var/log/sidlog.new /var/log/sidlog
В этом примере текущий список SUID- и SGID-файлов сохраняется в /var/log/sidlog.
Метки: Unix, Взлом