Всем привет! Ранее мы делились итогами работы песочницы PT Sandbox на The Standoff. Продолжаем традицию — теперь черед PT Application Firewall. Посвящаем этот материал истории о том, как на кибербитве отработал наш межсетевой экран уровня приложений. Мы расскажем, как глобальный SOC The Standoff, состоящий из специалистов нашего PT Expert Security Center, готовил PT Application Firewall к игре, какие хитрости мы использовали при написании правил, с чего мы начинали на The Standoff и что нового почерпнули. Некоторые результаты работы продукта на кибербитве стали для нас бесценными, и мы точно используем их в будущем.

В этот раз киберполигон включал шесть компаний, у каждой из которых была корпоративная сеть, в точности имитирующая реальную — с внешними сервисами, DMZ и сегментацией. Чтобы пробраться внутрь сети, атакующим предстояло пройти периметр. Для этого можно было найти уязвимость во внешнем сервисе, проэксплуатировать ее и закрепиться или использовать фишинговую рассылку с вредоносным вложением, которое открыло бы атакующим доступ из внешнего мира напрямую в пользовательскую сеть компании. Но основным вектором проникновения стали атаки на веб-ресурсы — примерно 90%.

На периметре каждого из шести офисов было заложено от 5 до 8 веб-уязвимостей разного уровня сложности. Простые уязвимости атакующие легко находили и могли сдавать их в программу Bug Bounty, за что получали очки. При этом серверы не имели внутреннего интерфейса и не давали пройти дальше. Чтобы пробраться внутрь, командам атакующих надо было найти и проэксплуатировать уязвимость удаленного исполнения кода средней или высокой сложности.

Все веб-ресурсы были под защитой PT Application Firewall, но тот работал в режиме мониторинга и не блокировал запросы, а только логировал их. Это позволяло синим командам видеть все действия атакующих, но не препятствовало проведению атак.

Атаки на веб в цифрах

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

Далее на графике можно увидеть распределение атак по времени и критичности:

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

Теперь разберем время прохождения периметра. Первый отчет о выявлении уязвимости глобальный SOC получил на 23-й минуте игры. Это была Path Traversal, которая позволяла читать произвольные файлы на сервере. Атакующие первым делом вытащили /etc/passwd.

Первый отчет о найденной RCE-уязвимости мы получили от команды TSARKA на 40-й минуте игры. Хотя наши аналитики SOC увидели эксплуатацию намного раньше: примерно через минуту после первой успешной команды, выполненной в 10:22.

Что позволило нашим аналитикам так быстро обнаружить атаку?

Как найти успешные атаки

Первый день кибербитвы. В 10:00 атакующие получили доступ к инфраструктуре, в 10:03 запустили сканеры. В 10:08 PT Application Firewall зафиксировал 4359 атак высокого уровня и 12 269 — среднего:

Атакующие вооружились сканерами и стали добавлять кавычки и другой вредоносный контент во все поля, которые находили. За пять минут мы увидели, что PT Application Firewall выдал большее количество сработок, чем то, на которое аналитик в состоянии отреагировать. И среди них не было ложноположительных. Действительно, каждый запрос подходил под паттерн, например SQL-инъекции или File Inclusion.

Домашние заготовки

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

Изначально мы не знали, какие уязвимости будут заложены в веб-сервисы офисов. Единственное, что мы могли, — это изучить сами приложения и их функциональные возможности. Все, как в реальной жизни. А дальше мы следили за атакующими и теми уязвимостями, которые они находили. Чтобы эффективнее фильтровать сработки, еще до старта мы написали очень простое правило, которое впоследствии сильно нам помогло. Как атакующие понимают, что могут исполнять код? Правильно: читают /etc/passwd, выполняют whoami или id, ping и другие простые команды. А потом смотрят ответ сервера и ищут паттерны вывода этих команд. Нам тоже нужно было увидеть вывод команд в ответах сервера. Для этого мы написали следующее правило:

Если в запросе есть id, а в ответе что-то подходящее под паттерн uid=\d+\(.*\) — о да, атакующие получили RCE.

Если в запросе есть whoami, а в ответе www-data, tomcat или apache, то это, скорее всего, преуспели атакующие. Сюда можно включить bitrix и другие распространенные учетные записи, от имени которых работают веб-сервисы. Но мы ориентировались на то, что действительно было в инфраструктуре, чтобы минимизировать количество ложных срабатываний.

Проблемы были с выводом команды ls. Сложно найти паттерн, если заранее не знаешь, в какой папке атакующие получат возможность исполнить код и какие файлы там лежат. Поэтому мы пошли на компромисс: мы искали паттерн вывода не ls, а ls -la: (dwrx|-rw) — действительно мало страниц содержат информацию о разрешениях файлов. Если на вашем сайте такие есть, то PT Application Firewall позволяет добавить исключение по URL или пути запроса.

Что получилось

Спустя 23 минуты мы поймали первый вывод phpinfo(). Этого было достаточно, чтобы создать правило для конкретной уязвимости. Мы знали, что POST-запрос по пути /cockpit/auth/check позволяет исполнить код, который специальным образом передается в теле запроса. Это уязвимость в CMS Cockpit версии 0.6.1. Вышло вот так:

Нам даже показалось, что мы нашли успешное исполнение команды раньше, чем это сделали атакующие. Они запустили сканер и оставили его на несколько минут. К моменту, когда они увидели результаты и стали раскручивать полученную уязвимость, наше правило было уже готово и вовсю отлавливало хакеров. Вот такое мы ловили правилом [BB] Cockpit CMS RCE:

На самом деле этот запрос поймали и стандартные правила, которые есть у каждого, кто использует PT Application Firewall. Они ищут паттерны веб-атак в запросах, не определяя их успешность, что позволяет остановить атакующих еще до того, как те смогут исполнить свои злые намерения. Несомненно, в реальной жизни такие запросы нужно сразу блокировать! Но на киберполигоне у нас была другая задача, так как PT Application Firewall работал в режиме мониторинга: среди тысяч запросов от сканеров нам нужно было выделить удачные попытки эксплуатации.

Всего в ходе игры мы оперативно написали более 30 правил для уязвимостей различного типа. Вот некоторые из них:

AlienSec — это сайт, предназначенный для отображения содержимого файлов на сервере. Изначально атакующим предстояло найти уязвимость Local File Inclusion, прочитать через нее исходный код приложения и понять, что уязвимым к RCE параметром является filename по пути /2591c98b70119fe624898b1e424b5e91.php. Сложность эксплуатации этой ошибки имеет средний уровень сложности. В итоге ее сумели найти и успешно проэксплуатировать три команды.

Ubuntu YAML — очень простая для эксплуатации уязвимость: нужно передать код в параметре на ext.php. Легко обнаруживается сканерами.

phpCollab — система управления проектами. Версия 2.7.2 и ниже позволяют неавторизованным пользователям загрузить произвольные файлы на сервер и исполнить код от имени www-data. Подробнее об уязвимости и ее эксплуатации можно почитать по ссылке. Ошибка имела низкий уровень сложности, но тем не менее только шесть команд смогли ее обнаружить.

FileHosting стал одним из самых популярных сервисов у атакующих — 26 команд смогли провести успешные атаки. Скорее всего, это связано с количеством и разнообразием заложенных уязвимостей (SQLi, RCE, XSS, Path Traversal) и их простотой. Сервис представляет собой хранилище файлов, позволяет загружать и просматривать документы. Написан на Python Flask.

Но, наверное, самое интересное, что мы смогли поймать, — это RCE в base64-encoded cookie. Отчасти это было даже случайно. Когда мы готовили наше большое правило для обнаружения успешных RCE, мы поспорили: а действительно ли стоит искать паттерн в запросе и в ответе? С одной стороны, это позволит минимизировать число ложноположительных срабатываний, с другой, у нас будут все шансы пропустить то, что мы не предусмотрели заранее. В итоге мы пришли к выводу, что такое правило лишним не будет. Оно получилось похожим на первое, только не проверяло запрос, а лишь искало специфичный вывод в ответе. Написали и забыли. Но в какой-то момент в ходе игры мы поймали сработку, где в запросе не было ничего, а вот в ответе…

Если вы внимательно посмотрите, значение Cookie user_id было следующим: dW5hdXRob3Jpc2VkOyBpZDs, что при декодировании превратилось в unauthorised; id;. И у нас появилось правило [BB] Tomcat cookie RCE — оно декодирует параметр user_id заголовка Cookie и ищет в нем признаки выполнения команд операционной системы.

Новый уровень понимания действий атакующих

А дальше нам стало интересно отслеживать не отдельные сработки, а цепочки исполнения команд атакующими. Поэтому мы стали коррелировать события.

В правиле корреляции мы объединяли сработки успешных RCE в атаки по CLIENT_IP и REQUEST_PATH. То есть мы стали собирать все запросы от одной команды по одному пути вместе. И в этот момент нам стало понятнее, что делают атакующие, так как мы смогли наглядно разделить цепочки действий по командам и часто даже между членами одной команды — когда ребята параллельно пытались раскрутить сразу несколько найденных уязвимостей.

Это было первое, но далеко не единственное, что нам удалось получить от корреляций. Их суть в том, чтобы обнаруживать такие атаки, где каждое действие по отдельности кажется нормальным, но последовательность запросов может быть опасной. Самое простое и очевидное — перебор пользователей на GitLab через API. API для того и создан, чтобы можно было быстро автоматизированными средствами получить информацию. Но, согласитесь, подозрительно, что кто-то забирает информацию обо всех пользователях:

Благодаря корреляциям, мы обнаружили, что система CMS Cockpit была уязвима не только к RCE, но и к User Enumeration (перебору пользователей) через восстановление пароля. Если в POST-запросе на страницу /cockpit/auth/requestreset отправлялось имя существующего пользователя, то страница возвращала ответ Recovery email sent, иначе — User not found. Что интересно, в JSON можно было отправить не только полное имя пользователя, но и регулярное выражение. И если хотя бы одно имя пользователя под него подходило, то такому пользователю отправлялось электронное письмо с инструкциями по восстановлению пароля. Уязвимость не самая опасная, да и атакующие, скорее всего, первым делом попробовали имя Admin. Но тем не менее знать о такой «особенности» работы своего приложения всегда полезно. Еще полезнее — иметь правило, позволяющее обнаружить и заблокировать подозрительную активность.

А что с рисками

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

В офисе Heavy Ship Logistics, компании, которая занимается перевозками, был определен риск «Сбой системы регистрации пассажиров». А задание было следующим: продемонстрировать возможность зарегистрировать на рейс пять пассажиров. Звучит как корреляция!

В данном случае мы ждали более пяти событий за не очень большой промежуток времени с одного IP-адреса и в рамках одной сессии. Чтобы это отследить, нам пришлось добавить в правило значения заголовка Cookie: они могли быть любыми, но сессионные cookie должны были попасть в MATCHED.VARIABLE_NAME, чтобы бы мы могли скоррелировать запросы.

Другой интересный риск, реализацию которого нам удалось обнаружить с помощью PT Application Firewall, — удаление информации о штрафах граждан. Суть задания была в изменении записи в базе данных городского портала. А именно: надо было изменить размер штрафа пользователя Todd Smith. И атакующие могли действовать любым удобным способом — никто заранее не знал, каким путем можно пойти.

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

Интересно, но не по заданию. Организаторам пришлось восстанавливать всю базу данных. Хотя команда глобального SOC была очень благодарна. Теперь мы знали, что нужный штраф имеет идентификатор 9, а номер документа — 6534 976653. Нам осталось только выяснить, как атакующие получили необходимые права на портале. Для этого мы провели небольшой ретроспективный анализ по IP-адресу. Поле авторизации на портале оказалось уязвимым к SQL-инъекции:

На самом деле анализ был большой и трудоемкий. Запросов было много, и почти все возвращали ответ 302 (redirect), то есть мы не могли сказать точно, была ли авторизация удачной, так как в любом случае перенаправление осуществлялось на главную страницу. Нам пришлось повторить вручную множество запросов атакующих, прежде чем мы смогли авторизоваться на портале под пользователем BIGBOSS. В результате мы написали правило: если при запросе на страницу /index.php?page_controller=create_fine пользователь видит номер документа 6534 976653 и кнопку «Delete» fine, то, скорее всего, команда атакующих получила доступ на портал с правами, достаточными для удаления штрафа. И конечно, мы не забыли правило для уязвимого к SQL-инъекции поля. Некоторое время спустя мы поймали авторизацию другой команды — также через SQL-инъекцию. А еще чуть позже третья команда реализовала риск, на этот раз точно в соответствии с заданием:

Информация к размышлению

The Standoff — это четыре дня напряженной работы, за которые мы приобрели тонну опыта. Прежде всего кибербитва — это шанс отработать навыки оперативного реагирования: выявлять реальные веб-уязвимости и мгновенно писать правила, позволяющие их закрыть. За четыре дня мы написали более 30 правил, которые помогали выявлять атакующих на первых шагах входа в инфраструктуру и уже прицельно следить за дальнейшим развитием векторов реализации рисков.

Конечно, в реальной жизни при обнаружении подобных уязвимостей самое верное — это устранять их на уровне кода приложения. Но это небыстрый процесс, поэтому оперативное написание правила, блокирующего вредоносные запросы, является важной задачей команды защиты. В повседневной жизни специалисты PT Expert Security Center каждый день анализируют тысячи запросов к веб-ресурсам наших клиентов, чтобы обнаруживать новые векторы атак на всевозможные системы и противодействовать им.

Главным показателем нашей работы как глобального SOC стало то, что мы полностью понимали ход игры, знали, где есть уязвимости, где команды находятся в конкретный момент, и в большинстве случаев видели реализацию рисков задолго до получения отчета от атакующих. Киберполигон The Standoff — отличный шанс найти пробелы в собственных знаниях и стать лучше, расти и совершенствовать подходы к мониторингу.

Автор: Юлия Фомина, специалист отдела мониторинга информационной безопасности PT Expert Security Center