Hackeando un SQL Server

Considera que el servidor de Microsoft SQL es un ambiente popular y robusto para muchos usos que utilicen bases de datos? En efecto, ste ofrece excelentes capacidades multi-access, cobertura comprensiva de la seguridad y puede ser transportado fcilmente a otras plataformas de la base de datos. Este artculo apunta a identificar ciertos tipos de riesgos que pudieron resultar de la gerencia inadecuada del servidor de Microsoft SQL. Cules son las conclusiones? Usando la cuenta del administrador del sistema Procedimientos Almacenados Extendidos Por qu no revocar la autorizacin? LocalSystem predeterminado? Referencias Revisin histrica Microsoft SQL Server es un medio popular y robusto para muchas aplicaciones que utilizan bases de datos, ofrece excelentes capacidades multi-acceso, cubre aspectos de seguridad y puede utilizarse fcilmente con otras plataformas de base de datos. Desafortunadamente, no se podr observar tal potencial, a pesar del uso del MSDE (motor de la base de datos de Microsoft, optimizado para soluciones individuales o pequeas de un grupo de trabajo) si no se proporciona un mnimo de proteccin adecuada a la seguridad de las bases de datos. Por qu es necesaria esta tecnologa? Porque las altas capacidades del SQL Server se combinan con alta flexibilidad, y demasiada flexibilidad puede ser perjudicial si es utilizada de forma incorrecta. Si se configuran correctamente, cada SQL Server permite que todos los usuarios tengan acceso a la base de datos principal, que a su vez contenga la configuracin del SQL Server y toda la informacin que el SQL Server utiliza para abrir las bases de datos. Tambin incluye todas las identificaciones SQL, datos de los servidores conectados etc. Por supuesto no se permite a los usuarios "normales" tener acceso a todos los recursos de la informacin. La figura 1 ilustra cmo se comporta el servidor con un intento de acceso a la lista de cuentas, como puede verse, el servidor evita la lectura de contraseas a los usuarios. Sin embargo, los nombres de cuenta y las bases de datos (incluyendo la informacin almacenada en ellas) se pueden alcanzar por usuarios no privilegiados. Un ejemplo que muestra una parte de informacin adquirida por un usuario, se ilustra abajo, en el cuadro 2.

CUADRO 1: Un intento fallido de acceso a la lista de usuarios.

CUADRO 2: Cuando un usuario normal manipula el acceso a la lista usuarios. Desplazndonos al final de la pantalla en la figura anterior, obtenemos las lneas finales de la solicitud a la base de datos, mostradas a continuacin:
1> select name, dbid from sysdatabases 2> go namedbid ----------------master1 tempdb2 model3 msdb4 pubs5 Northwind6 Pages7 (7 rows affected)

Puede apreciarse lo difcil que es mantener los datos a salvo de usuarios curiosos. Por supuesto, el lector podra inquirir "pero, despus de todo, mis usuarios no tienen permitido realizar peticiones en el SQL Server", no obstante, si se examina minuciosamente lo anterior es una afirmacin bastante dudosa, porque la posibilidad o imposibilidad de poner peticiones deliberadamente creadas en una aplicacin del SQL Server no implica necesariamente que la misma regla es vlida para el propio servidor! Aunque una aplicacin especfica es segura aparentemente contra tal situacin, sugiere reconsiderar la idea de "que todos los scripts estn protegidos contra ataques de SQL Injection"[[1][2] Qu si el usuario, al definir las condiciones de una peticin, puede unir una tabla a los resultados? Y cul es el esquema de autenticacin definido en el servidor que se aplicar a usuarios potenciales? Incluso si la aplicacin presumiblemente est bien protegida contra el acceso no autorizado, acaso el propio usuario no puede ejecutar las herramientas de comunicacin estndar en su computadora para conectar el SQL Server sql.exe, VBScript que utiliza ADO, o cualquier otro programa que funcione como ODBC (u OLEDB), directamente con el servidor de la base de datos. Conocer la contrasea del SQL Server es el nico prerrequisito. Todava, en muchas situaciones la posibilidad de autenticacin de los usuarios locales de la red en los servicios de directorio es suficiente. Sin embargo no deje que la paranoia lo domine, simplemente debemos aceptar que la posibilidad de autenticacin del usuario en el SQL Server est asociada a sus permisos de realizar peticiones probadas, o an las indiscretas.

Cules son las conclusiones?

En el ejemplo anterior se entregan los nombres de usuarios, algunos estn definidos en el SQL Server y son reconocibles por el valor 0 en la columna "isntname". Si est c se configura para realizar la autenticacin en modo de autenticacin mixto, el SQL Server aceptar intentos de conexin con estas cuentas, mientras no se deshabilite la cuenta por intentos repetidos. ste es el inconveniente del mecanismo de autenticar conexiones en modo mixto del SQL Server. Afortunadamente, su uso es opcional y an cuando est presente, no se recomienda, porque crea las oportunidades para un ataque de fuerza bruta en el cual se pruebe cada llave o contrasea posible hasta que se encuentra la correcta.

Un atacante puede hacer esto si usa un programa adecuado para automatizar tal trabajo. La ms "apreciada" es una cuenta "sa" (administrador de sistema), que tiene acceso a todo lo creado especficamente por el SQL Server (es similar a root en Linux o LocalSystem en Windows NT) al contar con privilegios para manejar cualquier base de datos (incluyendo la base de datos "master"), acceso completo para realizar cualquier funcin en el SQL Server e incluso ejecutar los procesos que son heredados por el servidor, a saber el proceso SQLSERVR.EXE. Por otra parte, en muchas instalaciones, el SQL Server funciona en el contexto que tiene el administrador de la seguridad - de tal modo el usuario "sa" puede manejar una computadora con el servicio de MS SQL Server instalado adems de todas las bases de datos. Al trabajar con MSDE, la situacin empeora, pues el servicio est instalado debajo de LocalSystem, con una cuenta por default "sa" con una contrasea EN BLANCO! El cuadro 3 ilustra dos intentos consecutivos de obtener la cuenta "sa", uno errneo y otro acertado. CUADRO 3: Dos ataques contra una cuenta "sa", con una contrasea en blanco? El segundo intento es exitoso.

Usando la cuenta del administrador del sistema

Primero que nada, el usuario "sa" tiene control sobre todos los datos, esquema y disposicin del SQL Server. No es necesario entrar en detalles porque la lista de privilegios del administrador de sistema puede contener casi cualquier cosa. Mejor centrmonos en ciertos tipos de ataques maliciosos. El ms simple consiste en crear una cuenta nueva con los mismos privilegios que el usuario "sa" tiene. A continuacin se muestra un ejemplo:
1> sp_addlogin 'hacked','h4xor' 2> go New login created.

1> sp_addsrvrolemember 'hacked','sysadmin' 2> go 'hacked' added to role 'sysadmin'. 1> quit C:\>osql -U hacked -P h4xor -Q "SELECT DB_NAME(),USER_NAME()" ----------master dbo (1 row affected) C:\>

En lugar del procedimiento "sp_addlogin" uno puede utilizar, por ejemplo, el "sp_grantlogin" ste crea una cuenta que es autenticada por el sistema operativo en el que se encuentre el SQL Server. Se debe hacer notar, que es muy fcil ganar privilegios "sa" apenas asignando el rol de sysadmin a la cuenta seleccionada del usuario (o un grupo de usuarios definidos en la fase de inicializacin del SQL Server). Aparte de este rol, el servicio del SQL Server permite explotar otra caracterstica que, sin embargo, no se puede utilizar para manejar completamente el servidor. (Consultar [3]). Por supuesto, no se puede excluir que el administrador detectar tal cuenta (incluso si su nombre no parece inusual). Si es as un atacante no tiene otra opcin ms que utilizar la cuenta existente la manera ms simple sera modificar la contrasea empleando el procedimiento "sp_password".Si un intruso desea cubrir su rastro, puede intentar descifrar las contraseas, que utilizan los usurarios para acceder al servidor. Debemos recordar en este punto el modo mixto de autenticacin, el SQL Server puede utilizar su propio mecanismo de autenticacin almacenando no slo la informacin de los identificadores de los usuarios (similar a la autenticacin realizada por el sistema operativo), tambin contraseas. Esto se hace en la columna de "passwd" de la tabla de syslogins la cual contiene un hash de la contrasea del usuario producida por la funcin pwdencrypt(). Este es un hecho bastante conocido, descrito brillantemente por David Litchfield en su artculo "Crackeando contraseas en SQL" [4] indica las herramientas que se pueden utilizar para realizar ataques de fuerza bruta [5]. Si su SQL Server no se configura para utilizar SQL Server Authentication, no tiene que preocuparse de ser atacado de dicha manera. Un intruso ms malvolo puede procurar instalar una puerta trasera. Dos posibilidades se presentan a continuacin.

Procedimientos Almacenados Extendidos

El SQL Server ofrece la posibilidad de ejecutar procedimientos escritos por el usuario. Estos procedimientos pueden ser escritos en el lenguaje de SQL y almacenados en cualquier base de datos, o ser bibliotecas de ligado dinmico (DLLs) que el SQL Server pueda cargar y ejecutar dinmicamente si lo requiere. Este ltimo tipo se conoce como "procedimientos almacenados extendidos" y tienen caractersticas interesantes: se agregan directamente al SQL Server y comparten la seguridad ejecutada por el SQL Server. En la prctica, stos se hacen para funcionar con privilegios de "sa" en la base de datos. Pueden ser definidos solamente en la base de datos "master" y pueden ser agregados a la base de datos exclusivamente por el administrador (el usuario "sa"). La configuracin del SQL Server por default contiene virtualmente un nmero enorme de estos procedimientos, sin embargo la mayora de ellos no estn documentados. Los procedimientos almacenados extendidos ejecutan bajo diversos esquemas de autenticacin, ciertos procedimientos son accesibles para

todos los usuarios incluso de forma predeterminada o porque la funcionalidad del servidor los requiere. Solamente el administrador de sistema puede ejecutar otros procedimientos almacenados extendidos. Esto crea varias dificultades operacionales para el administrador especialmente en la deteccin de procedimientos "especiales" que un intruso coloc probablemente en el servidor. Es suficiente cargar un archivo DLL previamente preparado (usando el API de Open Data Services, que se instala opcionalmente con el SQL Server), llama despus al procedimiento "sp_addextendedproc" con sus respectivos argumentos, se conceden derechos de ejecucin de dicho procedimiento para todos los usuarios (por ejemplo, al grupo de usuarios "public"). El resultado, un atacante podr utilizar tal procedimiento podr ser utilizado por un atacante, para ejecutar operaciones con privilegios de "sa" desde cualquier cuenta de usuario sin importar su nivel.

Por qu no revocar la autorizacin?

Chris Anley en su documento titulado "Violating Database - Enforced Security Mechanisms" [6], describe un enfoque para mejorar la seguridad, que incluye una modificacin del funcionamiento de SQL Server para que se ignoren las peticiones de "cualquiera" excepto de los usuarios "sa". Su invencin se basa en el manejo de excepciones de autorizacin por el cdigo SQL. "En vez de intentar un anlisis esttico de todo el cdigo de la base de datos, con un pequeo depurador nos llevara en la direccin correcta". Por supuesto, dichos cambios son factibles bajo ciertas condiciones, algunas manipulando el archivo ejecutable que contiene el cdigo de la base de datos o haciendo operaciones en la imagen en memoria. En ambos casos el administrador del SQL Server es la nica persona autorizada para hacerlo. Sin embargo, esta es una situacin simplificada y la realidad es ms triste. Antes de entrar en mayor detalle, recordemos que es importante el observar los boletines de seguridad, pues de otra forma el buffer podra desbordarse. Por qu el problema de buffer overrun es de preocuparse? SQL Server procedimientos predeterminados, por ejemplo funciones DLL que vienen con el SQL Server. Dichas rutinas estn escritas en lenguajes de alto nivel (por ejemplo C) y son compiladas como DLL. Cuando comienza la ejecucin, leen los parmetros que introduce el usuario a un buffer de memoria. Sin embargo podra suceder, por alguna razn, que el programador olvide codificar una verificacin de datos antes de meter la informacin en las variables del programa, y si un atacante enva demasiada informacin es posible que dichos datos se "desborden" del tamao predeterminado y sobrescriban datos en las reas adyacentes del buffer. Este desbordamiento del buffer puede permitir a usuarios maliciosos ejecutar comandos de cualquier tipo en el sistema remoto. (Ver, por ejemplo, "Anlisis de Ataques de Buffer Overflow" por Piotr Frej y Maciej Ogrkiewicz). El problema es que SQL Server de Microsoft contiene procedimientos que son vulnerables a este tipo de ataques. Estos procedimientos y funciones implementadas en el lenguaje Transact-SQL (un ejemplo puede ser la funcin antes mencionada "pwdencrypt"). Esto puede suceder tambin con las bibliotecas OLEDB, que son objetos COM cargados en el proceso del cliente.

Recuerde que en el contexto COM, todo programa basado en componentes se convierte en cliente. Siempre que el comando OPENROWSET es activado, el SQL Server se convierte en cliente del proveedor de datos, que lo hace automticamente vulnerable a errores en el cdigo de alguna funcin de OLEDB. Aquellos interesados pueden leer varios boletines de seguridad [7] para mayores detalles de los problemas y de las soluciones propuestas. Si lo hacen tengan en cuenta que un ataque de buffer overflow exitoso significa que el usuario puede ejecutar cualquier cdigo en el SQL Server en el contexto de la cuenta de administracin local. Estos privilegios de ("sa") permiten la manipulacin arbitraria del servicio de SQL, sin embargo seguimos con el mismo problema qu tan poderosos son los privilegios "sa" en el contexto del sistema? Son igualmente poderosos que el servicio SQL y razonablemente estrictos en trminos de seguridad, dichos privilegios corresponden a los del proceso SQLSERVR.EXE. De forma predeterminada el servidor SQL incluye varios procedimientos eficaces para comunicarse con el sistema operativo. Por slo mencionar algunos de ellos: "xp_cmdshell", "sp_OACreate","xp_regwrite","xp_instance_rewrite", "xp_adsirequest". Aunque algunos de ellos estn documentados (los dos primeros), an no estamos seguros de los efectos de los otros. Con estos procedimientos los administradores del servidor SQL pueden interactuar con el sistema operativo y con la limitacin del nivel de privilegios configurada en el servicio de MSSQLSERVER. Si fuera el caso de que este servicio se ejecute bajo la cuenta de LocalSystem, el "sa" podra acceder a los mayores privilegios para ingresar al escritorio, pero no a los servicios de red. El atacante puede usar los privilegios como se ilustra en la figura 4. FIGURA 4: Usando la cuenta "sa" para cargar un programa desde Internet al servidor.

Si en vez de esto, se ejecuta el servicio con una cuenta de dominio, que tenga acceso a la red, entonces el "sa" puede acceder a toda ella. Los privilegios del "sa" dependen de cmo se configur MSSQLSERVER. En la documentacin de SQL Server, se especifica claramente que la cuenta de MSSQLSERVER es una cuenta de

usuario y no de sistema. Incluso aunque lemos en los boletines de seguridad de Microsoft del SQL: "SQL Server 2000 puede ejecutarse con una cuenta no-administrativa, requiere de un completo acceso a la llave de registro: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSSQLServer" Teniendo este nivel de acceso, el SQL Server, puede modificar un valor de "ObjectName" en el registry. ste contiene el nombre de la cuenta que se requiere para ejecutar el servicio. Y es suficiente para reconfigurar el servicio, ejecutando como LocalSystem. Por lo tanto, un atacante que pueda aplicar cdigo sobre la cuenta de SQL Server es capaz de reconfigurar el servicio para que se implemente con los mayores privilegios del sistema, aunque el SQL Server lo haga como usuario normal. Este problema fue tratado en la tercera seccin del boletn MS02-034 [8]. Para leer acerca de los permisos que requiere SQL Server, ver el documento SQL Server 2000 Security[9]

LocalSystem predeterminado?
El Servidor MS SQL 2000 Desktop Edition (MSDE 2000), en la ltima versin se instala con cuenta de LocalSystem de forma predeterminada. Por supuesto, esto genera el potencial de vulnerabilidades antes mencionadas. Naturalmente el parche para SQL Server, Service Pack 3, mejora la seguridad slo en el servicio SQL, no as en el equipo en que se ejecuta. Al tener Service Pack 3, se pueden experimentar problemas si el servidor se est ejecutando fuera de la localhost. Esto es consecuencia de los permisos que se colocan en las llaves del registry y en el sistema de archivos donde se instala el Service Pack 3. Por supuesto, minimiza privilegios no deseados, que es algo positivo, pero fuera de este enfoque, la documentacin insuficiente es una mala prctica. Ms adelante se incluye informacin bsica para ayudarle a documentar correctamente. Para reducir los privilegios asociados a MSDE en el sistema operativo: Sustituya las cuentas de MSSQLSERVER y SQLSERVERAGENT (de LocalSystem) a alguna otra. D a la nueva cuenta permiso de leer en el directorio C:\Program Files\Microsoft SQL Server\MSSQL, recordando seleccionar la opcin "Reset permisions on all child objects". Aplique todos los privilegios en los subdirectorios DATA y LOG. Ejecute regedt32.exe (registry editor) (de tal manera que permita editar permisos, usar regedit.exe en windows xp) y conceda todos los permisos para la cuenta en la llave de registro HKLM\SOFTWARE\Microsoft\MSSQLServer. Re-ejecute "Reset permisions on all child objects..." Permita a la cuenta acceso de *slo lectura, en la llave de registro HKLM\SYSTEM\CurrentControlSet\Services\MSSQLSERVER Ejecute el servicio MSSQLSERVER Agregue la cuenta del servicio al rol de sysadmin (para soporte del servicio de SQLServerAgent), usando los siguientes comandos: 1> sp_grantlogin 'COMPUTER\account_sql'
2> go Granted login access to 'COMPUTER\account_sql'. 1> sp_addsrvrolemember 'COMPUTER\account_sql','sysadmin' 2> go 'COMPUTER\account_sql' added to role 'sysadmin'.

 Ejecute el servicio SQLServerAgent Los comandos SQL deben ser ejecutados con el programa osql.exe, bajo la cuenta de administrador de sistema especificando el parmetro E. Obviamente, deber especificar el nombre real de la cuenta de SQL Service, precedido por el nombre del equipo. Si no desea permitir acceso al Servidor MSDE desde la red, deshabilite la siguiente llave de registro: HKLM\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib Por razones obvias, es buena prctica exportar dicha llave de registro en un archivo .reg antes de hacer cambios. Si hay problemas al iniciar el servicio MSDE, use FileMon y RegMon disponibles en www.sysinternals.com, las cuales son - Son herramientas muy tiles cuando se analizan y remedian dificultades, resultado de reglas sobre-protectoras en el registro o sistemas de archivos. Vale la pena consultar la documentacin de SQL Server 2000 [3][9].

Referencias
[1] http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf [2] http://www.it-faq.pl/itfaqarticle.asp?id=136 [3] http://msdn.microsoft.com/library/en-us/startsql/portal_7ap1.asp [4] http://www.nextgenss.com/papers/cracking-sql-passwords.pdf [5] http://www.cqure.net/tools10.html [6] http://www.nextgenss.com/papers/violating_database_security.pdf [7] http ://www.microsoft.com/technet/security/current.asp?productid=30 [8] http://www.microsoft.com/technet/security/bulletin/MS02-034.asp [9] http://www.microsoft.com/technet/prodtechnol/sql/maintain/security/sql2ksec.asp

Revisin histrica Liberacin original: 24-Ene-2005 ltima revisin: 7 de octubre de 2010 La Subdireccin de Seguridad de la Informacin/UNAM-CERT agradece el apoyo en la elaboracin y revisin de este documento a: Galvy Cruz Valencia Andrs Leonardo Hernndez Bermdez

Para mayor informacin acerca de ste documento de seguridad contactar a: UNAM-CERT Equipo de Respuesta a Incidentes UNAM Subdireccin de Seguridad de la Informacin Direccin General de Cmputo y de Tecnologas de Informacin y Comunicacin Universidad Nacinal Autnoma de Mxico E-Mail: [email protected] http://www.cert.org.mx http://www.seguridad.unam.mx ftp://ftp.seguridad.unam.mx Tel: 56 22 81 69 Fax: 56 22 80 43