Управляемые базы данных MySQL в публичных облаках призваны снять с клиента заботы об инфраструктуре - обновлениях, резервном копировании и сетевой сегментации. Провайдер берёт на себя "железо" и платформу, а заказчик отвечает за аутентификацию и контроль доступа. Такое разделение обязанностей работает, пока обе стороны соблюдают свою часть. Однако практический эксперимент, проведённый Varonis Threat Labs, показал, что при типовых ошибках конфигурации промежуток между развёртыванием инстанса и его компрометацией измеряется минутами.
Описание
Исследователи решили проверить, как быстро злоумышленники обнаружат и взломают заведомо уязвимый экземпляр MySQL, развёрнутый в разных облачных провайдерах. Они настроили однотипные honeypot-серверы в Google Cloud Platform (CloudSQL), Amazon Web Services (RDS) и Microsoft Azure (MySQL Flexible Server). Для каждой инсталляции задали слабый пароль root ("password") и открытый доступ с любого IP-адреса (0.0.0.0/0). На GCP дополнительно включили логи доступа к данным и общие логи MySQL, а также разместили две фиктивные базы с имитацией реальных записей клиентов.
В течение восьми минут после запуска на GCP-инстанс начались атаки методом перебора паролей. Спустя несколько часов два независимых злоумышленника успешно вошли в систему, похитили тестовые таблицы и оставили записки с требованием выкупа в биткоинах. При этом аналогичные honeypot-серверы в AWS и Azure взломаны не были - автоматизированные сканеры либо не нашли их, либо встроенные механизмы защиты платформ заблокировали подбор. Эта разница, как показал эксперимент Varonis, объясняется отличиями в настройках безопасности по умолчанию между тремя облаками.
Первый атакующий начал с массированной brute-force атаки. После примерно 576 неудачных попыток он подобрал пароль и вошёл. Затем он сменил IP-адрес на адрес, связанный с VPN, и приступил к рекогносцировке. Сначала он перечислил все базы данных, таблицы и их структуру. После чего сериями извлекал данные (SELECT с флагом SQL_NO_CACHE), что характерно для массового копирования. Затем он удалил внешние ключи, стёр исходные таблицы и создал новую таблицу RECOVER_YOUR_DATA с требованием выкупа. Текст записки гласил: "Все ваши данные скопированы. Вы должны заплатить 0,0094 BTC на адрес bc1qd9r8c0t7x0dw748f8ft5wng2wjf9puh29ay5ku. В течение 48 часов ваши данные будут опубликованы и удалены". Были указаны контактный email и код базы для идентификации жертвы после оплаты.
Исследователи восстановили инстанс до исходного состояния, и всего через шесть часов второй атакующий тем же способом проник в базу. Он обнаружил первую записку, заблокировал её таблицу, изучил её содержимое и создал свою версию RECOVER_YOUR_DATA_info, заменив требование выкупа на собственное. Таким образом, два разных оператора программ-вымогателей атаковали одну и ту же открытую базу данных в течение одного дня.
С точки зрения индикаторов компрометации были зафиксированы IP-адреса, участвовавшие в атаках: 204.76.203[.]30 (источник brute-force), 85.11.167[.]218, 5.194.178[.]102, 196.251.100[.]205 (основной атакующий) и 5.255.126[.]29. Дополнительный анализ показал, что первый атакующий из второй волны ранее появлялся в других honeypot-кампаниях на немодифицированные PostgreSQL, MongoDB и скомпрометированные базы Postgres. Это подтверждает, что одни и те же группы работают с автоматизированными вымогательскими схемами, нацеленными на разные типы СУБД.
Масштаб проблемы оценили с помощью сервиса Censys: по всем трём провайдерам обнаружено 17 931 открытый MySQL-инстанс на GCP, 65 375 на AWS и 18 256 на Azure. Каждый из них доступен из публичного интернета и является потенциальной целью для аналогичных атак.
Техника выявления подобных атак включает несколько контрольных точек. Множественные неудачные логины с одного IP - в эксперименте их было 576, и любой анализатор должен сработать раньше. После успешного входа смена IP на VPN - стандартный приём для разделения трафика подбора и операционной деятельности. Аномалии во времени запросов: массовые SELECT * с флагом SQL_NO_CACHE, частые SHOW FIELDS, множественные DROP TABLE и SHOW TRIGGERS - вид активности, резко отличающийся от нормальной работы приложения. Характерная последовательность рекогносцировки: перечень баз, затем таблиц, затем полей, затем массовое извлечение - типичный почерк атакующего. Наконец, массовое чтение, а сразу после него удаление таблиц - прямая сигнатура программы-вымогателя для баз данных.
Все уязвимости, приведшие к инциденту в GCP, устранимы. Ключевые меры: отключение публичного IP-доступа и полный запрет диапазона 0.0.0.0/0 в правилах межсетевого экрана; использование сложных паролей и интеграция с облачными сервисами управления идентификацией (IAM на GCP и AWS, Microsoft Entra на Azure); обязательное включение аудита на уровне базы данных (флаги general_log и cloudsql_mysql_audit на GCP, плагин MARIADB_AUDIT_PLUGIN на AWS, параметр audit_log_enabled на Azure); настройка защиты от удаления и автоматических резервных копий с восстановлением на момент времени; применение организационных политик (GCP Custom Constraints, AWS Service Control Policies, Azure Policy) для блокировки создания публично доступных инстансов или отключения логирования.
Вывод эксперимента однозначен: облачные провайдеры берут на себя инфраструктурную безопасность, но аутентификация, контроль доступа и мониторинг остаются зоной ответственности клиента. Атакующие активно сканируют именно эти "щели", и в условиях, когда первый взлом происходит за восемь минут, рассчитывать на удачу не приходится.
Индикаторы компрометации
IPv4
- 196.251.100.205
- 204.76.203.30
- 5.194.178.102
- 5.255.126.29
- 85.11.167.218
BTC
- bc1qd9r8c0t7x0dw748f8ft5wng2wjf9puh29ay5ku
