Даже если бы администраторы поставили все 1449 июльских обновлений Oracle, описанную атаку это бы не остановило. В этом и неприятная суть истории про патчи Oracle: злоумышленники не ломали СУБД новой дырой, а использовали то, что в ней уже было включено и доступно через плохо защищенную связку веб-приложения и базы.
Об этом, как пишет The Register, рассказал Крейг Сэвидж, руководитель направления кибербезопасности в Spinnaker Support, комментируя инцидент, который ранее описала Huntress. По данным Huntress, в июле компания получила сигнал о краже учетных данных в инфраструктуре неназванной организации. Начальная точка входа выглядела почти банально: простая SQL-инъекция в публичном веб-приложении. Но дальше началось уже не типичное «утащили дамп и ушли», а более неприятный сценарий с использованием встроенной логики Oracle Database.
После первичного доступа атакующие загрузили в базу постэксплуатационный набор инструментов под названием khunt. Ключевой прием состоял в том, что код попал не на отдельный сервер приложений и не в виде внешнего бинарника, а прямо внутрь Oracle Database через механизм Java Source. У Oracle есть встроенная JVM, а Java-код может храниться как объект базы данных. По описанию Huntress, злоумышленники передавали в Oracle команды CREATE JAVA SOURCE из Tomcat через существующее соединение с БД, а затем этот код компилировался внутри самой базы как объект схемы. То есть атакующий фактически поселял свой инструмент там, где многие защитные процессы смотрят не в первую очередь.
Сам по себе прием не новый на уровне теории. Huntress отдельно уточняет, что подобные техники обсуждались и раньше, в том числе в контексте подхода, известного как oraexec. Новизна не в академическом описании, а в том, что такой способ редко документировался в реальных атаках. Именно это и делает историю показательной для команд, которые до сих пор мыслят в модели «есть CVE, есть патч, значит проблема закрыта». Здесь патчи Oracle вообще не были главным сюжетом: злоумышленники использовали легитимную функциональность продукта, которая оказалась доступна из небезопасно настроенного продакшн-контура.
Сэвидж формулирует мысль жестко: это не был «взлом Oracle» в прямом смысле. По его словам, возможность запускать и собирать Java внутри базы в промышленной среде должна быть жестко ограничена, а у веб-сервера таких прав быть не должно вообще. В нормальной конфигурации, считает он, подобный механизм стоит держать закрытым и включать только на время разработки или обслуживающего окна. Отдельно он подчеркивает, что право компилировать код на production-сервере должно быть доступно максимум DBA-пользователю. Если бы эта функция была заблокирована, база могла бы принять присланный код, но не смогла бы его собрать и превратить в рабочий инструмент внутри СУБД.
Для разработчиков и DevSecOps-команд здесь довольно неприятный, но полезный вывод. Патчи Oracle по-прежнему обязательны, и никто не отменяет управление уязвимостями. Но история показывает предел эффективности одной только стратегии patch management. Если веб-приложение допускает SQL-инъекцию, а между Tomcat и Oracle живет избыточно привилегированное соединение, то злоумышленник получает не просто доступ к данным, а возможность исследовать внутренние механизмы платформы и использовать их как штатный инструмент. На практике это означает, что список критичных проверок должен включать не только уровень CVE, но и инвентаризацию опасной функциональности: кто может создавать Java Source, кто может компилировать код внутри БД, какие схемы и сервисные аккаунты реально нужны приложению, а какие права исторически «просто остались».
Для бизнеса риск тоже меняется. Раньше многим было достаточно показать совету директоров красивую картинку: все критические патчи Oracle установлены, SLA соблюдается, сканер уязвимостей зеленый. Теперь этого явно мало. Когда атакующие переходят от поиска дыр к эксплуатации штатных возможностей продукта, в игру снова возвращаются старые, не очень модные, но жизненно важные вещи: сегментация, least privilege, hardening, отключение неиспользуемых функций и аудит доверительных связей между приложением и базой. Ирония в том, что рынок годами повторял мантру про «патчите быстрее», а реальность все чаще напоминает: если прод открыт шире, чем должен, скорость установки обновлений не компенсирует архитектурную лень.
История с Oracle, скорее всего, не последняя в этом жанре. Чем лучше защищаются продукты от классической эксплуатации уязвимостей, тем активнее злоумышленники изучают их нормальное, документированное поведение и ищут, как превратить его в боевой сценарий. Вопрос уже не только в том, сколько патчей Oracle успела поставить компания, а в том, понимает ли она, какие штатные функции ее платформы вообще не должны быть доступны из продакшн-приложения.