stihl не предоставил(а) никакой дополнительной информации.
Сегодня я покажу пример подделки запросов на стороне сервера (SSRF). Мы получим доступ к внутрянке сайта и извлечем критически важные данные, затем найдем данные технической учетной записи и повысим привилегии в Linux через уязвимость в библиотеке GitPython.
Наша цель — получение прав суперпользователя на машине Editorial с учебной площадки Для просмотра ссылки Войдиили Зарегистрируйся. Уровень задания — легкий.
И запускаем сканирование портов.
Наиболее известный инструмент для сканирования — это Nmap. Улучшить результаты его работы ты можешь при помощи следующего скрипта:
Он действует в два этапа. На первом производится обычное быстрое сканирование, на втором — более тщательное сканирование, с использованием имеющихся скриптов (опция -A).
Сканер нашел два открытых порта:
В форме есть поля для URL и загрузки файла. Если сервер будет обращаться к указанному нами URL, обязательно нужно проверить, нет ли тут уязвимости SSRF. Давай выполним запрос на свой сервер, для чего у себя запустим листенер:
И укажем адрес нашей машины в поле URL. Остальные поля для начала заполним тестовыми данными.
После отправки запроса страница обновляется, но в логах листенера пусто. Просматриваем запрос в Burp History и не находим там указанного URL.
Вернемся к форме на сайте, снова заполним ее данными, но в этот раз не будем их отправлять, а нажмем кнопку Preview. В этот момент на листенер приходит запрос от сервера.
А теперь ради эксперимента в поле URL вместо своего листенера указываем 127.0.0.1. В ответ получаем какой‑то путь.
Уязвимость SSRF на сайте явно есть, а значит, попытаемся ее раскрутить.
После окончания перебора фильтруем результаты по размеру ответа. Видим, что один из ответов отличается, а значит, сервис работает на порте 5000.
Комбинацией клавиш Ctrl-R пересылаем запрос в Burp Repeater и проверяем ответ. В ответе получаем уже другой путь, на этот раз файл в каталоге с загрузками.
Переходим по полученному URI в браузере и в истории запросов видим, что мы можем посмотреть содержимое файла.
Данные представлены в формате JSON, поэтому копируем их в файл и просматриваем с помощью утилиты jq.
Файл раскрывает нам несколько эндпоинтов API. По описанию каждого API можно понять, за что отвечает функция. Получим сообщения от авторов, для чего через SSRF выполним запрос к такому эндпоинту:
Для просмотра ссылки Войдиили Зарегистрируйся
Снова скачиваем файл и красиво выводим через jq.
В большом сообщении от автора раскрываются учетные данные записи dev. Успешно подключаемся от ее имени к серверу по SSH и получаем первый флаг.
или Зарегистрируйся (PEASS) — набор скриптов, которые проверяют систему на автомате и выдают подробный отчет о потенциально интересных файлах, процессах и настройках.
Загрузим на удаленный хост скрипт для Linux, дадим право на выполнение и начнем сканирование. Затем смотрим, что интересного он нашел.
В каталоге /opt есть два проекта: apps и internal_apps.
Из файла с настройками веб‑сервера Nginx узнаём о Unix-сокете editorial.sock в проекте /opt/apps.
В каталоге /home/dev/apps есть репозиторий Git.
Для удобного анализа Git-репозитория заархивируем каталог /home/dev/apps и скачаем его на свою машину.
Затем я открыл каталог в Visual Studio Code и посмотрел историю коммитов.
В одном из коммитов есть всего одно изменение: в сообщении вместо учетных данных записи prod записаны учетные данные для пользователя dev.
Используем учетную запись prod для смены контекста безопасности и получаем сессию нового пользователя.
Таким образом, можно выполнить скрипт /opt/internal_apps/clone_changes/clone_prod_change.py от имени пользователя root. При этом скрипту можно передать какие‑то параметры. Просмотрим его исходный код.
В самом коде ничего интересного найти не удалось. Однако есть импорт из пакета git. Часто в таких случаях можно обнаружить, что используются старые библиотеки, в которых есть известные уязвимости. Давай посмотрим, какая библиотека здесь.
Google выводит нас на библиотеку GitPython. Поищем эксплоиты для нее.
Версии GitPython меньше 3.1.35 уязвимы к Для просмотра ссылки Войдиили Зарегистрируйся — внедрению кода за счет внешнего вызова Git без достаточной очистки входных аргументов. Проверим, какая версия библиотеки используется на сервере.
На сервере — GitPython 3.1.29, а значит, мы можем внедрить свой код, который будет выполнен в привилегированном контексте. Как это сделать, можно Для просмотра ссылки Войдиили Зарегистрируйся.
В качестве выполняемого кода будем использовать скрипт exp.sh, который установит файлу командной оболочки /bin/bash бит SUID.
Эксплуатируем уязвимость и после кучи ошибок проверяем права на бинарник bash.
Все получилось, машина захвачена!
Наша цель — получение прав суперпользователя на машине Editorial с учебной площадки Для просмотра ссылки Войди
warning
Разведка
Сканирование портов
Добавляем IP-адрес машины в /etc/hosts:10.10.11.20 editorial.htbИ запускаем сканирование портов.
Справка: сканирование портов
Сканирование портов — стандартный первый шаг при любой атаке. Он позволяет атакующему узнать, какие службы на хосте принимают соединение. На основе этой информации выбирается следующий шаг к получению точки входа.Наиболее известный инструмент для сканирования — это Nmap. Улучшить результаты его работы ты можешь при помощи следующего скрипта:
Код:
#!/bin/bash
ports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
nmap -p$ports -A $1Он действует в два этапа. На первом производится обычное быстрое сканирование, на втором — более тщательное сканирование, с использованием имеющихся скриптов (опция -A).
Сканер нашел два открытых порта:
- 22 — служба OpenSSH 8.9p1;
- 80 — веб‑сервер Nginx 1.18.0.
Точка входа
На сайте находим форму для отправки информации о книге.В форме есть поля для URL и загрузки файла. Если сервер будет обращаться к указанному нами URL, обязательно нужно проверить, нет ли тут уязвимости SSRF. Давай выполним запрос на свой сервер, для чего у себя запустим листенер:
nc -nlvp 8000И укажем адрес нашей машины в поле URL. Остальные поля для начала заполним тестовыми данными.
После отправки запроса страница обновляется, но в логах листенера пусто. Просматриваем запрос в Burp History и не находим там указанного URL.
Вернемся к форме на сайте, снова заполним ее данными, но в этот раз не будем их отправлять, а нажмем кнопку Preview. В этот момент на листенер приходит запрос от сервера.
А теперь ради эксперимента в поле URL вместо своего листенера указываем 127.0.0.1. В ответ получаем какой‑то путь.
Уязвимость SSRF на сайте явно есть, а значит, попытаемся ее раскрутить.
Точка опоры
Так как мы можем получить доступ к внутренним ресурсам, попробуем найти еще какие‑нибудь внутренние сервисы. Для этого пробрутим порты в отправляемом URL через Burp Intruder.После окончания перебора фильтруем результаты по размеру ответа. Видим, что один из ответов отличается, а значит, сервис работает на порте 5000.
Комбинацией клавиш Ctrl-R пересылаем запрос в Burp Repeater и проверяем ответ. В ответе получаем уже другой путь, на этот раз файл в каталоге с загрузками.
Переходим по полученному URI в браузере и в истории запросов видим, что мы можем посмотреть содержимое файла.
Данные представлены в формате JSON, поэтому копируем их в файл и просматриваем с помощью утилиты jq.
Файл раскрывает нам несколько эндпоинтов API. По описанию каждого API можно понять, за что отвечает функция. Получим сообщения от авторов, для чего через SSRF выполним запрос к такому эндпоинту:
Для просмотра ссылки Войди
Снова скачиваем файл и красиво выводим через jq.
В большом сообщении от автора раскрываются учетные данные записи dev. Успешно подключаемся от ее имени к серверу по SSH и получаем первый флаг.
Продвижение
Теперь нам необходимо собрать информацию. Я буду использовать для этого скрипты PEASS.Справка: скрипты PEASS
Что делать после того, как мы получили доступ в систему от имени пользователя? Вариантов дальнейшей эксплуатации и повышения привилегий может быть очень много, как в Linux, так и в Windows. Чтобы собрать информацию и наметить цели, можно использовать Для просмотра ссылки ВойдиЗагрузим на удаленный хост скрипт для Linux, дадим право на выполнение и начнем сканирование. Затем смотрим, что интересного он нашел.
В каталоге /opt есть два проекта: apps и internal_apps.
Из файла с настройками веб‑сервера Nginx узнаём о Unix-сокете editorial.sock в проекте /opt/apps.
В каталоге /home/dev/apps есть репозиторий Git.
Для удобного анализа Git-репозитория заархивируем каталог /home/dev/apps и скачаем его на свою машину.
Код:
zip -r apps.zip apps
scp dev@10.10.11.20:/home/dev/apps.zip ./В одном из коммитов есть всего одно изменение: в сообщении вместо учетных данных записи prod записаны учетные данные для пользователя dev.
Используем учетную запись prod для смены контекста безопасности и получаем сессию нового пользователя.
Локальное повышение привилегий
Разведку мы уже проводили, поэтому при изменении контекста снова все проверять не нужно. Посмотрим только самое важное. Одно из мест, куда стоит заглянуть первым делом, — это файл sudoers.Справка: sudoers
Файл /etc/sudoers в Linux содержит списки команд, которые разные группы пользователей могут выполнять от имени администратора системы. Можно просмотреть его как напрямую, так и при помощи команды sudo -l.Таким образом, можно выполнить скрипт /opt/internal_apps/clone_changes/clone_prod_change.py от имени пользователя root. При этом скрипту можно передать какие‑то параметры. Просмотрим его исходный код.
В самом коде ничего интересного найти не удалось. Однако есть импорт из пакета git. Часто в таких случаях можно обнаружить, что используются старые библиотеки, в которых есть известные уязвимости. Давай посмотрим, какая библиотека здесь.
Google выводит нас на библиотеку GitPython. Поищем эксплоиты для нее.
Версии GitPython меньше 3.1.35 уязвимы к Для просмотра ссылки Войди
На сервере — GitPython 3.1.29, а значит, мы можем внедрить свой код, который будет выполнен в привилегированном контексте. Как это сделать, можно Для просмотра ссылки Войди
В качестве выполняемого кода будем использовать скрипт exp.sh, который установит файлу командной оболочки /bin/bash бит SUID.
Код:
#!/bin/bash
chmod u+s /bin/bashСправка: бит SUID
Когда у файла установлен атрибут setuid (S-атрибут), обычный пользователь, запускающий этот файл, получает повышение прав до пользователя — владельца файла в рамках запущенного процесса. После получения повышенных прав приложение может выполнять задачи, которые недоступны обычному пользователю. Из‑за возможности состояния гонки многие операционные системы игнорируют S-атрибут, установленный shell-скриптам.Эксплуатируем уязвимость и после кучи ошибок проверяем права на бинарник bash.
sudo /usr/bin/python3 /opt/internal_apps/clone_changes/clone_prod_change.py "ext::sh -c '/tmp/exp.sh'"Все получилось, машина захвачена!