SQL Server, ideas y experiencias

Actualización de Seguridad para el SQL Server 2005 Service Pack 3 (KB970894)

por Jose Mariano Alvarez 15. octubre 2009

Se ha identificado un problema de seguridad en el SQL Server 2005 Service Pack 3 que podría permitir a un atacante comprometer su sistema y obtener el control sobre ella. Entre los problemas conocidos que resuelve esta el del Boletín de seguridad Microsoft MS09-062

Security Update for SQL Server 2005 Service Pack 3 (KB970894)

http://www.microsoft.com/downloads/details.aspx?familyid=e6f307c1-8b21-406e-9c6f-b1a3a1e9a98f&displaylang=en

IMPORTANTE: Se recomienda aplicar la actualización lo antes posible, previa verificación de las cuestiones relacionadas (compatibilidad, etc)

 

Tags: ,

Actualizaciones

Boletín de seguridad Microsoft MS09-062

por Jose Mariano Alvarez 15. octubre 2009

El boletín de seguridad Microsoft MS09-062 del 13 de Octubre del 2009, es en realidad una actualización donde se modifica la información correspondiente a esta vulnerabilidad. Esta vulnerabilidad podría permitir la ejecución remota de código si un usuario, por ejemplo visualiza, utilizando el software afectado por esta vulnerabilidad, una imagen desde un archivo especialmente diseñado para aprovecharla.

Entre los sistemas que podrían estar afectados se encuentra el SQL Server 2005 Service Pack 3 o actualizaciones anteriores, algunas herramientas de desarrollo y otros productos. Como siempre ocurre, podrían ser menos afectados los usuarios que tengan pocos derechos en el sistema respecto de los usuarios que cuenten con derechos de administrador del equipo.

La actualización de seguridad relacionada resuelve varias vulnerabilidades reportadas del Microsoft Windows GDI +.

El detalle se encuentra en el siguiente enlace:

Microsoft Security Bulletin MS09-062

Critical - Vulnerabilities in GDI+ Could Allow Remote Code Execution (957488)

http://www.microsoft.com/technet/security/bulletin/ms09-062.mspx

IMPORTANTE: Se recomienda aplicar la actualización lo antes posible, previa verificación de las cuestiones relacionadas (compatibilidad, etc)

Tags: ,

Actualizaciones

Cómo ejecutar xp_cmdshell con mínimos permisos

por Jose Mariano Alvarez 3. agosto 2009

El procedimiento almacenado xp_cmdshell es esencialmente un mecanismo para ejecutar llamadas en el sistema operativo utilizando el contexto de SQL Server (es decir, la cuenta de Windows utilizada para iniciar el servicio del SQL Server) o una cuenta proxy que puede ser configurada para ejecutar xp_cmdshell con diferentes credenciales. Si bien habilitar y utilizar este procedimiento almacenado no es una buena práctica, ciertas aplicaciones usan esta técnica y a veces puede ser necesario acceder a la línea de comandos del sistema operativo para ejecutar algún programa fuera del SQL Server. En estos casos tenemos que tener mucho cuidado en como habilitamos y damos permisos para que el usuario pueda acceder a los recursos del sistema operativo con mínimos permisos. En este artículo analizaremos algunos detalles y de cómo habilitarlo con menos permisos que los indicado en la ayuda.

El procedimiento almacenado xp_cmdshell

Para ejecutar un programa fuera del contexto del SQL Server se utiliza el procedimiento almacenado extendido xp_cmdshell, Con este procedimiento almacenado extendido podemos ejecutar cualquier proceso de línea de comandos, por lo que no solo se pueden ejecutar programas EXE sino que se puede ejecutar un archivo de lotes (BAT o CMD).

Debemos tener sumo cuidado en cómo se utiliza este procedimiento almacenado ya que si el contexto de ejecución tiene permisos de administrador local del equipo por ejemplo el programa o un código inyectado pueden agregar un usuario administrador del equipo (del WIndows) utilizando NET USER y NET GROUP.

En SQL Server 2000, por los riesgos de seguridad que implica y para limitar el acceso al xp_cmdshell , su uso está restringido por defecto o en forma predeterminada solo a los miembros de la función de servidor o rol sysadmin. Para extender los derechos a otros usuarios se puede utilizar el comando GRANT.

En SQL Server 2005 el uso de xp_cmdshell está desactivado por defecto como mecanismo de protección para minimizar los riesgos de seguridad de código no deseado en ejecución dentro o fuera de SQL Server de SQL Server. Por ello, si no se habilita la ejecución del xp_cmdshell ni siquiera los administradores del SQL Server (grupo de servidor sysadmin) podrán ejecutarlo.

Por ejemplo si ejecutamos como administradores:

exec xp_cmdshell 'dir c:\*.*'

El resultado es:

Msg 15281, Level 16, State 1, Procedure xp_cmdshell, Line 1

SQL Server blocked access to procedure 'sys.xp_cmdshell' of component 'xp_cmdshell' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'xp_cmdshell' by using sp_configure. For more information about enabling 'xp_cmdshell', see "Surface Area Configuration" in SQL Server Books Online.

 

Para poder ejecutar el procedimiento almacenado extendido xp_cmdshell debemos habilitarlo haciendo:

--Habilito la ejecucion del xp_cmdshell

EXEC sp_configure 'show advanced options', 1
GO

RECONFIGURE
GO

EXEC sp_configure 'xp_cmdshell', 1
GO

RECONFIGURE
GO

Ahora vemos que si volvemos a ejecutar el scrip T-SQL anterior como administrador del SQL Server vemos que nos responde cuando estamos autenticados como administradores. El proceso de Windows creado por xp_cmdshell dispone de los mismos derechos de seguridad que la cuenta de servicio de SQL Server la cual tenía los permisos adecuados en la raíz del disco.

 

Cuenta proxy para el xp_cmdshell

Cuando es llamada por un usuario que no pertenece al rol (función de servidor) sysadmin, el xp_cmdshell se conecta a Windows con el nombre de la cuenta y la contraseña almacenados en la credencial con el nombre ##xp_cmdshell_proxy_account## en lugar de usar la cuenta de servicio por lo que habrá que indicarla previamente o sino dará error.

Vamos a probar ahora con un login que solo tiene permisos mínimos

--Creamos el login 
CREATE LOGIN [Prueba]
WITH PASSWORD=N'<la contraseña del usuario>',
DEFAULT_DATABASE=[master],
CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO

Para crear la credencial de la cuenta de proxy hay que ejecutar sp_xp_cmdshell_proxy_account y como parámetros el nombre del usuario y la contraseña de Windows.

-- Asigno la proxy account
EXEC sp_xp_cmdshell_proxy_account
N'sqltotal\mariano',
N'<la contraseña del usuario>'

El resultado es:

Msg 15137, Level 16, State 1, Procedure sp_xp_cmdshell_proxy_account, Line 1

An error occurred during the execution of sp_xp_cmdshell_proxy_account. Possible reasons: the provided account was invalid or the '##xp_cmdshell_proxy_account##' credential could not be created. Error code: '5'.

Aquí nos encontramos con un nuevo problema si estamos usando Windows Vista como es mi caso. No podemos asignar esta contraseña por más que el usuario usado sea administrador del SQL Server debido al UAC. Por lo tanto debemos ejecutar este comando en una nueva instancia del SQL Server Management Studio como administrador usando la opción “RUN AS ADMINISTRATOR” (ejecutar como administrador).

Luego de asignar la cuanta proxy como administrador local y del SQL Server abrimos una nueva ventana con el usuario prueba y verificamos que pasa:

exec xp_cmdshell 'dir c:\*.*'

Y el resultado es:

Msg 229, Level 14, State 5, Procedure xp_cmdshell, Line 1

The EXECUTE permission was denied on the object 'xp_cmdshell', database 'mssqlsystemresource', schema 'sys'.

En este punto si revisamos la ayuda en el link siguiente podemos verificar que nos dice que se requiere el permiso CONTROL SERVER, para poder ejecutar xp_cmdshell el cual no es adecuado ya que posibilita tomar el control total del SQL Server.

xp_cmdshell en la ayuda del SQL Server

Por lo tanto vamos a crear el usuario dentro de la base de datos master relacionado con el login y asignar solo el permiso de ejecución del procedimiento almacenado:

-- Creo el usuario en la base de datos
-- master para el login anterior
USE [master]
GO

CREATE USER [Prueba] FOR LOGIN [Prueba]
GO

-- Asigno el permiso de ejecucion al usuario
use [master]
GO

GRANT EXECUTE ON [sys].[xp_cmdshell]
TO [Prueba]
GO

Si ahora probamos veremos que es posible ejecutar el procedimiento almacenado xp_cmdshell sin ser administrador sin asignar permisos de CONTROL SERVER.

Veamos qué pasa si tenemos asignado solo el permiso de ejecución del procedimiento almacenado pero no existe la credencial.

Como administradores eliminamos la cuenta proxy:

EXEC sp_xp_cmdshell_proxy_account null

Probamos la ejecucion del procediemiento almacenado nuevamente con el usuario prueba

exec xp_cmdshell 'dir c:\*.*'

El resultado es:

Msg 15153, Level 16, State 1, Procedure xp_cmdshell, Line 1

The xp_cmdshell proxy account information cannot be retrieved or is invalid. Verify that the '##xp_cmdshell_proxy_account##' credential exists and contains valid information. 

Conclusiones

  • No es recomendable utilizar el procedimiento almacenado xp_cmdshell.
  • Para poder ejecutarlo se requiere habilitar su ejecución en la configuración del SQL Server utilizando el procedimiento almacenado sp_configure.
  • Si somos administradores podemos ejecutar el procedimiento xp_cmdshell el cual utiliza la cuenta de servicio del SQL Server
  • Si no somos administradores utiliza la cuenta proxy que debe estar definida.
  • Si no somos administradores solo debemos tener permiso de ejecución en el procedimiento almacenado xp_cmdshell y no hace falta asignar el permiso CONTROL SERVER como dice la ayuda.

Tags: , ,

Artículos

Cómo permitir el uso del Profiler o la creación de Trazas sin tener derechos de administrador

por Jose Mariano Alvarez 31. julio 2009

La ejecución del SQL Server Profiler requiere al menos del permiso de servidor ALTER TRACE. Este es el mismo permiso que se requiere para poder ejecutar los procedimientos almacenados de T-SQL que se utilizan para crear las trazas.

Veamos un ejemplo.

Creamos un usuario con mínimos permisos :

USE [master]

GO

-- creamos el Login 

CREATE LOGIN [prueba] 

WITH PASSWORD=N'pruebaPass', 

DEFAULT_DATABASE=[master], 

CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

GO

Luego podemos verificar que no se puede acceder mediante el profiler:

ProfilerPrbPerm

Hacer click en la imagen para agrandarla.

Asignamos el permiso de servidor ALTER TRACE con lo cual le concedemos el permiso de hacer trazas y conectar el Profiler para realizar un seguimiento.

GRANT ALTER TRACE 

TO [Prueba]

GO

Luego nos conectamos desde el Profiler y verificamos que ahora si se puede conectar.

Entonces ejecutamos :

CREATE LOGIN [prueba2] 

WITH PASSWORD=N'pruebaPass', 

DEFAULT_DATABASE=[master], 

CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

GO

exec sp_help 'sys.indexes'

Como puede verse en la próxima imagen siguiente, el Profiler funciona y como seleccionamos el evento SQL:BatchStarting nos muestra las sentencias que ejecutamos.

CreateLoginEnProfiler

Hacer click en la imagen para agrandarla.

Consideraciones de seguridad importantes al asignar el permiso ALTER TRACE

Es importante ver que en el caso del CREATE LOGIN nos oculta los datos del usuario y la contraseña. Sin embargo nos muestra el parámetro del procedimiento almacenado sp_help.

Como los usuarios que tienen el permiso ALTER TRACE pueden ver las consultas capturadas, se debe tener cuidado ya que las mismas pueden contener datos confidenciales, como contraseñas que se pasan como parámetros en los procedimientos almacenados. El caso mas común es cuando se utilizan mecanismos propietarios de autenticación. Por lo tanto, es importante conceder estos permisos solo a los usuarios que tengan autorización para ver información confidencial.

Tags: , , , ,

Artículos

Actualizaciones acumulativas del SQL Server 2008 – 20 Julio 2009

por Jose Mariano Alvarez 22. julio 2009

Se han liberado las nuevas actualizaciones de Julio. Como son acumulativas, cada versión nueva contiene todas las revisiones anteriores.

Es muy recomendable probar las revisiones antes de implementarlas en un entorno de producción. Si fuera posible como regla general, siempre es recomendable que se espere al lanzamiento del próximo Service pack que las incluiría antes de instalarlas.

 

Paquete de actualización acumulativa 6 para SQL Server 2008

Build 10.00.1812 (cumulative update)

Esta actualización es para quienes no han instalado aun el Service pack 1.

El 20 de julio se ha liberado la actualización acumulativa que contiene las revisiones para los problemas del SQL Server 2008 que han sido corregidos desde el lanzamiento de SQL Server 2008. Pueden encontrar más información en:

Cumulative update package 6 for SQL Server 2008

 

Paquete de actualización acumulativa 3 para SQL Server 2008 Service Pack 1

Build 10.00.2723 (cumulative update)

El 20 de julio se ha liberado la actualización acumulativa 3 para el SQL Server 2008 Service Pack 1 que contiene las revisiones para los problemas del SQL Server 2008 que han sido corregidos desde el lanzamiento de SQL Server 2008 Service Pack 1. Pueden encontrar más información en:

Cumulative update package 3 for SQL Server 2008 Service Pack 1

Tags: , ,

Actualizaciones

Cómo validar un usuario con funciones de cifrado del SQL Server sin almacenar la contraseña en una tabla

por Jose Mariano Alvarez 6. julio 2009

Aunque usar mecanismos de autenticación propios no es lo más recomendable, podemos utilizar,  con cierta seguridad, las funciones de cifrado EncryptByPassPhrase y DecryptByPassPhrase incorporadas al T-SQL del SQL Server 2005 y SQL Server 2008 para implementar un mecanismo propio, que además no almacena ni siquiera la contraseña cifrada como mecanismo adicional de seguridad.

Para evitar que se pueda obtener la contraseña, vamos a utilizar un mecanismo que evita almacenarla y en su lugar vamos a utilizar un mecanismo de cifrado mediante clave simétrica que almacena, en su reemplazo, el usuario utilizando la contraseña ingresada por el usuario como frase de contraseña o clave de cifrado.  Esto prácticamente restringe los posible ataques a la prueba por fuerza bruta de la contraseña.

Se conoce a la frase de contraseña como una contraseña que incluye espacios. Dado los requerimientos de seguridad crecientes, que implican tener claves cada vez más complejas y grandes, la ventaja de usar una frase de contraseña es que es más fácil recordar una frase larga con significado que una cadena de caracteres larga. Las función EncryptByPassPhrase que vamos a usar para cifrar no comprueba la existencia de espacios en la frase de contraseña ni la complejidad de la contraseña, por lo que queda como responsabilidad del programador realizar esta comprobación.

Los parámetros de EncryptByPassPhrase son:

  • passphrase: Frase de contraseña a partir de la cual se genera una clave simétrica.
  • cleartext: Texto no cifrado que se va a cifrar.
  • add_authenticator: Indica si se cifrará un autenticador junto con el texto sin cifrar. 1 si se va a agregar un autenticador. int.
  • authenticator: Datos a partir de los cuales se obtiene un autenticador. sysname.

El resultado de la función es el dato cifrado el cual se obtiene como varbinary con un tamaño máximo de 8.000 bytes.

Este código crea una base de datos de ejemplo y una tabla que almacena los datos

use master
go

-- Creo una base de datos para la prueba
Create database Prueba
go
use Prueba
go

-- Creo una tabla de usuarios que no almacena 
-- la contraseña ni la contraseña cifrada
-- sino el usuario cifrado con la contraseña como 
-- clave de cifrado.
Create table dbo.Usuarios
(
    Usuario varchar(100) primary key,
    HashUsuario varbinary(8000)
)
go

Para agregar los datos del usuario usaremos el siguiente procedimiento almacenado que permite agregar al usuario con el correspondiente usuario cifrado para usar luego al validar las credenciales.

-- procedimiento para cifrar y guardar el usuario
Create procedure dbo.AgregarUsuario
    @Usuario varchar(100),
    @Contrasena varchar(100)
as 
Insert into Usuarios(Usuario,HashUsuario) 
values(
    @Usuario,
    EncryptByPassPhrase(@Contrasena ,@Usuario ,0)
)
GO

Se debe tener en cuenta que cada vez que se ejecuta la función EncryptByPassPhrase, aunque usemos los mismos parámetros, el resultado cifrado es diferente, por lo cual no se pueden comparar los resultados cifrados de dos ejecuciones y por lo tanto se debe utilizar la función de descifrado para validar.

La función de descifrado es DecryptByPassPhrase y los parámetros son:

  • passphrase: Frase de contraseña que se utilizará para generar la clave para el descifrado.
  • 'ciphertext':Es el texto cifrado que hay que descifrar. Es del tipo varbinary. El tamaño máximo es 8.000 bytes.
  • add_authenticator: Indica si se ha cifrado un autenticador junto con el texto simple. Es 1 si se ha utilizado un autenticador. int.
  • authenticator: Son los datos del autenticador. sysname.

El  Tipos de valor devueltos es varbinary con un tamaño máximo de 8.000 bytes. La función DecryptByPassPhrase  devuelve NULL si se utiliza la información de autenticador errónea o la frase de contraseña errónea.

Veamos el ejemplo para validar el usuario

-- Procediemiento para descifrar y validar
Create procedure dbo.ValidarUsuario
    @Usuario varchar(100),
    @Contrasena varchar(100)
as 
if (
    Select COUNT(*)
    from    Usuarios 
    where    Usuario = @Usuario
    and        cast(DECRYPTBYPASSPHRASE(@Contrasena,HashUsuario,0) as varchar(100)) = @Usuario
) > 0
    print 'Validado'
else
    print 'Error en credenciales'
go

Ya tenemos todo el código necesario vamos a probarlo con las siguientes sentencias:

Agregamos un usuario

-- Agrego un usuario de prueba
exec dbo.AgregarUsuario 'Mariano', 'PassW0rd';
go

Probamos con una contraseña válida y vemos que nos imprime el cartel de validado. Luego probamos con una contraseña errónea y vemos que nos imprime el cartel de credenciales erróneas.

-- Probamos con la clave correcta
exec dbo.ValidarUsuario 'Mariano', 'PassW0rd';
GO

-- Probamos con la clave incorrecta
exec dbo.ValidarUsuario 'Mariano', 'otra password';
go

Para eliminar todo usamos el siguiente código

-- Borramos todo
use master;
drop database Prueba;
go

Conclusión

Vemos que se puede validar las credenciales, mediante el usuario y la contraseña de una manera eficiente con la funciones de cifrado y descifrado del SQL Server sin almacenar siquiera la contraseña cifrada lo que aumente la seguridad notablemente en los casos que queremos usar un mecanismo propietario.

Tags: ,

Artículos

Auditando en SQL Server 2008 con SQL Server Audit

por Jose Mariano Alvarez 12. marzo 2009

SQL Server 2008 introduce “SQL Server Audit” una nueva característica importante que ofrece una verdadera solución de auditoría.

Si bien el SQL Trace puede ser utilizado para satisfacer muchas necesidades de auditoría, la nueva auditoría de SQL Server ofrece una serie de ventajas que pueden ayudar a los DBA a alcanzar más facilmente sus objetivos como por ejemplo el cumplimiento de los requisitos legales requeridos para respetar las normas de seguridad. Estas incluyen la habilidad de proporcionar el almacenamiento centralizado de los registros de auditoría, la integración con System Center y un mejor rendimiento entre otras.

Este documento proporciona una descripción completa de la nueva característica de auditoría introducidas en el SQL Server 2008, y una guía de uso y algunos ejemplos prácticos.

Pueden encontrar el documento en el siguiente link:

Auditing in SQL Server 2008

Tags: ,

Documentos

Powered by SQL Total Consulting


View Jose Mariano Alvarez's profile on LinkedIn

 Add to Technorati Favorites 

Calendar

<<  agosto 2017  >>
lumamijuvido
31123456
78910111213
14151617181920
21222324252627
28293031123
45678910

View posts in large calendar

Locations of visitors to this page

Widget Twitter not found.

Root element is missing.X


Valid XHTML 1.0 Transitional

Valid CSS!