Первый путь до RCE.

1. Средний импакт: доступ к списку всех пользователей без аутентификации.

Бручу пути, нашелся эндпоинт, который возвращает всех существующих пользователей (логин, мыло, телефон).

2. Крит импакт: слабая парольная политика → sql injection → RCE

Имея имена пользователей с прошлой уязвимости, я решил пробрутить доступ к интерфейсу аналитики который так же нашел с помощью ffuf. Как пароль решил использовать логин т.е. admin:admin, test:test итд. Выпала одна валидная пара. Зашёл, начал смотреть запросы.
Увидел летающие sql запросы к конкретному эндпоинту в чистом виде. Т.е. буквально select *что-то где-то* прямо в теле POST запроса. Нужно определить с какой субд имею дело. С помощью sql запросов а-ля версия бд и гугления, определил что это ClickHouse. Погуглил есть ли прикольные (читай опасные) функции в clickhouse, оказалось есть https://blog.deteact.com/ru/yandex-clickhouse-injection/ (благодарочка летит r0hack(у)).
Взял пейлоад для эксплуатации SSRF, слегка адаптировал под свой случай, сделал запрос на 169.254.169.254. Запрос не прошел, кажется есть проверка на слово url. Байпасим с помощью ur''l. Успех. Full-read SSRF.
Потыкался в этот хост в поисках какого-нибудь токена, нашел в метаданных какой-то bash скрипт с какими-то кредами и хостами.

Погуглил что это за хосты, оказалось они от mcs (mail cloud solutions). Нашел на каком именно эндпоинте, через api, применить найденные креды. Отправил запрос с кредами, получил авторизационный токен и с этим токеном уже мог делать запросы к openstack и управлять облачной инфраструктурой.

Второй путь до RCE.

1. Высокий импакт: request logger+django debug -> утечка кредов админа

Нашел и набрутил много апи эндпоинтов. На некотором количестве из них был установлен silk. Это, как я понял, логгер http запросов и ответов, и трейса sql запросов, выполняющихся при обращении к эндпоинтам апи на котором silk установлен. Зафиксировали эту информацию.
Далее я вошёл в саму платформу (как обычный пользователь), ловил запросы и увидел, что не все api мне были известны до этого момента.
Попробовал, зная новый api эндпоинт, открыть на нем silk, выглядело это примерно так /api/newfunction/silk/. Silk оказался установлен. Идея была в том, чтобы найти в нем запросы от админа, взять его креды/куки и таким образом получить к нему доступ. Оказалось, что silk скрывает звёздами(*) куки и креды в запросах.
Начал копаться в списке запросов и ответов, и нашел запрос на авторизацию к админке django, который возвращал 500 ошибку. По счастливой случайности у django был включен дебаг, а это означает, что в ответе на запрос авторизации, который вернул ошибку (500) будет ПОЛНОЕ содержание отправленного запроса, с куками, передаваемыми параметрами итд. И вот тут silk уже ничего не маскирует. Так я нашел креды админа.
Они были небрутабельными.

2. Крит импакт: RCE by desing из админки

У меня в распоряжении было 3 хоста и порядка 5 админок на каждом. Я их нашел, поняв, по какому паттерну устроены пути до них.
Попробовал найденные креды на каком-то количестве из них, получилось войти в три. В одной из них была возможность исполнять python код. Правда сама такая возможность требовала ввести еще один пароль, непосредственно от этого куска функций. Пароль был простейший и был сбручен.
Далее я просто сделал запрос на 169.254.169.254 с помощью python и, способом описанным выше, получил креды от cloud инфры.

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

Для наглядности:
Есть https://example.com/cabinet/ и доступен он только аутентифицированному пользователю. У нас есть аккаунт, мы в него входим. Приспичило нам пробрутить директории по данному пути https://example.com/cabinet/FUZZ и сделать мы это хотим именно как юзер, то есть с куками, чтобы увеличить вероятность находок. В этом случае крайне неудобно копировать куки из запроса, и указывать их как опцию при запуске ffuf. Выглядело бы это так:

ffuf -b "НУУУУУУУ ОООООООООЧЕНЬ МНОООООГОООО СИМВОЛОООООООООВ" -u https://example.com/cabinet/FUZZ

Хорошо если куки это единственное, что нужно перенести из запроса, но бывают кейсы с дополнительными/нестандартными хидерами. В моем случае это приводит к тому, что я банально ленюсь забиваю на подобный брут (либо, если теория стоящая, использую медленный Burp Intruder).

У меня есть решение, которое выглядит не слишком элегантно, но мне нравится и я решил им с вами поделиться. Описывать буду для macOS, но полагаю, адаптировать под другие оси не сложно, у меня вышло провернуть даже на винде с wsl, потанцевав с костылями.

Как настроить

Подготовка:

1. Идем в репу https://github.com/bytebutcher/burp-send-to и устанавливаем этот совершенно замечательнейший плагин для бурпа.
2. Далее устанавливаем iterm2.
3. Настраиваем возможность подключения к vds по ssh

К делу:

Создаем там, где вам удобно (у меня это будет /Users/kedrisch/runner.sh), скрипт runner.sh с содержимым:

function iterm () { 
osascript &>/dev/null <<EOF 
   tell application "iTerm" 
     activate 
     tell current window 
       create tab with default profile 
          tell current session of current tab 
            write text "$@" 
          end tell 
      end tell 
    end tell 
EOF 
} 
iterm $@

Этот скрипт будет запускать iterm с помощью osascript, поскольку на macOS нельзя просто взять и из командной строки стартануть iterm. По крайней мере я не нашел способа.

Далее переходим в Burp на вкладку “Send to” и в поле “Run in terminal” вписываем “bash /Users/kedrisch/runner.sh %C”.

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

scp -i /path/to/privatekey %R user@ip:/tmp/request; ssh -i /path/to/privatekey user@ip '/path/to/ffuf -ac -request /tmp/request -w /path/to/list.txt'

Ставим галку “Run in terminal” и “Show prior to execution”. Ok.

Как запускать:

Ловим запрос. Ключевым словом FUZZ указываем в запросе то место, которое будет фаззиться. ПКМ. Extentions → Custom send to → Send to → *Profile name*

Немного пояснений

Что происходит, полагаю, и так видно, но поясню на всякий случай.
Плагин Send to берет запрос и пишет его содержимое во временный файл, путь к которому можно получить макросом %R.
Scp берет этот файл и загружает его на vds.
Ssh запускает ffuf, передавая на вход загруженный файл. Ffuf, как вы уже догадались, поддерживает возможность такого запуска.

Как вы понимаете, ffuf здесь как один из возможных вариантов использования данного плагина, дальше дело за вашей фантазией.

На этом все, спасибо за внимание.