SQL-инъекция превратила базу Oracle в плацдарм для атаки
Инцидент с SQL injection: как злоумышленники превратили Oracle DB в плацдарм для Remote Code Execution
Huntress недавно раскрыла детали сложной атаки, начавшейся с эксплуатации SQL injection vulnerability в публично доступном веб-приложении. Злоумышленники не только получили доступ к Oracle database, но и развернули в ней нестандартный post-exploitation toolkit khunt, превратив базу данных в активный инструмент для последующих действий. В результате атакующие добились Remote Code Execution (RCE) at the operating system level, что потребовало принципиально иных подходов к обнаружению и защите.
Вектор проникновения: уязвимое веб-приложение
Точкой входа послужило доступное извне веб-приложение на Java и Tomcat, лишённое необходимой защиты от вредоносных запросов. Эксплуатация SQL injection vulnerability позволила атакующим загрузить инструментарий напрямую в Oracle database, используя для этого объект Java Source. Такой метод кардинально маскирует полезную нагрузку, поскольку вредоносный код оказывается в несвойственной для большинства средств безопасности среде.
Инструментарий khunt: база данных как командный центр
Post-exploitation toolkit khunt состоит из набора компонентов, каждый из которых расширяет возможности злоумышленников внутри скомпрометированной системы:
- khuntCmd — загружает command line, позволяя выполнять произвольные команды операционной системы через SQL-запросы.
- khuntHash — извлекает конфиденциальные данные (имена пользователей и пароли) из внутренних таблиц базы данных и сохраняет их в файлы.
- khuntFS и khuntFS2 — предоставляют file management capabilities для исследования файловой структуры скомпрометированного хоста.
- khuntT — используется для проверки рабочего состояния инструментария.
- khuntUnzip — позволяет извлекать файлы.
- PL/SQL wrappers — набор обёрток, обеспечивающих вызов Java-методов непосредственно из контекста базы данных.
Post-exploitation: доступ к Windows registry
После закрепления в базе данных злоумышленники задействовали PowerShell-команды для копирования критических ветвей Windows registry — SECURITY и SYSTEM. Результирующие файлы сохранялись на скомпрометированной системе, открывая доступ к хешам паролей и другой конфиденциальной информации, необходимой для дальнейшего развития атаки.
Трудности обнаружения: почему khunt невидим для EDR
Размещение вредоносного инструментария внутри базы данных меняет её роль с пассивного хранилища на активную точку запуска. Поскольку все модули существуют в виде Java classes и PL/SQL элементов, стандартные endpoint detection and response (EDR) и antivirus-решения, ориентированные на мониторинг файловой системы и процессов ОС, их игнорируют. Это позволяет атакующим действовать скрытно, обходя основные защитные механизмы.
Рекомендации по снижению рисков
Чтобы противостоять подобным атакам, организациям необходимо внедрять многоуровневую защиту:
- Injection-proof input forms — обязательная input sanitization и query parameterization на всех уровнях веб-приложения.
- Restrict user privileges — учетные записи, взаимодействующие с базой данных, не должны обладать excessive privileges, особенно ролями, разрешающими выполнение Java source code или stored procedures.
- Мониторинг активности в СУБД — отслеживание создания нестандартных Java-объектов и PL/SQL wrappers, способных свидетельствовать о компрометации.
- Сетевая сегментация — ограничение возможности прямого обращения к базе данных из скомпрометированного веб-приложения и фильтрация подозрительного трафика.
Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.
Ознакомиться подробнее с отчетом можно по ссылке.
