Команды только для root

Разделение привилегий — основа безопасности в операционной системе Linux. Обычные пользователи работают с ограниченными привилегиями и могут влиять только на собственную рабочую среду, но не на операционную систему в целом. Пользователь с именем root имеет привилегии суперпользователя — это административная учетная запись без ограничений.

Использование su для получения прав root

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

su -l pavel
Пароль: здесь-пароль-pavel

Справка по команде su.

В Ubuntu для суперпользователя пароль не задан, поэтому нельзя запустить сеанс root. Как правильно ввести пароль, которого нет? Чтобы обойти это ограничение, достаточно добавить sudo перед su.

Хотя в Ubuntu нет пароля для root, его всегда можно установить. И запускать сеанс root с помощью su, без sudo. Но делать это не рекомендуется без веских причин.

Обратите внимание, что мы не указываем имя пользователя для passwd — в этом случае подразумевается root. Чтобы вернуть Ubuntu в исходное состояние, нужно заблокировать учетную запись root.

sudo passwd -l root

Использование sudo для запуска команд от root

Иногда нужно выполнить несколько команд с правами root и вводить каждый раз sudo (и периодически — пароль) может быть неудобно. Тогда можно начать сеанс root, выполнить все команды, после чего завершить сеанс.

Справка по команде sudo.

Присвоение пользователю привилегий sudo

В Ubuntu группа sudo имеет полные привилегии администратора. Добавляя пользователя в эту группу, мы предоставляем ему такие же привилегии.

Проверка прав при использовании sudo

Проверить, какие права есть у пользователя при использовании команды sudo, можно с помощью опции -l.

Также можно узнать, может ли пользователь с помощью sudo выполнить ту или иную команду. Если команда запрещена, то ничего не будет выведено. Если команда разрешена, то будет выведен полный путь до файла.

sudo -l -U evgeniy passwd # команда разрешена
/usr/bin/passwd
sudo -l -U vasiliy passwd # команда запрещена

Файл конфигурации /etc/sudoers для sudo

Команда sudo настраивается с помощью файла /etc/sudoers. Редактировать это файл можно только с помощью команды visudo, которая перед сохранением проверяет синтаксис файла. Обычно visudo открывает файл /etc/sudoers в текстовом редакторе vi. Однако в Ubuntu команда visudo настроена на использование текстового редактора nano.

Строки по умолчанию Defaults

Первая строка Defaults env_reset сбрасывает среду терминала для удаления переменных пользователя. Эта мера безопасности используется для сброса потенциально опасных переменных среды в сеансе sudo.

Вторая строка, Defaults mail_badpass, предписывает системе отправлять уведомления о неудачных попытках ввода пароля sudo для настроенного пользователя. По умолчанию это учетная запись root.

Бывает, что злоумышленники пытаются запускать вредоносную программу с помощью sudo, которая разветвит фоновый процесс и он остается активным на терминале пользователя, даже после того как основная программа завершила свое выполнение. Чтобы избежать этого, можно настроить sudo на запуск команд только с помощью psuedo-pty с использованием параметра use_pty.

Строки пользовательских привилегий

Пятая строка файла конфигурации определяет права для пользователя root. Давайте посмотрим, что означают различные поля.

ALL=(ALL:ALL) ALL # Поле показывает имя пользователя, для которого составлено это правило
root =(ALL:ALL) ALL # Первое ALL означает, что данное правило применяется ко всем хостам
root ALL=(:ALL) ALL # Второе ALL разрешает root запускать команды от лица любого пользователя
root ALL=(ALL:) ALL # Третье ALL разрешает root запускать команды от лица любой группы
root ALL=(ALL:ALL) # Последнее ALL разрешает пользователю root запускать любые команды

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

Строки привилегий для групп

Данная строка означает, что файлы в каталоге /etc/sudoers.d также рассматриваются как файлы конфигурации и применяются. В основном это нужно, чтобы приложения могли изменять привилегии sudo после установки. Файлы в этом каталоге следуют тем же правилам, что и сам файл /etc/sudoers. И редактировать эти файлы следует только с помощью команды visudo.

sudo visudo -f /etc/sudoers.d/file-to-edit

Настройка персонализированных правил

Мы познакомились с общим синтаксисом файла, а теперь попробуем создать новые правила.

Создание псевдонимов

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

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

Если не указать пользователя или группу «запуска от имени», команда sudo по умолчанию использует пользователя root.

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

Прочая информация по команде sudo

Если задать в файле конфигурации пользователя или группу, от имени которых выполняются команды, можно выполнять команды от их имени.

sudo -g run-as-group command

Для удобства sudo сохраняет данные аутентификации в течение определенного количества времени на одном терминале. Это означает, что не нужно будет вводить пароль снова, пока это время не истечет. В Ubuntu по умолчанию это 15 минут — изменить это можно, если добавить следующую строку в файл конфигурации.

Defaults timestamp_timeout=60

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

Команда sudo -k позволяет сбросить таймер сохранения данных аутентификации. То есть, после выполнения команды с использованием sudo, выполнение команды sudo -k удалит данные аутентификации.

Команда sudo -v запросит пароль и сохранит данные аутентификации для последующего использования sudo без ввода пароля. Данные аутентификации сохраняются на то кол-во минут, которое указано в файле конфигурации.

Поиск:
Linux • Ubuntu • Команда • Настройка • Пользователь • Права доступа • su • sudo • root

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Время на прочтение

Первый квартал 2020 года я провел за подготовкой к экзамену OSCP. Поиск информации в Google и множество «слепых» попыток отнимали у меня все свободное время. Особенно непросто оказалось разобраться в механизмах повышения привилегий. Курс PWK уделяет этой теме большое внимание, однако методических материалов всегда недостаточно. В Интернете есть куча мануалов с полезными командами, но я не сторонник слепого следования рекомендациям без понимания, к чему это приведет.

Мне хочется поделиться с вами тем, что удалось узнать за время подготовки и успешной сдачи экзамена (включая периодические набеги на Hack The Box). Я испытывал сильнейшее ощущение благодарности к каждой крупице информации, которая помогала мне пройти путь Try Harder более осознанно, сейчас мое время отдать должное комьюнити.

Я хочу дать вам мануал по повышению привилегий в OS Linux, включающий в себя разбор наиболее частых векторов и смежных фишек, которые вам обязательно пригодятся. Зачастую сами механизмы повышения привилегий достаточно несложные, трудности возникают при структурировании и анализе информации. Поэтому я решил начать с «обзорной экскурсии» и далее рассматривать каждый вектор в отдельной статье. Надеюсь, я сэкономлю вам время на изучение темы.

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

Повышение привилегий через небезопасную конфигурацию

Прежде всего давайте разберемся с небезопасной конфигурацией. Начнем с того, что ИТ-специалисты часто пользуются мануалами и ресурсами вроде stackoverflow, многие из которых содержат небезопасные команды и конфиги. Яркий пример — новость о том, что самый копируемый со stackoverflow код содержал ошибку. Опытный админ увидит косяк, но это — в идеальном мире. Даже грамотные специалисты при повышенной рабочей нагрузке способны допускать ошибки. Представьте, что админ занимается подготовкой и согласованием документации на очередной тендер, параллельно вникает в новую технологию, которую предстоит внедрить в следующем квартале, при этом периодически решает задачи по поддержке пользователей. И тут ему нарезают задачу по-быстрому поднять пару виртуалок и раскатать на них сервисы. Как вы думаете, какова вероятность того, что админ просто не заметит косяк? Потом специалисты меняются, а костыли остаются, при этом компании всегда стремятся минимизировать затраты, в том числе на ИТ-шников.

Получаем стабильный shell

Системная оболочка, полученная на стадии эксплуатации, часто бывает ограниченной, особенно если вы заполучили ее через взлом пользователя веб-сервера. Например, ограничения оболочки могут помешать применить команду sudo с выводом ошибки:

sudo: no tty present and no askpass program specified

После получения оболочки я рекомендую создать полноценный терминал, например, с помощью Python.

python -c ‘import pty;pty.spawn(«/bin/bash»)’

Вы спросите: «Зачем мне тысяча команд, если я могу воспользоваться одной, например, для передачи файлов?» Дело в том, что системы бывают сконфигурированы по-разному, на очередном хосте может быть не установлен Python, однако иметься Perl. Мастерство в том, чтобы иметь возможность делать в системе привычные вещи без привычных инструментов. Полный перечень возможностей можно найти тут.

Низкопривилегированный шелл можно получить, используя команды 1 и команды 2 (удивительно, что даже GIMP).

Просмотр истории команд

Linux собирает историю всех выполненных команд в файле ~/.bash_history. Если сервер активно используется, и его история не очищается, существует большая вероятность найти в этом файле учетные данные. Чистить историю банально неудобно. Если администратор вынужден выбирать десятиэтажные команды через , конечно, ему будет удобнее вызвать эту команду из истории, чем вводить заново. Плюс многие не знают об этом «хаке». Если в системе присутствуют альтернативные оболочки вроде Zsh или Fish, они ведут свою историю. Чтобы вывести историю команд в любой оболочке, достаточно набрать команду history.

cat ~/.bash_history
cat ~/.mysql_history
cat ~/.nano_history
cat ~/.php_history
cat ~/.atftp_history

Поиск паролей в файловой системе и атаки на смежные системы

Команда sudo дает пользователю возможность выполнить команду в контексте root с помощью собственного пароля или вовсе без его использования. Многие операции в Linux требуют привилегий root, однако работа из-под root считается очень плохой практикой. Вместо этого лучше применять выборочное разрешение на выполнение команд в контексте root. Однако многие инструменты Linux, включая стандартные типа vi, можно использовать для повышения привилегий вполне легитимными способами. Для поиска подходящего способа рекомендую посмотреть здесь.

Первое, что нужно сделать, получив доступ в систему, — выполнить команду sudo -l. Она выведет разрешение на использование команды sudo. Если получен пользователь без пароля (например, apache или www-data), вектор повышения привилегий через sudo маловероятен. При использовании sudo система запросит пароль. Через команду passwd задать пароль также не выйдет, она запросит текущий пароль пользователя. Но если sudo все же доступен, то, по сути, необходимо искать:

Suid/Sgid

В Интернете есть множество мануалов, которые советуют собрать все suid/sgid команды, однако редкая статья даёт конкретику, что делать с этими программами. Варианты повышения привилегий, не учитывающие применение эксплоитов, можно найти тут. Также ряд исполняемых файлов имеет специфические уязвимости под версию ОС, например.

В идеальном мире нужно пропустить все установленные пакеты хотя бы через searchsploit. На практике подобное стоит проделывать с наиболее популярными программами типа sudo. Также всегда есть вариант использовать и поддерживать разработку автоматизированных инструментов, которые подсветят интересные, с точки зрения повышения привилегий, исполняемые файлы с выставленными битами suid/sgid. Перечень таких инструментов я приведу в соответствующем разделе статьи.

Доступные на запись скрипты, запускаемые Cron или Init, в контексте Root

Задачи cron могут выполняться в контексте различных пользователей, в том числе root. Если в cron выставлена задача со ссылкой на исполняемый файл, и он доступен вам для записи, его легко можно подменить вредоносным и выполнить повышение привилегий. При этом по умолчанию файлы с задачами cron доступны на чтение любому пользователю.

ls -la /etc/cron.d # show cron jobs

Похожим образом обстоят дела с init. Отличие в том, что задачи в cron выполняются периодически, а в init — при старте системы. Для эксплуатации потребуется перезагрузка системы, при этом часть сервисов может и не подняться (если они не были прописаны в автозагрузку).

ls -la /etc/init.d/ # show init scripts

Также можно поискать файлы, доступные для записи любому пользователю.

Метод довольно известный, опытные системные администраторы аккуратно пользуются командой chmod. Однако на просторах Сети в подавляющем большинстве мануалов описано выставление максимальных прав. Подход неопытных системных администраторов «лишь бы заработало» создает возможности для повышения привилегий в принципе. Если есть возможность, лучше поискать в истории команд небезопасное использование chmod.

chmod +w /path
chmod 777 /path

Получение доступа в оболочку других пользователей

Смотрим список пользователей в /etc/passwd. Обращаем внимание на тех, у кого есть оболочка. Можно побрутить этих пользователей — не исключено, что через полученного пользователя в итоге удастся повысить привилегии.

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

Самописный код

Стоит внимательно посмотреть на исполняемые файлы в домашней директории пользователя и веб-сервера (/var/www/, если не задана другая). Эти файлы могут оказаться совершенно небезопасным решением и содержать в себе невероятные костыли. Конечно, если вы имеете какой-нибудь фреймворк в директории веб-сервера, не имеет смысла искать в нем zero-day в рамках пентеста, однако найти и изучить кастомные доработки, плагины и компоненты рекомендуется.

Для повышения безопасности лучше по возможности отказаться от использования учетных данных в самописных скриптах, а также от потенциально опасного функционала, например чтения /etc/shadow или манипуляций с id_rsa.

Повышение привилегий через эксплуатацию уязвимостей

Прежде чем пытаться повысить привилегии через эксплуатацию, важно разобраться с передачей файлов на целевой хост. Помимо привычных средств вроде ssh, ftp, http (wget, curl) есть целый «зоопарк» возможностей.

Для повышения безопасности системы регулярно обновляйте ее до актуальных стабильных версий, а также старайтесь использовать дистрибутивы, рассчитанные на Enterprise. В противном случае, редко, но бывают ситуации, когда apt upgrade делает систему неработоспособной.

Эксплуатация сервисов, запущенных в контексте пользователя root

Самым удачным случаем можно считать работу взломанного сервиса в контексте пользователя root. Эксплуатация сервиса SMB дает привилегированный доступ SYSTEM в системах Windows (например, через ms17-010). Однако в системах Linux такое встречается нечасто, поэтому можно провести немало времени над повышением привилегий.

Эксплуатация уязвимостей ядра Linux

cat /proc/version
uname -a
searchsploit «Linux Kernel»

Metasploit

Для того, чтобы поймать и обработать соединение, всегда лучше использовать модуль exploit/multi/handler. Главное — выставить правильный payload, например, generic/shell/reverce_tcp или generic/shell/bind_tcp. Оболочку, полученную в Metasploit, можно улучшить до Meterpreter с использованием модуля post/multi/manage/shell_to_meterpreter. Имея Meterpreter, вы можете автоматизировать процесс постэксплуатации. Например, модуль post/multi/recon/local_exploit_suggester проверяет платформу, архитектуру и необходимые для эксплуатации сущности и предлагает модули Metasploit для повышения привилегий на целевой системе. Благодаря Meterpreter, повышение привилегий иногда сводится к запуску нужного модуля, однако взлом без понимания происходящего под капотом не является «тру» (вам еще отчет писать).

Tools

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

Linpeas

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

LinEnum

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

Linux-exploit-suggester (1,2)

Этот эксплоит проанализирует систему на наличие подходящих условий для эксплоитов. По сути, сделает работу, идентичную модулю Metasploit local_exploit_suggester, но предложит не модули Metasploit, а ссылки на исходные коды exploit-db.

Linuxprivchecker

Данный скрипт соберет и систематизирует по разделам большое количество информации, которая может быть полезна для формирования вектора повышения привилегий.

В другой раз я подробно разберу повышение привилегий в ОС Linux через suid/sgid.

В предыдущей статье мы рассмотрели вопросы хранения учетных данных в ОС семейства Линукс. Теперь перейдем к обсуждению вопросов правильной и не очень настройки прав доступа к различным объектам операционной системы.

Напомню основные моменты относительно учетных записей в Линукс: есть суперпользователь root (id=0), который может все и есть все остальные учетные записи (id от 500 или 1000), которые имеют ряд ограничений и по идее не могут нанести большого вреда системе.

Но на практике возможны различные ситуации, когда обычному пользователю необходимы административные права. Например, обычный пользователь не может прочитать файл с хэшами паролей /etc/shadow, но он может изменить свой собственный пароль с помощью команды passwd. Очевидно, что для внесения изменений в защищенный файл команда должна выполняться с правами суперпользователя. И таких примеров может быть довольно много.

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

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

Вызов su без аргументов приведет к запуску оболочки root. Для возврата в оболочку основного пользователя, из под которого была вызвана команда su необходимо просто ввести exit.

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

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

Основное отличие двух команд на примере пользователя root: su переключает вас в аккаунт root и требует пароль root. Sudo запускает с привилегиями root одну команду — она не переключает вас в аккаунт суперпользователя и не требует отдельного пароля root. Исключение sudo -i.

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

Но даже ввод корректного пароля еще не гарантирует выполнение команды под root.

Дело в том, что для разрешения запуска команд по sudo пользователь должен быть внесен в специальный файл /etc/sudoers, содержащий настройки использования sudo. Для нас в плане настройки доступа наиболее интересен раздел, связанный с разрешенными пользователям командами:

root    ALL=(ALL:ALL) ALL

Если мы хотим разрешить пользователю запускать под sudo любые команды, то необходимо использовать ключ ALL, например

А если при этом мы еще и не хотим спрашивать пароль, то используем NOPASSWD

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

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

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

Поэтому учитывайте это обстоятельство при настройке /etc/sudoers. Разрешать всем все явно не нужно.

Права и SUID bit

Вернемся к приведенному ранее примеру со сменой пароля обычным пользователем с помощью команды passwd. Но для того, чтобы понять как выполняется этот трюк с доступом к привилегированному файлу мы немного поговорим о том, как в Линукс осуществляется доступ к файлам.

В стандартной модели доступа есть 3 вида прав, помимо специальных:

Права на файлы определяются для пользователей из трех групп:

Для каждой операции выделены свои группы битов:

В зависимости от того, что разрешено, мы можем увидеть соответствующий набор значений:

Также права доступа можно представить в виде чисел, формируемых по следующему правилу:

Для того, чтобы пользователь не обладающий административными правами мог запускать приложения, требующие права root для своей работы (как в нашем примере с passwd) в Линукс предусмотрен специальный механизм — SUID (Set UID) bit. Данный бит позволяет выполнение программы с правами хозяина файла. Это ключевой механизм повышения прав в Unix системах. Особенности SUID программ в стандартных конфигурациях Linux:

Для того, чтобы установить SUID бит необходимо воспользоваться следующей командой:

chmod u+s выполнимый_файл

в результате в выводе в правах будет отображаться буква s

Обратите внимание на то, что владельцем файла является root. Кстати же знакомая нам команда sudo тоже имеет SUID бит.

Посмотрим, что произойдет, когда двоичный файл, имеющий SUID бит, выполнится. Созданный процесс изменит свой эффективный идентификатор пользователя (EUID) со стандартного UID на владельца этого специального двоичного исполняемого файла который в этом случае — root.

Ядро принимает решение, имеет ли этот процесс привилегию, просматривая EUID процесса. Потому что теперь EUID указывает на root — эта операция не будет отклонена ядром.

При самостоятельной установке SUID bit администраторам нужно быть особенно внимательными, так как некоторые утилиты имеют штатный функционал позволяющий запускать командную оболочку. О том как эксплуатировать подобные уязвимости мы подробно поговорим в следующей статье. Но прежде, чем разрешать какой-либо команде запускаться по sudo или устанавливать SUID bit я бы рекомендовал сначала прочитать man по данной команде, нет ли там ключика, позволяющего запускать shell.

Непутевый PATH

Переменная среды PATH предназначена для указания оболочке, где искать исполняемые файлы. То есть, благодаря PATH можно указывать только имя выполняемого файла без полного пути, а дальше уже ОС будет пытаться найти файл с таким именем по всем прописанным в переменной путям.

Но при не совсем корректном составлении списка путей в переменной PATH возможна ситуация, когда злоумышленник сможет разместить по одному из путей, указанных в PATH свой файл с таким же названием, как и легальное приложение. Но этот файл будет выполнен вместо легального приложения, так как путь к нему прописан в PATH раньше, чем путь к легальному приложению. Например, на скриншоте /usr/local/bin идет раньше, чем /usr/bin, поэтому если легальный файл лежит по второму пути, то злоумышленник может сохранить свой файл с таким же именем по первому и он будет выполнен вместо легального. Таким образом, злоумышленник имея доступ в каталоги прописанные в PATH может поместить свой выполнимый файл с тем же именем, и при выполнении, по сути, подменить легальный файл на свой. А учитывая, что файл могут пытаться запустить с правами суперпользователя злоумышленник в результате подмены может получить права root.

Заключение

В этой статье мы рассмотрели основные моменты настройки прав доступа. Я сознательно не рассматривал никакие “хакерские фокусы”, то есть практические примеры эксплуатации ошибок в данных настройках, так как этому будет полностью посвящена следующая статья. Но основные рекомендации по безопасности можно дать уже сейчас. Прежде всего, необходимо использовать принцип минимизации привилегий, то есть пользователям необходимо назначать только те права, которые необходимы им для работы. Недопустимо использование прав 777 на те приложения, запуск которых может привести к получению root-shell. Также недопустимо разрешение пользователям запуска любых команд под sudo, так как это равносильно получению прав root. Аналогично, SUID бит должен устанавливаться только на безопасные приложения, в противном случае есть риск получения пользователем прав root.

В двух предыдущих статьях (часть 1, часть 2) мы рассмотрели различные аспекты правления учетными записями и настройки доступа к файлам. Однако, при настройке доступа всегда можно ошибиться, задав неверные значения. Если администратор выдал недостаточные права, то такая ошибка будет найдена довольно быстро, так как, тот кому этих прав не хватит очень скоро пожалуется админу. Но что делать, если прав в итоге оказалось больше, чем нужно? Многие, конечно, могут сказать, что это вообще не проблема, мол больше не меньше, но на самом деле это ошибочная логика. Как мы увидим в сегодняшней статье, даже безобидные на первый взгляд разрешения могут привести к получению прав root в системе.

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

Исходные данные

Перед тем, как начать обсуждение хакерских методов, нам необходимо договориться о том, что у нас будет на старте. Итак, предположим, что вы являетесь администратором серверов Linux, с которыми работают различные пользователи: программисты, инженеры, тестировщики. Всем им в том или ином виде необходим доступ в консоль на различных серверах и определенные наборы прав: одни работают со скриптами и планировщиком crontab, другие с контейнерами docker, а третьи компилируют и отлаживают код. Но ни у кого из этих пользователей нет прав root.

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

Эскалируй это

Наш пользователь программист активно работает с репозиториями с помощью команды git. Однажды, для выполнения срочной задачи программисту потребовались права sudo для работы с файлами в каталогах с правами root.

Но как часто бывает, после выполнения этой срочной задачи, администратор не стал снова править файл /etc/sudoers, в результате чего, программист смог и дальше запускать git под sudo без пароля.

Когда злоумышленникам удалось получить доступ к машине программиста, они смогли попасть на Linux сервер. Узнав, что для git разрешен запуск под sudo, хакер выполнил следующие команды

sudo git help config

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

Пользователь инженер постоянно пишет скрипты и правит конфиги с помощью редактора nano. Для доступа к некоторым системным каталогам он попросил дать sudo для работы с nano.

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

Для эскалации сначала запускаем sudo nano, затем Ctrl+R и Ctrl+X, оказываемся в командной строке и выполняем

Также получаем root shell.

Тестировщик часто пользовался командой find, и его очень раздражало, что при попытке обращения к некоторым каталогам команда возвращала Permission Denied. Так он получил sudo на find. А хакер получив доступ на его машину, просто подсунув тестировщику специально собранный файл с машины программиста. Для получения root shell необходимо просто выполнить команду с ключом для запуска оболочки.

sudo find . -exec /bin/sh ; -quit

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

Злой SUID

Напомним, что такое SUID bit. Это специальный бит, который позволяет выполнение программы с правами хозяина файла. Для его установки необходимо под root выполнить команду

chmod u+s файл_shell.

Но вернемся к нашим героям. Злоумышленник продолжая захватывать сеть с учетками трех пользователей обнаружил на одном из серверов много каталогов с правами на запись. Также в некоторых из этих каталогов находились файлы скриптов, которые судя по логам довольно часто запускались админом. Он дописал в некоторые скрипты следующие строки:

cp /bin/sh /bin/sys_sh

chmod u+s /bin/sys_sh

Первая строка копировала легальный шелл /bin/sh в некий sys_sh, а вторая присваивала sys_sh SUID bit. Когда через некоторое время один из “пропатченных” скриптов был запущен, создался файл /bin/sys_sh который после запуска открывал оболочку root.

На другом сервере злоумышленник использовал аналогичный сценарий но с переменной PATH, только теперь он рассовал скрипты с одинаковыми названиями в различные каталоги.

Планировщик crontab является удобным средством выполнения задач по расписанию в ОС Линукс. По сути, cron это классический Unix daemon , использующийся для периодического выполнения заданий в определенное время. При этом,  задания хранятся в специальных файлах в определенном формате, поддерживается возможность запуска заданий от имени разных пользователей.

Зайдя на один из серверов под пользовательским аккаунтом злоумышленник выполнил следующую команду:

Эта команда ищет файлы, на которые установлен SUID bit 04000 — (s-бит) выполнение с правами владельца файла. Также в логах было найдено упоминание работы скрипта backup.sh, который имел SUID bit, и при этом его мог редактировать данный пользователь.

Тогда наш хакер решил заполучить выполнимый файл, после запуска которого он получит права root. Для этого ему потребуется следующий код на языке С:

Данный код получает эффективный UID и затем с этим идентификатором открывает командную строку. Но проблема заключается в том, что нашему хакеру необходимо, чтобы этот выполнимый файл должен быть собран под root и ему должен быть назначен SUID bit. То есть необходимы выполнить следующие команды:

gcc suid.c -o /bin/backdoor

chmod u+s /bin/backdoor

Но мы помним про файл скрипта, который выполняется в crontab под root, и в который может вносить изменения любой пользователь. Злоумышленник просто добавляет в этот скрипт несколько строк, которые сначала создают во временном каталоге файл с исходным кодом на С, который затем компилируется и получает SUID bit.

gcc /tmp/suid.c -o /bin/backdoor

Теперь для получения root shell достаточно просто запустить файл /bin/backdoor.

Побег из контейнера

На одном из серверов программист попросил sudo для запуска контейнеров docker. Когда злоумышленник попал на этот сервер, он подгрузил контейнер с Linux, из которого получил root для системы на основной машине.

docker run -v /:/mnt –rm -it alpine chroot /mnt sh

Во время настройки одного из серверов права sudo предоставили инженеру для обновления софта. Потом, этому серверу закрыли доступ в интернет, а вот забрать права забыли. В результате, злоумышленник запустил apt-get с ключом Pre-Invoke, который выполняет действия до начала загрузки обновлений и которому вообщем-то неважно отсутствие доступа в интернет.

Root shell был получен с помощью следующей команды:

sudo apt-get update -o APT::Update::Pre-Invoke::=/bin/sh

Мы рассмотрели целый набор типовых ошибок при настройке прав доступа в Линукс. Что можно было бы посоветовать для минимизации рисков поднятия привилегий. Там где это допустимо, можно ограничить выполнения команд, разрешив выполнение только без аргументов. Для этого в /etc/sudoers необходимо указать после команды пустые кавычки. Вот пример для ls.

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

Для получения полного списка команд, аргументы которых позволяют открыть шелл совершенно необязательно часами шерстить man. Узнать эти команды с примерами эксплуатации можно на сайте https://gtfobins.github.io/

Для борьбы с SUID воспользуйтесь следующей командой:

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

Также необходимо провести аудит прав доступа к различным скриптам, особенно к тем, что выполняются crontab из под root. У пользователей не должно быть возможности вносить изменения в такие файлы.

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

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

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

Команда sudo позволяет запускать отдельные команды с повышением привилегий (по умолчанию с правами root) пользуясь непривилегированной учетной записью. Давайте разберемся, что же требуется для работы этой утилиты.

Установка и настройка

В ОС Ubuntu sudo включена по умолчанию, а в Debian, если в процессе установки не был выбран соответствующий пакет, скорее всего будет следующая картина:

Значит, требуется установить недостающий пакет. Обновляем информацию о репозиториях и устанавливаем sudo:

apt-get update
apt-get install sudo

Дожидаемся окончания процесса:

Скриншот №1. Процесс установки sudo

После успешной установки потребуется сконфигурировать sudo, определив, какие пользователи или группы смогут использовать повышение привилегий и в каком объеме. Все эти настройки хранятся в конфигурационном файле /etc/sudoers, однако вносить в него изменения напрямую настоятельно не рекомендуется. Для этих целей используется специальная команда:

которая запускает текстовый редактор с конфигурационным файлом:

Скриншот №2. Текстовый редактор

За предоставление прав здесь отвечают две строки:

root    ALL=(ALL:ALL) ALL
%sudo   ALL=(ALL:ALL) ALL

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

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

Добавлять новую запись рекомендуется в тех случаях, когда список привилегий будет корректироваться (об этом чуть позднее). Если мы внесли изменения в файл, нужно их сохранить нажатием сочетания клавиш Ctrl-O и выйти из редактора — Ctrl-X.

Теперь можно проверить корректность работы:

Тонкая настройка

Таким образом, обычный пользователь может запускать команды с правами учетной записи root не зная ее пароль. Это очень удобно, но может быть небезопасно — есть ли возможность ограничить круг команд, которые можно исполнять посредством sudo? Да, и поможет нам в этом тот же самый конфигурационный файл. Снова запускаем visudo и разбираемся дальше. Нас интересуют параметры, указанные после имени пользователя:

Скриншот №3. Настройки ограничения команд

Разберем их подробнее:

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

Полезное

Скриншот №4. Список привилегий пользователя

В состав sudo входит команда sudoedit, которая запускает текстовый редактор с указанным файлом сразу с повышенными привилегиями, то есть вместо команды:

sudo nano /etc/network/interfaces

Если требуется длительная работа в режиме повышенных привилегий и вводить sudo для каждой команды неудобно, можно запустить через sudo экземпляр командного интерпретатора:

и продолжить работу в нем — все команды будут запускаться с повышенными правами. По завершении работы выходим из интерпретатора командой exit.

Аverage rating :

ул. Домбровская, д. 9

+375 (173) 88-72-49

ООО «ИТГЛОБАЛКОМ БЕЛ»

The main two commandline possibilities are:

Sudo (preferred when not running a graphical display)

This is the preferred method on most systems, including Ubuntu, Linux Mint, (arguably) Debian, and others. If you don’t know a separate root password, use this method.

Sudo requires that you type your own password. (The purpose is to limit the damage if you leave your keyboard unattended and unlocked, and also to ensure that you really wish to run that command and it wasn’t e.g. a typo.) It is often configured to not ask again for a few minutes so you can run several sudo commands in succession.

sudo service apache restart

If you need to run several commands as root, prefix each of them with sudo. Sometimes, it is more convenient to run an interactive shell as root. You can use sudo -i for that:

Instead of sudo -i, you can use sudo -s. The difference is that -i reinitializes the environment to sane defaults, whereas -s uses your configuration files for better or for worse.

su -c ‘service apache restart’

The command to run must be passed using the -c option. Note that you need quotes so that the command is not parsed by your shell, but passed intact to the root shell that su runs.

To run multiple commands as root, it is more convenient to start an interactive shell.

On some systems, you need to be in group number 0 (called wheel) to use su. (The point is to limit the damage if the root password is accidentally leaked to someone.)

Logging in as root

If there is a root password set and you are in possession of it, you can simply type root at the login prompt and enter the root password. Be very careful, and avoid running complex applications as root as they might do something you didn’t intend. Logging in directly as root is mainly useful in emergency situations, such as disk failures or when you’ve locked yourself out of your account.

Other programs

See also Wikipedia.

PolicyKit (preferred when using GNOME)

Simply prefix your desired command with the command pkexec. Be aware that while this works in most cases, it does not work universally.

KdeSu, KdeSudo (preferred when using KDE)

kdesu and kdesudo are graphical front-ends to su and sudo respectively. They allow you to run X Window programs as root with no hassle. They are part of KDE. Type

kdesu -c ‘command —option argument’

and enter the root password, or type

kdesudo -c ‘command —option argument’

and enter your password (if authorized to run sudo). If you check the “keep password” option in KdeSu, you will only have to type the root password once per login session.

Ktsuss (“keep the su simple, stupid”) is a graphical version of su.

Beesu is a graphical front-end to the su command that has replaced Gksu in Red Hat-based operating systems. It has been developed mainly for RHEL and Fedora.

Obsolete methods

gksu and gksudo

gksu and gksudo are graphical front-ends to su and sudo respectively. They allow you to run X Window programs as root with no hassle. They are part of Gnome. Type

gksu command —option argument

gksudo command —option argument

gksu and gksudo are obsolete. They have been replaced by PolicyKit in GNOME, and many distributions (such as Ubuntu) no longer install them by default. You should not depend on them being available or working properly.

Manually via one of the shell-based methods

Use one of the methods in the «running a shell command as root section». You will need to ensure that neither the DISPLAY environment variable nor the XAUTHORITY environment get reset during the transition to root. This may require additional configuration of those methods that is outside the scope of this question.

See How do I edit a file as root?

I need to run something as sudo without a password, so I used visudo and added this to my sudoers file:

Then I tried it out:

asked Aug 16, 2011 at 10:29

97 gold badges249 silver badges348 bronze badges

If there are multiple matching entries in /etc/sudoers, sudo uses the last one. Therefore, if you can execute any command with a password prompt, and you want to be able to execute a particular command without a password prompt, you need the exception last.

answered May 12, 2011 at 11:36

Having done that, sudo will prompt for a password normally for all commands except /path/to/my/program, which it will always let you run without asking for your password.

answered Aug 16, 2011 at 11:32

16 gold badges177 silver badges168 bronze badges