Как докатиться от broken access control до нескольких вариантов RCE.
Итак, представляю вашему внимаю write-up нескольких уязвимостей, найденных мною некоторое неопределенное время назад в рамках bug bounty. Описывать буду в порядке нахождения и соответственно раскрутки. Поехали.
Первый путь до 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 инфры.
