Взлом через автодополнение: хакеры спрятали целый арсенал Khunt внутри Oracle

Как работала атака: SQL-инъекция через строку поиска с автодополнением

Точкой входа стала уязвимость SQL-инъекции в публичном Java-приложении, запущенном на Apache Tomcat . Функция автодополнения в строке поиска не фильтровала пользовательский ввод, что позволило атакующим внедрять SQL-команды через JDBC-соединение с базой данных Oracle . Как отмечают исследователи Huntress, это не новый класс уязвимостей — SQL-инъекции существуют десятилетиями и обычно являются результатом некорректной обработки пользовательских данных, направляемых к SQL-серверу . Простая неспособность приложения очистить поле поиска запустила цепочку компрометации.

Инструментарий Khunt: жизнь внутри базы данных как Java-объектов

Вместо развертывания традиционных файлов вредоносного ПО на скомпрометированном сервере атакующие использовали встроенную JVM Oracle и оператор CREATE JAVA SOURCE для компиляции и хранения всего пост-эксплойт-инструментария в виде Java-объектов схемы внутри базы данных Oracle . Этот подход сделал инструментарий невидимым для стандартных защит уровня ОС, так как EDR и антивирусы ориентируются на процессы, бинарные файлы и файлы на операционной системе — они, как правило, не проверяют Java-классы и PL/SQL-обертки, хранящиеся внутри Oracle .

Инструментарий khunt включал следующие компоненты, каждый из которых хранился как объект базы данных:

Полный контроль над системой: от базы данных до Windows OS

Атакующие не ограничились доступом к БД. Они использовали инструментарий khunt для перехода от уровня базы данных к операционной системе Windows в несколько шагов:

1. Выполнение команд ОС через KhuntCmd: с помощью модуля KhuntCmd они выполнили cmd.exe /c whoami, что подтвердило наличие привилегий SYSTEM на сервере Windows, установив удаленное выполнение кода (RCE) от БД к ОС .
2. Кража учётных данных: с помощью PowerShell они вызвали reg.exe и скопировали кусты реестра SECURITY и SYSTEM, сохранив их как khuntSECURITY.hiv и khuntSYSTEM.hiv в F:\Oracle\ .
3. Перечень служб: выполнили tasklist /svc и сохранили вывод как khunttasks.txt .
4. Дополнительное извлечение кустов: использовали esentutl.exe для копирования SAM и второй копии SECURITY, сохранив их как khuntSAM.hiv и khunt_SECURITY.hiv .

Извлеченные кусты реестра могут быть использованы офлайн для извлечения и декодирования хэшей паролей всех локальных учётных записей .

Слепые зоны защиты: ключевые выводы Huntress

Расследование Huntress выявило несколько критических слепых зон, позволивших атаке пройти незамеченной:

• База данных как плацдарм: БД превратилась из пассивного хранилища данных в активную атакующую платформу, где вредоносный инструментарий живет внутри базы данных, а не на диске или в памяти .
• Обход EDR/AV: Традиционные системы EDR и антивирусы не проверяют Java-классы и PL/SQL-обертки внутри Oracle, что делает инструментарий невидимым для стандартных защит ОС .
• Классическая уязвимость, необычная доставка: начальная SQL-инъекция — известный класс багов. Не потребовалось ни одного zero-day. Функции автодополнения было достаточно, чтобы добраться до PL/SQL и операционной системы — базовый сбой проверки ввода приводит к глубокой компрометации, если движок БД имеет доступ к ОС .
• Избыточные привилегии учётных записей БД: даже после успешной SQL-инъекции ущерб ограничен, если учётная запись пользователя БД не имеет прав на создание Java-источников или выполнение хранимых процедур. Организации часто предоставляют избыточные привилегии, что дает атакующим дополнительные разрешения для развертывания khunt .

Меры защиты, рекомендованные Huntress

Основываясь на этой атаке, Huntress рекомендует :

• Корректная санитизация ввода и параметризация запросов для всех веб-входов.
• Ограничение привилегий пользователей БД, чтобы даже внедренные запросы не могли создавать Java-источники или выполнять произвольные хранимые процедуры.
• Расширение мониторинга на объекты БД (Java-классы, PL/SQL-обертки), а не только артефакты уровня ОС.

Эта атака служит суровым напоминанием: движки баз данных со встроенными средами программирования (как JVM Oracle) могут стать незаметными атакующими платформами, если их сочетать с единственным непроверенным полем ввода. Командам безопасности необходимо расширять мониторинг за пределы ОС, включая слой объектов базы данных.