Комментарии 26
Огромное спасибо! Как-раз готовлюсь к зачислению на OSCP.
Не могли бы еще подобное про Windows написать? С юниксами чувствую себя довольно уверенно, а вот пытаюсь получить рута на Windows — испытываю какой-то первобытный ужас.
Не могли бы еще подобное про Windows написать? С юниксами чувствую себя довольно уверенно, а вот пытаюсь получить рута на Windows — испытываю какой-то первобытный ужас.
Понимаю вас. Возможно, я доберусь до Windows после закрытия цикла статей по Linux. На самом деле можно проводить параллели между векторами. В Windows чаще всего встречал небезопасные разрешения на сервисах. Пока что могу рекомендовать вот этот мануал.
Почитал по диагонали, но статья понравилась. Утащил в закладки. Спасибо автору.
Я есть Гroot. Созвучное получилось название статьи. Классно.
Огромное спасибо за статью. Сейчас разбираю прохождения retired машин на HTB и составляю свой конспект, gtfobins.github.io — отличное пополнение для моей книги рецептов. С удовольствием бы прочитал нечто подобное по 1. enumeration 2. как лучше брутить и на чем 3. что за отчеты такие, о которых в каждой вакансии пишут. Понимаю, что статьи писать долго, буду благодарен даже вашим избранным ссылкам на ресурсы
что за отчеты такие, о которых в каждой вакансии пишут
А в каких вакансиях вы встречали требования к отчетам. Я подобного не наблюдала.
Учту. Пока быстрый ответ:
1. Enumeration. Вполне может быть, что весь local enumeration вам заменит тула, вроде linpeas. Я хочу сначала разобрать вектора, чтобы читатель гораздо осознаннее анализировал данные, полученные на этапе перечисления. Думаю, можно будет разобрать эту тему чуть позже.
2. Брутить нужно все, что брутится. В приоритете интерфейсы управления, вроде SSH. Лишь бы не положить целевой хост и не заблокировать пользователей. Мы скоро разберем атаку типа credential stuffing, хорошая штука. Сюда же профилирование словарей.
3. Не получится просто «наколдовать». Если мы говорим о реальном пентесте или OSCP, необходимо будет объяснить, человеческим языком, что вы сделали, в виде отчета.
1. Enumeration. Вполне может быть, что весь local enumeration вам заменит тула, вроде linpeas. Я хочу сначала разобрать вектора, чтобы читатель гораздо осознаннее анализировал данные, полученные на этапе перечисления. Думаю, можно будет разобрать эту тему чуть позже.
2. Брутить нужно все, что брутится. В приоритете интерфейсы управления, вроде SSH. Лишь бы не положить целевой хост и не заблокировать пользователей. Мы скоро разберем атаку типа credential stuffing, хорошая штука. Сюда же профилирование словарей.
3. Не получится просто «наколдовать». Если мы говорим о реальном пентесте или OSCP, необходимо будет объяснить, человеческим языком, что вы сделали, в виде отчета.
Первое, что нужно сделать, получив доступ в систему, — выполнить команду sudo -l. Она выведет разрешение на использование команды sudo.
А разве sudo не запросит для этого пароль?
Если получен пользователь без пароля (например, apache или www-data), вектор повышения привилегий через sudo маловероятен. При использовании sudo система запросит пароль. Через команду passwd задать пароль также не выйдет, она запросит текущий пароль пользователя.
Это я к тому, что если вы, например, подобрали пароль на ssh, sudo может стать easy win для поднятия привилегий. Сначала нужно проверить простейшие вектора.
Скучная статья. Ожидал увидеть методику подготовки к экзамену, какие-то практические вещи. По факту — очередная банальщина. Типа разделяйте сервису, не используйте похожие пароли и прочее.
Я уж не говорю о том, что часто есть вектор в виде физического доступа к железу. А дальше все просто — ребут, подмена рутового пароля с локальной консоли и понеслось. Страшно? Да. А ещё страшнее, когда сервера не твои, а чужие, а ты хостишь там приложение.
Честно говоря, какое-то странное перечисление банальщины.
Просто понимая как работает баш и стандартные gnu утилиты, можно сделать все что угодно, если у вас внезапно есть sudo или доступ к рут.
А в статье перечисляется не то, как собственно получить sudo или root, а такое ощущение, что магия кроется именно в банальных less/grep/chmod.
Это же просто навыки работы в командной строке.
Ну вот пример
Ну вот какое отношение вышеупомянутая команда имеет к взлому сервиса?
Разве что посмотреть что апач запущен от рута, а не от www юзера. Так это уже дырища, если посторонний человек получил шелл доступ на сервер.
Я больше надеялся, что в статье будет обзор того, что по ссылкам накидано…
Просто понимая как работает баш и стандартные gnu утилиты, можно сделать все что угодно, если у вас внезапно есть sudo или доступ к рут.
А в статье перечисляется не то, как собственно получить sudo или root, а такое ощущение, что магия кроется именно в банальных less/grep/chmod.
Это же просто навыки работы в командной строке.
Ну вот пример
ps -aux | grep root # Linux
Самым удачным случаем можно считать работу взломанного сервиса в контексте пользователя root.
Ну вот какое отношение вышеупомянутая команда имеет к взлому сервиса?
Разве что посмотреть что апач запущен от рута, а не от www юзера. Так это уже дырища, если посторонний человек получил шелл доступ на сервер.
Я больше надеялся, что в статье будет обзор того, что по ссылкам накидано…
Просто понимая как работает баш и стандартные gnu утилиты, можно сделать все что угодно, если у вас внезапно есть sudo или доступ к рут.
Так тут ситуация подразумевается, что рута нет и нужно искать пути его получения.
То есть рута нет???
А sudo можно себе настроить под обычным пользователем? Нет, под рутом.
А /etc/cron.d можно править под обычным пользователем? Нет, под рутом.
А .history других юзеров можно смотреть под обычным пользователем? Нет, под рутом.
То есть перечисление вариантов, что если бы у вас уже был рут, то можно себе еще сделать рута.
А sudo можно себе настроить под обычным пользователем? Нет, под рутом.
А /etc/cron.d можно править под обычным пользователем? Нет, под рутом.
А .history других юзеров можно смотреть под обычным пользователем? Нет, под рутом.
То есть перечисление вариантов, что если бы у вас уже был рут, то можно себе еще сделать рута.
А sudo можно себе настроить под обычным пользователем? Нет, под рутом.
А /etc/cron.d можно править под обычным пользователем? Нет, под рутом.
А .history других юзеров можно смотреть под обычным пользователем? Нет, под рутом.
Не зря пишут регламенты ИБ, по которым указанные каталоги и файлы должны быть закрыты от чтения и модификации не-руть пользователем. Иначе — потенциальная уязвимость
Простите, что?
У меня есть ощущение, что вы Линукс никогда в глаза не видели.
Эти каталоги изначально во всех дистрибутивах закрыты от чтения и модификации.
А если на приватный ssh ключ поставит чуть больше прав, то им даже воспользоваться будет нельзя — при попытке авторизации тебе скажет что этот ключ слишком открытый и возможно уже скомпроментирован.
Это не регламенты ИБ. Это базовая настройка из коробки. И чтобы эти каталоги открыть, это кто-то руками УМЫШЛЕННО должен это сделать.
У меня есть ощущение, что вы Линукс никогда в глаза не видели.
Эти каталоги изначально во всех дистрибутивах закрыты от чтения и модификации.
А если на приватный ssh ключ поставит чуть больше прав, то им даже воспользоваться будет нельзя — при попытке авторизации тебе скажет что этот ключ слишком открытый и возможно уже скомпроментирован.
Это не регламенты ИБ. Это базовая настройка из коробки. И чтобы эти каталоги открыть, это кто-то руками УМЫШЛЕННО должен это сделать.
А sudo можно себе настроить под обычным пользователем? Нет, под рутом.
пользователю можно дать исполнять определенные команды под sudo. Много команд ведут к повышению привелегий.
А /etc/cron.d можно править под обычным пользователем? Нет, под рутом.
Нельзя. Но там могут быть уже задания, которые можно использовать для повышения привелегий.
А .history других юзеров можно смотреть под обычным пользователем? Нет, под рутом.
Можно смотреть «свои» history. Зачастую там бывает полезная информация для получения рута.
Все и дело в том, что если поставить линукс из коробки и никак его не править — он очень устойчив (не считая кернел эксплоитов). Но если он поживет какое-то время и активно администрируется, то обрастает кастомными скриптами, странными правами и всякими скриптами с SUID.
пользователю можно дать исполнять определенные команды под sudo. Много команд ведут к повышению привелегий.
А /etc/cron.d можно править под обычным пользователем? Нет, под рутом.
Нельзя. Но там могут быть уже задания, которые можно использовать для повышения привелегий.
А .history других юзеров можно смотреть под обычным пользователем? Нет, под рутом.
Можно смотреть «свои» history. Зачастую там бывает полезная информация для получения рута.
Все и дело в том, что если поставить линукс из коробки и никак его не править — он очень устойчив (не считая кернел эксплоитов). Но если он поживет какое-то время и активно администрируется, то обрастает кастомными скриптами, странными правами и всякими скриптами с SUID.
пользователю можно дать исполнять определенные команды под sudo. Много команд ведут к повышению привелегий.
Некорректная фраза.
в sudo вы конкретно настраиваете или вы даете повышение привилегий или другие вещи. Много команд к этому не ведет.
Если пользователю не нужно — не давайте судо. Если нужно — научитесь им пользоваться.
Нельзя. Но там могут быть уже задания, которые можно использовать для повышения привелегий.
А еще возле клавиатуры может лежать листик с паролями.
Можно смотреть «свои» history. Зачастую там бывает полезная информация для получения рута.
Зачастую?
Каким образом в историю ВАШЕГО юзера попадает информация для получения рута?
Все дело в том, что все советы даны на случай, если кто-то берет Линукс и специально делает в нем кучу уязвимостей. В нормальной рабочей машине все советы из статьи — бессмысленны, а их подача искажает терминологию и смысл некоторых команд.
Поэтому не стоит поддакивать. Стоит почитать документацию.
В нормальной рабочей машине все советы из статьи — бессмысленны
согласен
а их подача искажает терминологию и смысл некоторых команд.
согласен
Стоит почитать документацию.
стоит, а еще стоит думать, прежде чем вносить любые изменения в уже существующую систему
Каким образом в историю ВАШЕГО юзера попадает информация для получения рута?
в history может оказаться, например, командная строка с указанием пароля, не обязательно для конкретного сервера, возможно и удаленного. Но это относится к вышесказанному — быть аккуратным, думать о последствиях своих действий. Тогда таких проблем нет.
в sudo вы конкретно настраиваете или вы даете повышение привилегий или другие вещи.
да, но можно ошибиться и, например, дать права на какую-то команду, но не учесть, что можно дописать в нее какой-то хвостик и она уже будет иметь другое значение, но это опять относится к "Если нужно — научитесь им пользоваться."
У меня есть ощущение, что вы Линукс никогда в глаза не видели.
Видел, Ваше мнение тут не является экспертным.
Эти каталоги изначально во всех дистрибутивах закрыты от чтения и модификации.
Вот готовы поспорить? Квантор всеобщности Вас губит. Ей-Богу.
А если на приватный ssh ключ поставит чуть больше прав, то им даже воспользоваться будет нельзя — при попытке авторизации тебе скажет что этот ключ слишком открытый и возможно уже скомпроментирован.
да, есть такая история, причем не только в ssh клиенте — та же ботва и с постгресом (и ssl сертификатами), причем зачастую это создает больше проблем, чем решает. Но я скорее за то, чтобы такие механизмы защиты от дурака были, чем наоборот.
Это не регламенты ИБ. Это базовая настройка из коробки.
это именно, что регламенты ИБ, по которым МОЖЕТ быть произведена базовая настройка. А с другой стороны — БАЗОВАЯ настройка часто бывает субоптимальной.
И чтобы эти каталоги открыть, это кто-то руками УМЫШЛЕННО должен это сделать.
скорее да, чем нет. Но все равно попытаться заглянуть в эти каталоги — хорошая идея. Мало ли там чего будет. Например, пароли открытым текстом в скриптах.
в history может оказаться, например, командная строка с указанием пароля, не обязательно для конкретного сервера, возможно и удаленного. Но это относится к вышесказанному — быть аккуратным, думать о последствиях своих действий. Тогда таких проблем нет.
Обычный юзер может посмотреть только свой history, чужой — не может. Если в history есть пароль, то их вводил собственно сам юзер, а значит он его и так знает.
да, но можно ошибиться и, например, дать права на какую-то команду, но не учесть, что можно дописать в нее какой-то хвостик и она уже будет иметь другое значение, но это опять относится к «Если нужно — научитесь им пользоваться.»
Обычно в sudo дают полный доступ. Если дают частичный, то это делает человек, который прочитал документацию, ибо дать доступ на отдельную команду — сложнее, чем просто доступ к руту.
Других способов получения рута нет.
Как раз другие способы и есть.
При наличии физического доступа — получить рут не слишком сложно.
Если на линукс много необновленных компонентов — можно нагуглить уязвимости.
Можно поискать используемый софт, и уже в нем искать уязвимости.
Но в первую очередь — если челове в принципе имеет доступ к серверу, даже на рид-онли, это подразумевает что он уже в круге знакомых. Зачем ломать сервер, к которому тебе дали доступ — не очень ясно. Это не пентестинг. Это немного другое.
Не до конца понимаю, что Вы пытаетесь доказать? Других способов получения рута нет. Если и есть, то их немного и они «специфичные». В 95% случаев используются методы из статьи.
Вы спрашиваете видели ли мы Линукс? Видели
А вы хоть раз занимались пентестом?
Вы спрашиваете видели ли мы Линукс? Видели
А вы хоть раз занимались пентестом?
Хорошая статья пользовался ей в работе.
только вот сюда
только вот сюда
grep -lRi «password» /home /var/www /var/log 2>/dev/null | sort | uniqеще бы /opt добавил.
ого не сталкивался.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Я есть root. Разбираемся в повышении привилегий ОS Linux