sábado, 30 de enero de 2010

Referencias web: PASS

Otro sitio interesante para poder aprender sobre SQL Server es el de la Asociación Profesional para SQL Server (Professional Association fon SQL Server - PASS en sus siglas en inglés):

http://www.sqlpass.org/

Se trata de una asociación independiente y sin ánimo de lucro dedicada a la comunidad de usuarios de SQL Server, en teoría independiente de Microsoft. En su página se puede encontrar una gran cantidad de información (previo registro), que va desde artículos técnicos y manuales específicos sobre ciertas utilidades de SQL hasta documentación y pautas para prepararse para obtener los certificados oficiales de Microsoft.

El carácter de comunidad online queda bien plasmado en la organización que tienen en capítulos en función de la zona geográfica del usuario. Los usuarios se agrupan en función de su zona de procedencia (o de la zona en la que desarrollan sus tareas) y se promueven actividades de carácter social para potenciar las relaciones entre usuarios y así favorecer la implicación de los mismos con la comunidad, lo que redunda en un mayor feedback para la comunidad al aumentar el número de aportaciones así como el nivel de las mismas, ya que los usuarios alcanzan un nivel superior de manejo de las herramientas al aprender de forma más rápida de otros usuarios más experimentados.

Otra prueba más de su carácter de comunidad es que se encuentran totalmente integrados en redes sociales como Linkedin, Facebook o Twitter, donde tienen su correspondiente perfil.

Facilitan una extensa lista de blogs que tratan el tema de SQL Server desde infinidad de puntos de vista, lo que supone una inagotable fuente de opiniones de lo más variadas.

Por último, comentar el encuentro organizado por la asociación, el PASS Summit 2010, que tendrá lugar a finales de este año, entre el 8 y el 11 de Noviembre, en Seattle (EEUU), y en el que profesionales de todas partes del mundo participarán en conferencias y ponencias sobre SQL Server.

viernes, 29 de enero de 2010

Referencias web: La página del fabricante

A la hora de aprender cosas sobre SQL Server será siempre conveniente, por no decir indispensable, visitar la página de su fabricante, Microsoft, donde se puede obtener casi cualquier información de interés sobre el producto:

http://www.microsoft.com/sqlserver/2008/en/us/default.aspx

Allí se puede hallar información referente a todas las versiones que ha tenido SQL Server con sólo dedicar unos minutos a buscar y recorrer algunos enlaces, si bien lo más interesante será centrarse en la más reciente: la SQL Server 2008. Sobre ella se puede encontrar muchísima información con todo lujo de detalle, tanto acerca de sus características como de sus aplicaciones y usos, así como la posibilidad de comprar el producto, descargar una versión de prueba o descargar de forma gratuita la versión reducida del producto (SQL Server 2008 Express) para poder hacer pruebas sobre su capacidad y prestaciones con vistas a adquirir el producto en el futuro.

También se pueden encontrar vínculos a noticias sobre el producto, opiniones de consultores y desarrolladores, opiniones de usuarios particulares (tanto vinculados a empresas como freelance) y páginas relacionadas con el tema, algunas de las cuales se comentarán en el futuro.

La nota negativa, como casi siempre que se consulta la página del fabricante, es que consideran su producto el mejor y que sus fallos son insignificantes , o directamente no los mencionan y no son accesibles desde la propia página, a pesar de encontrarse en páginas que pertenecen al propio fabricante, sino que hay que llegar a ellos a través de otras páginas o buscadores que facilitan los enlaces. Una muestra clara de su “imparcialidad”, vinculada a que nos encontramos ante una página anuncio que tiene como objetivo vender el producto y deja en un segundo plano dar soporte a la tecnología. Esa es la primera impresión, seguramente la que se busca en posibles clientes, eso sí, sin dejar atrás que en ella subyace un árbol muy completo de información.

miércoles, 27 de enero de 2010

Precauciones en el proceso de instalación. Contramedida

El fabricante no pone a disposición de los usuarios ninguna actualización de seguridad relativa a esta vulnerabilidad, principalmente por dos motivos: una vez conocida es fácil subsanar el problema y, por otra parte, está catalogada como moderada y sólo afectaría a los instaladores dispuestos para determinadas aplicaciones, de forma que las nuevas versiones ya incluirán instaladores más adecuados. En estos nuevos instaladores, toda la información relativa a contraseñas que pueda recogerse, se va a cifrar adecuadamente con la suficiente robustez para no ser susceptible de ser de utilidad a un atacante.

Si aún así se utiliza el software afectado cabe tomar algunas medidas que podrían evitar llegar a esta situación de vulnerabilidad. Estas están referidas a modificar los privilegios de acceso a los archivos críticos y llevar una política de cambio de contraseñas correcta, de modo que cuando los usuarios reciben una contraseña inicial de acceso al sistema, la actualicen tras la primera utilización, además de realizar cambios periódicos.

Aunque no exista una actualización disponible para subsanar el fallo, como ya se ha dicho, el fabricante si pone a merced de sus usuarios una herramienta que permite borrar las contraseñas almacenadas en el sistema en todos aquellos directorios que son accesibles. Se trata de “Killpwd”, que actualmente se encuentra en su versión 3.0 y no ocupa más de 200 KB.

Su misión concreta es escanear de forma automática los archivos de instalación que se han descrito en el post anterior y borrar directamente las contraseñas que se hayan podido guardar en ellos. Está destinada de forma específica a su uso sobre esos archivos de instalación que se utilizan en las versiones apuntadas de SQL Server (7.0 y 2000). La descarga es gratuita y responde al código 263968-Fix en el apartado de descargas del fabricante.

También da la opción de hacer un escaneado más personal al usuario. Una vez desempaquetado (no es necesaria su instalación como tal) en el sistema podría acudirse a la consola y utilizar la siguiente sentencia para comprobar cualquier archivo “.ISS” que se encontrase en un determinado directorio identificado previamente por el usuario:

>killpwd –R –P “C:\Directorio_a_escanear” –T “*.iss”

Sería una opción más directa y concisa, pero lo mejor es ejecutarlo de forma genérica para evitar posibles olvidos, ya que el modo manual requiere un conocimiento mucho más profundo del funcionamiento del sistema.

Este es un claro ejemplo de una herramienta destinada a subsanar una vulnerabilidad, dado que dicha vulnerabilidad no es crítica y no hace falta llegar a utilizar un parche en forma de actualización que subsane los problemas planteados por el instalador. Para versiones muy posteriores no se plantean problemas ya que ya estarán libres del error, pero si existe (en este caso, ha existido) un periodo de tiempo crítico en donde el software afectado se utiliza en mayor medida y aún no están implantadas esas nuevas soluciones. Ese sería el periodo donde la diferencia entre la atención hacia vulnerabilidades del sistema o la falta de información pueden jugar un papel importante para la seguridad del sistema.

martes, 26 de enero de 2010

Vulnerabilidad en el proceso de instalación

Esta vulnerabilidad está catalogada como moderada por el fabricante, pero no deja de ser curiosa puesto que se refiere al posible acceso a las contraseñas almacenadas en el proceso de instalación en sus archivos de registro. Esto se hace así como medida para poder llevar a cabo a posteriori nuevas instalaciones (actualizaciones, nuevos módulos a añadir, etc.), de forma desatendida, sin tanta implicación para el usuario como la impuesta para el proceso inicial en el que se instala el “núcleo” de la aplicación.

Es conveniente apuntar que esta vulnerabilidad afecta a versiones pasadas, más concretamente a la 7.0 y a la 2000 de SQL Server y no a las que aparecieron después de SQL Server 2005. Esto se basa principalmente en el modo de guardar las contraseñas de cada versión. Mientras que en la versión 7.0 estas se almacenaban en texto plano, para la versión 2000 se comenzaron a cifrar, pero utilizando un cifrado muy débil. De este modo cualquiera que tenga acceso a los ficheros afectados podría hacerse con unas credenciales de acceso al sistema, y si se junta una mala práctica en cuanto a la política de renovación de contraseñas y se ha facilitado la contraseña de administrador en la instalación, un atacante podría tomar el control total del sistema. En otros casos podrían conseguirse ciertos privilegios teniendo en cuenta que para llegar a este punto el atacante debe tener primero acceso al sistema.

Algo que debe cumplirse para que se almacenen las contraseñas es que el proceso de instalación se haya realizado siguiendo los siguientes modelos:

- Cuando se instala SQL Server en “Mixed Mode”, en cuyo caso el administrador tendrá que introducir unas credenciales que le identifiquen más adelante.
- Tanto en el modo anterior como en el modo por defecto de instalación (“Authentication Mode”) se da la opción al administrador de crear durante la instalación cuentas para sus usuarios. Esta es una medida muy común hoy en día, ya que tras finalizar la instalación ya estarán creadas las cuentas que se necesitan inicialmente para el sistema, con la comodidad que supone ese “apoyo” desde el proceso de instalación. Si se facilita esta información acerca de los logins creados, el instalador la guardará.

Si no fuese así, no es necesario guardar las contraseñas y la aplicación estaría libre de esta vulnerabilidad. En caso de que sean almacenadas, podrán guardarse bien dentro del archivo de instalación “Setup.iss”, en el registro de la instalación, o bien en archivo “remsetup.ini” para algunas versiones. Estos archivos van a permanecer en el servidor tras completarse la instalación con el peligro que esto conlleva, ya que esos usuarios con acceso a los directorios del sistema (basta con tener privilegios de acceso al sistema para ir a los directorios) pueden substraer la información y utilizarla en su provecho.

La vulnerabilidad está recogida en el boletín MS02-035 y en la base de datos CVE parece que está siendo modificada debido a la petición de alguno de los revisores. Este es un claro ejemplo de fallo de previsión ligado a dotar a los usuarios de ciertas “comodidades” que en última instancia, y si no se tienen en cuenta todos los detalles de operación, pueden repercutir en la seguridad del sistema en mayor o menor medida. Modelos que den más agilidad a la actividad de los usuarios no deberían por ello sacrificar la seguridad, para lo que deben plantearse escenarios de escalabilidad en cuanto al desarrollo de las aplicaciones que cuiden al máximo los detalles relativos a la información comprometida que estas van a manejar.

lunes, 25 de enero de 2010

Contramedidas para los fallos al reservar memoria

Igual que se viene presentando para casos anteriores, el fabricante recomienda realizar la actualización de su software lo antes posible, de modo que los defectos que dan lugar a la vulnerabilidad sean subsanados y el sistema pueda funcionar con normalidad.

En este caso, y centrando la atención en los cambios que trae consigo la actualización, hay que considerar que lo que se pretende en esa actualización de seguridad es modificar el modo en el que SQL Server gestiona la reutilización de páginas en memoria, de modo que se destine más memoria para la función de conversión que maneja los datos. Así la función podrá validar los archivos que estén en el disco antes de que se carguen en memoria y a su vez podrá validar las sentencias enviadas por el usuario en la consulta. Con esto se evita que un posible atacante envíe sentencias mal formadas o fuerce a la memoria a reservar regiones no adecuadas para los datos que se están tratando.

Entre las medidas a tomar si no es posible realizar una actualización inmediata del sistema, se trata de incidir en impedir el acceso a los datos a posibles atacantes y en asegurar que la información se trata correctamente en memoria. Para ello se recomienda llevar a cabo las siguientes acciones:

- Activar la opción “Common Criteria Compliance”, que incluye protección para la información residual, permite ver estadísticas del login en el sistema a través de la vista de gestión dinámica “sys.dm_exec_sessions”, o priorizar ajustes de tablas con estado “denegado” a otros ajustes a nivel de columna. Para activar esta opción debe ejecutarse como administrador un pequeño script:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'common criteria compliance enabled', 1;
GO
RECONFIGURE
GO

- Anular el soporte para SMB y WebDAV que implementan los servidores SQL, de modo que se pueda prevenir el acceso a ficheros de forma remota.

Después de realizar los cambios propuestos en la configuración del sistema, se pide que este sea reiniciado para que tomen efecto.

Una vez se pueda instalar la actualización de seguridad deben deshacerse estos cambios para asegurar que el sistema funcione correctamente. Esto se hará volviendo a activar el soporte a los protocolos anulados y ejecutando el script de nuevo, pero cambiando el valor de la variable “common criteria compliance enabled” a '0'.

Esta vulnerabilidad, al igual que las vistas hasta este punto, ha de tratarse lo antes posible. Las actualizaciones disponibles según el software se recogen, para la última versión (2005), bajo el nombre SQLServer2005-KB94810X. Estas podrán descargarse desde los repositorios oficiales de Microsoft.

viernes, 22 de enero de 2010

Vulnerabilidad: Fallos al reservar memoria

Esta vulnerabilidad trata cuatro aspectos diferentes que pueden llegar a permitir que un atacante tome el control completo del sistema afectado, sobre las versiones desde la 7.0, hasta la 2005 pasando por la 2000 de SQL Server. En este caso sí que se reduce el abanico de aplicaciones de Microsoft con el problema, ya que estará relacionado con aspectos más cercanos al trabajo con una base de datos.

En cuanto a las debilidades del sistema, el primer aspecto está vinculado a la reutilización de páginas de memoria en los procesos de asignación que lleva a cabo la base de datos, el segundo a desbordamientos en el buffer debido a instrucciones SQL mal formadas, el tercero se basa en desbordamientos del buffer para determinadas sentencias de acceso a la base de datos y el último en el trato de archivos que están en local (y a los que se vincula un tamaño) que puede crear desbordamientos en el buffer. En este último caso, concretamente, ese tamaño se guarda en un entero de 32 bits que sirve para reservar a su vez un tamaño en el buffer de la pila que albergará el objeto cuando este se va a cargar en memoria, de modo que si se aumenta su valor no habrá espacio suficiente y creará una condición explotable por un atacante.

En los peores casos, como se ha dicho, el atacante puede ejecutar cierto código para tomar el control completo del sistema modificando los privilegios asignados. Otros efectos menos dañinos podría ser el simple acceso a la información almacenada en la base de datos, sin cambios en los privilegios que permitan otras operaciones que no sean la de lectura.

Los cuatro aspectos de la vulnerabilidad (identificada como MS08-040) se tratan como “importantes” por parte de Microsoft, debido a que afecta a sistemas delicados pero dentro de ese espectro más reducido. Tienen el estado de “Candidatas” en la base de datos que se publica en CVE.

Se ha visto en otras entradas que las vulnerabilidades están, aunque tratándose de forma más concreta, ligadas también con la inyección de código para explotar determinados agujeros de seguridad. Ahora ocurrirá lo mismo, de forma que en muchos casos los ataques se construyen basándose en esa técnica para poder llevar a cabo accesos al sistema. Además estos podrán llevarse a cabo aprovechando cuentas por defecto, como la que utiliza SQL Server 2005 (“Network Service”) para dar acceso a usuarios sin privilegios y que podría ser utilizada por cualquiera para realizar consultas en la base de datos. El atacante podría usar entonces el protocolo SMB (Server Message Block) o el estándar WebDav (que a través del protocolo HTTP permite realizar acciones de gestión de archivos en el sistema) para, una vez dentro, construir el ataque.

jueves, 21 de enero de 2010

Vulnerabilidad: GDI+ (II)

Las vulnerabilidades basadas en la interfaz suelen clasificarse como muy importantes o críticas por el hecho de que la interfaz gráfica que pueden utilizar las aplicaciones de una determinada compañía se construyen de modo similar y por lo tanto comparten muchas características en cuanto al trato de los datos, tipos de archivo o modelos de presentación entre otros. Esto se traduce en que si se descubre una vulnerabilidad sobre la interfaz gráfica de una de las aplicaciones, esta se propague a otros productos “hermanos” y por ello su peligrosidad aumente. Además, otro factor que contribuye a ese aumento es la facilidad para producir fallos en la interfaz, punto de contacto con el usuario, debidos a esa vulnerabilidad. Esos fallos se presentarán entonces ante situaciones más cotidianas (más frecuentes entonces), con las consecuencias para la seguridad que conlleva la mayor exposición del sistema.

La vulnerabilidad que se presenta aquí (MS08-052) es una ampliación de la que se presentó anteriormente y referida a aspectos similares de desbordamientos de algunos tipos de datos vinculados a la interfaz. También se clasifica como “Crítica” desde Microsoft y es candidata a presentarse en la lista CVE como entrada oficial.

Afecta a las versiones 2000 y 2005 de SQL Server y puede permitir la ejecución remota de código sobre todo dentro de escenarios en los que un usuario accede a una página Web donde se le presentan algunos tipos de imágenes cuidadosamente manipuladas para explotar la vulnerabilidad cuando este las trata con alguna de las aplicaciones afectadas. Este tipo de escenarios están creados para poder atacar a víctimas a las que previamente se ha manipulado para acceder a los recursos dañinos, utilizando alguna de las técnicas de las que han cobrado protagonismo hoy en día y tratan de hacer que los usuarios utilicen enlaces encubiertos con propósitos específicos.

Se plantean problemas de corrupción de memoria para tipos de archivos de imagen “.EMF” (Enhanced Windows Metafile), de invasión de buffer relacionado con algunas librerías dinámicas del estándar “VML”, al analizar archivos “.GIF” que puedan contener marcadores gráficos y etiquetas malformados, de desbordamiento de buffer para archivos de imagen “.WMF” o de desbordamiento de enteros relacionado con archivos “.BMP”.

Dichos problemas son, como se ha dicho antes, similares a los vistos para la interfaz gráfica en la vulnerabilidad anterior y por ello las contramedidas a tomar también son muy parecidas. Mientras no se pueda instalar la actualización que ha puesto a disposición de sus usuarios Microsoft, se deben tomar una serie de medidas relacionadas con algunas librerías dinámicas como “gdiplus.dll” o “vgx.dll”, que deben quitarse del registro temporalmente, y con algunos procedimientos relacionados con la interfaz que deben desactivarse. Por otro lado será necesario tener especial cuidado con los permisos con los que los usuarios trabajan con las aplicaciones afectadas para no maximizar los riesgos de un posible ataque. Como se ha visto, por tratarse de contramedidas similares, no se aludirán en adelante.

Con estas vulnerabilidades de la interfaz gráfica se ven algunos fallos vinculados a archivos de imágenes que distan un poco de los ataques relacionados con elementos de código que no forman objetos a diferente nivel, más relacionados con etiquetados y malformaciones en la estructura de las imágenes. Como es habitual cuando se trata de explotar vulnerabilidades resulta interesante el escenario planteado por Microsoft en el que los atacantes “obligan” al usuario a ejecutar imágenes, y más concretamente en la creación por parte de esos atacantes de esas imágenes "mal formadas" para conseguir su objetivo.

miércoles, 20 de enero de 2010

GDI+: contramedidas

El estado crítico al que lleva a las diferentes aplicaciones esta vulnerabilidad (MS09-062) hace que sea muy importante la instalación de la actualización que Microsoft pone a disposición de sus usuarios. Dicha actualización puede descargarse, además del catálogo en sí, del sitio web de actualizaciones “Windows Update”, teniendo en cuenta que si el gestor de actualizaciones de Windows está activado podrá descargar e instalar el paquete con el parche de forma semi-transparente para el usuario.

Hay que tener en cuenta que muchos de los procesos de actualización llevan consigo la necesidad de reiniciar el equipo con las consecuencias pertinentes, en este caso, al hablar de bases de datos, con el cese de servicio a los posibles usuarios durante un determinado periodo de tiempo. El aplicaciones críticas esto puede hacer que los administradores tengan que avisar a los usuarios de dicho cese, ya que repercutirá sobre su actividad. La mayoría de las veces se intentan aprovechar momentos de poca o nula utilización del sistema (si existen) para actualizar el sistema sin que los usuarios tengan conocimiento de ello ni el proceso afecte a su trabajo.

En este caso no se especifica si será necesario reiniciar el sistema, aunque se proporciona el código que devolverá la instalación al terminar, lo que hace ver que será preciso hacerlo pero intentando darle poca importancia o desviar la atención sobre el asunto.

Mientras no sea posible aplicar la llamada “actualización de seguridad” sería conveniente tomar una serie de medidas como las que se citan a continuación:

- Deshabilitar el procesamiento de meta-archivos

- Restringir el acceso a “gdiplus.dll”

- Desregistrar “vgx.dll”

- Evitar que IExplorer use el RSClientPrint

- Leer los correos electrónicos en texto plano

- Deshabilitar en IExplorer XAML Browser Applications

- Deshabilitar de forma parcial algunas aplicaciones .NET de confianza

- Evitar la apertura de archivos de Office desconocidos o de fuentes no fiables

Todas estas medidas buscan reducir el impacto de la vulnerabilidad reduciendo su interacción con otros componentes del sistema. Como ya se comentó para la actualización de seguridad, algunos de estos cambios requeriran reiniciar el sistema.

Una vez más, cuando sea posible actualizar el sistema, los cambios deben deshacerse para asegurar su completo funcionamiento. Esta vulnerabilidad explota muchas más alternativas concretas que la vista anteriormente referida al desbordamiento de la pila, recogiendo un abanico de ellas que afectan a un gran número de aplicaciones, de ahí que la importancia que se le da sea mayor y suba su nivel de criticidad.

martes, 19 de enero de 2010

Vulnerabilidad: Interfaz gráfica (GDI+)

Se trata de una vulnerabilidad que afecta a numerosas aplicaciones basadas en la interfaz gráfica de Microsoft Windows, partiendo de los propios sistemas operativos disponibles en el mercado desde la versión XP, hasta herramientas tan cotidianas como el explorador, pasando por herramientas críticas como SQL Server. Ya que con este programa se van a manejar grandes volúmenes de datos, resulta vital responder de forma inmediata para subsanar el fallo, de modo que las bases de datos gestionadas dejen de ser vulnerables lo antes posible. Es por ello que para la mayoría de aplicaciones de Microsoft de cierta importancia se ha catalogado como “Crítica”.

La vulnerabilidad se basa en fallos por desbordamientos de diferentes tipos según cómo hayan sido originados, estando la mayoría asociados al manejo de archivos de imágenes. Así, se distinguen una serie de acciones que pueden dar lugar a una ejecución indeseada: validaciones incorrectas dentro de procedimientos vinculados a la interfaz gráfica cuando se ejecutan archivos de imágenes “.WMF”, en la administración de la pila cuando se abre un archivo “.PNG” con la GDI+ por medio o cuando se calcula el tamaño del buffer para trabajar con una imagen de ese tipo, en la asignación del buffer que se asocia a la lectura de archivos “.TIFF”, cuando se tratan dentro de Office imágenes “.BMP” o en último término en la administración de los búferes al realizar llamadas de la API de .NET y la apertura de archivos de Office que incluyan formatos incorrectos.

Sobre la base de datos que aporta CVE se definen unas cuantas entradas relacionadas según las diferentes variantes vistas antes, que se muestran como “Candidatas”, lo que quiere decir que puede ser modificada más adelante y debe aún revisarse. No obstante, en la base de datos de Microsoft sí se le da la importancia que merece por afectar a un amplio abanico de sus aplicaciones.

La peligrosidad de la vulnerabilidad está estrechamente ligada a los efectos que se tratan en vulnerabilidades de desbordamiento de la pila, ya que de las acciones conflictivas tratadas, algunas tienen relación directa con ese problema y otras a otro tipo de desbordamientos como los de enteros, de múltiples enteros o de buffer en general. Otro de los problemas está vinculado a la incapacidad de algunas de las aplicaciones afectadas de manejar correctamente objetos mal formados, algo que debería revisarse en la labor de desarrollo y es más propio de errores de procedimiento asociados a la comprobación de objetos. De este modo un atacante que se aprovechase de esta vulnerabilidad podría llegar a ejecutar determinado código malicioso en la máquina o sistema atacado, siendo tanto más peligroso cuanto mayores resultasen los permisos de ejecución en el sistema del usuario que desemboca o propicia el ataque. A partir de esa ejecución no deseada podrían realizarse acciones como ver archivos, modificarlos o borrarlos, cambio de permisos o instalación de programas dependiendo de esos permisos de usuario que incluso llegasen a hacer que el atacante tomar el control total del sistema.

Si bien hay que recalcar que es una vulnerabilidad que no afecta solamente a SQL Server, mencionar cómo un sistema con esta aplicación instalada puede encontrarse completamente vulnerable a un ataque que se base en estos problemas de la interfaz, que comprometa determinadas bases de datos desprotegidas. Esta vulnerabilidad no afecta a la última versión de SQL Server pero sí a diferentes ediciones de las versiones 2005 y 2000.

lunes, 18 de enero de 2010

Desbordamiento en la pila: contramedidas

La medida principal que asegurará el correcto funcionamiento del sistema dentro de los parámetros de seguridad deseados, será realizar la correspondiente actualización que el fabricante pone a disposición del usuario una vez se ha identificado la vulnerabilidad y se ha logrado desarrollar una actualización. Si se ha detectado el problema pero aún no se dispone de una actualización, o bien si en ese momento no es posible aplicarla, conviene tomar una serie de medidas que aunque no subsanarán el daño, pueden reducir su peligrosidad o por lo menos las posibilidades de explotarlo.

Estas medidas tendrán que ver con cambios en las opciones de configuración, que básicamente tratan de reducir la funcionalidad asociada al procedimiento “sp_replwritetovarbin”. Para denegarles a los usuarios el acceso a este, se pueden realizar dos acciones:

- Ejecutar la siguiente secuencia T-SQL dentro de SQL Server Management Studio:

use master

deny execute on sp_replwritetovarbin to public

- Acudir al listado “Extended Stored Procedures” de la bases de datos y habiendo localizado el procedimiento, modificar los permisos que tiene asignados en el diálogo “Propiedades”. Esta última operación puede variar según la versión de SQL Server que se esté utilizando.

El hecho de deshabilitar este procedimiento sólo afectará a determinados usuarios que tengan habilitada la replicación transaccional con subscripciones para la actualización de tablas. Pequeñas variaciones de este modelo transaccional no tienen por qué tener problemas al llevar a cabo esta acción.

Una vez tomadas estas medidas, el siguiente paso natural sería actualizar el sistema cuando el fabricante ponga a disposición de los usuarios el correspondiente parche. Para ello se podrá acudir al “Microsoft Update Catalog” (sólo se podrá acceder si se utiliza Internet Explorer 6.0 o superior) y descargar la correspondiente actualización para la versión del software de la que disponga el usuario, utilizando por ejemplo el número del boletín de seguridad de Microsoft que ha publicado la vulnerabilidad (en este caso el MS09-004). Con ello se podrán ver todos aquellos parches disponibles para todo el software afectado.

Una vez descargada e instalada la actualización debe asegurarse el usuario que deshace las medidas tomadas para limitar la funcionalidad del procedimiento conflictivo, de modo que se asegure que se restablece el completo funcionamiento del sistema. Estas medidas son las contrarias a las expuestas antes y se basan en volver a dotar de los privilegios anteriores al procedimiento. Si se saltase este paso el usuario estaría en último término desaprovechando posibilidades del sistema, aunque no tendría por qué ser así dependiendo de la configuración utilizada en la base de datos que administra. Una vez realizado este último paso, el usuario podrá estar seguro de que el sistema no será vulnerable según las directrices que marcaba este boletín, aunque no por ello podrá afirmar tener un sistema completamente seguro.

sábado, 16 de enero de 2010

Vulnerabilidades: Desbordamiento en la pila

Se trata de una vulnerabilidad en SQL Server que podría permitir la ejecución remota de código malicioso haciendo uso previamente de técnicas de intrusión como podría ser la comentada inyección de código SQL. Se trata de una vulnerabilidad clasificada en el CVE con el código 2008-5416 (aún se muestra como candidata) y descrita en el marco de “desbordamientos en la pila”.

Microsoft, que la ha catalogado de “Importante”, dedica en su boletín las correspondientes referencias para informar a sus usuarios afectados e identificando aquel software que se ve afectado por ella. Hay que tener en cuenta que esta vulnerabilidad afecta a otros productos diferentes al propio SQL Server, como pueden ser numerosas versiones de Windows Server o Microsoft Data Engine además de las distintas versiones de SQL Server hasta la versión 2005 SP2. Versiones superiores a esta se suponen libres de esta amenaza.

Se produce al realizar llamadas sobre el procedimiento extendido “sp_replwritetovarbin”, pasándole determinadas variables sin inicializar como parámetros, lo que hace que se puedan realizar escrituras de memoria sobre una localización controlada por el atacante. Dependiendo de la versión de Windows que se esté utilizando, podría ser posible ejecutar cualquier código en el contexto de SQL Server, agravándose el problema por estar ese procedimiento accesible a cualquiera en la configuración por defecto del programa. Un atacante que pueda autenticarse con cualquier tipo de permiso en la base de datos, podría realizar la llamada tras haber fijado los parámetros correspondientes y ejecutar el procedimiento, por ejemplo haciendo uso del siguiente script T-SQL:

DECLARE @buf NVARCHAR(4000),
@val NVARCHAR(4),
@counter INT
SET @buf = '
declare @retcode int,
@end_offset int,
@vb_buffer varbinary,
@vb_bufferlen int,
@buf nvarchar;
exec master.dbo.sp_replwritetovarbin 1,
@end_offset output,
@vb_buffer output,
@vb_bufferlen output,'''

SET @val = CHAR(0x41)
SET @counter = 0
WHILE @counter <>
BEGIN
SET @counter = @counter + 1
SET @buf = @buf + @val
END

SET @buf = @buf + ''',''1'',''1'',''1'',
''1'',''1'',''1'',''1'',''1'',''1'''
EXEC master..sp_executesql @buf

La llamada al procedimiento con esa serie de parámetros que no se han contemplado para su ejecución puede permitir que el atacante ejecute ese código nocivo comentado antes e instalar programas, ver, cambiar o borrar datos. También podría crear una cuenta con privilegios para tomar cierto control del sistema y llevar a cabo una labor continuada de “ataques” mientras el administrador no sea consciente de la intrusión. Este es un claro ejemplo de aquellas vulnerabilidades que puede aprovechar la inyección de código para tomar control remoto del sistema, pasando de un plano más general a pequeñas concreciones de las que se abastece el primero. Normalmente son más controlables que las referencias del plano general, arreglándose con una comprobación concreta a la hora de programar el sistema, o en este caso y por parte de los desarrolladores, de actualizar.

viernes, 15 de enero de 2010

Inyección SQL: Medidas preventivas

Siempre y cuando el código SQL inyectado sea sintácticamente correcto, no será sencillo detectar alteraciones dañinas en tiempo de depuración. Por ello cobra especial importancia validar todos los datos especificados por el usuario mediante comprobaciones de tipo, longitud, formato e intervalo. A tal fin, es recomendable tener en cuenta las siguientes precauciones:

- No hacer suposiciones sobre el tamaño, tipo o contenido de los datos que recibirá la aplicación.

- Comprobar el tamaño y el tipo de los datos especificados, haciendo uso de unos límites adecuados. Esto puede impedir que se produzcan saturaciones deliberadas del buffer que provoquen DOS.

- Cuando se trabaje con documentos XML, validar todos los datos con respecto a su esquema a medida que se van indicando.

- No crear nunca instrucciones Transact-SQL directamente a partir de datos que indique el usuario.

- Utilizar procedimientos para la validación de los datos indicados por el usuario, ya que el modo en el que se pasan los parámetros a los procedimientos almacenados
evita que la inyección SQL pueda ser usada en la mayoría de los casos.

- En el caso de los entornos multinivel, todos los datos deben validarse antes de que se admitan en la zona de confianza. Los que no superen el proceso de validación deben rechazarse, devolviendo un error al nivel anterior.

- Implementar varias capas de validación. Las precauciones que se tomen contra usuarios malintencionados ocasionales pueden resultar ineficaces contra atacantes más obstinados. Lo más recomendable es validar los datos especificados por el usuario en la interfaz de usuario y después en todos los puntos posteriores que atraviesen un límite de confianza. Por ejemplo, la validación de datos en una aplicación cliente puede evitar la inyección de scripts. Sin embargo, si en el siguiente nivel se asume que ya se ha validado la entrada, cualquier usuario malintencionado que sea capaz de eludir un cliente puede disfrutar de un acceso sin restricciones al sistema.

- No concatenar nunca datos especificados por el usuario que no se hayan validado previamente. La concatenación de cadenas es el punto de entrada principal de una inyección de scripts.

- A ser posible, han de rechazarse los datos que contengan algunos caracteres especiales, como son: (delimitador de consultas), ‘ (delimitador de cadenas de datos de caracteres), -- (delimitador de comentarios), /*…*/ (delimitadores de comentarios que hacen que el servidor no evalúe el texto incluido en medio) y xp_ (se utiliza al principio del nombre de procedimientos almacenados extendidos de catálogo, como xp_cmdshell). Para ello será necesario comprobar determinados valores de la consulta que puedan incluir estos caracteres, como las cadenas.

- Resulta de gran utilidad limitar al máximo los permisos del usuario que ejecuta las sentencias para evitar posibles problemas. Por ejemplo, utilizando un usuario distinto para las sentencias SELECT, DELETE, UPDATE y asegurándose de que cada ejecución de una sentencia ejecute una sentencia del tipo permitido. Por supuesto, utilizar el usuario ‘sa’ (que proporciona control total del SQL Server, incluyendo una Shell a nivel de SO, con los privilegios del servicio MSSQLSERVER, usando el “procedimiento almacenado extendido” xp_cmdshell, y la habilidad de leer, escribir y mutilar todos los datos almacenados en la base de datos SQL Server) o uno que pertenezca al rol ‘db_owner’ (que proporciona habilidad de leer/escribir datos en la base de datos afectada, así como de eliminar tablas, crear nuevos objetos y, en definitiva, tomar el control total) para ejecutar las sentencias de uso habitual de la base de datos debería quedar descartado, ya que son los usuarios por defecto que se implementan en la instalación de SQL Server.

Este tipo de ataques, más allá de actualizaciones o herramientas de protección, requieren para mejorar la seguridad seguir una serie de buenos hábitos como pueden ser los anteriores y conocer a la hora de programar las posibilidades de las sentencias de acceso a las bases de datos. En la medida que los grandes volúmenes de información se afianzan como parte de la red y cada vez se hace más hincapié en su protección, hoy en día resulta mucho más dificil que hace unos años encontrar víctimas indefensas a estos ataques, si bien la creciente cantidad de recursos que se mueve actualmente sigue dando juego a la hora de utilizar la inyección de código para acceder a sistemas como los que implementa SQL Server.

jueves, 14 de enero de 2010

Vulnerabilidades: Inyección SQL

La inyección de código SQL pertenece al tipo de ataques de validación de entradas del usuario. Nos encontramos con una vulnerabilidad web que se encuentra en un gran número de aplicaciones de ese tipo y su potencial destructivo es enorme. SQL Server no ha sido una excepción a este respecto, y continuamente han ido apareciendo actualizaciones y parches de seguridad para solventar problemas de esa índole con las consecutivas versiones que Microsoft ha ido sacando al mercado, pero es un problema que parece no tener fin, a menudo por la falta de concienciación de seguridad de algunos programadores. Los programadores principiantes (y otros no tan principiantes) descuidan en ocasiones el código por desconocimiento, despistes o simplemente por comodidad.

La vulnerabilidad puede ocurrir cuando un programa construye descuidadamente una sentencia SQL, con parámetros dados por el usuario, para luego hacer una consulta a una base de datos. Dentro de los parámetros dados por el usuario podría venir el código SQL inyectado. Al ejecutarse esa consulta, el código SQL inyectado hace lo propio y podría hacer un sinnúmero de cosas, como insertar registros, modificar o eliminar datos, autorizar accesos, e incluso, llegar a ejecutar código malicioso en el computador.

Se trata por tanto de un problema de seguridad verdaderamente preocupante, ya que no requiere que el atacante tenga una elevada cualificación. Uno de los usos más simples es hacer uso de la inyección SQL para burlar una identificación y permitir el acceso no autorizado a una base de datos, pero esto es únicamente la punta del iceberg, puesto que el potencial de esta vulnerabilidad asciende al desastre total.

Por desgracia, Microsoft SQL Server es una de las aplicaciones que se muestran más vulnerables a ataques de inyección, dado que permite explotar el fallo más fácilmente por haber contemplado la posibilidad de concatenar consultas y la ejecución de sentencias múltiples. Además posee opciones que facilitan el acceso al sistema, como la ejecución de comandos desde la inyección (xp_cmdshell).

Todos los procedimientos que generan instrucciones SQL deben revisarse en busca de errores que den pié a ataques de este tipo, ya que SQL Server ejecutará todas las consultas recibidas que sean válidas desde el punto de vista sintáctico. Cabe mencionar que también existe un ataque menos directo que inyecta código dañino en cadenas destinadas a almacenarse en una tabla o como metadatos. Cuando las cadenas almacenadas se concatenan posteriormente en un comando SQL dinámico, se ejecuta el código dañino, pudiendo este quedar oculto en la base de datos temporalmente hasta que se accede a él y se produce el desastre.

miércoles, 13 de enero de 2010

Algunas Características

Después de una visión general, se procederá a comentar otras características más concretas de SQL Server. Lo primero es apuntar que alberga numerosas opciones ligadas a la Inteligencia Empresarial, actuando por ejemplo como servidor de informes, permitiendo el uso de herramientas de administración, prestando analítica empresarial y de servicios, o incluyendo mecanismos de gestión ligados a la minería de datos y texto.

Si se menciona su escalabilidad, debe considerarse que cuenta con un tamaño virtualmente ilimitado cuando nos referimos a la base de datos, al igual que ocurre con muchas de las soluciones serias que se encuentran en el mercado dentro de este campo. Es completamente compatible con procesadores multinúcleo, por lo que podría hacer uso de un número de CPUs también ilimitado, virtualmente hablando. Esto se entiende por su compatibilidad con bases de datos a gran escala, el procesamiento paralelo de operaciones de indexación y la vista de estas, acorde con los grandes volúmenes de datos a tratar.

Una de las características más importantes para una base de datos cuando se manejan esas cantidades de datos tan importantes será poseer un elevado nivel de disponibilidad. SQL Server consigue este objetivo incluyendo soluciones de conmutación rápida por error y redireccionamiento automático del cliente, así como otros aspectos importantes como los cambios del sistema en línea, la organización en clústeres, la transmisión de registros de seguridad o las operaciones de indización, restauración y recuperación de la base de datos tras determinadas operaciones.

Si se hace referencia a la arquitectura de los datos que se tratan, cabe indicar que SQL Server hace uso del protocolo del nivel de aplicación TDS (Tabular Data Stream) para llevar a cabo la comunicación Cliente-Servidor sobre la base de datos. Este a su vez se implementará sobre distintos mecanismos de intercambio de información, ya sea mediante memoria compartida, haciendo uso de la red con TCP/IP, o en general a través de métodos de comunicación entre procesos (ICP).

En el apartado de seguridad, muchos de los aspectos que se tratan son también comunes en otros sistemas de gestión, como por ejemplo el cifrado de los datos y la administración de claves, o los procesos de auditoría, autenticación y autorización. Después también se implementan una serie de análisis de las prácticas más adecuadas y se realizan procesos de integración con herramientas de Microsoft para, por ejemplo, buscar vulnerabilidades comunes que puedan surgir en el sistema.

Además permite en las nuevas ediciones incorporar tipos de datos definidos por el usuario, especialmente útiles para almacenar archivos multimedia y grandes bloques de información, así como la creación de aplicaciones avanzadas de suscripción y publicación. Otro aspecto relativo a la programabilidad es que incluye soporte para la gestión de datos XML, sumados al tipo básico que impone el modelo relacional.

En las nuevas versiones se viene haciendo hincapié en la robustez y la escalabilidad de la plataforma y, como viene siendo habitual, también en los procesos de monitorización y gestión, algo que sin duda responde al intento de Microsoft de adaptar su producto a las demandas del mercado según las nuevas normativas y los modelos de trabajo vigentes. Sin duda las nuevas incorporaciones serán bien recibidas por los desarrolladores y ayudarán a facilitar su trabajo.

martes, 12 de enero de 2010

Qué ofrece SQL Server

Los clientes están buscando soluciones para sus problemas de negocios. La mayoría de las "soluciones" de bases de datos conllevan múltiples niveles de costos y complejidad. La estrategia de Microsoft es la de hacer que SQL Server sea la base de datos más fácil de utilizar para construir, administrar e implementar aplicaciones de negocios. Esto significa tener que poner a disposición de los desarrolladores un modelo de programación rápido y sencillo, de modo que se elimine la administración de la base de datos para operaciones estándar, y suministre herramientas sofisticadas para operaciones más complejas.

SQL Server ofrece a los administradores de bases de datos una amplia variedad de herramientas y facilidades, tales como la administración multi-servidr y con una sola consola, la ejecución y alerta de trabajos basadas en eventos, una sólida seguridad integrada y scripting administrativo, además de permitir automatizar las diversas tareas de rutina que simplifican enormemente la tarea de los administradores. Todo esto hace de SQL Server una aplicación idónea para la administración de sucursales y aplicaciones de bases de datos insertadas.

Otro aspecto muy a tener en cuenta es que los clientes invierten en sistemas de administración de bases de datos en forma de aplicaciones escritas para esa base de datos, y la educación que implica para la implementación y administración de las mismas. Esa inversión debe protegerse: a medida que el negocio crece, la base de datos deberá crecer y manejar más datos, transacciones y usuarios. Los clientes también desean proteger las inversiones a medida que escalan aplicaciones de base de datos hacia equipos portátiles y sucursales.

Mientras los sistemas de procesamiento siguen siendo un componente clave para las infraestructuras de bases de datos corporativas, las compañías también están invirtiendo bastante en mejorar la comprensión que tienen de sus datos. La estrategia de Microsoft consiste en reducir el costo y la complejidad del almacenamiento de datos mientras hace que la tecnología sea más accesible a una mayor cantidad de público. A dicho fin, Microsoft ha establecido un enfoque total a todo el proceso de almacenamiento, cuyo objetivo es facilitar la construcción y diseño de soluciones efectivas a través de una combinación de tecnologías, servicios y alianzas con los proveedores.

La Microsoft Data Warehousing Alliance (DWA) es una coalición que une a los líderes en la industria de almacenamiento de datos y aplicaciones. El Microsoft Data Warehousing Framework constituye un conjunto de interfaces de programación diseñadas para simplificar la integración y administración de soluciones de data warehousing. Se trata de una arquitectura abierta que acelera, simplifica y reduce los costes de construcción, gestión y uso de las aplicaciones de negocio inteligentes cada vez más extendidas, integrando la capacidad de almacenamiento de SQL Server con las diversas herramientas provistas por Office.

Las mejoras introducidas en el data warehousing por SQL Server permiten manejar consultas complejas y bases de datos de gran tamaño, así como disponer de fiabilidad y escalabilidad, haciendo así que sea una de las aplicaciones líder en varias de las categorías de aplicación de rápido crecimiento en la industria de base de datos. Estas incluyen comercio electrónico, automatización de sucursales, aplicaciones de línea de negocios insertadas y mercados de datos.

lunes, 11 de enero de 2010

Introducción a SQL Server

SQL Server es un Sistema de Gestión de Bases de Datos Relacionales (según las siglas originales RDBMS) que hace uso principalmente de los lenguajes T-SQL (Transact-SQL) y ANSI SQL para llevar a cabo las consultas. Se trata de una solución propietaria de Microsoft como alternativa a otros sistemas existentes como pueden ser Oracle, MySQL o Firebird, por citar algunos.

Surgió entre finales de los 80 y principios de los 90 gracias a varias empresas entre las que se encontraba la propia Microsoft y otra empresa llamada Sybase como “cabezas visibles”. En el momento en el que sale al mercado Windows NT, ambas deciden tomar su propio camino. De este modo la primera de ellas buscó asegurarse la negociación de derechos exclusivos del software desarrollado para ser utilizado únicamente dentro de sus Sistemas Operativos. Sybase, por su parte, siguió con Sybase SQL Server, un nuevo sistema virtualmente idéntico pero con la diferencia de que conserva íntegramente la herencia Unix de sus inicios, de la que Microsoft planteó deshacerse en el momento de la separación.

La primera versión se denominó SQL Server 1.0 cuando todavía se encontraba dentro del compendio de empresas creadoras. Tras la separación, la siguiente versión data de 1993 y se denomina SQL Server 4.21, y a esta la siguen la 6.0, la 6.5 y la 7.0 (desde 1995 hasta 1999). En el año 2000, la versión 8.0 pasa a llamarse SQL Server 2000, y tres años después sale su homónima para plataformas de 64 bits. SQL Server 2005 se corresponde con la versión 9.0 y sale ese mismo año y lo mismo para la versión 10.0 o SQL Server 2008. Todas estas versiones a excepción de las dos primeras tienen asociado un nombre que las identifica. La última actualización se anunció en 2009 y es la SQL Server 2008 R2, con el nombre particular de edición “Kilimanjaro”, y siendo su principal característica la presencia de una consola centralizada que permite gestionar múltiples instancias SQL Server y la posibilidad de trabajar sobre un elevado número de procesadores lógicos.

Dado su carácter de pago y con vistas a no estancarse a la hora de atraer usuarios, Microsoft pone en mano de cualquier usuario que lo desee una versión reducida de SQL Server denominada SQL Express Edition. Lleva el mismo motor de DB pero está orientado a proyectos de pequeña envergadura, contando en la última versión con una capacidad de hasta 4 GB pero con las limitaciones que impone su ralentización cuando un número creciente de usuarios hace uso de ella de forma concurrente. Se trata pues de una versión de evaluación que permite a los desarrolladores familiarizarse con SQL Server sin la necesidad de pagar, algo que no tendrían que hacer para otros sistemas disponibles, pero que dentro del entorno empresarial y dada la implantación de los SO Windows no supone un problema demasiado acusado cuando hay dinero o bien se cuenta con intereses de mercado de por medio por parte de Microsoft.