Недавно завершилась одиннадцатая кибербитва Standoff, проходившая в рамках Positive Hack Days 12 в московском Парке Горького. C 17 по 20 мая 22 команды белых хакеров атаковали государство F — виртуальный город с собственной железнодорожной инфраструктурой, атомной станцией, заводом по обогащению урана, солнечной электростанцией и другими объектами. В одном из его сегментов располагалась сеть IT-отдела авиакомпании, принадлежащей Heavy Logistics. По легенде у отдела разработки был выстроен процесс безопасной разработки: код проверялся с помощью PT Application Inspector.

Сразу обратим ваше внимание, что эта ситуация была смоделирована специально для кибербитвы Standoff для того, чтобы PT Application Inspector, задача которого искать уязвимости, мог еще и обнаруживать зловредный код. Поэтому «обошли» его только в рамках кибербитвы и заложенных в нее сценариев возможных атак.

Красным требовалось внедрить «закладку» в исходный код разрабатываемого приложения и сделать так, чтобы для SAST-анализатора она выглядела безопасной. В случае успеха они могли бы выполнить произвольный код на удаленном сервере компании.

Что рассмотрим в статье:

• особенности внедрения SAST-анализатора в кибербитву Standoff,

• попытки красных команд обойти анализатор,

• итоги и планы.

В этом году Positive Hack Days вышел на новый уровень, превратившись в большой городской киберфестиваль. Его ключевыми идеями стали повышение доверия к технологиям и развитие осознанности их использования через киберграмотность (подробнее читайте по ссылке). Традиционно на PHDays прошла кибербитва Standoff между командами offensive (красные) и defensive (защитники). За четыре дня атакующим в вымышленном Государстве F (но с настоящими системами управления и защиты) удалось реализовать недопустимые события 204 раза, а защитникам — расследовать 43 атаки. 

Как мы внедряли SAST-анализатор в кибербитву Standoff

Одним из главных преимуществ Standoff можно считать то, что в реальной жизни участники команд атаки и защиты — практикующие специалисты в ИБ, которые проводят аудиты безопасности топовых компаний. Поэтому мы тоже решили приблизить наше задание к реальной жизни и внедрить основные процессы безопасной разработки в вымышленный IT-отдел авиакомпании Heavy Logistics.

Серверы компании были расположены следующим образом:

Атакующим был доступен сайт авиакомпании, на котором была возможность зайти в панель управления под ролью manager или reporter. При успешном входе в панель управления атакующий получал доступ к файлу с закрытым RSA-ключом и ссылкой для клонирования репозитория. Репозиторий хранился на GitLab-сервере компании.

???? Любопытный факт

Ради интереса был выставлен самый популярный логин — admin и пароль admin для входа в дашборд. Под ролью reporter можно было войти, введя email из футерa сайта. В роли reporter вход был выполнен в два раза чаще.

После успешного клонирования репозитория задачей атакующего было внедрить в исходный код приложения бэкдор, который PT Application Inspector не сможет обнаружить, и с помощью него получить RCE в контейнере с собранной и развернутой новой версией приложения.

Само приложение представляло из себя REST API на языке Python. Для реализации API используется фреймворк Flask, который есть в базе знаний нашего анализатора.

Для репозитория был настроен CI/CD, который выглядит следующим образом:

1. После того как хакер выгрузил код в репозиторий, первым шагом выполнялось сканирование всего приложения. Главной задачей нашего анализатора кода являлся поиск уязвимостей типа OS Commanding, SQL Injection, Server-Side Request Forgery и др. Но в этот раз мы решили дополнить ядро правилами для поиска бэкдоров (программных закладок). Сканирование не было инкрементальным, то есть предыдущие неудачные попытки обойти анализатор (например, сделанные другими командами) необходимо было обнаружить и удалить самостоятельно. О попытках атакующих обойти этот алгоритм поиска расскажем далее.

2. Если сканирование прошло успешно, происходила сборка Docker-контейнера и отправка в приватный GitLab Container Registry. Как и во многих компаниях в реальном мире, одним из шагов сборки являлось выкачивание зависимостей из приватного PyPI-зеркала. В нем хранились только те пакеты, которые используются в приложении, поэтому у хакеров не получилось изменить requirements.txt таким образом, чтобы подменить какой-либо модуль на зловредный и провести атаку типа supply chain. Кроме того, мы уверены, что все используемые Python-пакеты покрыты базой знаний нашего SAST-анализатора.

3. Финальным шагом было развертывание приложения на сервере. Контейнер с бэкендом брался из GitLab Container Registry.

Попытки атакующих обойти анализатор

Поначалу команды красных пытались внедрить уязвимый код таким образом:

Данную уязвимость PT Application Inspector обнаружил, так как метод os.popen() является потенциально опасным: в него приходят данные из недоверенного источника (запроса) посредствам метода request.args.get().

Кроме того, были попытки подменить пакеты в файле requirements.txt, но, как ранее упоминалось, это не сработало, поскольку при выкачивании пакетов используется приватное PyPI-зеркало без выхода в интернет.

Далее была попытка использовать встроенный модуль Python subprocess для проброса реверс-шелла, но и это не получилось.

Рассмотрим еще один вариант внедрения реверс-шелла. На этот раз использовался модуль pty для доступа к bash. И здесь наш анализатор тоже находит уязвимость.

И даже если послать на вход op.popen() закодированную строку, пайплайн не проходит.

Как же обойти защиту SAST-анализатора

После множества попыток (на рисунках выше) ребятам из команды True0xA3 все же удалось обойти PT Application Inspector и получить реверс-шелл на контейнере с приложением. Они закодировали import модуля subprocess и вызвали метод check_output, поэтому он не определился в базе знаний PT Application Inspector, что и привело к реализации недопустимого события.

Итоги и планы

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

После мероприятия мы пообщались с командами атакующих и собрали фидбэк. В числе приятных моментов можно отметить то, что некоторые хакеры назвали это задание одним из самых интересных на одиннадцатой кибербитве. Кроме того, мы поняли, насколько важна каждая деталь в описании задания: один из пунктов описания сервиса в README.md был воспринят атакующими как возможность провести атаку типа supply chain. Впредь формулировки будут более точными, обещаем ????

Хотим поблагодарить команду организаторов Standoff — наших коллег — за оперативную техподдержку до битвы и во время нее, а наших соратников по департаменту — за своевременный деплой и помощь в конфигурировании PT Application Inspector.

Мы будем продолжать придумывать интересные таски и давать больше возможностей для красных команд показать свои навыки при обходе SAST-анализатора. Будем рады видеть вас на следующих ивентах. До встречи в самое ближайшее время на киберполигоне Standoff365!

Александр Халиков

Младший специалист группы исследований безопасности приложений, Positive Technologies

Дмитрий Рассадин

Старший специалист группы исследований безопасности приложений, Positive Technologies