Оффлайн
- Регистрация
- 9 Май 2015
- Сообщения
- 1,480
- Баллы
- 155
BChecks — это чекеры, которыми ты можешь дополнить существующие сканеры уязвимостей Burp. Чекер — это шаблон наподобие популярных шаблонов Nuclei. В статье я покажу, как делать простые и быстрые чекеры, а заодно разберемся со скриптовым языком Burp.
Сильная сторона BChecks в простоте и скорости разработки. Слабая в том же: не получится построить мощные сканеры со сложной логикой, системными вызовами или работой с файловой системой. Подходи ответственно к алгоритмам, тщательно продумывай словари пейлоадов, и получишь мощный инструмент в свой хакерский арсенал.
warning
Статья имеет ознакомительный характер и предназначена для специалистов по безопасности, проводящих тестирование в рамках контракта. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Распространение вредоносных программ, нарушение работы систем и нарушение тайны переписки преследуются по закону.
Пассивное сканирование
BChecks идеально подходит для пассивного анализа, когда нет необходимости делать дополнительные запросы. Так ты соберешь максимум данных без лишних следов на сервере.
Первый чекер
Нашим «Hello world!» будет скрипт, который отслеживает ответы веб‑приложения и ищет в них заголовок X-Powered-By. Заголовок X-Powered-By указывает на основную технологию веб‑приложения, может раскрывать конкретную версию. Например, X-Powered-By: PHP/8.3.4 , который говорит о потенциальной критической уязвимости .
Чтобы начать создавать первый BСheck, перейди на вкладку Extensions и найди там BСhecks. Жми New и выбери Blank BCheck. Так ты создашь пустой шаблон.
В Burp есть база примеров шаблонов
В начале любого шаблона указываются метаданные:
metadata:
# Версия языка. На сегодня доступна только одна версия языка
language: v2-beta
# При добавлении уязвимости это название подставится в название потенциальной уязвимости
name: "X-Powered-By detected"
# Необязательные параметры, описывающие скрипт
description: "Простой пример пассивного сканирования"
author: "ret0x2A"
tags: "passive", "headers"
Добавь блок объявления переменных define.
define:
# Переменная объявляется с простым присвоением
x_header = "X-Powered-By"
# Можно использовать подстановки
problem = `Нашли заголовок {x_header}, возможен слив технологии`
Переменные
Встроенный язык поддерживает два варианта объявления переменных: define для констант и run for each для массивов. При использовании массивов шаблон выполнит проверки для каждого элемента массива. Переменные просто подставляются как значения.
Жестких требований для этих блоков нет. Можешь использовать блоки по отдельности или вместе, можешь вообще обойтись без них.
Действия и логика работы прописываются в блоке given … then. В given явно указывается случай, когда сканер выполнит проверку. Мы договорились, что будем обрабатывать ответы веб‑приложения, значит, нужно использовать given response then:
# Чекер срабатывает при каждом ответе от сайта
given response then
# Ищем хидер в последнем ответе сайта
if {x_header} in {latest.response.headers} then
# Фиксация уязвимости в Burp
report issue:
# Уровень угрозы info|low|medium|high
severity: info
# Точность certain|firm|tentative
confidence: firm
# Для получения значения переменной используй {}
detail: {problem}
end if
О блоке given ... then
Разработчики Burp предусмотрели given ... then для любых ситуаций. Если тебе нужно выполнить скрипт один раз для всего хоста, вместо response используй host. Для каждого пути, который нашел Burp, — path. Обработка запросов — request.
Можно привязать работу к точкам инъекции, которые проверяет сканер: cookie, header, body, query или ко всем сразу — any. Это заставит шаблон запускать проверку для каждой точки инъекции. Например, header заставит выполнить чек для каждого заголовка в отдельности: Host, Content-Type и так далее.
Точки инъекции допустимо совмещать: given query or body insertion point. Эта запись означает: «выполни проверку как для параметров в URL, так и для параметров в теле запроса».
Твой сканер готов! Сохрани код и переходи к запуску.
Форматирование
BCheck не предъявляет требований к форматированию. Отступы могут быть любыми или отсутствовать вовсе. Даже такая «мешанина» будет работать:
define:not_found = "404"run for each:wl = "~", ".old", ".bak", ".backup"
Соблюдай разумный подход, чтобы удобно было читать и модифицировать код.
Запускаем сканирование
Создай новый скан типа Crawl and Audit, конфигурация сканирования — кастомная. В блоке Issues Reported выбери индивидуальные значения и сбрось все типы уязвимостей, кроме BCheck generated issue. В реальных условиях ты будешь совмещать сканеры, но сейчас важно сократить время сканирования.
Настройка сканера на BCheck
Сохрани конфигурацию сканирования в библиотеку, чтобы не настраивать каждый раз, и запускай сканирование.
Burp понимает, что мы искали, и подсвечивает в интерфейсе
Пример простой, но ты можешь расширить его, получив кучу полезных сканеров: поиск токенов и секретных ключей, забытые комментарии разработчиков (такое встречается не только на YouTube), определение CMS по метатегу generator и так далее.
Ищем интересные файлы
Разработчики часто забывают файлы, иногда очень опасные. Мне попадались полные архивы с прод‑версией, включая ключи. Встречались дампы баз данных, бэкапы файлов скриптов и конфигов и даже дампы памяти. В целях обучения пойдем от простого к сложному и начнем с поиска .gitignore.
metadata:
language: v2-beta
name: ".gitignore file"
description: "Пример поиска одного файла"
author: "ret0x2A"
tags: "git", "file"
define:
# В блоке define объявляются константы
potential_path = ".gitignore"
# Чекер будет выполнен для каждого пути
given path then
# Выполнить GET-запрос и поместить результат в check
send request called check:
method: "GET"
appending path: {potential_path}
# Если код ответа равен 200, то добавляем уязвимость
if {check.response.status_code} is "200" then
report issue and continue:
severity: high
confidence: certain
detail: `Найден файл {potential_path}.`
remediation: "Не оставляй что попало где попало"
end if
Просканируй любой законный хост с файлом .gitignore в корне и получишь «уязвимость». Критической она помечена для демонстрации. Попробуй вариант с Severity: Low, чтобы увидеть разницу.
Найден .gitignore
Сильная сторона BChecks в простоте и скорости разработки. Слабая в том же: не получится построить мощные сканеры со сложной логикой, системными вызовами или работой с файловой системой. Подходи ответственно к алгоритмам, тщательно продумывай словари пейлоадов, и получишь мощный инструмент в свой хакерский арсенал.
warning
Статья имеет ознакомительный характер и предназначена для специалистов по безопасности, проводящих тестирование в рамках контракта. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Распространение вредоносных программ, нарушение работы систем и нарушение тайны переписки преследуются по закону.
Пассивное сканирование
BChecks идеально подходит для пассивного анализа, когда нет необходимости делать дополнительные запросы. Так ты соберешь максимум данных без лишних следов на сервере.
Первый чекер
Нашим «Hello world!» будет скрипт, который отслеживает ответы веб‑приложения и ищет в них заголовок X-Powered-By. Заголовок X-Powered-By указывает на основную технологию веб‑приложения, может раскрывать конкретную версию. Например, X-Powered-By: PHP/8.3.4 , который говорит о потенциальной критической уязвимости .
Чтобы начать создавать первый BСheck, перейди на вкладку Extensions и найди там BСhecks. Жми New и выбери Blank BCheck. Так ты создашь пустой шаблон.
В Burp есть база примеров шаблонов
В начале любого шаблона указываются метаданные:
metadata:
# Версия языка. На сегодня доступна только одна версия языка
language: v2-beta
# При добавлении уязвимости это название подставится в название потенциальной уязвимости
name: "X-Powered-By detected"
# Необязательные параметры, описывающие скрипт
description: "Простой пример пассивного сканирования"
author: "ret0x2A"
tags: "passive", "headers"
Добавь блок объявления переменных define.
define:
# Переменная объявляется с простым присвоением
x_header = "X-Powered-By"
# Можно использовать подстановки
problem = `Нашли заголовок {x_header}, возможен слив технологии`
Переменные
Встроенный язык поддерживает два варианта объявления переменных: define для констант и run for each для массивов. При использовании массивов шаблон выполнит проверки для каждого элемента массива. Переменные просто подставляются как значения.
Жестких требований для этих блоков нет. Можешь использовать блоки по отдельности или вместе, можешь вообще обойтись без них.
Действия и логика работы прописываются в блоке given … then. В given явно указывается случай, когда сканер выполнит проверку. Мы договорились, что будем обрабатывать ответы веб‑приложения, значит, нужно использовать given response then:
# Чекер срабатывает при каждом ответе от сайта
given response then
# Ищем хидер в последнем ответе сайта
if {x_header} in {latest.response.headers} then
# Фиксация уязвимости в Burp
report issue:
# Уровень угрозы info|low|medium|high
severity: info
# Точность certain|firm|tentative
confidence: firm
# Для получения значения переменной используй {}
detail: {problem}
end if
О блоке given ... then
Разработчики Burp предусмотрели given ... then для любых ситуаций. Если тебе нужно выполнить скрипт один раз для всего хоста, вместо response используй host. Для каждого пути, который нашел Burp, — path. Обработка запросов — request.
Можно привязать работу к точкам инъекции, которые проверяет сканер: cookie, header, body, query или ко всем сразу — any. Это заставит шаблон запускать проверку для каждой точки инъекции. Например, header заставит выполнить чек для каждого заголовка в отдельности: Host, Content-Type и так далее.
Точки инъекции допустимо совмещать: given query or body insertion point. Эта запись означает: «выполни проверку как для параметров в URL, так и для параметров в теле запроса».
Твой сканер готов! Сохрани код и переходи к запуску.
Форматирование
BCheck не предъявляет требований к форматированию. Отступы могут быть любыми или отсутствовать вовсе. Даже такая «мешанина» будет работать:
define:not_found = "404"run for each:wl = "~", ".old", ".bak", ".backup"
Соблюдай разумный подход, чтобы удобно было читать и модифицировать код.
Запускаем сканирование
Создай новый скан типа Crawl and Audit, конфигурация сканирования — кастомная. В блоке Issues Reported выбери индивидуальные значения и сбрось все типы уязвимостей, кроме BCheck generated issue. В реальных условиях ты будешь совмещать сканеры, но сейчас важно сократить время сканирования.
Настройка сканера на BCheck
Сохрани конфигурацию сканирования в библиотеку, чтобы не настраивать каждый раз, и запускай сканирование.
Burp понимает, что мы искали, и подсвечивает в интерфейсе
Пример простой, но ты можешь расширить его, получив кучу полезных сканеров: поиск токенов и секретных ключей, забытые комментарии разработчиков (такое встречается не только на YouTube), определение CMS по метатегу generator и так далее.
Ищем интересные файлы
Разработчики часто забывают файлы, иногда очень опасные. Мне попадались полные архивы с прод‑версией, включая ключи. Встречались дампы баз данных, бэкапы файлов скриптов и конфигов и даже дампы памяти. В целях обучения пойдем от простого к сложному и начнем с поиска .gitignore.
metadata:
language: v2-beta
name: ".gitignore file"
description: "Пример поиска одного файла"
author: "ret0x2A"
tags: "git", "file"
define:
# В блоке define объявляются константы
potential_path = ".gitignore"
# Чекер будет выполнен для каждого пути
given path then
# Выполнить GET-запрос и поместить результат в check
send request called check:
method: "GET"
appending path: {potential_path}
# Если код ответа равен 200, то добавляем уязвимость
if {check.response.status_code} is "200" then
report issue and continue:
severity: high
confidence: certain
detail: `Найден файл {potential_path}.`
remediation: "Не оставляй что попало где попало"
end if
Просканируй любой законный хост с файлом .gitignore в корне и получишь «уязвимость». Критической она помечена для демонстрации. Попробуй вариант с Severity: Low, чтобы увидеть разницу.
Найден .gitignore