30 ноября — 1 декабря прошел квалификационный этап турнира CTFZone, на который зарегистрировались 1043 команды со всего мира. По нашим данным, задачи решали даже в Зимбабве (26 уникальных IP). Если копать глубже, это была университетская сборная из города Булавайо.

В этом году CTFZone стал отборочным этапом DEF CON CTF, поэтому команда, которая победит в финале (он состоится на OFFZONE 16–17 апреля 2020 года), поедет на турнир в Лас-Вегас. Чтобы счастливчики точно успели оформить визы, даты конференции даже передвинули на более ранний срок.

DEF CON CTF — это самые старые и авторитетные соревнования для безопасников, куда хотят попасть многие команды. Пальмовую ветвь победителям не дают, но и без нее все складывается хорошо. Сейчас в мире всего 6 турниров, через которые можно отобраться на DEF CON CTF.

География участников CTFZone

Про концепцию

В международном CTF-движении так сложилось, что команды из разных регионов специализируются в отдельных областях. Например, исторически россияне лучше решают веб, а азиатские и американские коллективы сильнее в PWN. На том же DEF CON почти все задания — это бинарщина. Возможно, именно поэтому в последнее время там лучше выступают американские и азиатские команды. Мы же на CTFZone пытаемся показать, что CTF — это не только PWN, но и много других интересных категорий: веб, криптография, реверс, OSINT, форензика, PPC.

Web

В задания по вебу авторы — в рабочее время специалисты по тестированию на проникновение — пытались перенести уязвимости из реальных проектов. Например, в таске Web-Shop использовалась популярная библиотека python-markdown2, где наш эксперт за несколько недель до соревнований нашел уязвимость нулевого дня для обхода фильтра XSS. В ходе CTF, правда, каждая из четырех решивших команд нашла свою версию этой уязвимости, что заставляет задуматься о качестве фильтрации в библиотеке.

Для задания Web-Card мы использовали уязвимость нулевого дня в стандартном Java-классе валидации XML. Обнаружена она была при тестировании реального Web Application Firewall, поэтому мы предложили участникам обойти WAF, разработанный нами специально для задания. Подробная версия райтапа будет позднее.

Ну а таск EmeraldRush показал, чем за последний год стали похожи GitLab и Github — уязвимостями, связанными с Ruby, на котором они оба написаны. Одна из них основана на CVE-2018-18649 (к ней, однако, нет эксплоита в открытом доступе), вторая — недавно обнаружена и опубликована на платформе HackerOne (описание можно посмотреть в статье). Разумеется, разработчики были уведомлены и об этих, и обо всех остальных веб-уязвимостях до соревнования, в соответствии с принципами Responsible Disclosure.

Crypto

В свою очередь, команда разработки криптотасков брала за основу не только постоянно встречающиеся в CTF баги, связанные с имплементацией RSA, но и нашумевшие атаки последних лет. Например, в задании OCB2 надо было разобраться с атакой на одноименную симметричную систему шифрования, за обнаружение которой на конференции Crypto дали премию Best Paper Award.

А в таске NTRU требовалось изучить атаку на асимметричную систему на решетках. Ее описали еще в сентябре, но найти и прочитать соответствующую статью было недостаточно. Автор задачи и сам столкнулся с проблемами, когда выяснилось, что в публикации был взят самый удобный для описания случай, который не работал при параметрах, выбранных в итоговом таске. Пришлось переделывать алгоритм! Интересно, что один из участников (Алексей Удовенко из команды LC/BC) решил задачу без статьи, придумав немного другой способ решения, построенный на том же принципе.

Forensics

Ну а самой каверзной категорией на нашем CTF стала форензика. Все привыкли думать, что такие задания решаются с помощью трех утилит: foremost, volatility и strings. У нас же таски были другие — например, необычная задача In-The-Shadows, для решения которой нужно было разобраться с техникой, описанной тут. Подробности тоже выйдут в райтапе позже.

Про подготовку

Непосредственно подготовка к квалификации CTFZone состояла из нескольких основных этапов (сбор проектной команды, разработка тасков, тестирование и разворачивание инфраструктуры, запуск ракеты в космос) и множества вспомогательных (поиск вдохновения, установление коммуникации, терзания и сомнения, депрессия, выход из экзистенциального кризиса).

За три месяца до старта на общем совещании были выбраны даты — 7 и 8 декабря. Команда пришла к выводу, что ничего не успеет, но все равно взялась за дело. А дней через семь эти нереальные сроки были сдвинуты еще на неделю раньше, так как и выбранные даты, и все следующие уже заняли другие CTF. Оставалось только улыбнуться, сжать зубы и работать с утроенной энергией. Назад дороги не было, разработка стартанула.

В итоге тасков получилось больше обычного — 30 штук. Каждое задание уникальное, но живет совсем недолго: 3 месяца подготовки и всего 36 часов полета. Зато какого! К кнопкам, которые ты бережно отрисовывал на фронтенде, прикоснутся ведущие CTF’еры мира — погрузятся в твою идею и дадут личный фидбек. Это огромный опыт и возможность рассказать о своей работе большому сообществу. Ведь зачастую с уязвимостями, которые закладывают в задания, связана какая-то история. Некоторые таски получились такими жесткими, что их никто не смог раскусить. К концу квалификации нерешенных задач осталось две: Popular Forensic и Web-Card.

Про инфраструктуру

К организации инфраструктуры турнира можно было подойти по-разному. Например, по старинке нарезать для разработчиков тасков виртуалки и дать им туда доступ. При таком раскладе каждый разраб становится довольным админом локалхоста, все работает так, как ему хочется, и остается только обеспечить сетевую связность. Понятно, однако, что ни о какой репликации и отказоустойчивости речи в этом случае не идет. Ответственный за нашу инфраструктуру именно так провалил в 2016 году один из CTF на ZeroNights и в этот раз, наученный горьким опытом, решил делать все по-другому.

Мы долго решали, где будем жить, и в итоге надумали разворачиваться в облаке. Причины понятные: соревнования для хакеров, так пусть уж лучше Google ломают, да и в загашнике уже были готовые наработки. Основным инструментом для создания платформы стал Terraform, который позволяет описывать инфраструктуру в виде кода в декларативном формате, а все остальные телодвижения берет на себя. То есть, например, вам не нужно думать, как сходить в API Google и рассказать ему, сколько и каких виртуалок вы хотите развернуть.
Еще надо было решить, как запускать таски. Нам очень повезло, что все разработчики уже умели писать задания в Docker. Это такой хайповый контейнеризатор, позволяющий упаковать сервис со всеми зависимостями в изолированную среду, которая не изменяется между перезапусками. Путей работы с Docker не так уж много: в основном это оркестраторы вроде Compose и k8s. Чтобы сделать все красиво, то есть реализовать хотелки с балансировкой, репликами, отказоустойчивостью и прочими энтерпрайзами, выбор оркестратора был очевиден — Kubernetes.

Тут, правда, возникло некоторое недопонимание между создателем инфраструктуры и разработчиками. Пентестеры — особая каста IT-мира: они частично вроде и админы, и сетевики, и в базы данных умеют, и в программировании ориентируются. В общем, не люди, а швейцарские ножи. Они крайне неординарны и амбициозны, но, к сожалению, когда было принято решение под каждый таск писать Helm, как-то забылось, что пентестеры — все же не профессиональные админы. Это привело к небольшой войне, в ходе которой пришлось объяснять, почему принудительно принимаются те или иные решения и устанавливаются ограничения.

Опыта написания Helm у ребят не было, но все они умели написать Compose. Сами понимаете, что между локальным Compose и Helm-чартом пропасть в несколько недель или даже месяцев изучения материала. Это был первый звоночек, намекавший, что есть какие-то проблемы (куда же без них на CTF, особенно когда команда и админ практически каждый раз новые).

Из-за нехватки времени автоматизировать все не удалось — некоторые вещи пришлось переложить на плечи самих разработчиков. Пентестерам пришлось сидеть на встречах, где им рассказывали, как писать хелмы, пока сами они, судя по всему, проклинали это девопсерство на чем свет стоит. Но, несмотря ни на что, мы успели — все таски были описаны и упакованы в Helm-чарты, мониторинг настроен в виде Графаны и Прометея. Наступил момент истины.

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

Про финалистов

По итогам в финал отобрались 10 звездных команд. Почему звездных? Дело в том, что 6 из 10 команд входят в десятку мирового первенства на CTFtime, а остальные четыре — немножко за десяткой, но тоже в топе.

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

Итоговая таблица финалистов CTFZone 2019 Quals

Что дальше?

Дальше можно будет немного выдохнуть, чтобы потом снова глубоко вдохнуть и начать подготовку к финалу. Он будет проходить в формате Attack / Defence, а это уже совсем другая история. У кого-то может возникнуть вопрос: а зачем это все? Вопрос хороший, но логичного ответа на него, пожалуй, нет. Просто если хотя бы на 5 секунд удается по-настоящему кайфануть от происходящего, почувствовать себя живым и увидеть, частью какой команды ты являешься, то все не зря!

Как мы готовили квалификационный этап CTFZone-2020