# Реквием по MCTF 2024 Finals ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/249f88ae-34a2-4f0b-9727-805cbcfe319e/0.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=ba7191a45e0fd54431fbf25d04fa8bf170c03da32c0170fa24e9058b542d7f22&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "full-width =3198x965") --- В декабре 2024 года состоялся [ежегодный финал ивента MCTF](https://ctftime.org/event/2595), в котором приняли участие 18 команд из России и две международные команды. Финальное мероприятие прошло в традиционном для организаторов формате, но с некоторыми новыми идеями и экспериментами. К сожалению, не все аспекты проведения ивента соответствовали изначальным планам. В этой статье будут обсуждены возникшие проблемы при проведении MCTF Finals 2024 и причины их возникновения. p.s. я переписывал реквием 3 раза... и надеюсь на 4-й у меня все же получится дописать. --- # У нас была идея ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/7c6d0188-bb6c-4eda-94b0-77fac945d441/1.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=d30037839e18f6e6b3b0cf310675189cb045383cac92c5cf94c8d5d2f498e874&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "full-width =3198x965") Давайте для простоты просто перечислю те идеи, которые у нас были в этом году * Значительно расширить количество команд на финальной части соревнований (от части это связано с нашим желанием в будущем убрать ограничение на количество команд от одного университета) * Участие международных команд * Client - side сервис - blinbin --- # Проблема 1. Поздний старт разработки сервиса blinbin ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/175159a0-c125-48b1-be6c-24fdfa4992f5/2.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=9967ba3e17f4ca5a8e53b04bda10802472810ebd672c11fc077e50ac1d3d7711&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "full-width =3198x965") В самом начале мы думали, что для нас все пройдет по стандартному сценарию: :::tip * Приехали на площадку * Развернули заранее подготовленные роли * Раскидали сервисы и архивчики с конфигами и токенами * Ждем открытия сети ::: Но увы это было не совсем так, тут мы столкнулись с первой проблемой и первой ошибкой, которая повлияла на многие вещи. ## "Дай ему еще 30 минут" Обычно приемка сервисов у нас работает следующим образом: :::tip * Идея сервиса * Обсуждение идеи * Разработка * Предварительный прогон сервиса и чекера * Доработка (опционально) * Финальный прогон сервиса и чекера ::: Тут мы всегда стараемся сделать так, чтобы финальный прогон сервиса производился **как минимум за неделю до ивента**, это делается для того, чтобы у ребят было время в случае чего поправить какие-то мелкие косяки. С сервисом blinbin вышло все иначе, сам сервис был довольно сильно перегружен с точки зрения функционала и возможностей, но все это выстраивалось ради одной единственной уязвимости, которая и должна была стать особенностью ивента. Увы все сроки по сдаче сервиса были провалены, сервис был дописан за ночь до ивента, а чекер писался в эту самую ночь и, по сути, был "дописан" за 30 минут до старта ивента. ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/4f1d477a-c491-4e89-a2e9-293d3faa9aea/%D0%91%D0%B5%D0%B7%20%D0%B8%D0%BC%D0%B5%D0%BD%D0%B8-1.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=34ef97c049939488a5c4a0b337896644af2be3060af3d6a8568a5937b503b28a&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =856x477") И тут встал очень сложный выбор: * Обезопасить себя и не пускать данный сервис на ивент, доработать и загнать на следующий год :::success **Плюсы:** мы однозначно не получим проблем и бугурта от команд, что с сервисом что-то не так, а вероятность была очень высокая, ибо сам сервис мы так и не смогли протестировать. ::: :::warning **Минусы:** мы оставляем наш ивент без главного сервиса и главной задумки, оставляя всего 3 сервиса, что в целом нам показалось мало. ::: Рискнуть и выпустить этот сервис на ивент, думаю плюсы и минусы понятным образом вытекают из первого варианта. ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/0351c3f8-8473-4782-8e18-3159644b10ed/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=dffe652fa6f2c8ffe23a2ceb3a3fac316d1fed56cda5252242aaa92125eebf65&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =1500x415") И **мы приняли решение рискнуть** и запустить этого кота шредингера в финалы без какого либо предварительного тестирования. ## Итог **Мы не успели дописать сервис и решили, что сможем сделать все идеально за ночь до ивента без какой-либо внятной проверки.** :::success **Решение:** не пускать сервисы на ивент которые не прошли достаточного количества проверок и придерживаться указанных дедлайнов. ::: Как когда-то писал Сережа: ``` Мы на M*CTF уже давно привыкли дописывать сервисы или чекеры в ночь перед соревнованием. ``` И мне очень жаль, что мы повторили эту ошибку спустя 3 года. --- # Проблема 2. Таймауты с момента старта сети ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/bd61328e-f038-47d9-9a80-f1b75766ead3/3.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=6499a6c511180915912a3d3e99dc98f3f598720faa10362fd843f8a321b13932&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "full-width =3198x965") После открытия сети и старта хода чекеров, я заметил довольно странную вещь, с самого старта чекеры валились в таймауты. Прежде чем продолжать, давайте я покажу вам ключевые параметры, которые стояли у нас на чекерах: * `checkInterval: 20` - определяет интервал в секундах между проверками * `checksInRound: 3` - определяет количество запусков чекера за раунд Первая проверка всегда происходит на 0 секунде каждой минуты, затем через каждые `checkInterval` секунд Таким образом, `checksInRound * checkInterval` составляют длину раунда в секундах. Получается 1 раунд у нас длился ровно 1 минуту с ходом чекеров раз в 20 секунд. Это означало, что чекер должен успевать выполнять: :::info * Чек (check) * Сгенерировать флаг (pull) * Выполнить push -> положить флаг. ::: В целом мы хотели сделать это особенностью нашего CTFа - ход чекеров 3 раза за 1 раунд добавлял довольно сильно с точки зрения динамики игры. ## "Это не могут быть чекеры" Перед началом ивента, с учетом увеличенного количества команд, мы увеличили и аппаратные требования к нашим раннерам, на один хост выделялось: * **ЦПУ:** 12 ядер * **ОЗУ:** 28 ГБ * **Диск:** 20 ГБ SSD (20 МБ скорость) И таких раннеров мы подняли 3 штуки. Самое первое на что я подумал в тот момент, когда увидел моментальные таймауты... это, что чекерам не хватает мощности и они банально аппаратно не успевают выполнять операции. Мы пошли анализировать потребление ЦПУ / ОЗУ / Диск. ![p.s. пикча для примера, анализировали мы примерно такие же графики посредством встроенного мониторинга YC](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/7c7b5fcc-de10-4774-a9ec-cea900bdeed0/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=17145f3d7daf3a122f097d37cb9274dd4b160e2ab691488f5381f7b6b3b04653&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =1418x350") На первый взгляд ничего криминального мы не заметили, все в целом было стабильно и проблем просто было не видно. На всякий случай решили доставить еще 2 раннера на запас, и того **мы имели 5 раннеров и еще заготовку на 2 в случае ЧП.** После того как мы подняли количество раннеров, ситуация с таймаутами не изменилась, а местами даже ухудшилась. Но на самой борде сервисы хаотично не отваливались и ничего однозначно не указывало на проблемы кроме нашего мониторинга. Я решил просто подождать и надеялся, что чекеры расчихаются... а дальше произошло вот это. ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/dcd28558-395f-4ea6-b991-9c13f6b3fdf0/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=d384d5905d8f32a166d17dc596d4a3663219bb9e14293f0f163236ca028c4134&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =957x444") Неожиданно упало вообще все... первые мысли которые были у меня в голове: * Отъехал VPN сервак * Эти таймауты на чекерах сказали свое ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/a22bd7e7-49ea-4bdc-a72d-7541cba04d8a/Pasted%20image%2020241220114602.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=0d478e04ef2e2868cedd711ce9c07501c2bbde625d7820778c388941a1af7ef2&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "left-50") ### Проверка OpenVPN сервера Первое, что я сделал, пошел проверять все ли хорошо с OpenVPN сервером и его службами внутри. После просмотра логов и базовой диагностики выявили несколько проблем: 1. **На некоторых конфигах был спам ошибки:** ``` Authenticate/Decrypt packet error: bad packet ID (may be a replay)... ``` 2\. **Потери пакетов на некоторых клиентских конфигах.** На это сильное внимание я не стал акцентировать, т.к. это происходило лишь на части конфигов, а отвалилось у нас все и везде, но взял на заметку данную проблему. К этому мы еще вернемся. ### Проверка runner серверов И вот тут началась самая неприятная история, то, на что стоило обратить внимание с самых первых минут - скорость чтения и записи диска. Провалится на некоторые раннеры было просто невозможно, ибо диск бился в сотку по скорости, что привело к практическому повисанию некоторых серверов и служб внутри.   **Единственный способ вернуть их к жизни -> ребут серверов.** Было принято решение постепенно отключать раннеры и накидывать им скорость чтения и записи. После того как на первых двух раннерах мы накинули **до 65 МБ** и вновь запустили раннеры заметили, что максимальное потребление по скорости чтения и записи **не превышало 20 МБ**, в целом это ответило на вопрос, почему раннерам стало плохо (хотя это довольно аномально и с таким мы встречались впервые за 4 года). После того как мы проделали эти операции на всех раннерах… увидели, что как такового положительного результата мы не получили... наступила стадия отчаяния, все, что явно указывало на проблемы мы отметнули. ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/70b42aa5-d342-49aa-875d-7a78be2a8e04/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=133b9c50691848c04a9727f07dd7300265e1f5ee8b94fb0e503b6e03fe328d14&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =856x357") И тут пришла мысль через раннеры потыкаться в ручки, на которые ходит чекер и тут мы нашли причину. ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/6b57a5db-5508-41e5-8fbe-7049262506a3/Pasted%20image%2020241220123122.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=d8dcfabfac58513b0a999c1fab3fcc7e45973324abbad92dde1d93cd085999c6&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject) Мы обнаружили, что виновником стал сервис - **blinbin.** Но подробнее об этом напишем чуть ниже в итогах. Теперь смотрим на эту схемку. ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/eea0295f-9d7f-4c55-a058-9565f62972d2/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=da66d7f052a3b1dc575eadf5139457f2325aa67e342792c4b2cea59cba9c4475&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =824x327.5") Смотрите, по параметрам нашего чекера, у него есть 20 секунд на: * **Чек** * **Пулл** * **Пуш** Знаете, что произойдет если наш чекер зависнет на чеке > 20-и секунд? ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/d4924e3b-149a-49ba-8099-798ad1ebeb45/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=e6e1a88ee6c2d0652b1ba1a4e3e6627e081843d762c7dabbdecb7e2bbd26c6fe&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =866x411.5") Он залезет на свою вторую проверку и благополучно пропустит её, а если он её пропускает -> он считает, что ни один сервис ему не ответил, а значит у всех команд сервисы недоступны, что, собственно, и происходило. А зеленело все... через время, ибо 3-й ход чекера все же проходил. Ручка зависала спустя какое-то n-ое количество ходок на неё. ## Итог 1. **Мы очень долго диагностировали проблему, хотя она была у нас прямо перед носом** :::success **Решение:** НИ В КОЕМ СЛУЧАЕ, нельзя игнорировать таймауты на чекерах, вероятно обратив на это должное внимание с самого старта, мы бы могли сразу перейти к источнику проблемы, а не тратить время на догадки. ::: 2. **Чекер не успевал получить ответ с такой трассой за отведенное время.** :::success **Решение:** * Уменьшить количество ходов чекера до 2 или 1-го, другими словами, изменить параметры следующим образом: `checkInterval: 30 / 60` `checksInRound: 2 / 1` * Править таймауты на сервисе, в целом мы попытались это сделать, но столкнулись с двумя следующими проблемами ::: 3. **Мы не понимали какие именно нужно выставить таймауты на сервисе, без предварительного тестирования этого сервиса, увы без времени на тесты эмпирически быстро мы не смогли подобрать нужные параметры таймаутов.** :::success **Решение:** проверять - проверять и еще раз проверять сервисы перед началом ивента и делать это в несколько этапов: * На длительном промежутке - тут можно запустить сервисы и поиграть на них локально командой * Проверка исключительно ручек куда ходят чекеры, нагрузить и убедится, что таймаутов не будет. Но как уже было написано ранее, этот сервис мы пустили под свой страх и риск... поэтому нормальных тестов на нем не было. ::: 4. **У нас было 5 раннеров (2 в запасе) на которых нам необходимо было быстро поправить параметры c последовательным перезапуском раннеров, увы именно быстро мы этого сделать не могли.** :::success **Решение:** написать механизм, который делает это нажатием одной кнопки, например написать ansible роль под такую задачу. ::: 4. **На бэке сервисе blinbin была не одна ручка, которая возвращала полное содержание таблицы данных.** Это приводило к долгому получение этих данных клиентом, что серьёзно влияло на производительность чекеров. Лишь на одной из этих ручек `/api/users` было добавлено ограничение (не отдавать данные старше 30 минут), но оно было недостаточным и не защищало от целенаправленного переполнения данными :::success **Решение:** в сервисе не хватило клинера, который подчищал бы весь мусор ну или наконец добавить к нам в борду атак дату, что частично решила бы эту проблему. ::: Так же тут можно отметить особенность исполнение баги уязвимость предполагала атаку на клиента через создание референса целевому пользователю на другой пост. Когда этот пользователь заходил на свою страницу, клиент начинал дёргать каждый пост, в котором его референснули, по названию. Всё это происходило через хром-драйвер на чекере. Ввиду непродуманности данного функционала, существовала возможность заставить клиент очень долго обрабатывать страницу при создании множества референсов на данного пользователя. Чекер, конечно, пытался зафетчить абсолютно все референсы, но банально мог не успеть по таймауту выполнить данное действие. При обнаружении уязвимости всеми командами ситуация бы стала ещё хуже, т.к. каждая команда создавала бы референс на каждого пользователя в каждом сервисы. в результате, дизайн сервиса его и уничтожил. 5. **Ошибки на клиентских конфигах OpenVPN** * `Authenticate/Decrypt packet error: bad packet ID (may be a replay)...` Эта ошибка говорит о том, что в конфиг льются дубликаты пакетов / MiTM - атака (но в нашем случае это именно дубликаты). Пока команда не выключит лишний конфиг, стабильного подключения на интерфейсе не будет, ибо пакеты будут перебивать друг друга. То же самое касается и множественного подключения конфига на разные хосты. :::success **Решение:** skill issue - увы за участников мы никак это исправить не можем, подумываем над маленькой документацией с советами ::: * Потери пакетов Пришлось немного покопаться... и поэксперементировать, в итоге нашлись проблемые участки в наших конфигах. По сути всю проблему можно описать прямо такой вырезкой: > Перед пакетом длиной ``, который дошёл сервер оказывается отправлял еще один побольше - `` и он не доходил. После того как были отправлены эти два больших пакет клиент послал **ack** на пакет ``, мол вижу всё вплоть до твоих больших пакетов, после чего сервер несколько раз ещё пытался слать пакеты начиная с `` безуспешно ожидая от клиента подтверждения. А ну и фрагментации у нас не было :melting_face: :::success **Решение:** На **jury_client** и **vuln_client** ``` tun-mtu 6000 txqueuelen 1000 mssfix 0 keepalive 10 60 ``` Заменили на: ``` tun-mtu 1500 fragment 1300 mssfix keepalive 10 30 auth-nocache ``` На **jury_server** и **vuln_server** ``` mssfix 0 tun-mtu 6000 ``` Заменили на: ``` tun-mtu 1500 fragment 1300 mssfix auth-nocache ``` p.s. тут представлены лишь участки конфигов, а не полный конфиг (ну мало ли) ::: Описывать почему именно так… а не как-то иначе - местами эмпирически выявленные параметры, местами позаимствованные у более опытных ребят. p.s. данные конфиги уже протестировали и никаких проблем по потери трафика обнаружено не было. --- # Проблема 3. Проблема на сервисе blinbin убивает наш CTF ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/512a2509-2224-4222-80b7-c05e9f9dc013/4.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=c29c29c2a88d17ce6fa62147e9634c183ce9215b68dd7f18a46a6f5b49787dbc&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "full-width =3198x965") Окей, ивент идет и нужно как-то выруливать из этого пиздеца. Проанализировав весь этот ужас, мы пришли к понимаю того, что просто так выпилить ручку или быстро исправить проблему на чекерах с этим сервисом у нас не получится. ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/2bcea553-0715-4ffc-87e4-f2327f5cedea/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=20e70e71c3019066af47053b1d347ebbf0eaf3f34a61523e76a9cd88b4246446&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =471x477") ## Итог 1. **Нам нужно выпилить ручку, но сделать этого мы не можем, ибо там лежит уяза и вместе с этим исправить проблему на чекерах мы так же не можем** :::success **Решение:** заморозить сервис с выводом его в 100% SLA, что в целом было единственным и как по мне правильный решением в данной ситуации. ::: Но опять же нам пришлось потратить на это время, ибо нам хотелось оставить сервис поднятым, а механизма заморозки сервисов как такового у нас не было, поэтому мы на горячую патчили все наши раннеры. Не знаю можно ли сводить это в отдельную проблему, скорее это просто доработка к нашей борде на будущее. 2. **Сервис blinbin успели просплойтить и увы просплойтилли анэнтендед, гребанный jwt.** :::success **Решение:** опять же все упирается в тестирование сервиса перед ивентом, чего сделано не было. ::: --- # Проблема 4. Не сдаются флаги или “Это мой последний MCTF” ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/8c7f0161-8984-482b-8132-a34533212a3a/5.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=3007dab1f2fa0cfee7f3cadb276e01f9c96ad0f7a8d63c0965f4cfc18295ce8d&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "full-width =3198x965") **Но на этом проблемы не закончились, после заморозки мы обнаружили следующую проблему:** ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/48c8084a-b3f5-4263-80f2-da4dc268586a/Pasted%20image%2020241220125221.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=941baea4f20fd620436601100f6f3c836c36c4926abc94dc7d8131df9ccb4017&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "right-50 =385x64") ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/31771e8d-fadc-42c1-96a5-434129b07cf0/Pasted%20image%2020241220125331.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=44abc77257405c0ef5fb2a32e179007a2be50cb956b401db7cebcdc53f9c6778&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "left-50 =385x131") И с этой проблемой мы не справились вплоть до конца ивента, и произошло это по одной причине - невнимательность. На M\*CTF у нас всегда играло 12–13 команд, и все скрипты генерации всего что только можно, в частности и генерации токенов команд, были зашиты в отдельный скрипт, который работал с нашим основным файлов конфигурации борды, который после подтягивался с помощью ansible роли. Скрипт работал путем генерации токенов команд через счетчик, который я захардкодил. В этом году... я решил внести изменения в скрипт и отойти от захардкоженного варианта счетчика и сделать дин. подсчет команд и от этого уже выполнять генерацию. В целом, скрипт был написан и даже протестирован, но произошла вот такая ситуация.  ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/a112d05c-b522-48eb-a4c0-745189c141a4/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=83a37242ebf23eeea51cba1e7eb405be9ff0215346c61b635dde1f1cacfb02ff&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =856x503") Новый скрипт не тестировался на основном конфиге (не хотелось его побить), а тестировался на отдельном конфиге, который лежал рядом со скриптом. В итоге... я скопировал содержимое с основного конфига, где через `ctrl+c` были заполнены команды, но начиная с 12-ой команды токены просто повторялись. ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/d30f8e27-a11d-442a-a384-2a165cbeb44c/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=b4e950d74ee765693d7ab0c2334959cc8dd90feb86a226c71abab45448858b9a&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "left-50 =342x752")После того как я протестировал скрипт и убедился, что теперь дин. генерация токенов работает, я забыл поправить путь до конфиг файла и запустить скрипт повторно уже на основном конфиг.файле. И выходит, что уже вторым скриптом, который занимается упаковкой конфигов и сбором токенов, я собрал архивы с повторяющимся токеном начиная с 12-ой до 18 команды. Это означает, что все команды в этом диапазоне сдавали флаги для той команды, у которой данный конфиг был первее -> все сдавали флаги от команды номер 12 -> **N0N@ma13** Самое неприятное в этой ситуации, меня спрашивали про токены, но у меня перед глазами был открыт тот самый дубликат конфига на котором и тестировался скрипт, а не основной через который все раскатывалось. ## Итог **Флаги сдавались, поинты для флагов подсчитывались, на борде флагов нет.** :::success **Решение:** ~~никогда больше не проводить СTF~~ не знаю, как это комментировать и не знаю почему так произошло, банальная невнимательность и сумасшедшая уверенность в своей автоматизации, что я даже не стал проверять это на самих хостах после старта игры.  Нужно быть внимательней и перепроверять токены после раскатки стенда, как вариант вынести генерацию токенов на борду. ::: --- # Проблема 5. zbank - первый большой опыт для наших ребят ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/982fba12-198b-4f9c-95e0-98abc7971c06/6.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=3f69ac47984d3e1ae16ad4095a0834804142d80a8442c4c9fadb908c8af98f36&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "full-width =3198x965") Так вышло, что мы иногда к созданию сервисов привлекаем не самых опытных ребят в разработке из нашей команды, чтобы они учились и набивали шишки. ## Итог 1. **Молодые ребята на разработке** :::success **Решение:** увы с этим мы ничего поделать не сможем, мы заинтересованы в том, чтобы они продолжали пытаться и разрабатывать, мы в них верим :) Но вероятно чтобы прям не было такой задницы… мы предварительно отправим их сервисы на тренировки… для более лучшей отладки ::: 2. Касательно внутренностей самого сервиса / чекера * **В чекере не тот метод, не те параметры из-за чего флаги можно было брать просто так, а вулна пропадала** ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/1542016e-c55d-41f1-84bc-9d842a017dba/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=dd03d2f43689278e24d33bf02f574511e0f224ba0ffe8c0650909cce06d02395&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "left-50") ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/ce0283ff-a7d4-4f84-9043-ef7ae31bcdc4/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=39a43063bc90045b55e4ec6a15be2b73aa04ef3be85d70ef40229e95a847cbc7&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject) * **Тот самый потенциальный анэнтендед, конкатенация прямо в строку без параметризации (48), должно быть как в 31-34. такого во всех моделях много** ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/094cd98d-4c43-47ca-974d-d6fbfa506b21/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=48ee75674d0b1f8fd6bf44ff3dc6214946d08e9da3033310f3faa21eaf5dbc2b&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject) 3. **Забыли из чекера вынести лишние части алертов** ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/108053d0-eb20-406d-a180-02723256d07b/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=ba5e2506b357774c584699c56f39e6c58911e9a91ba05824f6fc6abb4bb1f667&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "left-50 =428x539") :::success **Решение:** skill issue в разработке сервисов, будем набивать лапу ::: 4. **Конфиг для VulnBox не работает на Windows** :::success **Решение:** использовать GNU Linux… мне правда нужно это комментировать? ::: --- # Работа над ошибками ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/ad7186e2-4800-4239-95b0-beba03d4558c/7.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=68c181f4747bf05dabce75f9b95f58f4cbe018b66a138bd7521e8df8c7379e5e&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "full-width =3198x965") По итогу мы вынесли целый пласт того… что нам необходимо исправить до следующих CTF, вот лишь часть таких задач: - [x] Заморозка сервиса одной кнопкой - [x] Дополнить мониторинг (мы хотим видеть вообще ВСЕ) - [x] Атак – дата - [ ] Логирование флагов - [x] Провести работу над ошибками и не допустить повторение ошибок финала ## Где будем проводить работу над ошибками А проводить работу над ошибками мы будем на таком прекрасном ивенте как **SIBCTF 2024.** ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/a5db63ad-6284-4430-9001-cd66004c08a2/%D0%9B%D0%BE%D0%B3%D0%BE%D1%82%D0%B8%D0%BF%20CTF.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=41abf911fe89f09012d72511c8653fb908ae2c2f6cdd3b3e6559bd31c3f493f4&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =445.75x457.5") Там наша команда участвовала в качестве админов инфраструктуры ивента, и нам очень сильно хотелось проверить свои силы еще раз. ## Как все прошло? Мы провели 2 ивента: * [Первый день «Sibintek CTF»](https://t.me/sibctf/150) - участвовали взрослые дядьки * [Второй день «Sibintek CTF»](https://t.me/sibctf/158) - участвовали студенты И если прям коротко подводить итоги, то вышло все - круто. Мы учли все ошибки допущенные на финалах и смогли по сути все отработать и на практике убедится, что с нашей стороны ошибок по части администрирования допущено не было. Все 2 ивента прошли без проблем и падений. ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/85af1b34-9af7-4174-9708-9c5166597a29/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=731c88c416794cb426f22ef3cbcfb9e770dfe4c25df41099fe3ae2f97ddb80b1&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =890x444.5") И без единого таймаута :) ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/d90373e1-48cb-4066-8cda-e0c281e00f3a/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=cfb111ac7510f6e2e899d9c7c1ec06d0c85f3f24e44f23dcd3e4ebc242e13be4&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =933x339.5") --- # Что дальше? ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/287dd68d-9a90-4679-9d6a-a3bd735f2955/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=1cb120f8234a28157b2b5e613f6f3fb982c4f3eb698048d3ce2449c9ebcd321e&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "full-width") На самом деле… не могу сказать точно будем ли мы проводить дальше M\*CTF, в том же составе или нет… но думаю, что с вероятностью на 90% это будем мы. А если это будем мы, то наверное лично от себя я могу пообещать, что все будет круто и без таких проблем… с которыми мы встретились в этом году. Для нас это стало крутым опытом и хорошим пинком, который дал возможность пересмотреть процесс разработки и подготовки в ивентам такого формата. Думаю на этом все, всем кто участвовал еще раз огромное спасибо и надеюсь молодым организаторам будет полезно почитать про ошибки которые были допущены нами… всех с наступающим, встретимся уже в будущем году :3 ![](https://minio.binarybears-notes.ru/datawiki/uploads/3a0325a9-4fa8-4f37-b8b3-19843d9b0219/c569207e-e516-46f7-8623-022869a491e4/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T124500Z&X-Amz-Expires=86400&X-Amz-Signature=5b1d3232979e4c42c7c6968564282fbbc52c10f45c6f0a70086fee4db84805e4&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =471x628")