Пишем простой модуль для Nessus


Одним из ключевых аспектов тестирования на проникновения является автоматизация шаблонных действий. Кто-то для этого пишет отдельные программы, однако сейчас существует множество продуктов, которые позволяют расширять свои функциональные возможности с помощью дополнительных модулей. Пример бесплатного сканера уязвимостей с поддержкой модулей - OpenVAS, но в этой статье речь пойдет о Nessus, который хоть и платный, но субъективно находит больше и генерирует меньше false positive срабатываний (хотя OpenVAS начался, как форк Nessus, но это было давно).

Большинство модулей для Nessus представляют собой обычные текстовые файлы с расширением .nasl. Часть модулей поставляются в виде бинарных файлов с расширением .nbin, но не будем об этом. Модули (или плагины) по умолчанию можно найти по следующим путям (https://community.tenable.com/s/article/Location-of-Plugin-Directory):

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

В качестве примера мы напишем тривиальный модуль для поиска скрипта администрирования БД Adminer (https://github.com/vrana/adminer/). В Nessus есть похожий модуль для phpMyAdmin (https://phpmyadmin.net/). Модуль будет искать Adminer по всевозможным характерным путям, определять версию и в зависимости от нее выставлять степень критичности находки (до версии 4.6.3 возможно было читать файлы на сервере с помощью LOAD DATA LOCAL INFILE, подробнее можно прочитать тут).

Отмечу, что документация по доступному API своеобразная и обрывочная, одни и те же действия в стадартных модулях временами реализуются разными способами без видимой причины, именование некоторых функций также оставляет вопросы, что наводит на мысль о пласте legacy-кода, который Tenable (разработчик Nessus) никак не вычистит (возможно, не хотят старые модули переписывать).

Приступим. Модуль начинается с указания уникального внутреннего идентификатора для него, а также описания, даты релиза, степени критичности, CVE и т.п. Практически все является опциональным и служит лишь для удобного представления в веб-интерфейсе (а ведь модули можно запускать и без него через консоль). Рекомендую использовать подсветку синтаксиса для Ruby. Тут, естественно, используется не он, а NASL, но подсвечивает приемлемо.

Так как код в целом простой, буду описывать суть в абзацах после фрагментов кода. В вышеприведенном участке мы задали уникальный идентификатор, версию, дату, описание и прочие атрибуты модуля. Список атрибутов неполный, если есть необходимость добавить связанный CVE, CVSS и прочее - посмотрите примеры в стандартных модулях. В конце мы задаем категорию модуля - CGI abuses и несколько условий. Нам необходимо, чтобы до старта нашего модуля отработал модуль webmirror.nasl. Данный модуль занимается перебором стандартных путей и заполняет некоторые глобальные структуры, которые затем могут быть использованы другими модулями. Далее мы задаем условия, чтобы наш модуль не запускался если в политике сканирования явно отключено CGI scanning (https://www.tenable.com/blog/nessus-web-application-scanning-new-plugins-configuration), либо отключено тестирование веб-приложений. Далее нам необходимо, чтобы предварительно Nessus просканировал и идентифицировал порты с веб-серверами, и задаем таймаут работы нашего модуля.

Вот так будет выглядеть информация о модуле в веб-интерфейсе Nessus.

Для поиска возможных путей нам необходим список версий, а также возможные именования. Все это можно получить из официального репозитория Adminer - https://github.com/vrana/adminer/. Я составил полный список возможных именований с учетом доступных языков - https://github.com/kaimi-io/web-fuzz-wordlists/blob/master/adminer.txt. В нашем модуле мы будем использовать сокращенный вариант, который при необходимости можно дополнить, и будем частично генерировать этот список, вместо того, чтобы хардкодить содержимое. Но для начала допишем (скопируем из других модулей) еще несколько моментов:

Мы подключаем некоторые модули, которые содержат используемые глобальные переменные и реализацию некоторых необходиммых функций. Далее получаем порт, где Nessus обнаружил веб-сервер. Переходим к draw the rest of the fucking owl основному коду:

Здоровенный фрагмент кода. В общем, исходя из репозитория, мы составили список версий, префиксов и суффиксов именования путей, по которым может быть расположен Adminer. Объявили несколько переменных (массивы для хранения пути, версии, общий счетчик числа обнаружений и флажок повышенной критичности). Далее мы начинаем процесс сканирования, используя при этом обнаруженные ранее пути. Формируем путь для проверки и делаем обычный GET-запрос. Обратите внимание на имя функции для его отправки и вспомните пассаж выше про legacy-код и качество API. Извлекаем обычным регулярным выражением версию и заносим в массивы, а также выставляем флажок, если обнаружена старая версия с возможностью чтения файлов на сервере. После проверки всех директорий генерируем текст для отчета, где указываем пути, обнаруженные версии и в зависимости от этого возвращаем, что ничего не нашлось (AUDIT_WEB_APP_NOT_AFFECTED), уязвимость низкого уровня (если версия >= 4.6.3), иначе высокого.
Вот так выглядят результаты работы модуля в веб-интерфейсе:


Как я упоминал, модуль также может быть запущен из командной строки следующим образом:

Подробнее можно почитать тут.
Наконец, после того, как модуль написан и перемещен в директорию с другими модулями, необходимо обновить БД плагинов (https://community.tenable.com/s/article/Rebuild-the-Plugin-Database):

Первая команда отключает проверку подписи у используемых плагинов. Все готово, можно пользоваться. Для желающих почитать более структурированное описание процесса разработки модулей - можно полистать книгу Nessus Network Auditing, издание старое, но представление о процессе и доступном API дает.

Модуль из статьи: adminer_detect.nasl.zip

Пишем простой модуль для Nessus: 3 комментария

  1. Kaimi, привет! Пишу в этой теме,т.к тема, соответствующая моему вопросу,закрыта. Можешь ли ты снять пароль с теста формата MTX,либо извлечь список вопросов за вознаграждение разумеется)?
    Все экстракторы в статье пробовал,все нужные версии качал-не идёт. Возможно дело в моих кривых руках..

    1. Если уже формат mtx, то надо не экстракторы пробовать, а брать софт из статьи про mtx, запускать редактор тестов, указывать процесс редактора и патчить память. Там это в одну кнопку вроде делается

      1. Привет Друг! Я пытался преобразовать файл теста (mytestx) .exe в mtf по твоей инструкции но что-то не хочет редактор открывать его. Поможешь мне с одним файлом, буду очень благодарен! https://yadi.sk/d/wWGrSOGM_YJmsA
        напиши пожалуйста ответ в вк. спасибо!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *