Skip to content

Latest commit

 

History

History
63 lines (41 loc) · 3.25 KB

README.md

File metadata and controls

63 lines (41 loc) · 3.25 KB

Web | Medium/Hard | Legacy

Информация

Даже простая секретница в нашей организации использует legacy-сервер авторизации.

Что может пойти не так ? http://:3210/login

Деплой

cd deploy
docker-compose -p web_legacy up --build -d

Выдать участинкам

Архив из директории public/ и IP:PORT сервера

Описание

Задача представляет собой простую секретницу, где у пользователя admin хранится флаг как секрет.

Для авторизации в приложении используется внутренний сервер, написанный на CGI (perl).

Задача - прочитать флаг админа.

Решение

Авторское решение.

Решение основано на двух фактах:

  1. Мы контролируем параметр user при генерации session-cookie и параметр не экранируется. Это означает что у нас есть Header injection - мы можем добавить новый заголовок в ответ Auth-сервера.
  2. python-requests при перенаправлении (redirect) отправляют нестандартные заголовки на новую страницу (как и большинство клиентов).

Тогда при генерации session-cookie мы можем добавить в ответ сервера заголовок Location: <our_site>, HTTP-клиент последует за перенаправлением и отправит запрос на <our_site>. В запросе будет секретный ключ для генерации сессий.

  1. Создаем пользователя с именем содержащим \r\nLocation:x, где x - наш вебхук.
  2. Аутентифицируемся за этого пользователя, на наш вебхук придет запрос с секретным ключом.
  3. Используя полученный AUTH_KEY подписываем куку для юзера admin.

Solve

Альтернативное решение

При генерации JSON ответа для проверки сессий параметр ** user** не экранируется.

Тогда, если мы создадим пользователя c именем admin", "garbage": "some, такого пользователя не будет в БД, однако в ответе будет валидный JSON, в котором user=admin.

Однако напрямую такой пэйлод не сработает (из-за кодировок), из-за чего нужно будет разбираться как правильно передать такой пэйлод.

Флаг

CUP{108bf777563a87921580b1e72c3578ad68f152d6}