Эта статья — логическое продолжение статьи Антона и Кости про управление маршрутами атак хакера). Здесь мы расскажем о построении графа моделирования угроз и методах расчета путей атакующего на нем. Одна из задач проактивного анализа и повышения защищенности инфраструктуры – это поиск потенциальных маршрутов кибератак. При этом, как показано в статье Даниила Неймана Методы моделирования атак на графах, для решения этой задачи наиболее эффективный подход - это использование графового представления инфраструктуры. В этой статье мы обсудим, какие проблемы при этом возникают и почему хорошо изученные алгоритмы поиска путей на графах плохо применимы к расчету путей атакующего. Посмотрим, какие способы решения задачи существуют, как мы их решаем при разработке MaxPatrol Carbon, поговорим об их проблемах и ограничениях, наметив пути решения некоторых из них. Итак, пристегнем ремни, поехали!
Граф TME
Технология моделирования угроз Threat Modeling Engine (TME) строит графоподобную структуру данных (граф TME) на основе информации об активах инфраструктуры, сетевой топологии, данных об уязвимостях и привилегиях пользователей. В результате граф TME описывает возможность перехода между компонентами системы.
Давайте посмотрим, а что же собой представляет граф TME. Всю инфраструктуру можно разложить на компоненты, которыми может владеть атакующий, например: операционная система, приложение, учетная запись и т. п. Компоненты между собой можно соединить действиями, выполняя которые атакующий может передвигаться от одного набора компонентов к другим, например: вход по RDP, эксплуатация уязвимости, выполнение LSASS Dump и т. п. При этом для выполнения действия атакующий должен обладать нужными привилегиями, которые определяются учетными записями в его руках. На рис. 2 приведен пример графа TME.
Итак, на графе мы видим четыре компонента: Host 1, Host 2, Host 3, Host 4. От Host 1 мы можем перейти к Host 2 через эксплуатацию уязвимости, что описывается действием RCE. Аналогично через эксплуатацию уязвимости мы можем перейти с Host 1 на Host 4, а с Host 4 на Host 3. С Host 1 можно перейти по RDP-протоколу на Host 3 при условии обладания привилегией Priv3. Внутри актива Host 2 мы имеем возможность выполнить действие LSSAS Dump и получить учетные записи 1C Admin и User. А находясь на Host 3, можем получить доступ к его внутреннему компоненту 1С. Очевидно, что реальные графы TME существенно больше, но для наших рассуждений и этого графа вполне достаточно. Пунктирными линиями показано использование учетных записей 1C Admin и User для выполнения действий, требующих привилегий. Внимательный читатель может задаться вопросом: а как в пунктирной линии из 1C Admin мы получили привилегию Priv 1C? Логика работы с учетными записями и их привилегиями вынесена с графа TME, хотя на этапе проектирования MaxPatrol Carbon рассматривался вариант с созданием гиперграфа, на котором использование учетных записей было бы явно нанесено на граф, как показано на рис. 3.
На нем мы явно указываем, какая учетная запись может быть использована для выполнения действия. Нетрудно представить себе, что в этом случае мы получаем комбинаторный взрыв, когда учетные записи перемножаются на действия, что показано на примере, если бы существовало несколько пользователей: User1… N. Поэтому логика работы с учетными записями и их разрешающими и запрещающими привилегиями вынесена с графа TME.
Итак, что такое граф TME, мы более-менее разобрались, теперь настал черед решения практической задачи на нем — поиска возможных маршрутов атакующих.
Расчет маршрутов
Начало
Сперва дадим определение маршруту
Маршрут — уникальная минимально необходимая упорядоченная комбинация шагов, выполнение которых позволяет перейти между компонентами.
Теперь мы подобрались к ключевой задаче проактивного анализа и повышения защищенности инфраструктуры — рассчитать в ней маршруты движения атакующего. Будем считать, что доступ к «1С» приводит к реализации недопустимого события для предприятия, а в качестве точки входа будем считать Host 1, который имеет прямой доступ во внешний мир. От Host 1 можно продвинуться в трех направлениях: через эксплуатацию уязвимости на Host 2 и Host 4 и по RDP на Host 3. Однако на данный момент атакующий не может выполнить действие RDP Login, так как у него нет привилегии Priv3. Предположим, он пошел через уязвимость RCE на Host 4, оттуда в очередной раз по RCE на Host 3, однако выполнить последнее действие для компрометации системы он не сможет — у него не будет привилегии Priv 1C. Для ее получения вначале атакующему будет необходимо попасть на Host 2 и выполнить там действие LSSAS Dump, которое принесет ему учетную запись 1C Admin, обладающую нужной привилегией, а также учетную запись User, обладающую привилегией Priv3. Итого на этом графе TME мы можем выделить два маршрута, показанные на рис. 4, где пунктиром отмечено применение учетной записи для реализации действия.
На первый взгляд все просто — граф, маршруты, мир умеет с ними работать. Но есть две проблемы:
Нахождение предикатов условий перехода (привилегий на ребрах) и компонентов учетных записей на графе TME, позволяющих получить эти условия, приводит к тому, что общепринятые алгоритмы обхода графа не работают. Скорее, это можно представить себе историей про комнаты и ключи, где, чтобы открыть красную дверь, вначале надо открыть желтую и получить там красный ключ.
Размеры графа ТМЕ — на реальных инфраструктурах это многие миллионы связей и, как следствие, огромное количество вариантов маршрутов реализации недопустимых событий от точек входа.
Очевидно, да и подтверждается практикой на реальных инфраструктурах, определить полное число маршрутов не представляется возможным. Но есть и хорошая новость: для того чтобы повысить безопасность, MaxPatrol Carbon, и не нужно знать полное множество маршрутов. Для решения своих задач ему достаточно уметь:
Находить репрезентативное множество маршрутов, позволяющих провести оценку компонентов системы с точки зрения защиты от атаки.
Определять кратчайший путь от точки входа до недопустимого события или в общем случае находить кратчайший путь между двумя компонентами с учетом привилегий.
При этом репрезентативное множество — это такое множество, которое позволит оценить с заданной точностью вероятность прохождения маршрутов атакующего через узлы. И тут можно воспользоваться известной метрикой на графах, как степень посредничества (betweenness centrality, BC). То есть будем называть репрезентативным такое множество маршрутов, которое позволяет с некоторой точностью получить метрику BC.
Стохастический поиск множества маршрутов
Как уже говорили ранее, найти полное множество маршрутов, даже ограниченное небольшим числом шагов, на практике невозможно. Выходом из ситуации могут быть либо эвристики, позволяющие не рассматривать часть маршрутов, либо применение стохастического подхода, в основе которого лежат методы Монте-Карло. Они прочно заняли свою нишу во многих направлениях, в частности в атомной физике, задачах переноса излучения и многих других. То есть там, где процесс по своей природе имеет случайный характер. Поведение атакующего также можно представить в виде случайного процесса блуждания по графу ТМЕ, где атакующий, обладая некоторым набором компонентов, принимает решение о том, какое действие выполнить дальше.
То есть, возвращаясь к графу TME, изображенному на рис. 1, имея в качестве точки входа Host 1, у атакующего есть два варианта, куда двигаться дальше: Host 2 или Host 4 через эксплуатацию уязвимостей RCE. Напомним, что действие RDP Login до Host 3 ему на начальном этапе недоступно, так как у него нет привилегии Priv3. Давайте случайно выберем одно из этих действий. К вопросу, с какой вероятностью их выбирать, мы еще вернемся, пока пусть все будет равновероятно. Пусть он выберет RCE до Host 2. Итак, теперь атакующий обладает двумя компонентами Host 1 и Host 2 и среди доступных ему в данный момент действий есть опять два: RCE до Host 4 и LSSAS Dump на Host 2. На новом шаге опять же выбираем случайным образом, пусть это будет LSSAS Dump, то есть на втором шаге атакующий получает учетные записи User и 1C Admin, что приводит для него к разблокировке действия RDP Login с Host 1 до Host 3, так как ранее мы обсуждали, что User обладает привилегией Priv3. Думаю, дальнейшие рассуждения вполне понятны: двигаясь итерационно, мы либо достигнем компонента, реализующего недопустимое для бизнеса событие, либо за некоторое количество шагов его не достигнем и итерация может быть признана неудачной.
Иными словами, мы фактические строим цепь Маркова – последовательность случайных событий, где вероятность следующего события зависит только от текущего состояния. Запустив таким образом алгоритм многократно, мы сможем получать маршруты. У подхода есть и очевидные проблемы:
В отличие от моделирования переноса излучения или частиц, где каждая итерация будет приносить вклад в решение, уменьшая дисперсию, здесь мы можем находить один и тот же маршрут многократно, отбрасывая его, и чем дольше работает алгоритм, тем ниже будет его эффективность.
В теории вероятности, если вероятность события А равна p(A), а события B равна p(B), то вероятность их комбинации AB будет равна произведению p(A) × p(B). Отсюда возникает много проблем с анализом на основе стохастического алгоритма. Если, к примеру, в некоторую область графа ведет ограниченное число связей со сложным условием предиката ребра (привилегии, которые сложно найти), то очевидно, что вероятность попадания в эту область будет низкой и маршруты в ней окажутся плохо исследованными.
Что с этим делать? Предпосылку для решения мы уже обозначили в начале описания стохастического алгоритма, когда договорились выбирать следующий шаг равновероятно. Что означает равновероятность? Мы считаем, что атакующий при принятии решения, какое действие выполнять, будет условно подкидывать монетку. Очевидно, что это не так. В методах Монте-Карло хорошо известно, что наибольшую сходимость обеспечивает выборка по значимости (importance sampling), максимально близко описывающая реальное распределение. Если вспомнить первые курсы инженерных специальностей вузов, то это будет классический пример вычисления определенного интеграла, когда искомую функцию заменяют максимально близкой. И тут появляются два варианта:
Строить модель атакующего, описывающую его поведение, в графе TME.
Строить выборку по значимости на основе анализа графа.
Модель атакующего — тема отдельной большой статьи. А вот историю с выборкой по значимости на основе анализа графа рассмотрим чуть подробнее. Итак, при равновероятной выборке вполне очевидно, что мы будем все время обходить в том числе и те области графа ТМЕ, через которые не проходят маршруты. Это будет ухудшать сходимость. А что, если после каждой успешной итерации для действий, которые оказались на маршруте, увеличивать некоторый счетчик и на очередной итерации при выборе действия, куда будет двигаться наш атакующий, выбирать действия с вероятностью, пропорциональной весам? Тогда мы начнем обходить преимущественно те области, в которых по большей части и пролегают маршруты. Реальный алгоритм несколько сложнее, но в целом в основе лежит идея муравьиного алгоритма, суть которого сводится к моделированию поведения колонии в поисках пищи, когда наиболее удачные пути маркируются большим количеством феромона. При этом при реализации алгоритма важно не нарушить репрезентативность множества.
Минимальный маршрут и множества на его основе
Задача поиска кратчайшего маршрута на графе хорошо известна и давно успешно решена с помощью таких алгоритмов, как алгоритм Дейкстры, поиск А* и т. п. Но, как мы уже обсуждали, мы имеем дело не с графом, а с графом ТМЕ, и для него графовые алгоритмы неприменимы. При этом задача поиска кратчайшего пути имеет важное значение во многих контекстах работы с MaxPatrol Carbon.
Поиск минимального маршрута осуществляется обходом графа в ширину. На старте алгоритма — компоненты и учетные записи, которые считаются захваченными. Идея алгоритма:
От каждого захваченного компонента выполняется проверка, какие действия с него можно выполнить с имеющимся набором учетных записей.
Найденные действия позволяют атакующему переместиться на следующие компоненты или захватить учетные записи, как обсуждалось ранее.
От них, в свою очередь, снова определяются доступные действия.
Алгоритм выполняется, пока не будут достигнуты конечные точки.
Если какое-либо из действий можно выполнить с несколькими учетными записями и все они есть у атакующего, то в маршрут записывается та, путь до которой состоит из меньшего числа шагов. Если в ходе алгоритма действие приводит к уже захваченному ранее компоненту или учетной записи, то маршрут до нее перезаписывается только в случае, если новый путь состоит из меньшего числа шагов. Вроде бы несложный на первый взгляд алгоритм, но не такой простой в реализации, так как содержит очень много граничных случаев.
Что интересно, умение рассчитывать минимальный маршрут позволяет рассчитывать и множество путей хакера к атаке. Как? А что, если на графе ТМЕ убрать одно из действий минимального маршрута и запустить расчет по новой? Мы получим следующий минимальный маршрут. А дальше убрать другое действие и так далее. Выполняя эти действия, важно опять же не нарушить репрезентативность маршрутов.
Подобие маршрутов
Итак, мы научились считать репрезентативное множество маршрутов на основе методов Монте-Карло и расчета множеств минимальных путей, но давайте теперь посмотрим на это критически. На рис. 5 приведен пример реального маршрута с захватом нескольких учетных записей на реальной тестовой инфраструктуре.
В реальной инфраструктуре подобных маршрутов много и измеряется даже не миллионами. При этом будет множество путей, которые будут отличаться незначительно. С точки зрения анализа направления шагов хакера нам не всегда важно знать, на основе какой именно уязвимости построено действие, или нам непринципиально, по какому именно протоколу выполнено действие, или нам неважно, на основе какой версии приложения построен компонент. То есть мы можем начать группировать маршруты на основе некоторых признаков подобия, что позволит при решении некоторых задач анализа снизить размерность. Но тогда возникает резонное замечание: а для чего тогда мы их ищем раздельно, чтобы потом еще тратить ресурсы на их объединение?
Как правило, два компонента соединяет не одно действие, а их набор. Например, это могут быть действия, основанные на разных уязвимостях на разных портах. С точки зрения графа ТМЕ это разные ребра, но результат действия один и тот же. Такие ребра можно свернуть на этапе поиска маршрута в суперребро и записывать супермаршруты, разворачивая из них уже сами маршруты при необходимости. Тем самым мы будем на этапе поиска находить сразу множество подобных маршрутов и работать с ними.
Декомпозиция маршрута
Подход с суперребрами по сути является оптимизацией, и он позволяет значительно ускорить процесс расчета маршрутов. Но, как и у всех инженерных оптимизаций, у него есть пределы. На сверхбольших инфраструктурах вариативность даже в нотации суперребер может быть колоссальной. Следующим этапом оптимизации тут уже может быть изменение подхода к самому понятию маршрута.
Итак, маршрут можно разложить на отдельные ветки, что хорошо иллюстрируется на рис. 5: ветки, захватывающие учетные записи, и основная ветка до компонента, реализующего недопустимое событие. А что, если нам начать искать маршруты до компонентов, реализующих недопустимое событие, без учета предикатов действий, тем самым начав работать с обычным направленным графом. То есть мы уходим в область хорошо известных обычных графовых алгоритмов. Хорошо, но что делать с предикатами? Как мы помним, предикаты содержат в себе привилегии, которыми нужно обладать, чтобы выполнить действие. А привилегиями обладают учетные записи, которые могут быть захвачены на графе ТМЕ, что мы и видим на рис. 5. Тогда давайте будем рассчитывать маршруты не только до компонентов недопустимых событий, но и до всех учетных записей так же без учета предикатов. И назовем это квазимаршрутами. Тогда для каждого квазимаршрута мы можем записать список привилегий, от которых он зависит, и список привилегий, которые он приносит. А дальше мы сможем из таких квазимаршрутов конструировать уже настоящие маршруты.
Что дальше
Итак, мы рассмотрели вопросы построения графа ТМЕ и некоторые из реализованных и перспективных методов расчета маршрутов на нем, но на самом деле все самое интересное еще только начинается, и в следующих сериях мы точно рассмотрим такие темы, как время атаки (time to attack, TTA) и вероятностные модели. Возможно, обсудим вопросы разведки в атаках, граф привилегий, скоринговые модели, модель атакующего и еще много-много всего познавательного и увлекательного из мира управления маршрутами атак (Attack Path Management) и как мы их решаем в нашем метапродукте. До новых встреч!
Виктор Желтов
Руководитель отдела разработки MaxPatrol Carbon