nickstadb/pocРепозиторий для PoC-эксплойтов и инструментов.
Репозиторий с PoC-эксплойтами и инструментами.
Эксплойт для неаутентифицированного удалённого выполнения команд в агенте RSCD от BMC Server Automation. Эксплойт работает против серверов, затронутых CVE-2016-1542 (обнаруживается с помощью Nessus).
Теперь это модуль Metasploit, см. exploits/multi/misc/bmc_server_automation_rscd_nsh_rce
Эксплойт был создан так: Nessus сканировал Python-скрипт, который записывал пакеты и отправлял их/мусор обратно в Nessus. Захватив пакеты, формат данных было тривиально «развернуть», чтобы создать полурабочий эксплойт. Позже я получил доступ к уязвимому ПО агента и смог с помощью отладчика и некоторого фаззинга устранить недочёты и превратить это в полноценный RCE-эксплойт.
Подробнее о том, как я создавал эксплойт, читайте в моих постах в блоге:
Эксплойт для неаутентифицированного удалённого выполнения кода в HP Device Manager версий с 5.0.0 по 5.0.3 (CVE-2020-6926, CVE-2020-6927).
Эксплойт использует неаутентифицированный сервис Java RMI, в котором есть уязвимость внедрения Hibernate Query Language. ORM-инъекция используется для доставки пейлоада SQL-инъекции в Postgres с целью перезаписи файла pg_hba.conf на сервере HP Device Manager, что открывает удалённый доступ к встроенной в HPDM базе данных Postgres. После этого учётная запись бэкдор-суперпользователя используется для аутентификации в базе данных Postgres и выполнения произвольных команд операционной системы.
Подробнее о том, как я обнаружил эти уязвимости, читайте в моём посте в блоге:
Хотя этот эксплойт работает только против HPDM 5.x, неаутентифицированный сервис Java RMI присутствует во всех версиях HPDM до 5.0.4 и 4.7 с пакетом обновления 13. Влияние эксплуатации этого сервиса может быть ниже, но уязвимость HQLi/SQLi остаётся, как и возможность извлечения конфигурации (возможно, включая пароли других сервисов), а также всех имён учётных записей HPDM и соответствующих MD5-хешей паролей.
Эксплойт для неаутентифицированного удалённого выполнения кода на небезопасно сконфигурированных конечных точках Java-сервиса JNBridge. Основан на работе Moritz Bechler (CVE-2019-7839).
Сетевой протокол, реализованный в JNBridge, предназначен исключительно для обеспечения удалённого выполнения кода с целью взаимодействия между Java- и .NET-приложениями. Поэтому технически это не эксплойт, а просто удобный небольшой Python-скрипт для выполнения произвольных команд на Java-конечной точке JNBridge.
Пошаговое описание моего пути от security advisory до создания полноценного эксплойта — в моём посте в блоге:
Этот эксплойт нацелен на небезопасную функциональность автоматического обновления в WordPress, чтобы сбросить PHP-шелл на сервер. Эксплойт успешно протестирован вплоть до WordPress 4.9.8 — последней версии на момент публикации.
Когда WordPress проверяет наличие обновлений, он пытается установить защищённое HTTPS-соединение с api.wordpress.org. Если это соединение не удаётся, например из-за непроверенного сертификата, WordPress переключается на небезопасное HTTP-соединение.
Вторая проблема заключается в том, что WordPress доверяет обновлениям переводов. Он не обновляет автоматически плагины, темы или основные версии ядра, предположительно из-за рисков установки нового кода на сервер. Однако обновления переводов он устанавливает автоматически. К сожалению, WordPress не выполняет надлежащую проверку архивов переводов, поэтому, если ZIP-файл перевода содержит по крайней мере один файл с расширением .po и один файл с расширением .mo, WordPress извлечёт содержимое на сервер (включая шелл, вставленный MitM).
Я наткнулся на эти проблемы случайно, но когда я сообщил о них (ноябрь 2017), команда WordPress по сути ответила WONTFIX из-за обратной совместимости. Если кто-то запускает WordPress на сервере, который не может установить исходящее SSL/TLS-соединение, он, по их словам, всё равно должен иметь возможность автоматически обновлять WordPress по соображениям безопасности.
¯\_(ツ)_/¯
Подробнее в моём посте в блоге:
Несколько JS-сниппетов для эксплуатации XSS-уязвимостей WordPress.
