Всем привет!
Меня зовут @Алексей Медведев. Первый раз я участвовал в кибербитве Standoff в 2022 году. Далее стал капитаном синей команды (Command and Defend, которая впоследствии сменила название на Ctrl+Alt+Defend) и возглавлял ее на протяжении пяти битв подряд. На Standoff 16 я передал эту ответственную должность и стал своеобразным наставником команды. Расскажу о том, как мы защищали и как нас ломали.
В этот раз, на октябрьском Stаndoff, наша команда защищала город. Эта довольно обширная инфраструктура, включающая в себя несколько сегментов, а также 14 уникальных критических событий (события, реализация которых приводит к нанесению значительного ущерба компании), далее — КС. Перед соревнованиями мы подготовили схему сети, на которой отметили все КС, а также отобразили сетевые взаимодействия между сегментами.
В инфраструктуре помимо обычных Unix- и Windows-машин была целая подсеть SCADA — она включала в себя контроллеры, предназначенные для управления подсистемами, например уличным освещением, лифтами, МФЦ.
Спойлер: атакующие так и не получили доступ к SCADA, хотя реализация КС в этом сегменте и дальнейшее расследование считаются у нас верхом мастерства. Чтобы КС произошло, необходимо понимать, как работает контроллер вплоть до сигналов управления.
Стоит отметить, что от кибербитвы к кибербитве прослеживается четкая тенденция — увеличение количества Unix-машин. Это, безусловно, радует. В связи активным импортозамещением доля Unix-подобных систем в организациях сильно выросла — анализировать действия атакующих в них особенно интересно.
По результатам кибербитвы наша команда расследовала 11 из 12 реализаций КС, при этом уникальных КС было всего 3.
Такое малое количество уникальных КС — следствие того, что наша команда играла в режиме «Реагирование», с возможностью активного противодействия атакующим.
Из сданных командой 70 отчетов о единичных инцидентах 66 были связаны непосредственно с реагированием — то есть с нашей стороны по результатам обнаружения вредоносной активности были выполнены активные действия. Для противостояния атакующим организаторы предоставили нам большой инструментарий.
С помощью MaxPatrol EDR мы могли бесить «красных» реагировать вот так:
Заблокировать IP-адрес.
Заблокировать доменную учетную запись.
Заблокировать локальную учетную запись.
Полностью или частично изолировать узел.
Удалить ВПО на узле.
Разорвать удаленную сессию.
Отправить подозрительный файл с узла сразу в PT Sandbox.
Завершить подозрительные процессы на узле.
Стоит также упомянуть о IRP, которую нам предоставили организаторы и которой мы активно пользовались во время битвы, — R-Vision SOAR. На платформе была настроена интеграция с MaxPatrol SIEM и PT Application Firewall: данные о срабатываниях этих СЗИ отображались в R-Vision.
Очень удобно в единой консоли отслеживать всю активность и вести учет инцидентов.
Реагирование на инциденты также осуществлялось непосредственно из R-Vision SOAR. Для каждого инцидента был настроен набор возможных действий.
Функция, которой мы пользовались больше всего, — блокировка IP-адресов.
В совокупности было доступно порядка 40 коннекторов. Благодаря таким мощным инструментам противодействия мы достигли высоких результатов.
Теперь я расскажу, каким образом красные команды смогли проникнуть в нашу инфраструктуру и как у них получилось реализовать КС.
Первоначально «красные» получили доступ к нашей ДМЗ, в которой после проведения сканирования обнаружили общедоступные сервисы, такие как:
landing.city.stf — маркетинговая аналитическая платформа.
bets.city.stf — сервис букмекерской конторы.
govservices.city.stf — портал государственных услуг.
portal.city.stf — городской новостной портал.
punishments.city.stf — сервис для выставления и оплаты штрафов.
Внутри ДМЗ также находилась корпоративная VPN — vpn.city.stf, которая позволяла получать доступ ко внутренним сетям.
Таким образом, именно с ДМЗ хакеры начали продвижение по инфраструктуре, что является наиболее частым сценарием реальных атак. Отмечу, что мы фиксировали получение и запуск вредоносных писем на АРМ наших внутренних пользователей, но какого-то значимого эффекта атакующим достичь не удалось (спасибо MaxPatrol EDR).
Рассмотрим, как атакующие развивали атаку в нашей ДМЗ.
После скана сети атакующие обнаружили узел bets.city.stf, на котором требовалось реализовать КС.
В веб-приложении букмекерской конторы была возможность делать ставки на бойцов. Атакующие начали изучать его, установили, что в приложении можно проэксплуатировать уязвимость Path Traversal — например, с помощью специального запроса (/fighters/Soa%20Palelei?extension=%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc/passwd), и вывели содержимое файла /etc/passwd.
Далее они выполнили следующий запрос.
И получили содержимое файла systemd unit (из которого можно узнать, какую СУБД использует сервис bets), а также полезные сведения типа workingdirectory. Информация закодирована в Base64.
При расшифровке получаем информацию об используемой СУБД:
[Unit]
After=network.target mariadb.service
[Service]
User=root
Group=root
WorkingDirectory=/opt/bets-db
ExecStart=/opt/bets-db/server
Environment="DATABASE_HOST=localhost"
Restart=always
[InsFall]
WantedBy=multi-user.targetВ ходе дальнейшего изучения веб-приложения атакующие научились делать запросы напрямую к СУБД и принялись эксплуатировать всю ту же Path Traversal. В результате им удалось получить параметры соперников и более точно понять, как работает веб-приложение.
Далее на портале букмекерской конторы была создана учетная запись (далее — УЗ) Juyjuy.
После входа под данной УЗ пользователю был выдан токен, на основании которого он мог делать ставки с определенным коэффициентом выигрыша.
По умолчанию все УЗ в этом приложении создавались с привилегиями silver, что можно было понять расшифровав полученный токен:
token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJib29rbWFrZXIiLCJzdWIiOiJKdXlqdXkiLCJleHAiOjE3NTk5MTQzMzQsImlhdCI6MTc1OTkxMDczNCwibWVtYmVyc2hpcCI6InNpbHZlciJ9.0wK92bH61bPf1IQ6fUmKo3BryasUW2aPV4zzcwXJ7PY;
{
"iss": "bookmaker",
"sub": "Juyjuy",
"exp": 1759914334,
"iat": 1759910734,
"membership": "silver"
}В результате в дальнейших запросах атакующие изменили значение поля membership с silver на platinum, чтобы делать ставки с повышенным коэффициентом выигрыша. Делая ставки на разные пары бойцов, «красные» обнаружили ошибку в работе приложения: при выборе определенной пары и наличии статуса platinum ломалась логика расчета коэффициента. Итоговый коэффициент выигрыша становился отрицательным, в результате на баланс начислялась огромная сумма. Это видно по параметрам "membership": "platinum" и "balance": 18446744073709551117.
Реализация этого КС стала для нас очень интересной в плане расследования. Нам было необходимо разобраться не только в эксплуатации уязвимости, которую видно в предоставленных СЗИ, но и в логике работы приложения, на что ушло немало времени.
Теперь рассмотрим другие реализации КС.
Атакующие на одном из открытых портов узла landing.city.stf обнаружили главную страницу Apache HugeGraph-Server. Если посмотреть популярные уязвимости этого ПО, обнаружим уязвимость типа RCE, для которой есть публичный эксплойт. Воспользовавшись им, атакующий может выполнять команды непосредственно на сервере от лица УЗ hugegraphuser.
В СЗИ видим признаки эксплуатации данной уязвимости — запуск bin/bash от имени УЗ hugegraphuser и создание реверс-шелла к внешнему узлу (хосту атакующих).
Далее, попав на узел landing.city.stf, атакующие полностью его скомпрометировали и нашли конфигурацию VPN, благодаря которой смогли развить атаку во внутренней сети.
На хосте мы фиксировали много различных утилит, например LinPEAS для повышения привилегий, Chisel для организации проектирования трафика. Большую часть вредоносных действий удалось остановить через MaxPatrol EDR. Мы также направляли файлы на анализ в PT Sandbox.
Скомпрометировав узел landing, красная команда выложила все его креды в открытый доступ (о чем нам любезно сообщили организаторы).
После подключения ко внутренней сети по VPN атакующим стал доступен ресурс pharmacy.city.stf — онлайн-сервис по продаже лекарств. На нем было возможно реализовать сразу два КС:
Обход системы модерации в аптеке.
Сбой в работе онлайн-аптеки.
Для реализации первого КС атакующие провели брутфорс-атаку на веб-интерфейс личного кабинета. Ее выявил PT Network Attack Discovery (bruteforce_ad).
В результате мы видим успешный вход на портал под УЗ HelthCare (именно так, с использованием эрратива) с паролем Cardinal.
Далее, используя полученную УЗ HelthCare, атакующие смогли реализовать КС — создали рецепт с именем своей команды.
Для реализации второго КС атакующие воспользовались уязвимостью в веб-приложении pharmacy. В результате они смогли удаленно выполнять код непосредственно на сервере (RCE) внутри контейнера, где было запущено веб-приложение аптеки. Выяснять, что это была за CVE, мы не стали ввиду ограниченности времени, но в MaxPatrol SIEM видели успех ее эксплуатации — запуск usr/bin/ и чтение /etc/shadow внутри контейнера из-под УЗ сервиса ubuntu. Мы предположили, что в результате чтения /etc/shadow и был получен хеш пользователя root.
Далее атакующие организовали реверс-шелл к своей инфраструктуре.
При расшифровке переданной команды получаем следующее.
В результате брутфорса хеша пароля от УЗ root атакующие получили административные привилегии в контейнере.
Но для продолжения атаки было необходимо совершить побег из контейнера, что удалось сделать в результате смены корневой директории с помощью chroot.
chroot /proc/1/root/ /bin/bash
Данная команда меняет корень процесса с PID 1 (корневой системный init-процесс) на корень хост-системы и запускает там Bash. Это классический способ побега из уязвимого Docker-контейнера.
Далее дело техники — скачивание и запуск вредоносного файла (согласно легенде учений) на хосте, то есть реализация КС.
Как и всегда, участие в The Standoff оказалось захватывающим и очень полезным опытом. Кибербитва не только проверяет наши текущие навыки и знания в области информационной безопасности, но и позволяет выявлять и анализировать новые методы, применяемые Red Team. Красные команды постоянно совершенствуются, и с каждым разом их обнаружение становится всё более сложным, что делает противодействие более интересным и стимулирует наш профессиональный рост. Раз за разом мы решаем разнообразные увлекательные кейсы, что способствует развитию практических умений и укреплению командного взаимодействия. Такой опыт существенно повышает нашу готовность к реальным инцидентам и делает нас более уверенными в защите своей организации.