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


Некоторое время назад в сканере уязвимостей веб-приложений Acunetix появилась возможность расширения функционала за счет добавления собственных модулей. На официальном блоге даже была опубликована заметка, описывающая общий подход к разработке модулей. Давайте напишем простой модуль на основе нее, а также моей прошлогодней заметки по созданию модуля для Nessus. С точки зрения функций модуль будет аналогичным: поиск на узле скрипта Adminer, старые версии которого позволяют читать произвольные файлы на сервере с помощью фичи MySQL LOAD DATA LOCAL INFILE.

Приступим. Исходя из вышеупомянутой статьи на официальном блоге, для создания модулей используется язык JavaScript. Модули необходимо размещать в следующих директориях:

  • %PROGRAMDATA\Acunetix\shared\custom-scripts\ (Windows)
  • /home/acunetix/.acunetix/data/custom-scripts/ (Linux)

Дальнейший путь зависит от типа модуля. Существует два типа модулей: запускаемые один раз для сканируемого хоста (их необходимо размещать в директории target), запускаемые на каждый HTTP-ответ при сканировании (директория httpdata). Нам доступны некоторые дополнительные интерфейсы, описание которых находится в файле native.d.ts (директория custom-scripts). Для нашего модуля мы воспользуемся вторым типом (на каждый HTTP-ответ), так как нам необходима информация о доступных путях, собранная Acunetix'ом, фактически, наш модуль будет запущен для каждого обнаруженного пути. Далее мы отфильтруем ситуации, когда наш модуль вызывается в контексте обращения к директории. Дополнительно активировать модуль не требуется, достаточно в профиле сканирования включить опцию Custom Scripts (на блоге Acunetix этот момент подробно описан). Перейдем к коду.

Мы объявили переменную с описанием уязвимости, массивы для формирования возможных путей сценария Adminer, регулярные выражения для извлечения версии и проверки, является ли она устаревшей, и пару массивов для хранения возможных и обнаруженных путей. Первый массив необязателен, но немного упрощает восприятие кода и может быть использован для отладки. Накладные расходы с точки зрения используемой памяти несущественны.

Стоит отметить, что описание доступных интерфейсов неполное как в блоге Acunetix, так и в файле native.d.ts, например, в коде я проверяю значение scriptArg.location.isFolder, которое не описано. Так как это Javascript, то при разработке имеет смысл использовать отладочные сообщения (функция ax.log) для вывода всех доступных полей и методов объектов. Например, ниже приведены доступные свойства и методы scriptArg.location, scriptArg.target, scriptArg.http с примерами значений (сканируемый хост - 192.168.0.1, порт 80):

Вообще, судя по отсутствию вменяемой документации и по доступным интерфейсам, возможность создавать собственные модули находится в начальной стадии. Разработка модулей для Nessus и OpenVAS гораздо лучше документирована, а доступные интерфейсы обладают бОльшими возможностями. Но что-то мы отвлеклись. Приведу примеры, как будут выглядеть результаты в веб-интерфейсе Acunetix после сканирования в случае, если что-то было обнаружено.


На этом на сегодня все. Ставьте лайк, подписывайтесь на канал, жмите колокольчик.

Модуль из статьи: adminer.js.zip

P.S. Когда-то на сайте Acunetix можно было свободно скачать демо-версию, а сейчас приходится просить знакомых, чтобы проверить работоспособность модуля. Неудобства на ровном месте. О существовании пиратских версий я знаю, но это не наш выбор.

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

  1. Здравствуйте, помогите пожалуйста, понимаю, что тема заезжена.. Но, завтра серьезный экзамен, хотелось бы поготовиться. Использовал вашу программу MyTestXProHelper, не получилось, вытащить тест, пишет "can t find test data in memory" испробовал все, виртуальную машину XP итд. Все равно - "can t find test data in memory". Если у Вас получится вытащить тест, в долгу не останусь, обязательно отблагодарю вас, сколько скажете. Файл ПМ.01 экзешник.

    1. В *.59 могут наблюдаться сложности с извлечением. Это возможно сделать вручную (на XP):
      1. Взять x64dbg, включить Hide Debugger (или взять OllyDbg с настройками под VMProtect)
      2. Открыть тест, поставить breakpoint на VirtualFree
      3. Запустить, после срабатывания breakpoint просканировать память процесса в соответствии с сигнатурой из xml-файла в составе MyTestXProHelper
      4. Установить hardware breakpoint on write для первого байта этого адреса
      5. Перезапустить процесс (Ctrl+F2)
      6. Первое срабатывание hardware breakpoint пропустить, а на втором по идее сигнатура в начале блока останется прежней, но содержимое будет расшифровано в памяти
      7. Скопировать содержимое памяти от сигнатуры заголовка до сигнатуры конца (все из xml-файла) в *.mtx файл.

Добавить комментарий для Kaimi Отменить ответ

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