HPP26 Seguridad en Base de Datos

Artículo publicado en la revista @RROBA # 95
Suplemento “Hack Paso a Paso” #26 – Octubre 2005

(Material Sin Editar)
Seguridad en Base de Datos

Introducción
Hace algunos días, me encontraba dando una conferencia relacionada con Seguridad en
Base de Datos, en el Sheraton Hotel de Buenos Aires, Argentina, en el marco de un
evento al cual los organizadores dieron en llamar “Security & Ethical Hacking
Conference & Exhibition” (Ver Destacado). Luego de exponer tan solo algunas, de las
técnicas frecuentemente utilizadas al momento de atacar sistemas de bases de datos, y
una vez finalizada la ponencia, varias fueron las personas que se me acercaron
mostrándose preocupadas y con algún grado de nerviosismo (a pesar de haber dedicado
algún tiempo a exponer acerca de las contramedidas), a solicitar cualquier consejo que
pudiera serles de utilidad al momento de evitar alguno de los ataques presentados.
Sucede que hoy en día, se hace impensable administrar un negocio cualquiera sea su
envergadura, sin la implementación de algún tipo de software de base de datos.
Sistemas de Recursos Humanos, Liquidación de Haberes, Administración de Clientes,
ERPs, CRMs, Registros de Inventarios, Aplicaciones Web interactivas, son tan solo
algunos de los sistemas que a menudo suelen ser requeridos en gran parte de los
escenarios de negocio, y si requieres alguno de ellos... indirectamente requieres un
gestor de base de datos!
Pero... aguarda un instante... acaso no era esta la Era de la Información? pues donde
esperabais que se guarde la información de la era de la información si no es en una base
de datos? estáis de acuerdo verdad? Ok, entonces seguramente tu base de datos se
encontrará sumamente protegida... bien... y cuál fue la fecha de el ultimo análisis de
seguridad realizado a tu sistema de base de datos? cuando tienes planificado hacer el
próximo? cuantas intrusiones has detectado a tu base de datos en los últimos días? ...
ok... lo se... no tienes la menor idea... no te alarmes (o mejor dicho alármate!!) no eres el
único, se cuentan por miles las empresas que a pesar de invertir frecuentemente en
seguridad informática, aún no comprenden como funciona la seguridad en base de
datos, y esta problemática mi querido lector, es lo que me ha llevado a escribir el
presente artículo el cual espero que disfrutes y aproveches.
En las próximas paginas, recorreremos algunos conceptos generales de seguridad en

bases de datos desde un punto de vista conceptual, con la intención de que los
fundamentos vertidos os sirvan más allá, del gestor de base de datos que estén
utilizando. Por último y para hacer esto un poco mas divertido, nos concentraremos en
la elaboración de un test de seguridad controlado sobre nuestro equipo de pruebas, a fin
de llevar a la práctica alguna de las lecciones aprendidas.
La Problemática
Como consultor en seguridad informática, a menudo me encuentro asesorando a clientes

del sector público y privado, que de uno u otro modo, se proponen elevar el listón en
Copyright © 2005 Hernán Marcelo Racciatti 1

http://www.hernanracciatti.com.ar
materia de seguridad a fin de sentirse un poco más seguros. Con el tiempo, he

encontrado que a pesar de lo cambiante de la tecnología, gran parte de los errores a
partir de los cuales suelen surgir los incidentes de seguridad, se encuentran relacionados
con la sumatoria de aquellos pequeños aspectos, que habiendo pasando desapercibidos
en un principio, se transforman luego en graves incidentes de seguridad.
Las bases de datos no conforman precisamente la excepción a la regla, y del mismo

modo, pequeños errores u omisiones, ya sea en el desarrollo de un producto como en su
instalación o administración, abren las puertas del cielo al atacante.
Seguramente habrás oído por allí que “la seguridad de un sistema es tan fuerte como su
eslabón mas débil”. Nada mas real que esta afirmación!!
No importa que tan seguro sea el firewall instalado en tu empresa, si el personal no se
encuentra bien entrenado, debilidades del factor humano por ejemplo, podrán suplir la
falta de alguna vulnerabilidad explotable en sus sistemas de defensa autónomos.
Pero llevemos estos dichos al plano práctico. Lo que generalmente sucede al momento
de implementar algún tipo de solución de negocios, por ejemplo basada en Internet por
medio de una aplicación web, es lo siguiente:
- El administrador de sistemas o redes, encargado de la seguridad del host

donde se alberga la aplicación web, supone que el desarrollador web no
permitirá que su aplicación escriba en directorios no permitidos, por tal
motivo el administrador de red, probablemente no se preocupe por
configurar los permisos de directorios en forma minuciosa.
- El desarrollador de la aplicación web, confía no solo en que el administrador
del host hará efectivos los permisos necesarios a nivel de file system, sino
también en que el administrador del software de base de datos, se encargará
de hacer su parte configurando la seguridad del mismo, motivo por el cual
decide confiar parte de la validación de su aplicación, al servidor de base de
datos.
- Por último, el administrador de base de datos, probablemente se encuentre
preocupado por que la performance sea la correcta a la hora de servir datos a
la aplicación web demandante, pero no respecto de los privilegios que ha
asignado al usuario de base de datos que los desarrolladores le han
solicitado, a fin de que la aplicación funcione en forma “correcta” (¿?)
Por supuesto que la situación se agrava cuando el desarrollo de la aplicación web por
ejemplo, se encuentra dado por un equipo y no por una sola persona, en muchos de
estos casos la división de responsabilidades de desarrollo no tiene en cuenta aspectos
referentes a la seguridad de la información, produciendo resultados inesperados desde el
punto de vista de la seguridad, los cuales a menudo se evidencian por ejemplo, al
momento de realizar un test de penetración.

Pero cual es el verdadero problema que esconde el ejemplo presentado? Ok... como sin
dudas habrás notado, no es uno sino varios!! Por empezar debemos admitir que en la
mayoría de las organizaciones, suelen existir por lo general, problemas de comunicación
entre los mismos profesionales abocados a un proyecto, lo que termina en situaciones
como la mencionada en párrafos anteriores. Por otra parte es habitual encontrar
escenarios en donde ni los desarrolladores, ni los administradores de red, ni los DBA
(del ingles Database Administrator’s), tienen conocimientos de seguridad o necesidad
“a su juicio” de practicarla!!
Por ultimo, sin lugar a dudas... el motivo más importante por el cual las bases de datos
suelen ser vulnerables a algunos de los ataques que mencionaremos a lo largo del
presente artículo, se encuentra íntimamente relacionado con la poca importancia que por
“extraños motivos” las empresas brindan a sus almacenes de datos. Y si esto no es
cierto... piensen nuevamente… cuantos de ustedes en vuestra empresa, cuentan con
listas de verificación de seguridad específicas al momento de instalar servidores de base
de datos, metodologías de hardening específicas para vuestro servidor MS-SQL,
ORACLE, MySQL o cual fuera, políticas acerca de los accesos y el privilegios a nivel
DB y a nivel de sistema operativo, planes formales correctamente establecidos respecto
de la ejecución periódica de test de seguridad específicos para sus servidores de base de
datos, pero... un momento seguramente habrás notado que la palabra específico ha sido
utilizada en forma reiterada... acaso crees que es un error de tipeo!! NO! Bajo ningún
punto de vista!! Sucede que el error más común y definitivo, cometido incluso por
algunos profesionales de seguridad, es intentar evaluar “en la práctica” un servidor de
base de datos, del mismo modo que lo haría con un host!! o cualquier otro software o
dispositivo y este es otro grave error!! La seguridad en base de datos, requiere de
atención y cuidados especiales… después de todo… allí es donde esta su activo mas
valioso!!
Donde están los intrusos!
Bien, en los párrafos anteriores intente plasmar la problemática de los servidores de

base de datos en general, tomando como ejemplo, una típica aplicación publicada en
Internet, por medio de la cual es posible interactuar con un servidor de base de datos
dentro de la organización.
Estoy seguro que mientras leían dichas líneas muchos habrán pensado... bueno... “pero
tengo entendido que el firewall parará todos los ataques”, “la base de datos se encuentra
protegida porque lo que esta publicado es la aplicación web y no la DB”, “después de
todo mi IDS podrá detectar todos los ataques” o “el usuario que tiene asignado la
aplicación no tiene privilegio alguno sobre la DB mas que para ejecutar una mera
consulta”... bien, déjenme decirles que aquí hay nuevamente errores conceptuales
gravísimos... el intruso... no solo esta afuera, también lo esta adentro... y créanme... esto
es mucho peor...

Muchos administradores relajan sus controles hacia adentro, presuponiendo que el

usuario interno no actuará con malicia y esto es especialmente cierto cuando se trata de
software de base de datos. En mis auditorias, con frecuencia encuentro instalado clientes
de base de datos (Generalmente de ORACLE o de Microsoft SQL Server) que permiten
al usuario conectarse en forma directa con la base de datos, obviando cualquier control
que se haya querido imponer al usuario a través de la aplicación. Por que sucede esto?
sencillamente porque el administrador “supone” que ningún usuario intentará acceder de
un modo no permitido a la base de datos!! Iluso no? Precisamente aquí es donde
comienzan los problemas para algunos y la parte divertida para otros…
Diferentes tipos de Ataques
Si bien entre los profesionales que conformamos la comunidad de seguridad

informática, eventualmente puede surgir alguna divergencia al momento de definir los
diferentes tipos de ataques en general, en aquellos relacionados con Bases de Datos el
tema es bastante más sencillo, o dicho de otro modo, la definición del tipo de ataque se
encuentra bastante estandarizada.
En líneas generales, podemos decir que los ataques a base de datos suelen formar parte
de uno de los siguientes dos grandes grupos: Ataques que No Requieren Autenticación y
Ataques que Requieren Autenticación.
Los ataques que No Requieren Autenticación, son los que generalmente suelen tener
mas prensa (y para algunos los mas divertidos...), puesto que no se requiere presentar
“credenciales validas” antes de lanzar el ataque. Dentro de esta categoría, se encuentran
por ejemplo, algunas de las explotaciones de Buffer Overflow con más prensa.
Otros ataques dignos de ser mencionados, dentro de aquellos que No Requieren

Autenticación, son aquellos por medio de los cuales se intenta obtener un nombre de
usuario y contraseña validos en el sistema objetivo mediante técnicas tales como la
adivinación y los ataques de fuerza bruta o diccionario.
Por su parte, los Ataques que Requieren Autenticación deben ser lanzados por los
poseedores de credenciales validas (al margen si estas fueron adquiridas en forma lícita,
o como parte de la explotación de otro tipo de ataque!). Este hecho se encuentra
directamente relacionado con la gran cantidad de vulnerabilidades existentes dentro de
esta categoría, puesto que en este escenario, el usuario posee acceso al sistema a
objetivo y cuenta con muchas más oportunidades al momento de lanzar un ataque, en
parte fruto de la funcionalidad propia de la aplicación para la cual se obtiene un juego
de credenciales validas.
Un claro ejemplo respecto de los Ataques que Requieren Autenticación, es entre otros,
el de la explotación de buffer overflows en procedimientos almacenados.

Metodología
Bien, a esta altura nos hemos formado una idea general respecto de parte de la
problemática en torno a la seguridad en base de datos y entre otras cosas hemos
recordado que el software de base de datos, al igual que cualquier otro tipo de software,
brinda al atacante la posibilidad de explotar vulnerabilidades propias de este tipo de
aplicaciones.
Al mismo tiempo hemos hecho referencia a que los servidores de base de datos deben
ser asegurados y testeados. Respecto a este ultimo punto, en mi ultimo artículo,
discutimos algunas metodologías de testeo de seguridad tal como el OSSTMM de
ISECOM o el ISSAF de OISSG, motivo por el cual no volveremos sobre lo escrito
oportunamente, en cambio, en esta oportunidad tan solo me permitiré mencionar los
puntos que metodológicamente deben ser cubiertos al momento de realizar un test de
penetración (o un ataque... dependiendo del lado que te encuentres) a un servidor de
base de datos:
§ Adquisición
§ Fingerprinting/Sondeo/Descubrimiento
§ Obtención de Acceso
§ Escalación de Privilegios
§ Compromiso Total del Host
Vale aclarar que si bien el camino mencionado suele ser utilizado al momento de
realizar un test de penetración interno o externo, el complemento ideal a dicho
procedimiento, será la realización desde el interior, de una auditoría detallada en la cual
se involucren tareas tales como la revisión de:
§ Seguridad Física
§ Políticas y Procedimientos
§ Seguridad a Nivel de File System
§ Seguridad del Entorno
§ Stored Procedures
§ Passwords
Paso a Paso
Llegado este punto es hora de poner manos a la obra y conocer algunas de las técnicas y
herramientas con las cual deberemos estar familiarizados a la hora de llevar a la práctica
nuestro test de penetración controlado a bases de datos.
Para hacer esta parte un tanto mas divertida, les cuento que utilizaré un viejo servidor
Microsoft SQL Server 2000, que aún poseo instalado en mi laboratorio de pruebas.

Instalando Microsoft SQL Server 2000
Si quieres seguir los ejemplos que mencionaremos a continuación y no posees ningún

SQL Server 2000, en tu laboratorio de pruebas, no te desanimes, Microsoft tiene la
solución a todos tus problemas... puedes registrar y descargar una versión de evaluación
del siguiente url:
http://www.microsoft.com/sql/evaluation/trial/
O en su defecto ordenar el envío de una copia a tu domicilio (Al menos eso dice en su
web...) En cualquiera de los casos, ten en cuenta que la versión trial provista
(Denominada: SQL Server Evaluation Edition Release A) se encuentra a nivel de SP2
(Service Pack 2 de SQL) mas la adición de un parche que protege la instalación del trial,
del gusano Slammer (Q323875 - Buffer Overruns in SQL Server 2000 Resolution
Service Could Enable Code Execution), lo que significara que probablemente alguno de
los ejemplos mostrados en este articulo, no puedan ser ejecutados. Es por eso que te
recomiendo intentes preguntar a alguno de tus amigos si no tiene algún servidor SQL
Server 2000 sin SP o con SP2 que puedas usar para testear alguno de los exploits que
mencionaremos a continuación.
Respecto de la instalación, no hay mucho que decir, tan solo deberemos ejecutar la
instalación desde el CD o bien desde la ubicación donde hayamos descargado la versión
de pruebas, y seguir los asistentes que nos guiarán paso a paso hasta tener nuestro
servidor de base de datos operativo. Recuerden que ésta NO es la forma de instalar
ningún producto en un entorno de producción, pero como se trata de nuestro equipo de
pruebas, en esta oportunidad, nos permitiremos darnos el lujo de no invertir tiempo en
el setup, hardening, etc; tiempo que sin lugar a dudas SI DEBERA ser invertido al
momento de realizar una instalación en producción.
Herramientas y Ataques
Como probablemente sabrás, existen muchos aspectos que siendo fundamentales,

deberás tener en cuenta a la hora de realizar cualquier tipo de testeo. Entre ellos, se
encuentran dos a los cuales nos referiremos exclusivamente en este artículo: el
conocimiento de los riesgos o vulnerabilidades a los que se enfrenta la implementación
del servidor objetivo y las herramientas correctas para identificar y explotar con éxito
las vulnerabilidades encontradas.
SQL Scaning, Descubrimiento e Information Gathering
A fin de cumplir con su objetivo, un servidor de base de datos presenta servicios de

conexión los cuales suelen escuchar en diferentes puertos por defecto. Si bien a
menudo, el administrador tiene la opción de cambiar los mismos, lo cierto es que la
mayoría de las veces, esto no sucede.

En el caso de la bases de datos ORACLE por ejemplo, el puerto por defecto suele ser
1521/tcp mientras que Microsoft SQL Server por su parte, suele utilizar 1433/tcp y
1434/udp.
El puerto del terror
El 25 de Enero del 2003, un gusano llamado Sapphire también conocido como

Slammer, se identificaba como el responsable de la infección más rápida jamás sufrida
en la historia de Internet. Slammer explotaba una vulnerabilidad de buffer overrun en
computadoras corriendo versiones no parcheadas de Microsoft SQL Server o MSDE
2000 (Vulnerabilidad detectada y corregida por Microsoft un año antes!!)
Varios fueron los factores que contribuyeron en su momento, a la rápida infección de

Slammer (Parches no aplicados por los administradores, reglas de filtrado inexistentes o
mal definidas, incapacidad por parte de Microsoft de integrar servicios automáticos de
update tal como sucede con sus sistemas operativos, etc.), pero me gustaría referirme en
esta oportunidad, a la participación del port 1434/udp en este asunto.
El puerto 1434/udp, habilitado por defecto en toda instalación de SQL Server 2000, es
el frontend del servicio de resolución de SQL Server (SQL Server Resolution Service /
Microsoft SQL Port Monitor). Por medio de tal servicio, SQL Server 2000 es capaz de
administrar diferentes instancias nombradas de base de datos, actuando de un modo
“similar” a RPC en Windows o portmapper en unix.
Ahora bien, puesto que Slammer explotaba una condición de buffer overrun
precisamente en el “resolution service”, a la escucha en dicho puerto, el simple hecho de
no tener publicado hacia Internet dicho puerto, hubiera bastado para detener el ataque,
no importando si la versión de SQL Server se encontraba o no parcheada.
Pero por que menciono esto? por dos motivos, primero para desmentir el hecho de que
este port debe estar habilitado para que todo funcione. FALSO en la mayoría de los
casos, NADA dejará de funcionar al bloquear este puerto. Inclusive si en tu entorno se
están manejando diferentes instancias nombradas, bastará con configurar el cliente o la
aplicación cliente involucrada, para que conozca a donde realizar los requerimientos sin
preguntar al servicio de resolución.
Créeme, aunque los “SQL Books On Line” de Microsoft, insistan respecto de que el
port 1434 debe ser abierto en su firewall, esto sencillamente no es verdad. Siempre que
se especifique en las aplicaciones a utilizar, el port de la instancia nombrada como parte
del string de conexión no existirá problema alguno.

Como no podía ser de otro modo, lo primero que haremos será lanzar un escaneo del
host objetivo a fin de confirmar la existencia de servicios de SQL expuestos. En mi
caso, la línea de comando nmap luce del siguiente modo:
c:\nmap –sS –sU 172.16.1.96
En la figura 1, puedes observar la salida obtenida a partir de la corrida de nmap en mi

entorno de pruebas.
Figura 1
Como verás, dos puertos anuncian la posible presencia de un servidor SQL corriendo en
este host:
1433/tcp open ms-sql-s

1434/udp open | filtered ms-sql-m
Es un buen comienzo... ahora veamos que información adicional podemos obtener a

partir de estos puertos. A tal efecto utilizaremos una herramienta denominada
“SQLRecon” desarrollada por Chip Andrews, de sqlsecurity.com que combinando
técnicas de scanning tanto activas como pasivas, nos permitirá extraer información que
seguramente podremos aprovechar en algún punto del ataque.
“SQLRecon” es considerada por algunos, como la evolución de una pequeña pero

innovadora herramienta del mismo autor, denominada “SQLPing”. Si bien es cierto que
la versión de línea de comandos de “SQLPing” permite su inclusión en tareas
programadas o scripting, lo cierto es que “SQLRecon” posee algunas mejoras
importantes respecto por ejemplo, de las técnicas de reconocimiento utilizadas, o de su

capacidad de auditar toda la red y descubrir instalaciones de SQL Servers/MSDE, de las

cuales probablemente el administrador no tenga conocimiento.
Su utilización es sencilla, una vez descargada e instalada (No deberías tener problemas
con su asistente, solo tener la precaución de cumplir con el requerimiento de tener
instalado en tu equipo, .Net Framework 1.1), la ejecutaremos ingresando tan solo la
dirección IP de nuestro servidor objetivo, en los campos mencionados como Start/End
dentro del cuadro “IP Range”. Luego tan solo presionaremos “Scan” y esperaremos los
resultados.
En mi caso en particular y tan solo para remarcar el valor agregado de esta herramienta
como parte de vuestro proceso interno de auditoría, he decidido lanzar un scanning
sobre toda mi red de pruebas. En la Figura 2 puedes observar el resultado obtenido.
Recomiendo que intentes también ejecutar “SQLPing”, comprobarás que la información
brindada es en esencia la misma. Figura 3
Figura 2

Figura 3
Pero recapitulemos... que hemos obtenido hasta aquí? En principio, descubrimos que
nuestro servidor objetivo efectivamente se encuentra corriendo alguna versión de
Microsoft SQL Server, por otra parte, “SQLPing” y “SQLRecon” nos hicieron saber
que:
- El nombre del Servidor (HONEYNET, el nombre de mi equipo de prueba)

- El nombre de la Instancia SQL (MSSQLSERVER, el nombre por defecto)
- Que el equipo no forma parte de un Cluester SQL (IsClustered: No)
- Que el equipo esta utilizando un password nulo o en blanco para el usuario SA
(El usuario con mayor privilegio en MS SQL Server!!)
- El número de versión de MS SQL Server corriendo en el server (8.00.194)
Vamos a detenernos tan solo un segundo en este ultimo punto. Cada versión de
Microsoft SQL Server, puede ser identificada por un número, que “idealmente” refleja
el estado de instalación del software, esto es... no solo su versión base, sino también el
nivel de parches y services packs!! Información imprescindible al momento de planear
un ataque!! A fin de interpretar correctamente este número de versión, vamos a valernos
de una lista que podrás encontrar disponible en Internet en el siguiente URL:
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=37
Este excelente documento, muestra una base de datos conformada por registros
conteniendo número de versión y descripción. Si hechas un vistazo a la Figura 4 podrás
observar lo útil y sencillo de utilizar que resulta este recurso. También podrás observar
que en mi entorno de prueba, la descripción que se corresponde con el número de
versión de SQL Server de mi servidor objetivo es:

8.00.194 2000 RTM/No SP
Lo cual indica que estamos frente a un SQL Server 2000 sin Service Pack ni parches
instalados… ideal para mostrar algunas de las cosas que veremos a continuación.
Figura 4
Hora de Disparar
Perfecto! ahora que conocemos la versión y el nivel de SP (Sin SP en mi caso!!)

podremos concentrarnos en intentar la explotación. Varios son los modos aunque por
cuestiones de espacio, nos concentraremos puntualmente en tres o cuatro de los ataques
mas comúnmente utilizados.
Microsoft SQL Server... Buffer Overflows
A mediados del año 2002, el ambiente relacionado con la seguridad informática, se

conmociono al conocer la existencia de tres nuevas vulnerabilidades relacionadas con
condiciones de buffer overflows en Microsoft SQL Server, dos descubiertos por David
Litchifield de NGSSoftware (Uno basado en stack y otro basado en heap), los cuales
ocurrían sobre el servicio de “Port Monitor / Resolution Service” a la escucha en
1434/udp y un tercero descubierto por Dave Aitel de Inmmunity Security Inc, y
conocido como “Hello Bug”, el cual a diferencia de los primeros, interactuaba con el
port de servicio 1433/tcp. Una característica en común: todos ellos permitían su
explotación de modo no autenticado!!.
Pero... volvamos a nuestro laboratorio de pruebas e intentemos explotar alguno de estos

bugs!!

Hello Bug!!!
Oportunamente, Dave Aitel descubrió que al momento de conectar al servicio corriendo

en el puerto 1433/tcp, y precisamente antes de que la autenticación tome lugar, algunos
paquetes eran intercambiados entre el cliente y el server. En resumen, alterando el
contenido del primer paquete enviado por el cliente, era posible explotar una condición
de stack buffer overflow, a partir de lo cual podía ejecutarse código arbitrario sobre el
servidor objetivo. He aquí, la razón del nombre con el cual se conoció este bug...
“Hello”.
Si estas interesado en revisar el aspecto que tiene el código de un exploit capaz de

explotar esta vulnerabilidad, te recomiendo actualices tu versión de Metasploit
Framework (En mi ultimo artículo encontraras como...) y hecha un vistazo al exploit
bajo el nombre “mssql2000_preauthentication”. Si por el contrario gustas de las cosas
directas, una búsqueda en google respecto de “sqlhello.rar” te guiará hacia el exploit
que intentaremos ejecutar en nuestro laboratorio. Una vez descargado y descomprimido,
lo ejecutaremos sin parámetros esperando algún tipo de ayuda:
D:\Tools\Database\sqlhello\
SQL Hello Exploit – Remote Shell Callback by JoePub
sqlhello victimip victimport
victimip Address of host to send exploit payload

victimport Port to attack on victim
D:\Tools\Database\sqlhello
Como podrás observar el trabajo duro aquí lo ha hecho JoePub, tu tan solo tendrás que
verificar que el server donde lanzaras el exploit es vulnerable (<SP3). Confirmado este
punto (tal es el caso en nuestro entorno de pruebas...) bastará con completar la IP y el
port (1433) del equipo víctima y esperar la obtención de una shell remota. En mi caso,
finalmente la línea de comandos tiene el siguiente aspecto:
D:\Tools\Database\sqlhello\sqlhello2 172.16.1.96 1433
y la Figura 5 muestra la secuencia mencionada y la obtención de nuestra consola en el

servidor objetivo, con privilegios de SYSTEM.
Ataque al port 1434
David Litchfield, descubrió que cuando SQL Server recibía un paquete con el primer
byte seteado a 0x04, “SQL Monitor Port” sucedían una serie de eventos que podían ser
aprovechados para construir un ataque y provocar un buffer overflow en el stack, a
partir del cual era posible comprometer el sistema objetivo, nuevamente sin necesidad

de estar autenticado. Para llevar a la práctica este ataque, nos valdremos de lo aprendido
en un artículo pasado, cuando conocimos Metasploit Framework.
Figura 5
El exploit en cuestión, lo encontraras en el Framework Metasploit, bajo el nombre

“mssql2000_resolution”. Puesto que probablemente ya estés al tanto del manejo de la
consola en Metasploit (Algunos números atrás, nos encargamos de mostrarte su
funcionamiento), tan solo especificaré los comandos que me ha tomado lanzar este
exploit contra el servidor dispuesto en mi laboratorio de pruebas:
msf > use mssql2000_resolution

msf mssql2000_resolution > set RHOST 172.16.1.96
RHOST à 172.16.1.96
msf mssql2000_resolution > set PAYLOAD win32_bind
PAYLOAD à win32_bind
msf mssql2000_resolution(win32_bind) > exploit
Perfecto! si todo ha salido bien, habrás obtenido nuevamente, una shell remota sobre el
sistema objetivo, con altos privilegios!! (Figura 6) Ten en cuenta, que ante
determinadas circunstancias, debido al modo de funcionamiento de este exploit, puede
que el servicio “Agente de SQL Server” haya sido “stopeado” en el transcurso de la
explotación, sobre el servidor objetivo. Si tienes dudas, bastara con que des entrada al
siguiente comando, en la consola remota:
Microsoft Windows 2000 [Version 5.00.2195]

(C) Copyright 1985-2000 Microsoft Corp.
C:\WINNT\system32\net start sqlserveragent

Con esto bastara para que el servicio de agente de SQL Server, vuelva a funcionar.
Figura 6
Desde Adentro…
Probablemente muchas hayan sido las veces, que habrás escuchado mencionar aquella
teoría que dicta que la mayor parte de los ataques sufridos por una organización,
provienen del interior. Esto es, visitantes eventuales, empleados disconformes,
administradores comprados, etc.
Por otra parte, es importante tener en cuenta, que TODO software de base de datos
incluye debilidades que pueden ser explotadas, si luego de realizada su instalación
inicial, no son realizados una serie de cambios (Proceso que comúnmente se conoce
como hardening)
Microsoft SQL Server no es la excepción, permisos débiles a nivel file system y objetos
del propio servidor de base de datos, tal como procedimientos almacenados al alcance
de usuarios con pocos privilegios, suelen a menudo convertirse en un potencial riesgo
para todo administrador de base de datos.
Al solo efecto de ejemplificar tan solo uno de los ataques posibles relacionados con este
vector, mencionaremos una serie de “Procedimientos Almacenados Extendidos” o
“Extended Store Procedures”, que pueden ser abusados por un usuario que habiendo
obtenido previamente acceso autenticado de Windows a SQL Server, puede ser capaz

de ejecutar comandos del sistema operativo con los mismos privilegios que el usuario
corriendo el motor de base de datos!!!
“xp_execresultset”, “xp_printstatements” y “xp_displayparamstmt” entre otros, son

precisamente tres procedimientos almacenados extendidos, que en una instalación por
defecto permitirían al usuario, ejecutar consultas arbitrarias. Cuando la consulta
parametrizada sea ejecutada, SQL Server intentara una reconexión a si mismo con sus
propias credenciales… y finalmente ejecutara la consulta indicada con dicho privilegio
y no con los del usuario original!
Pero veamos un ejemplo para que quede mas claro:
exec xp_displayparamstmt N’exec master..xpcmdshell ‘’dir >

c:\listado.txt’’’,N’master’,1
Nota: Ten en cuenta que este ataque puede no funcionar en tu equipo de pruebas. Esto
dependerá del nivel de SP o parches instalados, así como también del tipo de
autenticación que hayas seleccionado al momento de la instalación. Recuerda que el
problema al que nos referimos en este caso, requiere “Autenticación de Windows” y no
“Autenticación SQL Server”.
Si todo falla…
Como no podía ser de otro modo, SQL Server al igual que la mayoría del software que
utiliza algún tipo de método de autenticación por medio de usuario/contraseña, es
susceptible a un ataque por fuerza bruta. El condimento adicional en Microsoft SQL
Server, es que este software posee una cuenta denominada SA (System Administrador),
la cual hasta la llegada del SP3 podía permanecer en blanco!! Apuesto a que estas
pensando lo mismo que yo… adivina… ok… adivinaste… la verdad es que aunque
cueste creerlo, hoy en día tienes muchas probabilidades de encontrar un servidor SQL
Server al cual puedas acceder con solo identificarte como SA/blank.
Pero… suponiendo que nos encontramos ante un servidor con Microsoft SQL Server
instalado, con el port 1433/tcp accesible desde el exterior, y en donde el administrador
haya asignado un password por ti desconocido, aun tendremos la chance de intentar
adivinar, brutforcear, o atacar mediante técnicas de diccionario la cuenta SA. A tal
efecto, utilizaremos una herramienta denominada “SQLDict”, de Arne Vidstrom.
“SQLDict”, (Figura 7) es una sencilla y útil herramienta de interfaz grafica para

Windows, mediante la cual podremos lanzar un ataque de diccionario contra la cuenta
de nuestra elección. Para echar a correr “SQLDict”, bastara con proveerle los siguientes
parámetros: dirección IP del servidor objetivo, nombre de la cuenta a atacar y archivo
de diccionario a utilizar.

Luego de una larga espera, y con un poco de suerte, “SQLDict” probablemente nos
brinde una grata noticia, al mostrarnos la password correcta para el usuario SA del
servidor objetivo.
Figura 7
Conclusiones
El software de base de datos, ha llegado para formar parte de toda organización

moderna. Su potencial e importancia dentro del mundo de los negocios, ha cambiado la
forma de trabajar en muchos aspectos. Es hora que administradores y responsables de
seguridad, entiendan la implicancia de trabajar con base de datos, se esmeren por
conocer más acerca de su comportamiento interno y el modo en que pueden ser
protegidas.
Claro esta que el hecho de haber tratado en este articulo con Microsoft SQL Server, no
significa que sea ni mas ni menos segura que otras bases de datos, de hecho, al
momento de escribir este articulo, existen cerca de 60 ataques 0 Day’s capaces de
afectar cualquier instalación de Oracle… una base de datos en teoría “Unbrekeable”!!!
(Ver Argeniss en Referencias).
Mantén en mente que lo mostrado en este articulo, no llega a conformar ni una décima
parte de los riesgos u ataques a los que se encuentra sometida una base de datos en

producción. Por el contrario, solo intenta alertar a los usuarios en general acerca de las
posibilidades en la explotación de este tipo de aplicaciones.
Antes de terminar, no quería dejar de mencionar otro aspecto que debe ser tenido en
cuenta. En este caso me estoy refiriendo a la proliferación de instalaciones del software
conocido como MSDE (SQL Server 2000 Desktop Engine) dentro de las
organizaciones. Muchas de las aplicaciones de oficina, así como algunas de las
herramientas de desarrollo de Microsoft, requieren este software instalado en el desktop.
Pero por que hay que tener en cuenta dichas instalaciones? precisamente porque son ni
mas ni menos que BASES DE DATOS, susceptibles a gran parte de los mismos ataques
a los cuales son susceptibles sus hermanos mayores, con la diferencia que a menudo
estas instalaciones pasan desapercibidas para los administradores de red y al estar fuera
de su control, se mantienen vulnerables a la espera de que un atacante se aproveche de
ellas. Créeme, si alguien penetra en tu red, probablemente no pierda el tiempo en atacar
tu gran servidor de base de datos directamente, por el contrario, probablemente obtenga
administrator en algún desktop con MSDE, a partir del cual intentara otro tipo de
ataques mas elaborados, sobre tu gran servidor de base de datos.
Por ultimo, debes tener presente que el testing de base de datos, requiere de algunas
técnicas y herramientas particulares al momento de ser realizado. Si bien es cierto que
algunas de las más populares herramientas Open Source, tal como Nessus, son capaces
de detectar algunas de las vulnerabilidades más comunes, si deseas realizar un test
profesional, probablemente encuentres en aplicaciones comerciales tales como
“AppDetective”, de “Application Security Inc” o “NGSSquirrel” de “NGS Software”
una excelente opción.
Recuerda, la seguridad es un proceso continuo… mantente al tanto de las ultimas

técnicas y vulnerabilidades, elabora políticas y procedimientos que incluyan el trabajo
con base de datos y el modo en que el usuario tiene permitido interactuar con ellas,
trabaja en la seguridad de tu base de datos, teniendo en cuenta que esta será tan solo
“una capa mas” a la hora de estar protegido, pero que deberá ser complementado con el
resto de los mecanismos de seguridad a los que estas acostumbrado, tal como firewalls,
IDS, seguridad en profundidad, seguridad física, etc. Contrata auditorias externas en
forma periódica, y si están especializadas en base de datos… mejor aun.
Finalmente, no olvides lo que mencionamos al inicio, no hay necesidad de que los

puertos de tu base de datos se encuentren publicados hacia el exterior.
Ups… y me olvidaba, nunca… pero nunca… confíes en tus usuarios internos, menos
aun, cuando ellos son usuarios de tu base de datos : )
Hernán Marcelo Racciatti


Referencias
http://www.microsoft.com/sql/evaluation/trial
http://www.insecure.org/nmap/nmap_download.html
http://www.metasploit.org
http://www.google.com
http://www.argeniss.com/products.html
http://ntsecurity.nu/toolbox
http://www.appsecinc.com/products
http://www.ngssoftware.com/software.htm


HPP26 Seguridad en Base de Datos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HPP26 Seguridad en Base de Datos

Uploaded by

Copyright:

Available Formats

Artículo publicado en la revista @RROBA # 95

Suplemento “Hack Paso a Paso” #26 – Octubre 2005

Seguridad en Base de Datos

En las próximas paginas, recorreremos algunos conceptos generales de seguridad en

Como consultor en seguridad informática, a menudo me encuentro asesorando a clientes

Copyright © 2005 Hernán Marcelo Racciatti 1

materia de seguridad a fin de sentirse un poco más seguros. Con el tiempo, he

Las bases de datos no conforman precisamente la excepción a la regla, y del mismo

- El administrador de sistemas o redes, encargado de la seguridad del host

Copyright © 2005 Hernán Marcelo Racciatti 2

Donde están los intrusos!

Bien, en los párrafos anteriores intente plasmar la problemática de los servidores de

Copyright © 2005 Hernán Marcelo Racciatti 3

Muchos administradores relajan sus controles hacia adentro, presuponiendo que el

Diferentes tipos de Ataques

Si bien entre los profesionales que conformamos la comunidad de seguridad

Otros ataques dignos de ser mencionados, dentro de aquellos que No Requieren

Copyright © 2005 Hernán Marcelo Racciatti 4

Copyright © 2005 Hernán Marcelo Racciatti 5

Instalando Microsoft SQL Server 2000

Si quieres seguir los ejemplos que mencionaremos a continuación y no posees ningún

Como probablemente sabrás, existen muchos aspectos que siendo fundamentales,

SQL Scaning, Descubrimiento e Information Gathering

A fin de cumplir con su objetivo, un servidor de base de datos presenta servicios de

Copyright © 2005 Hernán Marcelo Racciatti 6

El puerto del terror

El 25 de Enero del 2003, un gusano llamado Sapphire también conocido como

Varios fueron los factores que contribuyeron en su momento, a la rápida infección de

Copyright © 2005 Hernán Marcelo Racciatti 7

c:\nmap –sS –sU 172.16.1.96

En la figura 1, puedes observar la salida obtenida a partir de la corrida de nmap en mi

1433/tcp open ms-sql-s

Es un buen comienzo... ahora veamos que información adicional podemos obtener a

“SQLRecon” es considerada por algunos, como la evolución de una pequeña pero

Copyright © 2005 Hernán Marcelo Racciatti 8

capacidad de auditar toda la red y descubrir instalaciones de SQL Servers/MSDE, de las

Copyright © 2005 Hernán Marcelo Racciatti 9

- El nombre del Servidor (HONEYNET, el nombre de mi equipo de prueba)

Copyright © 2005 Hernán Marcelo Racciatti 10

8.00.194 2000 RTM/No SP

Perfecto! ahora que conocemos la versión y el nivel de SP (Sin SP en mi caso!!)

Microsoft SQL Server... Buffer Overflows

A mediados del año 2002, el ambiente relacionado con la seguridad informática, se

Pero... volvamos a nuestro laboratorio de pruebas e intentemos explotar alguno de estos

Copyright © 2005 Hernán Marcelo Racciatti 11

Oportunamente, Dave Aitel descubrió que al momento de conectar al servicio corriendo

Si estas interesado en revisar el aspecto que tiene el código de un exploit capaz de

sqlhello victimip victimport

victimip Address of host to send exploit payload

D:\Tools\Database\sqlhello\sqlhello2 172.16.1.96 1433

y la Figura 5 muestra la secuencia mencionada y la obtención de nuestra consola en el

Ataque al port 1434

Copyright © 2005 Hernán Marcelo Racciatti 12

El exploit en cuestión, lo encontraras en el Framework Metasploit, bajo el nombre

msf > use mssql2000_resolution

Microsoft Windows 2000 [Version 5.00.2195]

C:\WINNT\system32\net start sqlserveragent

Copyright © 2005 Hernán Marcelo Racciatti 13

Copyright © 2005 Hernán Marcelo Racciatti 14

“xp_execresultset”, “xp_printstatements” y “xp_displayparamstmt” entre otros, son

Pero veamos un ejemplo para que quede mas claro:

exec xp_displayparamstmt N’exec master..xpcmdshell ‘’dir >

“SQLDict”, (Figura 7) es una sencilla y útil herramienta de interfaz grafica para

Copyright © 2005 Hernán Marcelo Racciatti 15