Статья Эксплуатация фреймворка Empire C2

[BLUA]

Источник:

ACE Responder

Hands-on cyber defense training and challenges for SOC analysts, threat hunters, detection engineers, and purple teamers.

aceresponder.com

Перевёл: BLUA специально для xss.pro

Этот отчёт отхватывает процесс эксплутации фреймворка Empire C2 версии ниже 5.9.3 и завершается рекомендациями для атакующих и защитных команд. Вы можете найти демонстрацию эксплойта здесь.

Как компания, сециализирующая на реалистичном оборонительном обучении, мы очень заинтересованы во внутреннем устройстве фреймворка управления и контроля(C2). Empire - это модернизированный, открытый фреймворк, оснащённый широким спектром возможностей. Изучение его внутренней работы предоставляет две возможности: во-первых, улучшить моделирование действий противника, и во-вторых, разработать новые защитные техники. При анализе процессов начальной загрузки и выполнения задач мы обнаружили несколько уязвимостей, которые злоумышленник мог бы использовать для получения root-доступа к серверу C2.

В понедельник, 5 февраля 2024 года, мы сообщили об этих уязвимостях компании BC Security. Команда разработчиков оперативно начала работу над устранением проблемы и выпустила первый черновой патч всего за 24 часа. К пятнице, 9 февраля, BC Security выпустила Empire версии 5.9.3, включающую тщательно протестированный патч, который полностью устраняет выявленные уязвимости.

Предистория Empire

Основная причина этих проблем впервые появилась в 2016 году, когда @zeroSteiner сообщил разработчикам об уязвимости обхода каталогов. Его эксплойт, получивший название Skywalker, использовал особенности того, как агенты Empire извлекают файлы с компрометированных хостов. Путём имитации агента он мог "обмануть" сервер C2, заставив его думать, что на задачу "скачать" ответил действительный агент. Поскольку сервер неправильно обрабатывал имена файлов, zeroSteiner мог перемещаться вверх по файловой системе и перезаписывать критически важные системные файлы, что приводило к RCE.

Разработчики Empire должным образом устранили эти проблемы в последующем выпуске. Однако уязвимости обхода путей снова возникли в результате фундаментальных изменений и обновлений.

Загрузчики

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

Есть два ключевых элемента информации, которые мы можем извлечь из загрузчиков: ключ постановки(staging key) и URL сервера C2(командного центра). Слушатель на C2 сервере имеет один связанный с ним ключ постановки. Любой агент, который хочет зарегистрироваться у слушателя, должен "аутентифицироваться" с помощью этого ключа. Если у нас есть этот ключ, мы фактически становимся агентом для сервера C2.

Процесс постановки

Загрузчики Empire запускают агент в три этапа.

Стадия 0

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

Стадия 1

Мы запрашиваем вторую стадию с действительным ключмо инициализации. Вторая стадия используется для установления нового ключа сеанса через процесс обмена ключами Диффи-Хеллмана. Также на этом этапе мы сообщаем серверу C2, каким мы хотим видеть наш идентификатор сеанса.

Стадия 2

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

Задачи C2

Empire, как и большинство C2 фреймворков, имеет процесс постановки задач. Когда оператор взаимодействут с агентом, сервер C2 помещает их команды в очередь в базе данных. Агенты периодически обращаются к серверу C2 и запрашивают новые задачи. Если у них есть ожидающая задача, они выполнют указанное действие и отправляют результат серверу C2. То, как агент реагирует на задачу и как сервер обрабатывает ответ, определяется типом задачию. Вот несколько примеров типов задач:

- TASK_SYSINFO - Обновить информацию о хосте для агента
- TASK_SHELL - Выполнить shell команду
- TASK_UPLOAD - Загрузить файл на систему жертвы
- TASK_DOWNLOAD - Скачать файл с системы жертвы

Нет требования, чтобы задание существовало для того, чтобы сервер обработал ответ. Другими словами, мы можем заставит сервер обработат данные задания, отправляя непрошенные "ответы".

Обход директорий(Directory Traversal)

Изучив, как сервер обрабатывает разные типы задач, мы заметили зловещий комментарий в пути TASK_DOWNLOAD:

На этом этапе мы нашли первого кандидата на эксплуатацию. Если вы помните из STAGE1, агент сам выбирает свой идентификатор сессии. Идентификаторы сессий состоят из 8 байт и не проходят очистку. Это означает, что мы можем указать серверу, что наш идентификатор сессии должен быть ./../../, и он добавит его к download_dir: /<install path>/empire/server/downloads/.

Имея только эту информацию, мы можем перезаписать любой файл в одной или двух директориях выше каталога загрузок. Основные кандидаты - это server.py и config.yml в empire/server/. Мы могли бы перезаписать server.py, добавив бэкдор, или изменить каталог загрузок на корневой в config.yml и отправив ещё одну задачу TASL_DOWNLOAD, чтобы записать в /etc/cron.d. Однако оба этих файла заргужаются при запуске. Поэтому нам либо нужно вызвать сбой на сервере C2, либо дождаться, когда операторы перезагрузят его. Мы могли бы достичь этого с помощью социальной инженерии, например, отправив операторам поддельные ошибки через другой тип задач, но это не совсем удовлетворительный путь эксплуатации.

Обход системы обнаружения Skywalker

Вся причина , по которой мы можем создавать файлы вне каталога загрузок, сводится к следующему условию:

safe_path = download_dir.absolute()
if not str(save_file.absolute()).startswith(str(safe_path)):

Условие проверяет, начинается ли путь save_file с safe_path(/<install dir>/impire/server/downloads/). Если нет, серер предполагает, что это попытка атаки обхода каталогов, выдаёт сообщение о обнаружении "попытки эксплойта skywalker!" и прекращает выполнение.

Проблема в том, что метод absolute() не нормальзует пути. Он только преобразует относительные пути в абсолютные. Это означает, что он преобразует пут типа dir/file.txt в /home/kali/dir/file.txt. Но он также преобразует путь типа ../../dir/file.txt в /home/kali/../../dir/file.txt. Что сбивает с толку, нормализацией путей в модуле pathlib в Python выполняется с помощью метода abspath(), а не absolute().

Наша первая попытка обойти защиту заключалась в угадывании местоположения установки Empire. Наши обходы путей полностью перезаписывали save_path. Таким образом, угадывание правильного пути установки соответствовало бы условию startswith().

Но есть более простой способ сделать это. Наш обход пути перезаписывал save_path из-за нюанса в том, как pathlib добавляет дочерние каталоги. Если вы добавляете каталог с ведущим /, он заменяет весь путь на дочерний. Эта особенность работает в пользу Empire. Однако это показывает, почему удаление .. из ввода не является заменой нормализации пути.

Нам просто нужно убедиться, что наш обход не начинается с \, и у нас будет надёжная уязвимость.

Ещё один обход пути

Существует ещё одна функция, которая сохраняет файлы из ответов агента: save_module_file(). Логика более или менее такая же, как и у save_file(), включая обнаружение Skywalker. Функция save_module_file() вызывается двумя типами задач: TASK_CMD_WAIT_SAVE и TASK_CMD_JOB_SAVE.

Сначала мы рассмотрели TASK_CMD_JOB_SAVE, так как никто не любит ждать. Однако он неправильно кодировал ввод и вставлял b'' к расширению файла. К счатью, TASK_CMD_WAIT_SAVE работает точно так же, но кодирует наши данные перед созданием имени файла.

save_path для этой задачи интересен. Он создаёт директорию с именем из 15 байт и файл с:
- Имя хоста скомпрометированной системы
- Текущее время и дата
- Расширение размеров 5 байт

Итак "законный" файл будет называться примерно так: prefix/alice-pc_2024-02-09_16-25-32.txt. Мы контролируем 15-байтовый префикс и 5-байтовое расширение с помощью наших данных ответа. Однако эти два ввода позволяют только 5 переходов по каталогам. Даже если мы найдём место для записи, несмотря на это ограничение, мы застрянем с датой в имени файла.

Если вы помните из процесса подготовки, мы предоставляем информацию об операционной системе, когда запрашиваем третий этам STAGE2. Мы можем установит имя хоста, которое не имеет ограничение по длине или проверки ввода, на наше желаемое значение для обхода каталогов. Всё, что нам нужно сделать, это поместить обратную оболочку в фрагмент crontab и загрузить наш файл с очень некрасивым именем: _2024-02-09_16-25-32.aaaaa в /etc/cron.d/.

Это не работает. Оказывается, Cron очень придирчив к именам файлов и не любит специальные символы в нашем некрасивом файле. Однако у нас всё ещё есть удобные 5 байтов в расширении файла. Мы можем установить их как /../a и выполнить ещё один переход. Это создаст пустой каталог и однобайтовый файл /etc/cron.d. Наш save_path в итоге будет выглядеть примерно так:

Существует некоторая логика, которая усложняет этот подход. Условие в save_module_file() проверяет, существует ли путь сохранения, и создаёт необходимые каталоги, исли они не существуют.

Поскольку у нас есть один дополнительный переход по пути в расширении, os.makedirs() выдаёт ошибку. Он пытается создать каталог _2024-02-09_16-25-32. дважды: один раз для имени и один раз для последнего перехода ../. Ничего страшного. Нам просто нужно отправить ещё один запрос в течение той же секунды. Это приведёт к тому, что условие if not save_path.exists() вернёт true, и мы сможем записать файл a в /etc/cron.d/.

Выводы

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

Атакующие команды

Вы можете значительно снизит риск захвата C2-сервера, внедрив защищаемую архитектуру C2. Защищаемая архитектура предотвращает возможность использования вашей инфраструктуры против вас и ограничивает последствия успешного взлома.

Следующее основано на угрозах, использующих C2-сервер через C2-канал. Дополнительные меры следует учитывать для других векторов.
1. Заблокируйте доступ слушателю с IP-адресов, находящихся вне зоны дейтсвия.
2. Разверните выделенную инфраструктуру для каждого клиента. Если у двух целй разные границы безопасности, у них должная быть уникальная, изолированная инфраструктура.
3. Реализуйте мониторинг и обнаружение для инфраструктуры командования и управления(C2)
4. Полностью уничтожайте сервер командования и управления(C2) и извлечённые данные после каждого взаимодействия.
5. Меняйте ключи агентов/имплантов между взаимодействиями. Для Empire это ключи начальной загрузки и сессий.
6. Имейте план для быстрого изолирования скомпрометированных серверов C2.

Логи должны храниться отдельно от сервера C2 и мониториться на протяжении всего взаимодействия. Основные источники логов включают:
- Логи сервера C2
- Auditd
- Логи аунтентификации(auth.log)
- Логи веб-сервера или файлового сервера(если вы предоставляете инструменты/этапы)

Более широкая угроза заключается в возможности того, что злоумышленник получит ключ для промежуточного развёртывания. Ограничение доступа к слушателю предотвращает регистрацию агента/импланта злоумышленником с действительным ключом. Если все остальное не удаётся, мы можем обнаружит атаки обхода директорий с помощью базовых методов обнаружения.

Также стоит потратить усилия на создания дополнительных методов обнаружения в зависимости от вашей конфигурации C2. В первом пути, который мы исследовали, мы могли пройти только через две директории. Поэтому обнаружение изменений в заданиях Cron не применимо ко всем сценариям. Чтобы покрыт этот вектор атак, мы можем отслеживать изменения в файлах нашей C2-системы, так как они не должны часто изменяться.

Защитники

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

Те же соображения по обходу пути применимы к системам, которые мы защищаем. Подомно Empire, злоумышленник, ограниченный размером или лимитом символов, может перезаписать файл в рабочем каталоге службы. Хорошей идеей будет определить, каике скрипты и сполняемые файлы эти службы запускают регулярно, и следит за их изменениями. Также важно сохранять журналы веб-доступа и сервисов, которые, как и в случае с Empire, могут выявить строки обхода пути в неожиданных местах.