Cómo controlar la administración de la cuenta sa (System Administrator) de SQL Server 2000
Muchas veces suele escribirse y propagarse a través de internet o por otros lados verdades a media caña bien documentadas que apuntan a ser la ley para el mundo o para muchos. Particularmente soy bastante desconfiado con casi todo el mundo, siempre trato de probar lo dicho o leído, creo poco si me cuentan que en la experiencia esto es así o en algún escenario tal o cual feature es de utilidad o se comporta anormalmente. Siempre deseo experimentarlo y comprobarlo por mi mismo, y no me contento con que me lo cuenten o con que en la documentación esté dictaminado de tal manera, todo lo documentado son cosas que debo verificar. Bien se me viene a recordar algo que leí en alguna parte:
"In theory there is no difference between theory and practice. But, in practice, there is." (Jan L.A. van de Snepscheut)
Hoy día es uno de esos tantos días que decido compartir una verdad a media caña o mentira existente en SQL Server 2000 y bien documentada, uso el término “bien” para “justificar” lo que siempre he escuchado a ciertos ponentes predicar en algunas charlas y eventos hace ya tantísimos años. Debo entender que para todos aquel que conociere algo de SQL Server es conciente de que todas las versiones y ediciones de SQL Server han dado parto a la famosa cuenta sa (system Administrator), sí, aquella cuenta heredada de sybase y que Microsoft ha empadrinado como su hijo intocable.
Bien, siempre se ha dicho que hasta SQL Server 2000 no podíamos deshacernos de esta cuenta, Microsoft siempre recomendó y sigue recomendando no usar esta cuenta y protegerlo con alguna contraseña muy compleja, pues no queda otra opción ya que según documentación y más gente esta cuenta no puede eliminarse o modificarse. Mismo Microsoft en su documentación de SQL Server 2000 (actualizado al SP3) nos dice que el privilegio sysadmin de la cuenta sa no puede cambiarse, esto para muchos ha sido un mandamiento, a las pruebas me remito: http://msdn.microsoft.com/en-us/library/aa905197(SQL.80).aspx
System administrator (sa) is a special login provided for backward compatibility. By default, it is assigned to the sysadmin fixed server role and cannot be changed. Although sa is a built-in administrator login, do not use it routinely. Instead, make system administrators members of the sysadmin fixed server role, and have them log on using their own logins. Use sa only when there is no other way to log in to an instance of Microsoft® SQL Server™ (for example, when other system administrators are unavailable or have forgotten their passwords).
En resumen, se ha dicho hasta SQL Server 2000 que la cuenta sa no puede cambiarse de nombre ni eliminarse y mucho menos crearse una cuenta con este mismo nombre dándole el titulo de cuenta intocable y no modificable, aspecto que es totalmente falso, y esto es justamente lo que deseo compartir y demostrar en este post, …pero antes quiero aclarar que no lo hago con fines anti Microsoft ni con el ánimo de fastidiar a alguien, el único fin es aportar con fines profesionales evitando interpretaciones parciales, considerando importante y crítico todo aspecto relacionado a seguridad lo cual debe saberse para reducir la superficie de ataque en los pocos o muchos servidores en SQL Server 2000 que puedan aún seguir vivos a lo largo y ancho del planeta… y si hay algún pingüino por aquí buscando algún motivo para fastidiar, es mejor que se abstenga con sus comentarios.
Toda la demostración debe comprobarlo usted sobre un servidor de base de datos en SQL Server 2000 con Service Pack 3a. Una de las buenas prácticas de seguridad que todo DBA desea aplicar en SQL Server 2000 es eliminar la cuenta sa, o tal vez mantenerla pero quitándole el privilegio de sysadmin con fines de auditoria para saber quienes y desde donde existen usuarios que anhelan entrar al servidor con dicha cuenta, pero siempre la meta final será controlar la administración de esta cuenta, lo cual puede realizarse si nos echamos a analizar un poquito cómo se maneja la seguridad de esta cuenta. Lo primero que debemos saber es que se esconde en la base de datos master, pero dentro del archivo como tal, es decir cual es el código existente que valida restricciones para esta cuenta y en base a que parámetros. Que les parece si detenemos el servicio del motor de base de datos y nos echamos a darle un vistazo al archivo mdf de la base de datos master, y encontraremos entre tanto código lo siguiente:
-- CANNOT CHANGE SA ROLES --
if @loginame = 'sa'
begin
raiserror(15405, -1 ,-1, @loginame)
return (1)
end
Con esto, usted puede darse cuenta que la cosa es sencilla. Basta que cambie el nombre a la cuenta sa para que pueda quitarle el privilegio de sysadmin. Si seguimos más abajo, veremos que validación de eliminación de cuenta se realiza mediante el sid, si el sid es igual a 0x01 no te dejará eliminarla. Así que para conseguir eliminar la cuenta sa, hay que cambiarle el valor del sid y adicionalmente el nombre de la cuenta.
Para conseguir estos cambios en SQL Server 2000 podemos jugar con las tablas del sistema, pero antes debemos preparar el terreno:
sp_configure 'allow updates', 1
go
reconfigure with override
go
Cuando vayamos a modificar esta cuenta SQL Server 2000 no nos dejará:
sp_dropsrvrolemember sa,'sysadmin'
Server: Msg 15405, Level 11, State 1, Procedure sp_dropsrvrolemember, Line 40
Cannot use the reserved user or role name 'sa'.
Lo mismo sucederá cuando intentemos eliminarla:
sp_droplogin sa
Server: Msg 15405, Level 11, State 1, Procedure sp_droplogin, Line 39
Cannot use the reserved user or role name 'sa'.
Pero como nosotros ya nos autohabilitamos para modificar las tablas del sistema podemos pasar a la acción, pero antes revisemos nuestro target:
select * from sysxlogins where name='sa'
Veremos que la cuenta sa tiene como sid igual a 0x01:
srvid sid xstatus xdate1 xdate2 name password dbid language isrpcinmap ishqoutmap selfoutmap
------ ------ ------- ------------------------ ----------------------- - ------- --------------- ----- --------- ---------- ------------------ -------------
NULL 0x01 18 2000-08-06 01:27:52.687 2009-04-27 23:55:41.670 sa 0x01006E449... 1 NULL 0 0 0
(1 row(s) affected)
Ahora, si deseamos quitarle el privilegio de sysadmin debemos primero cambiarle de nombre a sa2 (puede ser cualquier otro nombre)
update sysxlogins set name='sa2' where name='sa'
Luego ejecutamos lo siguiente:
sp_dropsrvrolemember sa2,'sysadmin'
go
Con resultado que nos indica éxito total, lo hemos conseguido:
'sa2' dropped from role 'sysadmin'.
Tal vez lo que usted desee ahora es eliminar esta cuenta, para esto, tiene modificar un valor más que viene a ser el sid de la cuenta:
update sysxlogins set sid=0x02 where name='sa2'
Finalmente eliminamos la cuenta:
sp_droplogin 'sa2'
Sucede que ya eliminamos la cuenta sa, pero que pasa si necesitamos crear nuevamente la cuenta. Se nos ocurre lo siguiente:
sp_addlogin 'sa'
El mensaje obviamente es de un error, el nombre de cuenta sa es reservada, no podremos utilizarla.
Server: Msg 15405, Level 11, State 1, Procedure sp_addlogin, Line 49
Cannot use the reserved user or role name 'sa'.
…pero podemos realizar lo siguiente para crearla:
sp_addlogin 'sa2'
go
sp_addsrvrolemember sa2,'sysadmin'
go
Ahora le cambiamos de nombre a “sa”
update sysxlogins set name='sa' where name='sa2'
Si nos fijamos en el sid de esta cuenta veremos que es algo asi: 0x621D6A5D371EDA45A6502CBEFD45AD05… pero nosotros necesitamos que ésta sea igual a 0x01 pues es así como el sistema la válida para otros fines, claro suponiendo que quieres recuperar la misma cuenta que dropeaste, pero si éste no fuera el caso, no hay necesidad de que le cambies el sid.
update sysxlogins set sid=0x01 where name='sa'
Con todo lo anterior hemos conseguido controlar la administración de esta cuenta, la decisión la tiene usted, usted decide como administrar esta cuenta de acuerdo al entorno y las políticas de seguridad para su compañia. En SQL Server 2005 y 2008 ya no tenemos que realizar estas jugadas porque en estas nuevas versiones la administración de esta cuenta es común a cualquier otra cuenta de usuario.
Saludos,
PercyReyes,
Nota: (27/06/2009): Se cambió el título del post para evitar confusiones e interpretaciones erróneas en los lectores, debido a que no es exactamente una vulnerabilidad en SQL Server 2000. El fin es demostrar como controlar la administracion de la cuenta sa a pesar que la documentacion de Microsoft dice que no se puede, un recurso útil para todo DBA que desea deshacerse de dicha cuenta...