Мониторинг эксплойтов

В прошлой статье мы собрали данные для того чтобы мониторить эксплуатацию уязвимости в Windows Server, который имеет роль контроллера домена. В этой статье мы попытаемся понять есть ли возможность мониторить остальные классы эксплойтов с помощью инструментов ELK, Zabbix или Prometheus.

Классификация эксплойтов с точки зрения мониторинга

Уязвимость - несовершенство программного обеспечения. В простом случае это причина почему приложение не может выполнить свою задачу и завершает работу аварийно.

Можно ли все уязвимости отследить? Попробуем собрать факты воедино. Факт №1 уязвимости с точки зрения их использования для достижения целей компрометации или вывода из строя информационной системы можно условно поделить на:

1. Уязвимости приводящие к аварийному завершению работы приложения

2. Уязвимости позволяющие запустить дополнительные команды в уязвимой системе

Стоит отметить, что для обеих групп мы можем мониторить только последствия или зависимые события.

Первая группа уязвимостей достаточно просто мониторится системами ELK, Zabbix и Prometheus. Недоступность пострадавшей системы тут же будет выведено на общий мониторинг.

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

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

Факт №2 - всего классов уязвимостей задокументировано - 699. Интересная цифра, но это тоже верхнеуровневая абстракция, на самом деле и у этих 699 уязвимостей тоже есть вариации.

Что особенного среди 699 групп уязвимостей? Особенность заключается в том, что большую часть этих уязвимостей в силу своей природы достаточно проблематично обнаружить. К примеру, группа CWE-120. Группа уязвимостей основной смысл которых заключается в том, что программист не верно рассчитал количество памяти, которое нужно было приложению для работы с определенным объектом. В результате у атакующего есть возможность влиять на заполнение памяти процесса. В ряде случаев это может привести к выполнению передаваемых злоумышленником команд.

Очень редко современные операционные системы предоставляют в своих логах события, которые позволяют обнаруживать такого рода уязвимости. Более того эти уязвимости если и есть в программном обеспечении их изучить или задетектировать можно только если перевести приложение в режим отладки, что не является для большинства приложений обычным режимом работы.

Получается память для мониторинга недоступна? На самом деле это не так. Любая система мониторинга и даже логи операционных систем могут включать информацию о том как потребляется память приложениями. Можно эти данные наблюдать в режиме реального времени с помощью различного софта типа VMMap. Софт может показывать количество страниц памяти, которое используется, освобождается, резервируется и т.д. Что же это нам дает?

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

• понимать как работает эксплойт, идеально если будет исходный код

• иметь возможность расширить набор событий в системных логах ОС

Тактика обнаружения на основании списка Mitre

Уязвимости сами по себе могут быть не видны на средствах мониторинга. При использовании возможностей только операционной системы. Иногда сами вендоры, видя популярность уязвимости могут создать отдельные события, которые помогают локализовать эксплуатацию уязвимости.

В случае с уязвимостью CVE-2020-1472 Microsoft добавила специальные события, которые генерируются, если система использует уязвимые алгоритмы. Нам же придется искать закономерности самостоятельно и использовать эти закономерности для мониторинга. Возможно даже придется прибегнуть к сторонним программным продуктам.

Для примера сбора таких закономерностей будем использовать эксплойт к уязвимости CVE-2020-0796. Основная проблема уязвимости - переполнение целочисленного элемента, который используется для контроля размера выделяемой приложением памяти. В сети можно найти 2 сценария использования уязвимости:

1. Remote Code Execution

2. Local Priveledge Escalation

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

Попробуем разобраться со второй. Проект на github предоставляет исходный код на языке программирования C++. Попробуем локализовать основные операциии, которые выполняет эксплойт.

Инициализация её код можно найти ниже:

Создается сокет на loopback интерфейсе и 445 порту. Далее эксплойт будет создавать в специальном формате пакет и отправит его на созданный сокет. Произойдет переполнение размера выделенной памяти в ядре ОС и код перетрёт память, которая относилась к primary токену основного процесса. С этими данными будет создан новый процесс cmd.exe. Как создается этот процесс? Эти данные можно найти в исходнике:

К сожалению, среди событий логов обнаружить ничего не удалось, так как все действия работали динамически в оперативной памяти и не задействовали стандартные механизмы получения доступа к объектам. Журнал "Security" тоже не будет содержать никакой информации. Что же делать? Есть 2 варианта:

1. Использовать IDS для loopback интерфейса

2. Использовать Endpoint защиту

Мы выберем 3-й путь. В ОС Windows есть возможность расширить список событий, которые будет генерировать система. Это возможно сделать с помощью инструмента SysMon. Чтобы инструмент мог генерировать нужные события, ему необходим конфиг, где и перечислены необходимые данные. Есть уже готовый. Причем если мы хотим поотслеживать события с loopback интерфейсом, нужно убрать следующие строки:

...
<RuleGroup name="" groupRelation="or">
        <NetworkConnect onmatch="exclude">
            ...
            <DestinationIp condition="is">127.0.0.1</DestinationIp> <==удалить
            <DestinationIp condition="begin with">fe80:0:0:0</DestinationIp> <==удалить
        </NetworkConnect>
    </RuleGroup>
...

Все данные по событиям выкладываются в системные журналы. Для Windows 10 можно использовать вот этот путь: Applications and Services Logs\Microsoft\Windows\Sysmon\Operational.

Для установки в систему конфига и Sysmon нужно набрать следующую команду:

sysmon.exe -accepteula -i sysmonconfig-export.xml

Запустим эксплойт и заглянем в лог Sysmon:

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

P.S. Для систем на базе Linux тоже скоро будет SysMon.

Прямо сейчас в OTUS открыт набор на новый поток курса "Мониторинг и логирование: Zabbix, Prometheus, ELK". 15 апреля пройдет бесплатный вебинар в рамках которого вы сможете узнать о карьерных перспективах в данной области.

Записаться на вебинар

Также хотим пригласить всех желающих на демо-урок курса по теме: "ELK стэк"