Linux повысить права до root

Как дать Root права пользователю в Linux

Суперпользователь «root” — это король пользователей Linux / Unix. Наличие корневого доступа предоставляет полный и неограниченный доступ к дистрибутиву Linux.

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

Как дать Root права пользователю в Linux

Согласно разрешениям файловой системы Linux, root или суперпользователь имеет полные права на чтение (r), запись (w) и выполнение (x) любого файла. По умолчанию идентификатор пользователя root равен «0».

Я собираюсь создать двух пользователей, а именно user1 и user2. Затем я предоставлю root-правак пользователю «user1«.

Способ 1: Добавление в корневую группу с помощью usermod

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

# adduser user1
# adduser user2
# groupadd test

Это группы, которые есть в моей дистрибутиве Linux.

# groups
root bin daemon sys adm disk wheel

Я собираюсь добавить user1 в корневую группу следующим образом:

Приведенная ниже команда даст пользователю привилегию root

Способ 2: Добавление в корневую группу с помощью команды Useradd

Я добавил нового пользователя «user3» в корневую группу с помощью команды:

# useradd -m -G root user3
# groups user3
user3 : user3 root

useradd -c “Imitation Root” -d /home/root_user -m -k /etc/skel -s /bin/bash -u 0 -o -g root root_user

Способ 3: Редактирование файла /etc/passwd

Отредактируйте /etc/passwd для конкретного пользователя. Измените UID и GID пользователя на «0«. Это даст root права пользователю в linux.

Теперь пользователь temproot должен иметь привилегии root:

ВНИМАНИЕ: это не рекомендуемый метод предоставления корневого доступа (root-прав)

Способ 4: Дать права пользователя Sudo

Конфигурационный файл sudo — это файл /etc/sudoers, и вы можете отредактировать его с помощью команды visudo:

Использование visudo защищает от конфликтов и гарантирует использование правильного синтаксиса.

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

Добавьте в файл запись, приведенную ниже:

Следовать этому методу не очень хорошая идея, потому что это позволяет и User1, и User2 использовать команду su для предоставления постоянных привилегий root. Таким образом пропуская функции ведения журнала команд sudo.

Предоставление доступа к определенным файлам одному конкретному пользователю

Эта запись позволяет User 1 и всем другим членам группы получить доступ ко всем программным файлам в каталогах /sbin и /usr/sbin, а также привилегию выполнения команды /usr/oracle/backup.pl…

User1, %operator ALL= /sbin/, / usr/sbin, /usr/oracle/backup.pl

Если у вас есть какие-либо вопросы или предложения по этой теме, оставьте комментарий.

Источник

Я есть 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.

1. curl
2. systemctl
3. vim

Если у вас появится интерес к разбору других кейсов повышения привилегий через SUID/SGID (или нет, не важно), пишите в комментариях или мне в личку. В следующем посте обсудим, как получать стабильный shell. Успешной охоты!

Источник

Пользователи в Linux. Повышение пользовательских прав su или sudo.

Продолжаем знакомиться с типами пользователей и средствами администрирования в Linux. Сегодня я хочу рассказать о повышении прав обычного пользователя с помощью команд su и sudo.

Во всех UNIX-системах всегда существует пользователь с расширенными привилегиями, как правило это пользователь root, имеющий право на выполнение любых операций. Его свобода действий ничем не ограничена, в отличии от обычных пользователей имеющих ограничения в правах.

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

Назначение пользователю администраторских прав может привести к следующим проблемам.

• Пользователь обладающий администраторскими правами может неправильно настроить систему, в связи с этим могут возникнуть технические проблемы и дыры в безопасности.
• Пользователь обладающий администраторскими правами может запустить небезопасные службы.
• Пользователь обладающий администраторскими правами может запустить небезопасные почтовые вложения. Это больше актуально в Windows, хотя в Linux тоже есть вирусы.
• Пользователь обладающий администраторскими правами может запустить небезопасные скрипты, программы или команды.
• Малейшая опечатка в выполняемой команде, может удалить важные файлы или директории целиком, если работа идет с правами root.

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

Повышение пользовательских прав командой su

Давайте рассмотрим такую ситуацию, когда пользователю нужно установить некую программу, например wget.

Все, приехали, для выполнения этой команды нужны привилегии суперпользователя. Что делать дальше? Далее можно воспользоваться так называемым повышением пользовательских прав. Для подобных целей существует команда su.

Что-же произошло в процессе выполнения команды? При выполнении команды был запрошен пароль суперпользователя, после ввода пароля происходит подмена имени пользователя test на имя root, что дает пользователю право выполнять все действия от его имени.

Было [test@test2

]$, стало [root@test2 test]#. Теперь можно установить нужную программу или выполнить необходимую операцию, ради которой все это и было затеяно. Для возвращения назад используют команду exit.

После выполнения команды exit происходит возвращение в свое пользовательское окружение [test@test2

Существует еще один вариант выполнения команды — su —. При выполнении su — изменяется не только имя, но и рабочее окружение пользователя.

Были [test@test2

]$, стали [root@test2

]#. Грубо говоря стали пользователем root, до тех пор пока не будет выполнена команда exit и пользователь не вернется назад в свое окружение.

У некоторых читателей может появиться вопрос: Зачем это нужно, если обычный пользователь зная пароль root может входить напрямую, без всяких заморочек? Да может, зная пароль это не составит особого труда. Я описываю ситуацию когда root и обычный пользователь, это один и тот-же человек.

Некоторые пользователи закрывают удаленный root-доступ на свои VPS/VDS сервера в качестве меры безопасности. Поскольку напрямую под root они входить уже не могут, то входят от имени обычного пользователя, после чего повышают себя до root для выполнения нужных задач.

А как быть если пользователей много? Ведь это не есть хорошо, когда пароль root знает каждый из них. В том-то и дело что не каждый юзер знает пароль. Грамотный администратор не будет разбрасываться паролем направо и налево, а доверит его только проверенным пользователям. Пароль может знать каждый, но не каждый сможет его применить, этой привилегией обладает тот, кто входит в специальную группу пользователей.

В UNIX-системах существует так называемая группа wheel, только входящие в нее пользователи могли выполнять команду su. В последних версиях Linux любой пользователь может выполнять su по умолчанию, а раньше у них такой возможности не было. В старых версиях Linux и системе FreeBSD, команда su могла выполняться только после внесения пользователя в группу wheel администратором.

Подобную манипуляцию пользователями можно провернуть и в современных версиях Linux. Допустим что у нас есть два пользователя techlist_1 и techlist_2, по умолчанию не относящиеся к группе wheel.

Читайте также:  Leshcatlabs catalyst для ноутбуков windows 10

Добавим пользователя techlist_1 в группу wheel, а techlist_2 оставим без изменений.

Отредактируем файл /etc/pam.d/su для возвращения возможности разделения пользователей, как в старых версиях Linux.

Проверим как теперь пользователи смогут выполнять команду su. Сначала проверим входящего в группу wheel пользователя.

Теперь второго, которого не добавляли в группу.

Что и требовалось доказать. Один пользователь выполняет команду su, а другой не может. Вот так может работать повышение пользовательских прав при помощи команд su и su -.

Повышение пользовательских прав командой sudo

Существует более современный способ повышения пользовательских прав с помощью команды sudo (substitute user and do — подменить пользователя и выполнить).

Sudo является программой системного администрирования, дающей возможность выполнять команды от имени root. Если для выполнения команды su все пользователи должны были знать пароль root, что само по себе небезопасно, то sudo его не требует. В sudo нужен пароль самого пользователя.

Sudo работает следующим образом, перед командой которую необходимо выполнить, нужно добавить sudo, например:

Sudo определяет пользователя сверяясь с настройками находящимися в файле /etc/sudoers, если пользователь внесен в sudoers, то команда выполняется. Если выполнить команду sudo от имени пользователя не внесенного в sudoers, то можно увидеть такую картину:

При попытке выполнить команду sudo, от имени пользователя test, выдается ответ что такого пользователя в файле sudoers не обнаружено. О событии создается запись в лог файле, также высылается электронное письмо root-пользователю с уведомлением о случившемся.

Для того чтобы пользователь мог выполнять sudo, его надо внести в файл sudoers. Сделать это можно двумя способами.

Первый способ — внесение имени пользователя непосредственно в сам файл /etc/sudoers. Для изменения файла sudoers, требуется обладать правами root.

После того как пользователь будет внесен в список допущенных к использованию, он может выполнять команду sudo.

Вторым способом разрешить пользователям выполнять команду sudo, является внесение пользователя в группу wheel, точно так же как в случае с командой su.

После перезагрузки системы, пользователь внесенный в группу wheel, сможет выполнять sudo.

Для того чтобы полностью сменить окружение пользователя на окружение root, используется команда sudo -i, что равносильно использованию команды su —

Возвращение в свое пользовательское окружение, происходит при помощи команды exit.

Каждый раз при использовании sudo, требуется ввод пароля пользователя. При вводе пароля, происходит обновление временной метки, что позволяет выполнять sudo без ввода пароля на протяжении некоторого времени. По умолчанию ввод пароля не требуется на протяжении пяти минут, после чего пароль опять будет затребован. Временной промежуток можно изменить при помощи опции timeout в файле sudoers. Существует возможность отключения ввода пароля.

Отключить ввод пароля для пользователей принадлежащих к группе wheel:

Отключить ввод пароля для пользователей добавленных вручную:

Sudo гибкая в настройке и позволяет настроить множество различных параметров. Грамотный администратор знающий sudo может творить настоящие чудеса с пользователями.

Для просмотра руководства по настройке sudo, выполняется команда:

Ограничение доступа для root

После настройки sudo и назначения пользователям нужных прав, можно ограничить доступ к учетной записи root. Существует несколько способов защиты от входа под root и ограничения доступа к его учетной записи.

Изменение пользовательской оболочки root

Для предотвращения входа в оболочку root, достаточно отредактировать файл /etc/passwd, заменив оболочку /bin/bash на /sbin/nologin. Данный способ предотвращает доступ к учетной записи root, с помощью команд использующих оболочку и протокола ssh.

Пробуем подключиться по ssh от имени root.

Пробуем выполнить команду su от имени обычного пользователя.

Таким образом достигается полное запрещение доступа от имени root, так и выполнение команд от его имени другими пользователями. Администратор настроив свой аккаунт пользователя и наделив его необходимыми правами может обходиться sudo не прибегая к помощи root.

Запрет удаленного доступа для root

Данный способ запрещает удаленное подключение от имени root по протоколу ssh. Ограничение затрагивает только ssh доступ, все остальные команды: su — или su — продолжают работать.

Для этого вносят изменения в файл /etc/ssh/sshd_config

Запрет доступа root с консольных устройств

Для ограничения доступа к учетной записи root, администраторы также могут запретить вход с любых консольных устройств использующих tty. Для реализации этого ограничения требуется очистить файл /etc/securetty.

Файл очищается и применяются изменения. Сначала не помешает сделать бэкап файла.

Источник