Права доступа Unix, SUID, SGID, Sticky биты
Содержание
Вступление
В Unix каждому файлу соответствует набор прав доступа, представленный в виде 9-ти битов режима. Он определяет, какие пользователи имеют право читать файл, записывать в него данные или выполнять его. Вместе с другими тремя битами, влияющими на запуск исполняемых файлов, этот набор образует код режима доступа к файлу. Двенадцать битов режима хранятся в 16-битовом поле индексного дескриптора вместе с 4-мя дополнительными битами, определяющими тип файла. Последние 4 бита устанавливаются при создании файлов и не подлежат изменению. Биты режима (далее права) могут изменяться либо владельцем файла, либо суперпользователем с помощью команды chmod.
Существует три пути управления доступом к файлу или каталогу. Было определено, что каждый файл должен иметь владельца (owner), группового владельца (group owner), а также может потребоваться доступ для всех остальных пользователей (everyone). Эти названия обычно приводятся как пользователь/группа/остальные (user/group/others) или коротко ugo. Реализация управления доступом к файлам и каталогам в Unix позволяет или запрещает доступ по трем флагам: флаг чтения (Read), флаг записи (Write), флаг выполнения (eXecute). Они представляются следующим образом:
Флаг типа (flag) может быть одним из следующих:
Права доступа
Посмотреть права доступа на объекты можно командой ls c ключем -l («л»). Также можно добавить ключ -a, для того,чтобы были отображены скрытые объекты:
Рассмотрим таблицу, чтобы было понятнее:
Для администрирования часто удобнее использовать не буквенное представление прав, а цифровое, в восьмеричном представлении (оно короче). Так, например, права на файл всем и вся, соответствуют записи 777 (что аналогично символьному представлению rwxrwxrwx).
Существуют также специальные биты, такие как SUID, SGID и Sticky-бит. SUID, SGID влияют на запуск файла, а Sticky влияет на определение владельца объектов в каталоге. При их применении необходимо использовать не три восьмеричных цифры, а 4. Зачастую, в различной технической литературе права обозначаются именно 4-мя цифрами, например 0744. Многие стараются не использовать специальные биты, сетуя на безопасность (и не без основательно), но, в некоторых ситуациях без них не обойтись. Поговорим о них несколько позже.
Давайте рассмотрим пример, итак:
Восьмеричное обозначение прав для файла pro_ubuntu.zip: 0700.
Для второй строки (это каталог, о чем свидетельствует флаг «d»), по аналогии:
Восьмеричное обозначение в этом примере: 0755.
На практике для каталогов используется только три режима: 7 (rwx), 5 (r-x) и 0 (—).
Но не надо думать, что такой каталог полноценно заменяет крипто-контейнер (т.е. может использоваться для хранения очень секретных данных). Да, имен объектов из такого каталога никак не получить, однако если попытаться создать объект с именем, которое уже существует, то такая операция закончится неудачей (т.е. мы получим подтверждение, что такое имя уже есть). Так же можно пытаться открыть (как файл или как каталог) объект с произвольным именем, если такого имени нет, то мы получим ошибку. Безусловно имя может быть очень длинным и шансы угадать его могут быть не велики, но не надо забывать, что права доступа могут сменить как владелец каталога так root. Да и пути доступа могут сохраниться в различных логах и файлах истории.
Команда chmod
Права устанавливаются командой chmod. Команда chmod поддерживает установку прав как в восьмеричном представлении, так и в символьном (маска режима доступа).
Синтаксис команды прост:
chmod
Опции
Из самых полезных и часто используемых опций можно выделить одну:
Права
Права можно записывать как в восьмеричном представлении так и в символьном. В восьмеричном представлении, для стандартных прав, указываются 3 восьмеричные цифры (1-я для владельца, 2-я для группы, 3-я для всех остальных. См. таблицу выше).
Для назначения прав используются три знака: минус, плюс или равно:
Использование символьного представления позволяет редактировать права файлов более гибко:
Символьное назначение окажет неоценимую услугу, если требуется добавить права на объект к уже существующим правам.
Массовое назначение прав
Иногда, бывает, нужно массово установить права на определенный тип объектов, например, только на каталоги или только на файлы. Простое использование опции -R (рекурсия) здесь не поможет т.к. chmod будет проходить по всем объектам удовлетворяющим маске, что иногда вовсе не то, что нужно.
Итак, чтобы массово установить права на определенный тип объектов можно использовать один из вариантов (вообще, их очень много):
Более длинный вариант аналогичной операции:
Биты SUID, SGID и Sticky
Если при создании пользователя основная группа не указана явно, то основной группой пользователя будет группа с тем же именем, что и имя пользователя. Например:
Что касается процессов, то с ними связано не два идентификатора, а 4-е: реальный и эффективный пользовательский (UID), а также реальный и эффективный групповой (GID). Реальные номера применяются для учета использования системных ресурсов, а эффективные для определения прав доступа к процессам. Как правило, реальные и эффективные идентификаторы совпадают. Владелец процесса может посылать ему сигналы, а также изменять приоритет.
Вобщем, одним словом установка битов SUID или SGID позволит пользователям запускать исполняемые файлы от имени владельца (или группы) запускаемого файла. Например, как говорилось выше, команду chmod по умолчанию может запускать только root. Если мы установим SUID на исполняемый файл /bin/chmod, то обычный пользователь сможет использовать эту команду без использования sudo, так, что она будет выполнятся от имени пользователя root. В некоторых случаях очень удобное решение. Кстати по такому принципу работает команда passwd, c помощью которой пользователь может изменить свой пароль.
Однако, в системе FreeBSD, если скомпилировать ядро с поддержкой suiddir, а так же смонтировать раздел с этой опцией, то, все объекты создаваемые в каталоге где установлен SUID будут иметь владельца этого каталога (наследование). Реализация подобного в Linux возможна (?) на файловой системе GFS2. Данная функция считается уязвимостью.
Установить SUID и SGID можно командой chmod:
Я есть root. Повышение привилегий в ОС Linux через SUID/SGID
В прошлом посте я провел «обзорную экскурсию» по методам повышения привилегий в ОС Linux. Сегодня разбираю вектор повышения привилегий через небезопасные разрешения SUID/SGID. Поэтому больше консоли и меньше слов.
Что такое SUID?
Бит смены владельца или SUID (Set User ID) — это разрешение файловой системы Linux, которое позволяет запустить исполняемый файл от имени его владельца. Он нужен, потому что многие действия в Linux (например, открытие «сырого» сетевого сокета) требуют прав суперпользователя. Хорошо знакомая всем команда ping использует сетевые сокеты и поэтому должна быть запущена от root’а. Каким образом можно позволить обычному пользователю применять команду ping? Можно выдать пользователю sudo на необходимые команды. Но представьте, что на условной Linux-машине имеется 100 пользователей и насчитывается около 20 привилегированных команд. А как потом управлять разрешениями sudo на все это «богатство»? Не самое элегантное решение, не правда ли? С другой стороны, бит смены владельца значительно упрощает процесс. Бит смены владельца сообщит системе, что все 100 пользователей системы запускают команду ping от имени root.
Итак, мы с вами поняли, что представляет собой SUID, но также это понимают и хакеры. В большинстве случаев повышение привилегий через исполняемый файл с SUID возможно, если:
Пример с curl
Разберемся по порядку. Допустим, я обнаружил, что исполняемому файлу curl выставлен бит смены владельца, мы можем это понять по букве s в разрешениях файла.
Выставление SUID для curl
Выставленный SUID позволяет скачивать файл от имени root’а. Поскольку файл скачивает root, то он же является и владельцем файла.
Загрузка файла через curl с SUID
Хорошо, что с этим делать дальше? Попытаюсь заменить какой-нибудь чувствительный файл: /etc/passwd подходит как нельзя лучше. Сначала скопирую существующий файл на хост атакующего.
Скачиваю файл командой scp
В полученном файле поменяю ID пользователя и группы для пользователя bob с 1000 на 0 (что соответствует root).
Исходные ID пользователя bob
Отредактированный файл скачаю на атакуемый хост с помощью команды curl.
Успешное повышение привилегий
Пример с systemctl
Думаю, стало понятнее, однако давайте разберем другой пример: я подобрал пароль пользователя bob и получил доступ по SSH. Осматриваюсь и изучаю окружение — в этом случае командой find.
Почувствуй разницу: слева вывод linpeas, справа, по сути, тот же вывод, но команда find введена вручную
Нахожу в выводе команды find бинарник /usr/bin/systemctl. Раз у меня есть доступ к systemctl, да еще и в контексте root (ведь я нашел этот бинарник, выполняя поиск файлов, владельцем которых является root и для которых выставлен suid), я могу запустить вредоносный сервис. Особого кун-фу тут не требуется, достаточно создать текстовый файл с описанием сервиса.
Демонстрация работы сервиса
Мне ничего не мешает изменить сервис, например, написать в него бэк-коннект. Остается только поднять хендлер (обработчик) на хосте атакующего и перезапустить сервис.
Успешное повышение привилегий. Наверху хендлер, внизу запуск сервиса
Я привел примеры, в которых бит смены владельца выставлен у пользователя root, но этот вектор также можно использовать для компрометации менее привилегированных пользователей системы. Как видите, бит смены владельца — это довольно чувствительная к безопасности «вещь», и он может оказаться узким местом харденинга Linux-системы.
Главное в этом векторе, как и везде в offensive, — понимать, как все устроено. Я рекомендую повторить пару примеров, чтобы не только понять, но и осознать полученную информацию. Для практики можно самому поднять стенд и поэкспериментировать, а можно совместить приятное с полезным и поискать write up’ы hackthebox устаревших машин, где для повышения привилегий использован вектор с SUID. Порешать их, прокачать свой аккаунт, рассказать о нем на собеседовании. Со временем вы поймете, что write up’ы лишают вас ощущения победы, и когда почувствуете в себе силы, сможете применять накопленный багаж знаний.
Больше конкретных примеров повышения привилегий через SUID можно найти тут, включая разобранный нами.
А что с битом смены группы владения SGID (Set Group ID)?
В целом суть та же, но некоторые трюки будут сложнее, например /etc/passwd таким образом перезаписать не удастся, так как группе root нельзя редактировать файл. Да и сервис перезапустить не получится.
Разрешения файла /etc/passwd не позволяют группе root изменение
Попытка перезапуска сервиса
Остается вариант с интерактивным шеллом, например через vim. Для этого используйте команду:
Группа root позволяет читать содержимое директории /root, но при этом нельзя даже прочитать содержимое файла id_rsa. Бит смены группы владения SGID дает несравнимо меньшие возможности для повышения привилегий.
Содержимое директории /root
Харденинг
Для безопасного харденинга рекомендую исключить наличие бита смены владельца/группы для указанных в перечне исполняемых файлов. При этом нужно учитывать, что за удалением бита смены владельца/группы могут последовать некорректное поведение сервиса и траблшутинг. И уж точно не стоит удалять бит смены владельца у всех исполняемых файлов.
Напоследок
В статье я использовал примеры из лучшего, на мой взгляд, сборника по повышению привилегий gtfobins.
linux-notes.org
Стандартные права (SUID, SGID, Sticky bit) в Unix/Linux
Использование «sticky bit» прав в Unix/Linux
Unix является многопользовательской ОС и в основном, устроен так, что несколько пользователей могут работать одновременно. Таким образом, программа которая находится в памяти требует меньше времени чтобы начать свою работу. Таким образом, когда один пользователь только что использовал программу, а затем новый пользователь хочет использовать ту же самую программу, то 2-й юзверь не будет иметь временной задержки для инициализации утилиты.
Установка Sticky Bit
Выставляем sticky bit на файл:
Или можно еще использовать следующую команду:
Sticky bit, в основном используется в общих каталогах, таких как /var или /tmp, поскольку пользователи могут создавать файлы, читать и выполнять их, принадлежащие другим пользователям, но не могут удалять файлы, принадлежащие другим пользователям. Например, если пользователь (предположим bob) создает файл с именем /tmp/bob, то другой пользователь (допустим tom) не может удалить этот файл, даже если в каталоге /tmp есть разрешение 777. Если sticky bit не установлен, то tom юзер может удалить /tmp/bob, так как файл /tmp/bob наследует разрешения родительского каталога.
Использование SUID ( Set User ID) прав в Unix/Linux
setuid (сокращения от англ. set user ID upon execution — «установка ID пользователя во время выполнения) являются флагами прав доступа в Unix, которые разрешают пользователям запускать исполняемые файлы с правами владельца исполняемого файла. Иногда файлы требуют разрешения на выполнение для пользователей, которые не являются членами группы владельца, в этом случае вам потребуется предоставить специальные разрешения на выполнение. Когда SUID установлен, пользователь может запускать любую программу, такую как владелец программы.
Установка SUID бит на файл.
Если SUID бит установлен на файл и пользователь выполнил его. Процесс будет иметь те же права что и владелец файла.
Например: команда passwd имеет SUID bit. Когда обычный пользователь захочет изменит свой пароль в файле /etc/passwd или /etc/shadow, то у него ничего не получиться, т.к нужны права суперпользователя (процесс командны PASSWD всегда работает с правами суперюзера).
Предположим, что я получил исполняемый файл «filename», и мне нужно установить SUID на этот файл, перейдите в командную строку и выпуск команду:
Теперь проверьте разрешения на файл с командой:
Наблюдайте за «s» буквой, которая была добавлена для SUID бита:
Чтобы выставить SUID для всех папок и файлов, используем:
Найти SUID файлы
Найти все SUID файлы для «root» пользователя:
Найти все SUID и SGID файлы:
Использование SGID ( Set Group ID ) прав в Unix/Linux
setgid (сокращения от англ. set group ID upon execution — «установка ID группы во время выполнения») являются флагами прав доступа в Unix, которые разрешают пользователям запускать исполняемые файлы с правами группы исполняемого файла.
Установка бита SUID / SGID
Если SGID бит установлен на любой каталог, все подкаталоги и файлы, созданные внутри получат те же пермишены что и группы в качестве основного каталога.
Устанавливаем SGID на директорию:
Теперь, переключаемся на другого пользователя и создаем файл в папке /home/captain/test_dir:
В приведенном выше примере test_file.txt создался с группой root.
Чтобы выставить SGID для всех папок и файлов, используем:
Найти SGID файлы
Найти все файлы с использованием SGID бита, для root пользователя:
Найти все SUID и SGID файлы:
Зачем нужены SUID и SGID?
Есть достаточно много программ и файлов, которые должны принадлежать пользователю root, и в то же время – простые пользователи должны иметь возможность выполнять его. Для примера – утилита passwd, которая находится в каталоге /usr/bin/passwd и которая имеет дело с файлом /etc/passwd, редактировать который может только пользователь root.
Вот еще полезное чтиво:
Команда chmod также может использоваться для установки или отмены следующих значений в качестве префикса для обычных трех числовых привилегий:
Тема «Стандартные права (SUID, SGID, Sticky bit) в Unix/Linux» завершена.
SUID и безопасность
Предисловие. Некогда в июне 2001 года в журнале «Системный администратор» (Sys Admin Magazine, June 2001, Volume 10, Number 6) была опубликована статья Томаса Акина «Danger of SUID Shell Scripts», которая не теряет своей актуальности и сегодня. К сожалению, в конце лета 2007 года журнал перестал выходить. По неизвестным мне причинам сайт журнала также прекратил существование — точнее он сейчас переадресовывает посетителей на другой. Было бы здорово, если бы сайт просто «заморозили», сохранив архив всех накопившихся материалов, который бесспорно представил бы собой кладезь полезной практической информации для специалистов сферы ИТ. В Сети можно найти скудные копии статьи, о которой идет речь; у меня же нашелся бумажный вариант оригинала и я хочу представить вольный перевод с небольшим дополнением. Некоторые моменты статьи мне кажутся несколько глупыми (например, использование временных файлов), некоторые — непривычными (оболочки, которые использует автор), но в целом я уверен — в статье есть на что обратить внимание, взять на заметку и не забывать.
Опасность использования SUID в сценариях командной оболочки
Уровень сложности: простой
Некоторые соглашения. SUID-программы, SUID-приложения — исполняемые файлы, имеющие атрибут setuid (в дополнение к атрибуту исполнения).
SUID-сценарии, SUID-скрипты — аналогично, сценарии командного интерпретатора, имеющие атрибут setuid в дополнение к атрибуту выполнения.
Unix-система — Unix или любая Unix-подобная операционная система.
Данная статья предпринимает попытку пройтись по тонкой границе между полным раскрытием и созданием эксплойта. Целью является иллюстрация работы SUID-приложений, чтобы помочь остальным избежать распространенных ошибок при написании своих программ. Примеры, приведенные в статье, достаточно разобраны для того, чтобы помочь понять каждую опасность, но нет гарантии, что все будет работать именно так, как показано, в случае попытки злонамеренного использования.
Обычно, сценарии и программы в Unix выполняются с правами пользователя, который их запустил. Вот почему простые пользователи не могут изменить свои пароли путем прямой правки файла /etc/passwd (Unix-системы не хранят более в данном файле пароли, а только информацию об учетных записях — прим.); у них нет прав на запись в /etc/passwd и ни одна команда, выполненная ими, не сможет этого сделать. Однако, SUID-программы перекрывают нормальные права доступа и всегда выполняются с правами владельца программы. Следовательно, пользователи могут с помощью команды /usr/bin/passwd менять свои пароли. Программа /usr/bin/passwd имеет атрибут SUID и пользователя root как владельца. Она всегда выполняется с правами пользователя root:
Когда начинающие администраторы открывают для себя атрибут SUID они видят его как панацею и незамедлительно начинают его использовать для программ и сценариев, чтобы упростить себе работу. К сожалению, очень часто они поступают неверно.
Работая с администраторами, которые недавно познакомились с атрибутом SUID, часто можно встретить сценарии, подобные этому:
% ls change-pass
-rwsr-x— 1 root helpdesk
37 Feb 26 16:35 change-pass
Данный простенький скрипт призван разрешить службе поддержки (группа helpdesk) сбрасывать пароли пользователей, что является довольно частой задачей. Сценарию присвоен атрибут SUID и суперпользователь установлен в качестве владельца. Члены группы helpdesk могут читать и запускать данный сценарий на выполнение. который полон «дыр» безопасности подобно решету. В рамках статьи будут рассмотрены семь из них, а также варианты, как их избежать.
Первоочередной проблемой является использование C-shell. Сценарии этой оболочки уязвимы к манипуляциям с переменными окружения. Для того, чтобы использовать это как преимущество, взломщик может скомпроментировать учетную запись службы поддержки и получить оболочку с правами суперпользователя следующим образом:
% env TERM=’`cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755/tmp/sh`’ change-pass
Урок первый — никогда не используйте C-shell для SUID-сценариев
Переменная PATH была изменена и теперь команда change-pass вызовет /tmp/passwd вместо /usr/bin/passwd.
Урок второй — необходимо всегда вручную устанавливать переменную окружения PATH и использовать абсолютные пути
Теперь PATH в безопасности и используются абсолютные пути, но если присмотреться можно заметить, что сценарий может изменить пароль любого пользователя даже root. Мы ведь не хотим, чтобы кто-либо из службы поддержки (или взломщик) с помощью нашего скрипта изменить пароль суперпользователя.
Урок третий — необходимо понимать работу задействованных программ
Теперь мы никому не позволим изменить пароль пользователя root, но обратите внимание на использование временного файла (лично я этой необходимости понять не могу — прим.). Сценарий удаляет временный файл, создает его, заполняя именем пользователя, пароль которого следует сбросить, и в конце концов проверяет, не root ли этот пользователь. Что если злоумышленник очень точно отмеряет момент, когда файл будет удален, а новый еще не создан, и создаст пустой файл /tmp/.user? Будет ли он перезаписан? Возможно да, а возможно и нет… Зависит от настроек системы. Если созданный взломщиком /tmp/.user не будет перезаписан, проверки в скрипте будут пройдены и passwd предложит сменить пароль суперпользователя (случай с отсутствием аргументов — прим.). Для облегчения проведения подобной атаки злоумышленник может составить специальную программу для отслеживания активности (появления файла /tmp/.user в данном случае) и подмены необходимого файла.
Примечание. Такие типы атак основаны на временных задержках (далее будет еще один подобный пример).
Урок четвертый — не используйте временный файлы или (в случае неизбежной необходимости их применения) не помещайте их в доступные на запись остальным места
% change-pass «user;cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755 /tmp/sh»
/usr/bin/passwd user;cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755 /tmp/sh
заставит сценарий вызывать не /usr/bin/passwd, а вместо этого выполнить по порядку usr, bin и passwd. Теперь злоумышленник может создать скрипт с названием usr, который создает оболочку с правами root, а наш SUID-сценарий выполнит его.
Урок шестой — всегда определяйте IFS вручную
возможно выполнить что угодно от имени root. Применяя такую технику шансы на успех крайне малы, но существуют методики и программы, которые повышают вероятность успеха и помогают автоматизировать процесс. Существует два способа защититься от подобного рода атак. Первый — не использовать SUID-сценарии командной оболочки. Вторым обладают некоторые системы (например, Solaris), который заключается в предотвращении возникновения условий «гонок» путем передачи описателя открытого файла сценария командной оболочке, избегая таким образом необходимости в переоткрытии и чтении файла SUID-скрипта.
Урок седьмой — не используйте SUID-сценарии
Даже после всей проделанной работы практически невозможно написать безопасный SUID-сценарий командной оболочки (это невозмножно на большинстве систем). Из-за указанных выше проблем некоторые системы (например, Linux) не поощряют установку атрибута SUID на командные сценарии. Существует три более безопасных способа получить функциональность SUID: программа-обертка на языке C, скрипт на Perl или программа подобная sudo. Начинающим в безопасном программировании следует использовать sudo или Perl-программу. Suidperl имеет втроенные механизмы защиты от ошибок программиста, описанных в статье. Дополнительную информацию о безопасном программировании с использованием атрибута SUID можно найти в книге «Practical UNIX & Internet Security» (O’Reilly & Associates) или статье «Writing Safe Setuid Programs».
Послесловие. Прототип программы-обертки для использования SUID:
#include
#include
#include
#include