Разработка программы для построение графов атак - Форум по вопросам информационной безопасности

Добрый день, я учусь в аспирантуре и занимаюсь разработкой программы, которая стоит графы атак. В данный момент тема построения и анализа графов атак представляет больше теоретический интерес, но если получится что-то подходящее для практического использования, то было бы не плохо. Основным отличием моего подхода от предыдущих явлется использование sat-подхода, т.е. решения задачи булевой выполнимости. В данный момент есть работающая программа, основанная на модели Мелиссы Данфорт https://dl.acm.org/citation.cfm?id=1237287, строящая граф атак для сети, в которой присутствуют 4 элементарные атаки на рабочие станции и 2 элементарные атаки на "файерволлы". В данной работе определен ещё ряд элементарных атак, но не приведено сведений на основе чего эти атаки были составлены так, как они составлены.
Сейчас рабираюсь с генератором графов MulVAL http://people.cs.ksu.edu/~xou/mulval/, который каким-то образом на основе информации, собранной с помощью сканера уязвимостей, определяет характеристики элементарной атаки, опять же в подробностях данный момент мне найти не удалось. Так же, насколько я могу судить, в этой системе нет возможности провести атаку на "файерволл" и не рассматриваются доверительные отношения между(trust relationship) участниками сети.
Лично я результатом своей работы вижу программу, которая будет получать на вход список уязвимостей и их характеристик(взятых, например, из CVSS), информацию о файерволлах и т.д., в общем всю информацию о сети, которая необходима для построения графа атак. Проблема заключается в том, что в данный момент работа уперлась в некоторый потолок и некому задать вопросы, например, вопрос о том, можно ли каким-то образом автоматически(или с минимальным участием человека) сгенерировать пред и постусловия для элементарной атаки, основываясь на CVSS векторе уязвимости, и какие вообще дальейшие шаги можно предпринять в моей работе, если пытаться приблизить её к реальной жизни.
Прошу у вас помощи. Если есть какие-то вопросы о подробностях уже проделанной работы, то спрашивайте, постараюсь максимально подробно ответить.

Поковыряйте Snort, получение уязвимостей (точнее правил для обнаружения) из разных feed уже есть, попытаться прикрутить сканер устройств в сети (не только сетевых устройств, а всех) обнаружение атак очень гибко настраивается, работает отлично ( и как IDS так и IPS), останется прикинуть вывод в граф и графику. https://www.snort.org

to Дмитрий
*в сторону* используйте bdu.fstec.ru вместо CVSS - даешь полное импортозамещение!

Диссертация вообще не должна быть приближена к реальной жизни. Во всяком случае, далеко не обязательно. Главное - наукообразие (мне за 4 года вдалбливали это на каждом шагу, ага)...
Если серьезно, то вам понадобятся:
- знание (первичный выбор оператором) конечной цели атаки (можно разделить на классические К, Ц, Д и justForFun, ага);
- потоковый сканер уязвимостей;
- полная и непротиворечивая информация о реализованной системе защиты: acl на firewall, правила IPS, схемы DLP, схемы honeypot, схемы иной защиты от НСД (например, замкнутость программной среды на тех или иных узлах сети, правила ИАФ, правила РСБ, правила УПД и т.п.);
- полная и непротиворечивая информация об используемом ОПО (начиная с прошивок всех сетевых устройств и BIOS ПЭВМ, заканчивая всеми установленными обновлениями ОС), ППО (начиная с версий и обновлений прикладного софта, заканчивая наличием установленного портативного софта).
И даже если вы решите проблемы, связанные с постоянным обновлением сканера, его API, его ошибками 1 и 2 рода, "глубиной" реализованной системы защиты, отсутствием/наличием уязвимостей в самих средствах защиты, полнотой актуализации ОПО и ППО (особенно portable), то... все равно останется вероятность, отличная от 0, что ваша программа будет либо строить графы абсолютно "нереальных" атак, либо не будет учитывать реально возможные атаки по причине недостаточности входных данных...
Но это только для пром-решения. Потому что графы атак, моделируемые в пром-решении, должны на крайне высокий процент совпадать с реально возможными атаками. Иначе такое решение не имеет смысла...
А в качестве диссертационного исследования можно и банально на знаниях того же CWE и обновлений конечного софта (прошивок) строить атаки. Повторюсь, главное - наукообразный и непротиворечивый принцип. До идеала можно доводить уже после защиты, если будет желание, ага...

Если брать тот же MulVAL, то он использует OVAL либо Nessus, чтобы собрать информацию о программах и уязвимостях, потом берет информацию из CVSS об этих уязвимостях и использует для определения пред и постусловий, про первые два импакт фактора автор говорит, что по ним тяжело сказать, какая именно информация утекла или была изменена, а вот доступность он использует, плюс каким-то непонятным для меня способом определяет повышение привилегий.

Разработка своего сканера и не стоит в списке целей. В идеале использовать что-то уже готовое. Тот же Nessus, например.

Момент в том, что в работе Данфорт используются три типа прав доступа - None, User и Root, но без подробностей. Например, одна из атак позволяет залогиниться на удаленную машину с права доступа User, а потом повысить эти права до Root. Плюс есть атаки, которые деактивируют фаерволл и т.д. В MulVAL'e этого нет(а нужно ли).

Как я понимаю в определить пред и постусловия в контексте модели Данфорт только по CVSS возможным не представляется, нужны какие-то дополнительные действия от пользователя.

Как таковой цели разработать промышленный продукт нет, интересуют разного рода комбинаторные задачи. Например заблокировать небольшое число уязвимостей(ну патчами там например, или фаерволл перенастроить), чтобы злоумышленник не добрался до своей цели, в рамках заданных ограничений, или найти кратчайшую атаку. SAT подход позволяет эффективно решать подобные задачи с большим, если не сказать огромным, количеством переменных.

Базировать работу только на диссертации Данфорт, это как-то не комильфо, да и хочется чего-то своего.

P.S. А на этом форуме какая-то система регистрации есть?

Что-то похожее (на мой непросвещенный взгляд) делает израильская компания Skybox Security (https://www.skyboxsecurity.com/). У них, правда, используется термин "вектор атак".

to Дмитрий
Собственный сканер вам и не нужен - хватает уже "ходовых". Проще всего к NMAP прикрутиться, особенно если ваше ПО под Linux (рекомендую, кстати)...
Вам в первую голову нужно, чтобы оператор ввел все данные по своей сети. Фактические, а не выявленные сканером. Сканер покажет только наличие торчащих наружу портов и сервисов, в которых попробует найти уязвимости. Но сеть сети рознь, у кого-то и honeypot может быть прикручен, у кого-то fake-вывод сканера будет (по разным причинам). Тогда можно ожидать на выходе графы реально возможных атак, а не атак по методу blackbox. И уже на основании их вывода проводить оценку эффективности реализованной системы защиты (хотя бы периметра, ага)...

Когда я писал про сканер, я имел в виду не сетевой сканер. OVAL - это сканер по на машине, он сканирует установленные версии по на то, есть ли для них в базе сканере информация об уязвимостях, если есть, то он пишет что это за уязвимость и её индекс CVE, по которому уже потом можно выгрузить информацию о CVSS. Немного про OVAL https://habrahabr.ru/post/136046/

Мне кажется есть некоторое не соответствие в терминологии. Под графом атак я поразумеваю граф, который показывает все возможные способы злоумышленника добраться до целевого объекта, но не только через сеть, но и через уязвимости в ПО. Например перегрузить ssh буфер и выполнить какой-то вредоносный код. Классический пример из работы Шейнера таков: всего четыре уязвимости в сети на "хостах" - перегрузка ssh буффера, ftp .rghosts, remote login, local buffer overflow. Эксплуатация первой позволяет атакующему сразу получить рут права на атакуемой машине, через вторую можно установить доверительные отношения между атакующим и атакуемым, третья позволяет залогиниться с правами юзера на атакуемую машину, и последняя повышает права доступа пользователя до рут прав. Плюс в сети есть файерволл и IDS, но это сейчас не принципиально. Если считать, что в сети просто два компьютера - атакующий и атакуемый, на котором установлены уязвимые версии ПО, то для такой сети граф атак будет состоять из двух веток - первая использование только атаки на перегрузку ssh буффера, вторая состоит из последовательной эксплуатации уязвимостей 2, 3, 4.

to Дмитрий
Это недостаток форумного общения - что-то долго писать не очень приятно. Собственно, я вас понял верно. Вопрос в другом. Если вы хотите простейшую реализацию, то используйте запросы OVAL и того же NMAP. Получите картину уязвимостей на фактических хостах и картину доступных извне сервисов (в которых эти уязвимости могут быть, ага). Дальше по информации из CWE (BDU?) моделируете атаку. Только есть косяк - это даст не более двух-трех стадий атаки. А для полноценной атаки вам придется писать коррелятивную функцию связи уязвимостей "как плацдарм" для продолжения атаки. И тут встает новый вопрос (о котором уже говорил): какова конечная цель атаки? Все-таки считаю, что такое разделение следует сделать. Потому как в зависимости от конечной цели будут различаться и графы. А если их совместить (без разделения целей), то итоговое дерево будет крайне "ветвистым", ага...
По-началу с атаками на firewall (кстати, тут мы одно и то же понимаем?) и прочие СЗИ рекомендую не заморачиваться. Надо написать движок, который отталкивается от известных (обнаруженных) уязвимостей, накладывает на них маску доступных сервисов (извне или изнутри системы - внешний и внутренний нарушители, ага) и еще одну маску реализованных защитных мер. И делает вывод, указывая стадии выполнения атаки (и их относительный процент реализации, например), в виде графа...

В самом простом случае можно запустить просчёт всех возможных атак и уже смотреть куда это может привести.

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

Проблема в том, что я не понимаю как отталкиваться от обнаруженных уязвимостей. Как правильно по информации из CWE составить пару предусловия-постусловия. Больше проблемы именно с постусловиями, т.е. как определить какие права доступа может получить злоумышленник в результате атаки, пусть даже в общем случае(none, user, root). На том же хабре есть буквально абзац про последовательные атаки в CVSS, но он мне не до конца понятен.

Уязвимость 1: AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Уязвимость 2: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Это просто какие-то абстрактные уязвимости, по крайней мере в тексте нет ссылок на их реальные прототипы. Порядок эксплуатации У2->У1, т.к. после эксплуатации второй уязвимости мы вроде как можем получить локальный доступ к атакуемой машине и проэксплуатировать первую уязвимость. Но вот допустим, если бы в первой уязвимости стояли необходимые права доступа(PR) на уровне L или даже H, то возможна ли была бы её эксплуатация, после второй? Как определить, какие права доступа получает злоумышленник на атакуемом хосте, ориентируясь только на CVSS вектор?

Дмитрий,
мои поздравления, вы очень точно сформулировали идею, над которой у нас сейчас работает большая команда :) Но на самом деле задача значительно сложнее, чем просто связка уязвимостей по описанию в CVE и CVSS Base Score. В вашей идее не хватает нескольких фрагментов информации:

1. Знания топологии сети. Если вы нашли уязвимости на узлах А (192.168.0.1) и B(192.168.0.11), это еще не значит, что в графе атак возможна дуга AB: узлы могут находиться в разных подсетях, маршрутизация между которыми может отсутствовать.

И наоборот: если вы знаете, что эти узлы находятся в изолированных друг от друга подсетях, это еще не значит. что в графе атак невозможен путь из A в B. Например, уязвимый узел C(192.168.0.2) может иметь второй интерфейс (192.168.1.12), который торчит в той же подсети, что и B, и тогда в результате промежуточной атаки узла С нарушитель может превратить его в мост между этими подсетями. Вот только сканирование уязвимостей в режиме "черного ящика" такие подробности об узле C вам не сообщит :)

2. Знания специфики уязвимостей. Мой любимый пример - XSS (например, CVE-2013-1937, XSS в phpMyAdmin). Оценка таких уязвимостей - застарелая детская болезнь CVSS, поскольку оценивается опасность уязвимости по отношению к уязвимому узлу. Уязвимому веб-серверу эта XSS неопасна совсем, поэтому Impact subscore для них с трудом натягивают до C:L,I:L:A:N. При этом вектор CVSS никак не дает вам понять, что с помощью этой уязвимости можно атаковать рабочее место администратора веб-сервера с последующим перехватом его логина и пароля для доступа к админке. Значит, кроме самого вектора вам надо еще знать, как минимум, классификацию данной уязвимости в CWE, потому что тогда по классу уязвимости вы можете худо-бедно определить, как она может использоваться нарушителем.

3. Знания инвентаризационной информации. На самом деле и классификации по CWE, и даже подробного описания уязвимости недостаточно для оценки последствий ее использования нарушителем. Например, если в некотором веб-приложении есть SQLI, и у вас даже есть исходный код этого приложения - вы все равно не можете ничего сказать о том, как нарушитель может использовать эту уязвимость. Техника и последствия эксплуатации SQLI зависят от того, какая именно из поддерживаемых приложением СУБД используется в атакуемой информационной системе. В одних СУБД SQLI может позволять только читать данные из таблиц, в других та же самая SQLI позволяет выполнять хранимые процедуры и через них манипулировать непосредственно операционной системой.

Все эти проблемы на самом деле решаются, но как - вопрос не для публичного обсуждения. Так что если вам для научной работы нужны консультации - пишите в личку. Мой адрес на GMail легко угадывается :)