Attack-Defense

Компьютерная Безопасность: Введение в CTF

1
Что такое-Attack Defense

● У вас есть сервер

● На сервере находятся сервисы, с которыми взаимодействуют клиенты
● Точно такие же серверы (и сервисы) находятся у ваших противников
● Задача 1: найти проблемы безопасности у себя и закрыть их
● Задача 2: проэксплуатировать проблемы безопасности, чтобы украсть
секретную информацию (флаги)

2
Про сервисы на Attack-Defense

● Сервис – какая-то программа, которая похожа на реальный продукт

● Пример: веб-магазин, сервис хранения паролей/заметок, доставка еды,
преобразование картинок в текст и так далее
● Сервисы могут быть и с исходным кодом и без
● Обычно, у вас полный доступ к серверу с сервисами
● Обычно, сервисы упакованы в Docker-контейнеры

3
Какие навыки можно получить, занимаясь AD

● Администрирование Linux (примитивное)

● Опыт работы с Docker-контейнерами
● Написание кода + написание скриптов
● Чтение кода (чужого!)
● Анализ трафика и разбор инцидентов
● Промышленный опыт разработки ПО

4
Составляющие Attack-Defense

5
Составляющие Attack-Defense

1. Поддержка и сопровождение сервера

2. Анализ исходного кода сервиса
3. Поиск уязвимостей в исходном коде
4. Исправление уязвимостей
5. Атака других команд
6. Централизованная отправка флагов
7. Анализ поступающего трафика (логов сервиса)

6
Поддержка и сопровождение сервера

7
Администрирование Linux

● Все начинается со входа на сервер – чаще всего, это SSH

● Доступ только через терминал (никакого GUI)
● Нужно сразу сменить стандартный пароль пользователя
● Установить необходимый софт (например, рекомендую htop для
просмотра информации о процессах сервера)
● Найти исходный код и/или конфигурационные файлы сервисов
● Сделать бэкапы

8
Администрирование Docker

● Скорее всего, ваши сервисы находятся в контейнерах (и рядом с ними

есть docker-compose.yml файл)
● Наиболее частые задачи: поднять сервисы, остановить сервисы,
положить сервисы (и удалить их volumes)
● Тоже очень часто потребуется: залезть в контейнер и исследовать
файловую систему, посмотреть логи контейнеров
● Контейнеры, чаще всего, основаны на Linux

9
Анализ исходного кода сервиса

10
Поиск и скачивание исходников

● Всегда делайте бэкапы!

● Проще всего найти исходники через команду find и ls
● Загружать на основной хост можно через: scp, curl (+ transfer.sh, etc.),
всякие FTP решения (вроде Filezilla)
● Зачем загружать исходный код к себе: чтобы анализировать код более
удобным образом и не мешать коллегам

11
Чтение и анализ исходного кода

● Рекомендую посмотреть лекцию про реверс

● Читать код удобнее в специализированных IDE, но и VS Code пушка
● Можно читать код прямо с сервера через vim / nano / etc.
● Анализировать код удобно глазами, но иногда SAST и SCA анализаторы
могут помочь в поиске уязвимостей в коде (semgrep как SAST решение,
trivy как SCA)

12
Загрузка новой версии кода

● Убедитесь, что вы работаете с последней версией кода!

● Убедитесь, что никто не правит код на сервере!
● Есть два подхода: править прямо на сервере и загружать на сервер
новую версию кода
● Оба подхода имеют право на жизнь, но первый немного быстрее, а
второй более надежный
● После обновления кода – убедитесь, что вы перезапустили
контейнер с приложением (и удалили ненужные записи в БД)

13
Поиск уязвимостей в исходном коде

14
Анализ критических точек исходного кода

● Одна из важнейших точек приложения – место (или места), где хранятся

флаги
● Анализируем, какой функционал взаимодействует с этими критическими
точками
● Чаще всего, это какие-то приватные поля пользователя / объекта,
которые обычно не должны быть доступны рядовому пользователю
● Отдельно обращайте внимание на странные архитектурные
решения (вроде выполнения команд ОС, обращения к БД)

15
Снова про подход «снизу вверх»

● Зная функционал, которые взаимодействует с флагами, мы можем

построить цепочку «как вызвать этот функционал»
● Ищем endpoints, с которыми взаимодействует этот функционал
● Обращаем внимание на бизнес логику, контроль доступа
● Обращаем внимание на странный функционал

16
Про модели угроз

● Очень часто у сервисов есть какая-то тематика. Например: интернет-

магазин, социальная сеть, сервис по распознаванию картинок и так далее
● Для каждой из тематик есть какие-то специализированные уязвимости,
которые могут возникать. Например, для магазина это может быть
махинация с промокодами, либо покупка продуктов с отрицательной
стоимостью
● Для социальной сети – неправильная обработки логики
отношений между пользователями (например, «друг друга»)
● Ваша задача – построить эти модели угроз и работать с ними

17
Исправление уязвимостей

18
Проверяющие сервисы жюри

● Очевидно, жюри должно как-то проверять, что сервис работает как

положено
● Плюс, необходимо, чтобы кто-то закладывал секретную информацию в
ваш сервис
● Такие программы называются чекеры. Их задача — проверять, что
работоспособность сервиса не нарушена, и присылать новые флаги
● Если сервис отвечает не так, как задумано = сервис нерабочий

19
Определяем проблему

● Представим, что у нас Remote Code Execution

● Нужно понять причину проблемы: в самом code execution или в
отсутствии валидации пользовательских данных или где-то еще
● В большинстве случаев проблема в отсутствии валидации
(пользовательского ввода или прав), но могут быть и основанные на
бизнес-логике

20
21
Быстрое решение проблемы

● На том же примере с Code Execution

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

22
Полное решение проблемы

● В коде необходим Code Execution

● Но проблема заключается в том, что странные пользовательские
данные для конечного приложения – это нормально и мы их должны
дальше передавать
● Тогда нам нужно использовать prepared statements в нашем коде
● Полное решение требует погружения в проблему, но позволяет решить
ее на 99%

23
Атака других команд

24
Как именно мы можем воспользоваться проблемой

● Допустим, вы нашли проблему

● Найдя проблему, необходимо соотнести ее с критической точкой, а
именно, как получить флаг
● На примере с RCE: мы можем выполнять команды от лица сервера,
соответственно, можем подключиться удаленно к базе данных и
выкачать ее
● Если у нас IDOR: можем просматривать чужие записи

25
Написание скрипта для атаки

● Нам подается на ввод IP-адрес вражеской команды

● Ваша задача: вытащить флаги
● Как: вы знаете проблему; придумайте, как ее проэксплуатиравть

26
27
Почему важно обрабатывать ошибки (RuCTFE)

● Кейс: нашли проблему, написали скрипт, запустили, пошли исследовать

другие сервисы (флаги поступают, но медленно)
● Через час проанализировали логи сплоита – увидели ошибки скрипта,
из-за которых он падал в большинстве случаев, не заканчивая свою
работу
● Это стоило нам большого количества поинтов

28
Тот самый сплоит

29
Зачем мимикрировать сплоит под чекер

● Некоторые команды отсекают трафик по поведению, которое не похоже

на поведение чекера
● Это: User-Agent, последовательность обращений к endpoints, запросы с
кавычками и так далее
● Спрятав эксплоит, можно обойти эти проверки
● Плюс, это усложнит другим командам анализ вашего трафика

30
Централизованная отправка флагов

31
Ферма: что это и зачем

● Эксплоит должен атаковать другие команды

● После чего отправлять флаги для проверки жюри
● Очевидно, что это лучше сделать централизованно
● Ферма – сервис, которые управляет вашими эксплоитами + ведет
статистику успешных флагов / атак на другие команды

32
Наш выбор – Destructive Farm

33
Как ее используют

● Написать эксплоит в правильном формате

34
Анализ поступающего трафика

35
Зачем это нужно

● Понять, как вас атаковали только по логам nginx – сложно

● Просто потому, что вы можете контролировать сервер и собирать
трафик
● Увидеть все полезные нагрузки, цепочки обращений к endpoints, понять
как вас атаковали, как работает чекер – вот для всего этого и нужен
анализ трафика

36
Наш выбор – Packmate

37
38
Советы по анализу трафика

● Смотрите на приходящие и уходящие флаги в трафике

● Внимательно смотрите на User-Agent чекера и эксплоитов
● Когда видите потенциально опасный трафик – отметьте его для других
● Когда только начинаете анализ сервиса – смотрите, какой функционал
позволяет положить флаг, а какой – его забрать (на основе трафика
чекера)
● Смотрите за поведением чекера

39
Что дополнительно изучить

● https://cbsctf.ru/ad
● SPbCTF «Сезон атак-дефенса»
● https://telegra.ph/AD-A-vy-lyubite-morozhenoe-03-12
● https://telegra.ph/Setevye-analizatory-07-07

40
Ответы на вопросы

41
TODO Эпилог

42