Het ontbreken van cryptografische zout variant van sa voor SQL Server-aanmelding hash corrigeren


Symptomen


In Microsoft SQL Server 2005 en hoger meerdere exemplaren van SQL Server de dezelfde cryptografische zout gebruiken voor aanmelding bij de ingebouwde sa. Omdat het zout hetzelfde voor alle installaties is, dat bepaalde soorten brute aanvallen praktischer zijn als de aanvaller eerst toegang krijgt tot het gecodeerde wachtwoord geworden. Gecodeerde wachtwoorden zijn alleen beschikbaar voor beheerders van SQL Server.

Oorzaak


In SQL Server 2005 en hoger wordt de cryptografische zout met de aanmelding sa gegenereerd. Als CHECK_POLICY is ingeschakeld, wordt de cryptografische zout niet gegenereerd wanneer de gebruiker het wachtwoord wijzigt om in overeenstemming zijn met de wachtwoordgeschiedenis. CHECK_POLICY is standaard ingeschakeld voor SQL Server 2005. Wanneer de CHECK_POLICY is uitgeschakeld, de consistentie van zout is niet meer nodig voor aanmelding bij de sa en een nieuwe zout wordt opnieuw gegenereerd op de volgende keer wachtwoord veranderen.


Hoewel dit voor alle accounts geldt, moet de aanmeldingsaccount sa wordt gegenereerd tijdens het maken. Het zout wordt gemaakt tijdens het maken dezelfde en daarom wordt gehandhaafd tijdens een exemplaar van SQL Server setup.


Opmerking Dit probleem geldt ook voor de standaard-aanmeldingen die worden gebruikt door de functie voor beheer op basis van beleid voor SQL Server 2008, maar het risico wordt verminderd. Deze aanmeldingen zijn standaard uitgeschakeld.

Beperkende factoren

Zelfs als de cryptografische zout hetzelfde door aan meerdere installaties blijft, volstaat het niet om de hash van het wachtwoord in gevaar brengen. De kwaadwillende gebruiker zou misbruik wil maken van dit probleem, administratieve toegang hebben tot een exemplaar van SQL Server voor het verkrijgen van de hash van het wachtwoord hebben. Als de aanbevolen procedures zijn gevolgd, gewone gebruikers niet halen van de hash van het wachtwoord. Zij zou dus geen misbruik maken van het ontbreken van cryptografische zout variatie.

Oplossing


Informatie over het service pack voor SQL Server 2005

U lost dit probleem, het meest recente servicepack voor SQL Server 2005 te verkrijgen. Voor meer informatie klikt u op het volgende artikelnummer om het artikel in de Microsoft Knowledge Base weer te geven:
913089 het verkrijgen van het meest recente servicepack voor SQL Server 2005

Informatie over het service pack voor SQL Server 2008

U lost dit probleem, het meest recente servicepack voor SQL Server 2008 te verkrijgen. Voor meer informatie klikt u op het volgende artikelnummer om het artikel in de Microsoft Knowledge Base weer te geven:
968382 Het verkrijgen van het meest recente servicepack voor SQL Server 2008

Tijdelijke oplossing


Voor SQL Server 2005 Service Pack 2 of hoger, kunt u het volgende script om de cryptografische zout van de aanmeldingsaccount sa opnieuw uitvoeren. Het script wordt uitgevoerd, u moet zijn aangemeld met een account met machtigingen voor de controle of de account moet lid zijn van de serverrol sysadmin. U moet er rekening mee houden dat, nadat u de cryptografische zout opnieuw instelt, de wachtwoordgeschiedenis voor de sa-aanmelding wordt ook opnieuw worden ingesteld.
-- Work around for SQL Server 2005 SP2+--
-- Sets the password policy check off for [sa]
-- Replaces [sa] password with a random byte array
-- NOTE: This effectively replaces the sa password hash with
-- a random bag of bytes, including the salt,
-- and finally sets the password policy check on again
--
-- After resetting the salt,
-- it is necessary to set the sa password,
-- or if preferred, disable sa
--
CREATE PROC #sp_set_new_password_and_set_for_sa(@new_password sysname, @print_only int = null)
AS
DECLARE @reset_salt_pswdhash nvarchar(max)
DECLARE @random_data varbinary(24)
DECLARE @hexstring nvarchar(max)
DECLARE @i int
DECLARE @sa_name sysname;

SET @sa_name = suser_sname(0x01);
SET @random_data = convert(varbinary(16), newid()) + convert(varbinary(8), newid())
SET @hexstring = N'0123456789abcdef'
SET @reset_salt_pswdhash = N'0x0100'
SET @i = 1
WHILE @i <= 24
BEGIN
declare @tempint int
declare @firstint int
declare @secondint int

select @tempint = convert(int, substring(@random_data,@i,1))
select @firstint = floor(@tempint/16)
select @secondint = @tempint - (@firstint*16)

select @reset_salt_pswdhash = @reset_salt_pswdhash +
substring(@hexstring, @firstint+1, 1) +
substring(@hexstring, @secondint+1, 1)

set @i = @i+1
END

DECLARE @sql_cmd nvarchar(max)

SET @sql_cmd = N'ALTER LOGIN ' + quotename(@sa_name) + N' WITH CHECK_POLICY = OFF;
ALTER LOGIN ' + quotename(@sa_name) + N' WITH PASSWORD = ' + @reset_salt_pswdhash + N' HASHED;
ALTER LOGIN ' + quotename(@sa_name) + N' WITH CHECK_POLICY = ON;
ALTER LOGIN ' + quotename(@sa_name) + N' WITH PASSWORD = ' + quotename(@new_password, '''') + ';'

IF( @print_only is not null AND @print_only = 1 )
print @sql_cmd
ELSE
EXEC( @sql_cmd )
go

---------------------------------------------------------------------------------------
-- Usage example:
--
DECLARE @new_password sysname

-- Use tracing obfuscation in order to filter the new password from SQL traces
-- http://blogs.msdn.com/sqlsecurity/archive/2009/06/10/filtering-obfuscating-sensitive-text-in-sql-server.aspx
--
SELECT @new_password = CASE WHEN 1=1 THEN
-- TODO: replace password placeholder below with a strong password
--
##[MUST_CHANGE: replace this placehoder with a new password]##:
ELSE EncryptByPassphrase('','') END
EXEC #sp_set_new_password_and_set_for_sa @new_password
go

DROP PROC #sp_set_new_password_and_set_for_sa
go

Voor SQL Server 2008, kunt u het volgende script uitvoeren. Het script wordt uitgevoerd, u moet zijn aangemeld met een account met machtigingen voor de controle of de account moet lid zijn van de serverrol sysadmin.
-- Work around for SQL Server 2008--

------------------------------------------------------------------------
-- Set the password policy check off for [sa]
-- Reset the password
-- Set the password policy check on for [sa] once again
--
-- NOTE: The password history will be deleted
--
CREATE PROC #sp_set_new_password_and_set_for_sa(@new_password sysname, @print_only int = null)
AS
DECLARE @sql_cmd nvarchar(max);

DECLARE @sa_name sysname;

-- Get the current name for SID 0x01.
-- By default the name should be "sa", but the actual name may have been chnaged by the system administrator
--
SELECT @sa_name = suser_sname(0x01);


-- NOTE: This password will not be subject to password policy or complexity checks
-- if desired, this step can be replaced with a "throw away" password for
-- and set the real password after the check policy setting has been set
--
SELECT @sql_cmd = 'ALTER LOGIN ' + quotename(@sa_name) + ' WITH CHECK_POLICY = OFF;
ALTER LOGIN ' + quotename(@sa_name) + ' WITH PASSWORD = ' + quotename(@new_password, '''') + ';
ALTER LOGIN ' + quotename(@sa_name) + ' WITH CHECK_POLICY = ON;'

IF( @print_only is not null AND @print_only = 1 )
print @sql_cmd
ELSE
EXEC( @sql_cmd )
go

---------------------------------------------------------------------------------------
-- Usage example:
--
DECLARE @new_password sysname

-- Use tracing obfuscation in order to filter the new password from SQL traces
-- http://blogs.msdn.com/sqlsecurity/archive/2009/06/10/filtering-obfuscating-sensitive-text-in-sql-server.aspx
--
SELECT @new_password = CASE WHEN 1=1 THEN
-- TODO: replace password placeholder below with a strong password
--
##[MUST_CHANGE: replace this placehoder with a new password]##:
ELSE EncryptByPassphrase('','') END
EXEC #sp_set_new_password_and_set_for_sa @new_password
go

DROP PROC #sp_set_new_password_and_set_for_sa
go

In SQL Server 2008, kunnen de cryptografische zout voor de aanmeldingsnamen op beleid gebaseerd beheer kan worden hersteld met behulp van het volgende script. Het script wordt uitgevoerd, u moet zijn aangemeld met een account met machtigingen voor de controle of de account moet lid zijn van de serverrol sysadmin.
-------------------------------------------------------------------------- Set the password policy check off for the Policy principals
-- Reset the password
-- Set the password policy check on for them once again
--
-- NOTE:
-- These principals are not intended to establish connections to SQL Server
-- So this SP will also make sure they are disabled
--
CREATE PROC #sp_reset_password_and_disable(@principal_name sysname, @print_only int = null)
AS
DECLARE @random_password nvarchar(max)

SET @random_password = convert(nvarchar(max), newid()) + convert(nvarchar(max), newid())
DECLARE @sql_cmd nvarchar(max)

SET @sql_cmd = N'ALTER LOGIN ' + quotename(@principal_name) + N' WITH CHECK_POLICY = OFF;
ALTER LOGIN ' + quotename(@principal_name) + N' WITH PASSWORD = ''' + replace(@random_password, '''', '''''') + N''';
ALTER LOGIN ' + quotename(@principal_name) + N' WITH CHECK_POLICY = ON;
ALTER LOGIN ' + quotename(@principal_name) + N' DISABLE;'

IF( @print_only is not null AND @print_only = 1 )
print @sql_cmd
ELSE
EXEC( @sql_cmd )
go


EXEC #sp_reset_password_and_disable '##MS_PolicyEventProcessingLogin##';
EXEC #sp_reset_password_and_disable '##MS_PolicyTsqlExecutionLogin##';
go

SELECT name, password_hash, is_disabled FROM sys.sql_logins
go

Status


Microsoft heeft bevestigd dat dit probleem kan optreden in de Microsoft-producten die worden vermeld in de sectie 'Van toepassing op'.
Dit probleem werd voor het eerst verholpen in SQL Server 2005 Service Pack 4 voor SQL Server 2005.
Dit probleem werd voor het eerst verholpen in SQL Server 2008 Service Pack 2 voor SQL Server 2008.

Meer informatie


Microsoft Bedankt de volgende voor de samenwerking met ons om klanten te beschermen: