Всем привет. Вчера я в команде Doofenshmirtz corp (название с отсылкой к Финесу и Фербу из мультика детства) участвовали в AlfaCTF, и хочу немного поделиться впечатлениями от таких соревнований.

Сразу отмечу: я не являюсь CTF-игроком, который живёт только такими задачами. Но мне нравится периодически участвовать в подобных мероприятиях офлайн, чтобы не засиживаться только в своих рабочих задачах и посмотреть на безопасность немного с другой стороны. В этом плане CTF, как и хорошие практические лабы, отлично помогают переключиться и потрогать логику атак руками.

В этом посте не хочу разбирать всё мероприятие целиком и проходиться по каждой задаче, которую мы решили. Хочу остановиться на одной таске из категории Easy / Web / Logic, потому что она мне понравилась.

━━━━━━━━━━ Задача “Охота на инсайдера” ━━━━━━━━━━

В реальной жизни, когда мы видим небезопасный ответ сервера или утечку чувствительных данных, это чаще всего повод: • оформить отчёт на Bug Bounty • завести тикет разработчикам

Но не всегда есть возможность полноценно дожать такую историю до конца и посмотреть, к чему именно она может привести при развитии цепочки.

А вот CTF как раз даёт такую возможность: взять уязвимую логику и довести её до конечного результата.

━━━━━━━━━━ Что было в приложении ━━━━━━━━━━

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

По условию нам нужно было получить флаг, раскрыв историю о том, как один пользователь имел доступ к чувствительным данным до их анонса и продавал их.

Функционал веб-сервиса был примерно таким: • создание аккаунта • аутентификация • подключение 2FA по желанию • сброс пароля • мессенджер • приватные заметки

То есть точек входа уже было достаточно: от банальных инъекций до более интересных связок между отдельными частями функционала.

━━━━━━━━━━ Как строилась цепочка ━━━━━━━━━━

Самая интересная часть начиналась на механике сброса пароля.

В ответе сервера возвращался JSON, где раскрывались: • полноценный email • поле password_sha1

Как и многие, я сначала пошёл по самому очевидному пути: попробовать расколоть хеш через hashcat и CrackStation, вдруг пароль уже где-то светился и задача решается простым входом под нужной учёткой.

Но спустя примерно 10 минут, несколько словарей и пару безрезультатных попыток стало понятно, что автор задачи явно ведёт нас не туда.

И вот дальше началось самое интересное.

Я обратил внимание на cookie entropy_session. Уже само название как будто намекало: “посмотри внимательнее, здесь что-то есть”.

После разбора оказалось, что значение cookie кодируется в Base64 и имеет структуру: • username|password_sha1

И вот здесь случилось бинго. Потому что необходимые нам: • username • password_sha1 мы уже знали из ответа на сброс пароля.

━━━━━━━━━━ Второе препятствие ━━━━━━━━━━

Казалось бы, дальше всё просто: собрали нужные данные, авторизовались и забрали флаг. Но нет)

После попытки входа выяснилось, что у пользователя включена 2FA, и нужно вводить 6-значный OTP-код.

Первая мысль, конечно, была про brute force, но защита на этом этапе уже работала нормально: после нескольких попыток сервер отдавал 429 Too Many Requests. И здесь снова решала логика.

На форме был сценарий «Потеряли доступ к 2FA?», и при переходе на него в ответе json раскрывалось поле totp_secret, то есть секрет, необходимый для генерации одноразовых кодов.

Дальше дело уже было за малым: • берём totp_secret • генерируем валидный OTP-код • вводим его в форму 2FA • заходим в аккаунт Но и это был не финал.

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

#appsec #alfactf #ctf #cybersecurity