Недавно выложил в паблик свою ферму для CTF в формате Attack-Defense, которую около года обкатывали командой 89cr3w 👻

https://github.com/arkiix/CulhwchFarm

Из интересного:
• API позволяет оптимизировать работу с фермой. Например, можете написать парсер команд, который добавит их в ферму (В репе есть примеры client/team_parsers)
• Валидаторы, с помощью них вы можете валидировать поступающие флаги в ферму (откидывать невалидные)
• Удобная настройка основных параметров фермы и параметров протоколов/валидаторов на фронте
• Генератор команд на фронте, Вы можете сгенерировать список команд в одно нажатие (Поддерживает IPv6)
• Скачивание уже настроенного скрипта-клиента на фронте (Автоматически установит URL и пароль фермы, attack-period)
• Удобные графики и метрики на основной странице
• Переделать протокол из DestructiveFarm или S4DFarm не составит труда, а основные протоколы мы уже завезли

Как поднять:
• Клоним репозиторий

git clone https://github.com/arkiix/CulhwchFarm

• Меняем SERVER_PASSWORD в compose.yml
• Выполняем

docker compose up --build -d

• После билда ферма будет доступна на http://127.0.0.1:8893

Сейчас зафорсилась уязвимость в aiohttp (CVE-2024-23334)

Если при добавлении обработчика возврата статических файлов флаг Follow_symlinks выставлен на True (Он служит для того чтобы обработчик следовал символическим ссылкам на файлы вне корневого каталога), то из-за недостаточной проверки это может привести к атаке обхода каталога (directory traversal, aka path traversal).
Что позволяет хакерам получить доступ к любым файлам на уязвимых серверах.

Данная уязвимость затрагивает все версии aiohttp, начиная с 3.9.1 и старше (Исправлено в 3.9.2).

Простой пример уязвимого кода:

app = web.Application()
app.router.add_static('/static/', path='static/', follow_symlinks=True)

PoC прост до безобразия, пример:

curl --path-as-is http://localhost:3000/static/../../../../../etc/passwd

В хакере вышла статья, написанная по моей работе с Pentest Award

https://xakep.ru/2024/11/15/email-bugs/

JWT blacklist bypass

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

Если пойти в Google с вопросом об отзыве JWT, вы наткнётесь на кучу обсуждений и предложений. Обычно подход заключается в занесении его в blacklist, который хранится, например, в Redis. В интернете много рекомендаций вроде: когда нужно отозвать токен, сохраняешь его (или его хэш) в Redis, а когда запрос с токеном прилетает на сервер — проверяешь, нет ли его там.

Во время пентеста я заметил интересную аномалию, природа которой описана в этой статье: Decoding the JWT anomaly. Если последний символ в подписи JWT заменить на смежный в алфавите, то сигнатура остаётся валидной, и сервер не замечает разницы.

Пример:

eyJhbGciOiJIUzI1NiJ9.eyIxIjoxfQ.OUTJgV9NjeWLUPzLk0QzICm280pH00Zf54IpR5C4IFs

eyJhbGciOiJIUzI1NiJ9.eyIxIjoxfQ.OUTJgV9NjeWLUPzLk0QzICm280pH00Zf54IpR5C4IFt

Заменив в конце токена букву s на t, получаем валидный токен. Можете проверить сигнатуру на jwt.io (ключ — “key”).

Отсюда появилась теория: если сервер ведёт blacklist JWT, сохраняя в него сам токен или его хэш, то, заменив последний символ, подпись останется валидной, но этого токена (или его хэша) не будет в blacklist.

Теорию я проверил на bug bounty, и уже во второй программе смог «возрождать» отозванные токены.

Если при разработке сервиса всё-таки необходимо отзывать JWT, то заносите в blacklist jti или другие уникальные идентификаторы токена.

VolgaCTF 2024