Обработка SQL-запросов в Azure SQL Database допускает удалённое повышение привилегий

В облачной реляционной базе данных Azure SQL Database выявили две уязвимости, связанные с обработкой SQL-запросов. Обе дают удалённому злоумышленнику возможность повысить свои привилегии. Записи о проблемах появились в Банке данных угроз безопасности информации (BDU) под номерами BDU:2026-15592 и BDU:2026-15593, им также присвоены идентификаторы CVE-2026-68789 и CVE-2026-68782. Производитель подтвердил обе уязвимости и уже закрыл их. Оценка по современной версии шкалы CVSS составляет 9,9 балла, по более старой версии той же шкалы 9 баллов. Оба случая относятся к внедрению SQL-кода, то есть к ошибкам, при которых структура запроса остаётся незащищённой.

Детали уязвимостей

Причина одинакова в обоих случаях. Приложение собирает запрос к базе из данных, которые приходят от пользователя, и не проверяет их структуру. Поэтому злоумышленник добавляет в обычное поле ввода фрагмент команды, и сервер выполняет его как часть собственного запроса. Такой класс ошибок называют внедрением SQL-кода, или SQL-инъекцией (CWE-89). Оценка сложности эксплуатации низкая. Кроме того, атака не требует участия пользователя и выполняется напрямую по сети. Злоумышленнику достаточно учётной записи с минимальными правами. Отдельная учётная запись с низкими правами не мешает атаке, потому что повышение привилегий происходит уже внутри базы. Взаимодействие с интерфейсом жертвы при этом не нужно, так как все действия идут через запросы. Следовательно, для попытки подойдёт любое приложение, которое передаёт пользовательские данные в SQL-команду без проверки.

Возможности атакующего после успешной эксплуатации широки. Он читает, изменяет и удаляет записи, а также влияет на доступность базы. Повышение привилегий открывает доступ к объектам, которые обычно закрыты для его учётной записи. Кроме того, вектор оценки фиксирует изменение области безопасности, то есть злоумышленник выходит за пределы своего компонента и получает контроль над смежными ресурсами. Высокие значения по конфиденциальности, целостности и доступности означают, что последствия затрагивают все три свойства данных одновременно. Например, изменения в служебных таблицах способны затронуть работу других приложений, которые используют ту же базу.

Azure SQL Database представляет собой управляемый облачный сервис Microsoft. Иными словами, база работает на инфраструктуре провайдера, а клиент обращается к ней по сети. В таких базах компании хранят клиентские реестры, отчётность и персональные данные. По этой причине ошибка в коде одного приложения способна открыть доступ к значительному объёму сведений. Внедрение SQL-кода остаётся одним из самых распространённых классов уязвимостей веб-приложений, хотя способы защиты известны давно. Настройки сети и брандмауэра ограничивают круг подключений. Однако они не мешают некорректно построенному запросу, который проходит проверку подлинности на общих основаниях. Поэтому настройки доступа сами по себе проблему не решают. Управляемая модель снижает нагрузку на администраторов, но переносит часть ответственности на разработчиков приложений.

Сведений о применении этих уязвимостей в реальных атаках пока нет. В карточках указано, что данные об эксплойте уточняются. Вместе с тем после публикации технических подробностей промежуток до появления рабочих образцов кода обычно сокращается. Облачные базы привлекательны для злоумышленников, поскольку за одним подключением часто стоит большой массив корпоративных данных. К тому же повышение привилегий внутри сервиса позволяет закрепиться и развивать атаку дальше. Пока подтверждён только сам факт наличия уязвимостей, однако это не снижает требований к защите. Владельцам приложений стоит учитывать, что проверка со стороны провайдера не заменяет проверку собственного кода.

Исправления Microsoft внесла на стороне сервиса. Следовательно, устанавливать патч локально клиентам не нужно, поскольку облачный провайдер обновил платформу централизованно. Microsoft опубликовала рекомендации в справочнике обновлений по идентификаторам CVE-2026-68789 и CVE-2026-68782. Помимо этого, организациям стоит проверить собственный код приложений. Надёжнее всего работают параметризованные запросы, когда данные передаются отдельно от текста команды. Полезно также ограничить права учётных записей, с которых приложение обращается к базе, включить журналирование запросов и настроить фильтрацию на уровне межсетевого экрана веб-приложений. Аудит помогает заметить попытки эксплуатации на ранней стадии. Регулярная проверка кода приносит больше пользы, чем разовая установка обновлений.

Ошибки такого рода появляются в коде приложений, а не в самой платформе. Поэтому облачный провайдер закрывает уязвимость централизованно, тогда как ответственность за корректную обработку входных данных остаётся на разработчиках. Похожие сообщения о внедрении SQL-кода в облачных сервисах выходят регулярно. Практика показывает, что этот класс ошибок возвращается вместе с ростом числа внутренних сервисов и обменов между системами. Значит, строгие права доступа, проверка входящих данных и мониторинг запросов остаются основой защиты облачных баз. Разработчикам стоит воспринимать такие сообщения как повод пересмотреть собственные обработчики запросов, а не только как формальное уведомление об устранении проблемы.

Детали уязвимостей

Ссылки