Raul Garcia's blog : General Security

Disaster Recovery: What to do when the SA account password is lost in SQL Server 2005

raulga — Fri, 13 Jul 2007 08:19:00 GMT

You may have faced the issue of losing the SQL Server SA password. Perhaps you followed the security best-practice of removing the builtin\Administrators from the sysadmin server role, and no one you can find is in the sysadmin role. At this point you may think that your only options are to reinstall SQL Server and attach the databases, or to directly access the master database files, which may potentially damage the data.

SQL Server 2005 provides a better disaster recovery option for this scenario that is non-intrusive for master DB and that will help you preserve any objects and data stored in master DB (such as logins, certificates, Service Master Key, etc.) intact. Members of the Windows Administrators group now have access to SQL Server when SQL Server is in started in single-user mode, also known as “maintenance mode “.

Using the single-user mode, SQL Server 2005 prevents a Windows Administrator to abuse this privilege to act on behalf of the sysadmin without being noticed. This allows Windows Administrator accounts to perform certain maintenance tasks, such as installing patches.

In order to start SQL Server in single-user mode, you can add the parameter “-m” at the command line. You can also use the SQL Server Configuration Manager tool, which provides proper controls for the file access and other privileges. To use the Configuration Manager tool to recover your system, use the following steps:

1. Open the Configuration Manager tool from the "SQL Server 2005| Configuration" menu

2. Stop the SQL Server Instance you need to recover

3. Navigate to the “Advanced” tab, and in the Properties text box add “;–m” to the end of the list in the “Startup parameters” option

4. Click the “OK” button and restart the SQL Server Instance

NOTE: make sure there is no space between “;” and “-m”, the registry parameter parser is sensitive to such typos. You should see an entry in the SQL Server ERRORLOG file that says “SQL Server started in single-user mode.”

5. After the SQL Server Instance starts in single-user mode, the Windows Administrator account is able to connect to SQL Server using the sqlcmd utility using Windows authentication. You can use Transact-SQL commands such as "sp_addsrvrolemember" to add an existing login (or a newly created one) to the sysadmin server role.

The following example adds the account "Buck" in the "CONTOSO" domain to the SQL Server "sysadmin" role:

EXEC sp_addsrvrolemember 'CONTOSO\Buck', 'sysadmin';

6. Once the sysadmin access has been recovered, remove the “;-m” from the startup parameters using the Configuration Manager and restart the SQL Server Instance

Important Security Notes:

This process should only be used for disaster recovery when no other method to access the system with a privileged (i.e. sysadmin or equivalent) is available.

This process allows a Windows Administrator account to override their privileges within SQL Server. It requires explicit and intrusive actions that can be monitored and detected, including:

· Stop SQL Server and restart it in single use mode

· Connecting to SQL Server using Windows credentials

Special thanks to Buck Woody (http://blogs.msdn.com/buckwoody/) for his help in writing this article.

Dynamic SQL and digital signatures in SQL Server 2005

raulga — Wed, 09 May 2007 21:42:00 GMT

As I already mentioned, dynamic SQL is a quite powerful, but also quite dangerous. In SQL Server 2005 we introduced a new feature that is also quite powerful and when used properly can be quite useful; but it is important to learn and understand any such feature in order to use it properly. In this small article I will describe a little bit more about the interaction between these two features.

First, I will describe briefly digitally signing modules in SLQ Server 2005, but this explanation will not be thorough, so I strongly recommend reading the references I include at the end of the article to learn more about this subject. After that I will explain how digital signatures affect dynamic SQL, what are the pitfalls you should try to avoid.

Digitally signing modules

Hopefully you are familiar with the concept of digital signatures. In SQL server 2005 we introduced digital signatures for modules, the concept per se is not far from the one you may be familiar with: have a piece of data (in this case I will talk about a T-SQL module) and use a digital certificate and its private key to create a signature; this signature and its relationship with the certificate can be used to a) verify that the original piece of data has not been modified since it was signed and b) that the data was signed by the owner of the give certificate.

Before SQL server 2005 there were very few reliable mechanisms to verify that the code issued by any ISV was not tampered. While typically not a problem for the consumer of the module as sysadmins and DBOs typically have good control (based on permissions and roles) on who can write executable modules (SPs, UDFs, etc.), ISVs have sometimes difficulties validating any unsupported modifications to their applications.

In SQL Server 2005, it is possible for ISVs to deliver digitally signed modules to their customers without granting any additional permissions or privileges based on the signature itself. This may allow them to help in support scenarios where customers (either by mistake or as an explicit act from a rogue employee) modified a module and their application is in an unsupported state. For example:

CREATE CERTIFICATE [cert_demo01]

WITH SUBJECT = 'Cert demo - simple siganture'

CREATE PROC [sp_demo01]

PRINT 'hello world'

ADD SIGNATURE TO [sp_demo01] BY CERTIFICATE [cert_demo01]

-- Let's see the signature

declare @thumb varbinary(32)

select @thumb = thumbprint from sys.certificates where name = 'cert_demo01'

select object_name(major_id) as 'object_name',

crypt_property as signature

from sys.crypt_properties where thumbprint = @thumb

-- Now alter the module to verify that the signature is gone

ALTER PROC [sp_demo01]

PRINT 'hello world again'

-- Let's see the signatures again... should be empty

declare @thumb varbinary(32)

select @thumb = thumbprint from sys.certificates where name = 'cert_demo01'

select object_name(major_id) as 'object_name',

crypt_property as signature

from sys.crypt_properties where thumbprint = @thumb

Another common issue DB administrators may face is the requirement to allow users o access some of the resources (such as tables) only via limited modules (i.e. users who should be able to execute an application, should not be able to access the tables directly). In SQL Server 2000, the common mechanism to achieve this was ownership chaining (OC), but OC has a lot of limitations because of its own nature (limited to DML, permissions are completely bypassed, security considerations for allowing cross-DB OC, etc.).

In SQL Server 2005, using digital signatures can be used to modify the execution context and add a user (mapped from the certificate) as a secondary identity that will affect the permission checks for the duration of the module (without bleeding to a subsequent module). Another way to explain this usage of signatures is to “extend permissions via signature” or “granting permission to the module”. In the following example I have some additional explanations in the comments:

CREATE CERTIFICATE [cert_demo02] WITH SUBJECT = 'Cert demo - signature as secondary identity'

-- Create a schema to store all resources, and a loginless user to be the schema owner

CREATE USER [usr_resources_owner] WITHOUT LOGIN

CREATE SCHEMA [sch_resources] AUTHORIZATION [usr_resources_owner]

-- Create a schema to store all modules, and a loginless user to be the schema owner

-- this will break Ownership chaining

CREATE USER [usr_module_owner] WITHOUT LOGIN

CREATE SCHEMA [sch_modules] AUTHORIZATION [usr_module_owner]

-- mCreate a simple table

CREATE TABLE [sch_resources].[t_Demo02]( data nvarchar(100) )

-- and a module to access it

CREATE PROC [sch_modules].[sp_demo02]

SELECT * FROM sys.user_token ORDER BY usage, type, name

SELECT * FROM [sch_resources].[t_Demo02]

-- Add a siganture to the newly created module

ADD SIGNATURE TO [sch_modules].[sp_demo02] BY CERTIFICATE [cert_demo02]

-- Create a user for our signing cert, but no permissions granted yet

CREATE USER [usr_cert_demo02] FOR CERTIFICATE [cert_demo02]

-- Now let's create a low-privielged user to test our module

CREATE USER [usr_lowpriv] WITHOUT LOGIN

GRANT EXECUTE ON [sch_modules].[sp_demo02] TO [usr_lowpriv]

-- Let's see what happens when the low priv user executes the module:

EXECUTE AS USER = 'usr_lowpriv'

EXEC [sch_modules].[sp_demo02]

-- What happened?

-- We can see that the user token during the module execution is different than

-- the token outside the call (below).

-- The signature is affecting the execution context based on the module siganture

-- and any permissions granted to the signing certificate will be added to the token.

SELECT * FROM sys.user_token ORDER BY usage, type, name

REVERT

-- Grant permission to access the table to the certificate

GRANT SELECT ON [sch_resources].[t_Demo02] TO [usr_cert_demo02]

-- and run the script from above again

-- Let's see what happens when the low priv user executes the module:

EXECUTE AS USER = 'usr_lowpriv'

EXEC [sch_modules].[sp_demo02]

REVERT

-- Now, it is impornat to notice that the siganture is added to the current token

-- not completetly replaced, and it is also importnat to notice that the permission checks

-- will still be evaluated based on this token (i.e. OC will bypass permission checks).

CREATE USER [usr_DeniedPrivs] WITHOUT LOGIN

-- Permission to execute the module, but not to access the table

DENY SELECT ON [sch_resources].[t_Demo02] TO [usr_DeniedPrivs]

GRANT EXECUTE ON [sch_modules].[sp_demo02] TO [usr_DeniedPrivs]

-- Should fail to select from table thanks to the DENY permission

EXECUTE AS USER = 'usr_DeniedPrivs'

EXEC [sch_modules].[sp_demo02]

REVERT

Digital signatures and dynamic SQL

Using the digital signature as a mechanism to extend permissions affects any operation on the body of the signed module, including dynamic SQL executed in it. What does it mean? It means that the signer should understand that the module to be signed will execute dynamic code that is also going to be signed. For example:

CREATE PROC [sch_modules].[sp_demo03] ( @Id int )

DECLARE @cmd nvarchar(max)

DECLARE @params nvarchar(max)

-- the follwoing code will be also afected by the siganture

SET @cmd = 'SELECT * FROM sys.user_token ORDER BY usage, type, name; SELECT * FROM [sch_resources].[t_Demo02] WHERE Id = @Id;'

SET @params = '@Id int'

EXEC sp_executesql @cmd, @params, @Id = @Id

-- Add a siganture to the newly created module

ADD SIGNATURE TO [sch_modules].[sp_demo03] BY CERTIFICATE [cert_demo02]

GRANT EXECUTE ON [sch_modules].[sp_demo03] TO [usr_lowpriv]

-- Let's see what happens when the low priv user executes the module:

EXECUTE AS USER = 'usr_lowpriv'

-- Will succeed

EXEC [sch_modules].[sp_demo03] 2

REVERT

This characteristic is a useful one, but it can also be dangerous in case of an arbitrary code execution or SQL injection. In the following example I will try to demonstrate these dangers in case of an injection.

-- The following module is subject to SQL injection

CREATE PROC [sch_modules].[sp_demo04] ( @Table_name sysname )

------------------------------------------------------------

-- WARNING: The following code is subject to SQL injection!!!

------------------------------------------------------------

DECLARE @cmd nvarchar(max)

-- the follwoing code will be also afected by the siganture

SET @cmd = 'SELECT * FROM sys.user_token ORDER BY usage, type, name; SELECT * FROM '

+ @table_name

EXEC ( @cmd )

-- Add a siganture to the newly created module

ADD SIGNATURE TO [sch_modules].[sp_demo04] BY CERTIFICATE [cert_demo02]

GRANT EXECUTE ON [sch_modules].[sp_demo04] TO [usr_lowpriv]

EXECUTE AS USER = 'usr_lowpriv'

-- Using the module as originally intented

EXEC [sch_modules].[sp_demo04] '[sch_resources].[t_Demo02]'

-- .. but now abusing the signature...

EXEC [sch_modules].[sp_demo04] '[sch_resources].[t_Demo02]; EXEC sp_addrolemember ''db_owner'', ''usr_lowpriv'';'

-- Notice that the attack failed thanks to the

-- limited permissions granted to the certificate.

-- This is one of the reasons why I always recommend

-- following the least privilege principle

REVERT

-- Now, what would happen if we would have granted

-- a much higher permission?

GRANT CONTROL TO [usr_cert_demo02]

EXECUTE AS USER = 'usr_lowpriv'

-- Your DB would be compromised!!!

EXEC [sch_modules].[sp_demo04] '[sch_resources].[t_Demo02]; SELECT * FROM fn_my_permissions( NULL, ''DATABASE''); print ''Insert your favorite attack here'''

REVERT

-- remove the extremely-high privilege from the cert

REVOKE CONTROL TO [usr_cert_demo02]

As you can see from the example, it is a good idea to follow the least-privilege principle when using signatures as a mechanism to extend the execution context.

Now, the natural question to follow: Why would SQL Server allow carrying the signature to dynamic SQL? The answer is not as simple, and I am sure there may be some people who won’t like it, but the truth is that SQL Server is a platform and digital signatures is a feature that, when used properly and responsibly, can be extremely useful and safe, and in case the application developer really don’t want to execute dynamic SQL with a signature, there is an alternative: Move the dynamic SQL to a non-signed module (the signature will not be carried to a different module). For example:

-- Based on demo04 and still carrying injectable dynamic SQL

CREATE PROC [sch_modules].[sp_demo05_dyn] ( @Table_name sysname )

------------------------------------------------------------

-- WARNING: The following code is subject to SQL injection!!!

------------------------------------------------------------

DECLARE @cmd nvarchar(max)

-- the follwoing code will be also afected by the siganture

SET @cmd = 'SELECT * FROM sys.user_token ORDER BY usage, type, name; SELECT * FROM ' + @table_name

EXEC ( @cmd )

CREATE PROC [sch_modules].[sp_demo05] ( @Table_name sysname )

SELECT * FROM sys.user_token ORDER BY usage, type, name;

SELECT * FROM [sch_resources].[t_Demo02];

-- Call the module that will do dynamic SQL

-- Noticed that the signature will be lost

EXEC [sch_modules].[sp_demo05_dyn] @table_name

ADD SIGNATURE TO [sch_modules].[sp_demo05] BY CERTIFICATE [cert_demo02]

GRANT EXECUTE ON [sch_modules].[sp_demo05] TO [usr_lowpriv]

-- Let's see what happens when the low priv user executes the module:

EXECUTE AS USER = 'usr_lowpriv'

-- The signature is not carried to the 2nd module as we intended

EXEC [sch_modules].[sp_demo05] '[sch_resources].[t_Demo02];'

REVERT

Conclusions

Digital signatures in SQL Server 2005 are a quite powerful tool, but as any such tool, it has to be used with care to avoid unnecessary risks and potential damage. When using digital signatures remember to be careful on what you are signing, and be extra careful when signing a module that includes dynamic SQL as it will be affected by the signature. Don’t sign unnecessary code, and keep the escalated (signed) code to a minimum.

I also strongly suggest following the least-privilege principle when using signatures. Grant the minimum permission necessary to the certificate, and if necessary, split the code and sign different pieces of the code by different certificates.

Additional references

From BOL:

· Module Signing (http://msdn2.microsoft.com/en-us/library/ms345102.aspx)

· Understanding Execution Context (http://msdn2.microsoft.com/en-us/library/ms187096.aspx)

Laurentiu Cristofor’s blog:

· SQL Server 2005: procedure signing demo (http://blogs.msdn.com/lcris/archive/2005/06/15/429631.aspx)

· SQL Server 2005: An example for how to use counter signatures (http://blogs.msdn.com/lcris/archive/2006/10/19/sql-server-2005-an-example-for-how-to-use-counter-signatures.aspx)

I hope this article will be useful. Please let me know either here in the blog comments or in the SQL Server Security forum () if you have any feedback or comments on this topic.

Quick guide to DB users without logins in SQL Server 2005

raulga — Tue, 04 Jul 2006 01:25:00 GMT

SQL Server 2005 introduced a new SQL DB principal subtype that can be quite useful: a SQL user that is not mapped to any login. You may be asking yourself “Why is this feature interesting? after all SQL Server already had the ability to create SQL users”, well, to answer this question I would like to describe what this SQL principal subtype really is and what interesting properties it has.

For most operations, these subtype of users behave the same way as regular SQL users. They can own objects and schemas, can be granted/denied permissions, can be impersonated, etc.; The difference as the DDL describes is that these are DB-scoped principals not mapped to any login.

Because there is no mapping on these principals there is no need to prerequisite to generate a login, therefore a DBO can generate such principals at will, even without having access to create/guess logins.

CREATE DATABASE db_Demo

-- Create a login whose only purpose is to manage the db_Demo DB

-- no other permissions at server or crossDB scope are granted

CREATE LOGIN db_Demo_dbo WITH PASSWORD = 'My dem0 p@ssw0Rd'

ALTER AUTHORIZATION ON DATABASE::db_Demo TO db_Demo_dbo

USE db_Demo

-- Switch to db_Demo_dbo

EXECUTE AS LOGIN = 'db_Demo_dbo'

-- Let's create a user for my application, but do we have a

-- login named my_app_login?

CREATE USER my_app_login

-- As you can see, the access to sys.server_principals

-- is limited. Forcing this DBO to "guess" the name of

-- a login in order to create a user ...

SELECT name FROM sys.server_principals

-- ... and of course, creating a new arbitrary login is out of question

CREATE LOGIN my_app_login WITH PASSWORD = 'My dem0 p@ssw0Rd'

-- USER WITHOUT LOGIN on the other hand does not require

-- any additional permission

CREATE USER my_app_user WITHOUT LOGIN

-- Succeeded!, Let's take a quick look to the MD

-- As youcan see, except for the SID, this looks like an ordinary SQL user

SELECT * FROM sys.database_principals WHERE name = 'my_app_user'

REVERT

In many situations, especially for ISVs, it may be interesting to create a DB user to own a schema and objects used in any given application, or to mark modules with execute as and granting only permissions to these principals. For this scenario, creating a regular SQL user will require to create a login with a password, this may affect the ability to script the application as well as potentially polluting the server principals information; using a user without login for this purpose may be a very good alternative that requires no password (making it easier to script).

-- Create a schema for the application objects

-- making my_app_user the owner of all of them

CREATE SCHEMA my_app_schema AUTHORIZATION my_app_user

-- my_app_user is the owner (via schema ownership) of this table

CREATE TABLE my_app_schema.table1( data int )

-- create a demo table that is required by the app,

-- but my_app_user is not the owner

CREATE TABLE dbo.table2( data int )

-- GRANT access to the demo table to my_app_user

GRANT SELECT ON dbo.table2 TO my_app_user

-- Create a module that will always run as my_app_user

CREATE PROC my_app_schema.sp_demo

WITH EXECUTE AS 'my_app_user'

SELECT user_name()

SELECT * FROM my_app_schema.table1

SELECT * FROM dbo.table2

One of my favorite ways to use users without login is to test if my application works with minimum permissions. As there is no need to create logins, I don’t expose or pollute my server in any way, and it is usually easy to clean up these users on a dev environment.

-- Let's test the app

-- I will create a user w/out login to test

CREATE USER my_app_tester WITHOUT LOGIN

-- This is the minumum permission needed to run my app

GRANT EXECUTE ON my_app_schema.sp_demo TO my_app_tester

EXECUTE AS USER = 'my_app_tester'

-- Should succeed and run as my_app_user

EXEC my_app_schema.sp_demo

-- direct access should fail

SELECT * FROM my_app_schema.table1

SELECT * FROM dbo.table2

REVERT -- my_app_tester

Now here is a quite interesting question: If there is no login for this user, how is it possible to impersonate the user and what is the behavior outside the current database?

Impersonation is possible as these type of users are mapped to special type of SID. This SID belong to a special family that indicates that the information used to create the login token is not available in metadata, instead, the login information must be generated on the fly (pretty much a “public access only” generic token). Let’s take a look in detail to the tokens:

EXECUTE AS USER = 'my_app_tester'

-- Let's look at the token

SELECT principal_id, sid, name, type FROM sys.login_token

SELECT principal_id, sid, name, type FROM sys.user_token

REVERT -- my_app_tester

principal_id	sid	name	type
0	0x010500000000000903000000…	S-1-9-3-…	Sql login
2	0x02	public	Server role

Notice that the principal_id is 0. This is a special id and refers to a principal that is not in metadata, also take a look to the SID and name, the name is really a string representation of the SID.

User token:

principal_id	Sid	name	type
<#>	0x010500000000000903000000…	My_app_tester	SQL USER
0	Null	public	ROLE

The user token on the other hand looks exactly the same as anty other database principal token would look like.

Now the next question: Can I access other databases or server resources while impersonating these subtype of users?

Unlike approles, that are truly DB scoped (the login token for approles is a special case, and it is never trusted on the server) the user without login tokens are bound to the same trust relationship as any other user impersonation. You can use digital signatures (recommended) or trustworthy bit (personally, I don’t recommend using this option) to establish a trust relationship to access server resources.

-- Modify the app to access a server resource

-- in this case we will use VIEW ANY DEFINITION

ALTER PROC my_app_schema.sp_demo

WITH EXECUTE AS 'my_app_user'

SELECT user_name()

SELECT count(*) FROM sys.server_principals

SELECT principal_id, sid, name, type, usage FROM sys.login_token

SELECT principal_id, sid, name, type, usage FROM sys.user_token

-- Let's run the app as our test user

EXECUTE ('EXEC my_app_schema.sp_demo' ) AS USER = 'my_app_tester'

-- No surprises so far, now let's grant VIEW ANY DEFINITION to public

-- we have to revert to sysadmin for this one!

REVERT -- db_Demo_dbo

use master

GRANT VIEW ANY DEFINITION TO public

-- Let's see how many logins we have, in my case it's 35

SELECT count(*) FROM sys.server_principals

-- Let's go back to the demo DB and test the app again

-- Let's run the app as our test user

USE db_Demo

EXECUTE ('EXEC my_app_schema.sp_demo' ) AS USER = 'my_app_tester'

-- What happened?! This time we only got 10 logins back

-- As you can see in teh login token info, the login token is not trusted (deny only)!

-- Let's sign the module and establish the proper trust relationship

CREATE CERTIFICATE my_app_cert ENCRYPTION BY PASSWORD = 'My c3r+ p@zzw0Rd' WITH SUBJECT = 'My app signing cert'

ADD SIGNATURE TO my_app_schema.sp_demo BY CERTIFICATE my_app_cert WITH PASSWORD = 'My c3r+ p@zzw0Rd'

-- Backup the cert and it's PVK and remove it from teh DB

BACKUP CERTIFICATE my_app_cert TO FILE = 'my_app_cert.cer'

WITH PRIVATE KEY( FILE = 'my_app_cert.pvk', ENCRYPTION BY PASSWORD = 'My c3r+ p@zzw0Rd', DECRYPTION BY PASSWORD = 'My c3r+ p@zzw0Rd' )

ALTER CERTIFICATE my_app_cert REMOVE PRIVATE KEY

-- Now go to master and create the cert, a login map to it and grant the appropiate permission

USE master

CREATE CERTIFICATE my_app_cert FROM FILE = 'my_app_cert.cer'

CREATE LOGIN my_app_cert FROM CERTIFICATE my_app_cert

GRANT AUTHENTICATE SERVER TO my_app_cert

-- Now that the cert is vouching for the context, let's try again

USE db_Demo

EXECUTE ('EXEC my_app_schema.sp_demo' ) AS USER = 'my_app_tester'

-- Success!!!

-- Notice that in the login token the certificate will work as both a

-- secondary identity and as authenticator

-- For this demo, we are only using it as authenticator.

These are just a few examples on how this new type of principal can be used along with other features in SQL Server 2005 based on the ways I typically use them, but I am sure you will find other new interesting way to take advantage of this feature.

I hope this article has been helpful.

Link to Laurentiu's blog

raulga — Thu, 04 May 2006 07:25:00 GMT

I am including a link to Laurentiu Cristofor's blog: http://blogs.msdn.com/lcris. Laurentiu is one of the most valuable contributors in the SQL Security forums, and his articles and demos are great resources for anyone interested in SQL Server security

I would also like to add a link for a blog that unfortunately has been discontinued, but has interesting articles: http://blogs.msdn.com/yukondoit/.