Пишем простой модуль для 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: 4 комментария

  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 файл.

      1. Пробовал аналогично из под Win XP. Но ничего не выходит (я рукожоп еще тот). У меня такая же ошибка "can't find test data in memory" при вытаскивании через MyTestXProHelper.
        Тест приложен ниже

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

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