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

  • Tutorial

Первый квартал 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

Существует 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


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


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


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

Инфосистемы Джет
Системный интегратор

Похожие публикации

Комментарии 26

    +3
    Огромное спасибо! Как-раз готовлюсь к зачислению на OSCP.
    Не могли бы еще подобное про Windows написать? С юниксами чувствую себя довольно уверенно, а вот пытаюсь получить рута на Windows — испытываю какой-то первобытный ужас.
      +1
      Понимаю вас. Возможно, я доберусь до Windows после закрытия цикла статей по Linux. На самом деле можно проводить параллели между векторами. В Windows чаще всего встречал небезопасные разрешения на сервисах. Пока что могу рекомендовать вот этот мануал.
      +2
      Почитал по диагонали, но статья понравилась. Утащил в закладки. Спасибо автору.
        0
        Я есть Гroot. Созвучное получилось название статьи. Классно.
          +2
          Огромное спасибо за статью. Сейчас разбираю прохождения retired машин на HTB и составляю свой конспект, gtfobins.github.io — отличное пополнение для моей книги рецептов. С удовольствием бы прочитал нечто подобное по 1. enumeration 2. как лучше брутить и на чем 3. что за отчеты такие, о которых в каждой вакансии пишут. Понимаю, что статьи писать долго, буду благодарен даже вашим избранным ссылкам на ресурсы
            0
            что за отчеты такие, о которых в каждой вакансии пишут

            А в каких вакансиях вы встречали требования к отчетам. Я подобного не наблюдала.
              0
              Учту. Пока быстрый ответ:
              1. Enumeration. Вполне может быть, что весь local enumeration вам заменит тула, вроде linpeas. Я хочу сначала разобрать вектора, чтобы читатель гораздо осознаннее анализировал данные, полученные на этапе перечисления. Думаю, можно будет разобрать эту тему чуть позже.
              2. Брутить нужно все, что брутится. В приоритете интерфейсы управления, вроде SSH. Лишь бы не положить целевой хост и не заблокировать пользователей. Мы скоро разберем атаку типа credential stuffing, хорошая штука. Сюда же профилирование словарей.
              3. Не получится просто «наколдовать». Если мы говорим о реальном пентесте или OSCP, необходимо будет объяснить, человеческим языком, что вы сделали, в виде отчета.
              0
              Первое, что нужно сделать, получив доступ в систему, — выполнить команду sudo -l. Она выведет разрешение на использование команды sudo.

              А разве sudo не запросит для этого пароль?
                +1
                Если получен пользователь без пароля (например, apache или www-data), вектор повышения привилегий через sudo маловероятен. При использовании sudo система запросит пароль. Через команду passwd задать пароль также не выйдет, она запросит текущий пароль пользователя.

                Это я к тому, что если вы, например, подобрали пароль на ssh, sudo может стать easy win для поднятия привилегий. Сначала нужно проверить простейшие вектора.
                0

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

                  +2
                  Страшно?

                  Да нет, не очень, осталось только получить доступ в гипервизор или непосредственно серверную. Сброс пароля root'a, путем изменения параметров загрузки ядра, действительно возможен, но это скорее к RHCSA относится.
                  0
                  Честно говоря, какое-то странное перечисление банальщины.
                  Просто понимая как работает баш и стандартные gnu утилиты, можно сделать все что угодно, если у вас внезапно есть sudo или доступ к рут.
                  А в статье перечисляется не то, как собственно получить sudo или root, а такое ощущение, что магия кроется именно в банальных less/grep/chmod.
                  Это же просто навыки работы в командной строке.

                  Ну вот пример

                  ps -aux | grep root # Linux

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

                  Ну вот какое отношение вышеупомянутая команда имеет к взлому сервиса?
                  Разве что посмотреть что апач запущен от рута, а не от www юзера. Так это уже дырища, если посторонний человек получил шелл доступ на сервер.

                  Я больше надеялся, что в статье будет обзор того, что по ссылкам накидано…
                    0
                    Просто понимая как работает баш и стандартные gnu утилиты, можно сделать все что угодно, если у вас внезапно есть sudo или доступ к рут.


                    Так тут ситуация подразумевается, что рута нет и нужно искать пути его получения.
                      0
                      То есть рута нет???
                      А sudo можно себе настроить под обычным пользователем? Нет, под рутом.
                      А /etc/cron.d можно править под обычным пользователем? Нет, под рутом.
                      А .history других юзеров можно смотреть под обычным пользователем? Нет, под рутом.

                      То есть перечисление вариантов, что если бы у вас уже был рут, то можно себе еще сделать рута.
                        0
                        А sudo можно себе настроить под обычным пользователем? Нет, под рутом.
                        А /etc/cron.d можно править под обычным пользователем? Нет, под рутом.
                        А .history других юзеров можно смотреть под обычным пользователем? Нет, под рутом.

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

                          0
                          Простите, что?
                          У меня есть ощущение, что вы Линукс никогда в глаза не видели.
                          Эти каталоги изначально во всех дистрибутивах закрыты от чтения и модификации.
                          А если на приватный ssh ключ поставит чуть больше прав, то им даже воспользоваться будет нельзя — при попытке авторизации тебе скажет что этот ключ слишком открытый и возможно уже скомпроментирован.

                          Это не регламенты ИБ. Это базовая настройка из коробки. И чтобы эти каталоги открыть, это кто-то руками УМЫШЛЕННО должен это сделать.
                          0
                          А sudo можно себе настроить под обычным пользователем? Нет, под рутом.

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

                          А /etc/cron.d можно править под обычным пользователем? Нет, под рутом.

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

                          А .history других юзеров можно смотреть под обычным пользователем? Нет, под рутом.

                          Можно смотреть «свои» history. Зачастую там бывает полезная информация для получения рута.

                          Все и дело в том, что если поставить линукс из коробки и никак его не править — он очень устойчив (не считая кернел эксплоитов). Но если он поживет какое-то время и активно администрируется, то обрастает кастомными скриптами, странными правами и всякими скриптами с SUID.
                            +1
                            пользователю можно дать исполнять определенные команды под sudo. Много команд ведут к повышению привелегий.

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

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

                            А еще возле клавиатуры может лежать листик с паролями.

                            Можно смотреть «свои» history. Зачастую там бывает полезная информация для получения рута.

                            Зачастую?
                            Каким образом в историю ВАШЕГО юзера попадает информация для получения рута?

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

                              согласен


                              а их подача искажает терминологию и смысл некоторых команд.

                              согласен


                              Стоит почитать документацию.

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


                              Каким образом в историю ВАШЕГО юзера попадает информация для получения рута?

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


                              в sudo вы конкретно настраиваете или вы даете повышение привилегий или другие вещи.

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


                              У меня есть ощущение, что вы Линукс никогда в глаза не видели.

                              Видел, Ваше мнение тут не является экспертным.


                              Эти каталоги изначально во всех дистрибутивах закрыты от чтения и модификации.

                              Вот готовы поспорить? Квантор всеобщности Вас губит. Ей-Богу.


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

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


                              Это не регламенты ИБ. Это базовая настройка из коробки.

                              это именно, что регламенты ИБ, по которым МОЖЕТ быть произведена базовая настройка. А с другой стороны — БАЗОВАЯ настройка часто бывает субоптимальной.


                              И чтобы эти каталоги открыть, это кто-то руками УМЫШЛЕННО должен это сделать.

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

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

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

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

                                Обычно в sudo дают полный доступ. Если дают частичный, то это делает человек, который прочитал документацию, ибо дать доступ на отдельную команду — сложнее, чем просто доступ к руту.

                                Других способов получения рута нет.

                                Как раз другие способы и есть.
                                При наличии физического доступа — получить рут не слишком сложно.
                                Если на линукс много необновленных компонентов — можно нагуглить уязвимости.
                                Можно поискать используемый софт, и уже в нем искать уязвимости.

                                Но в первую очередь — если челове в принципе имеет доступ к серверу, даже на рид-онли, это подразумевает что он уже в круге знакомых. Зачем ломать сервер, к которому тебе дали доступ — не очень ясно. Это не пентестинг. Это немного другое.
                                +1
                                Не до конца понимаю, что Вы пытаетесь доказать? Других способов получения рута нет. Если и есть, то их немного и они «специфичные». В 95% случаев используются методы из статьи.
                                Вы спрашиваете видели ли мы Линукс? Видели
                                А вы хоть раз занимались пентестом?
                        0
                        Хорошая статья пользовался ей в работе.
                        только вот сюда
                        grep -lRi «password» /home /var/www /var/log 2>/dev/null | sort | uniq
                        еще бы /opt добавил.
                          0
                          почему бы тогда уж и не /var/lib?
                            0
                            в /opt часто встречал конфиги от коробочных банковских продуктов, в /var/lib не видел.
                              0
                              конфиги от различных продуктов, в основном базы данных.
                              Да тот же /var/lib/jenkins целиком там живет.
                          0

                          ого не сталкивался.

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

                          Самое читаемое