Un estudio de caso en la vulnerabilidad de la seguridad de base de datos

En este estudio de caso, Chip Andrews, experto en seguridad de SQL Server, compartió esta experiencia (éticamente) la piratería en una base de datos de clientes para descubrir fallos de seguridad. Este ejemplo proporciona una advertencia para proteger su información importante al insistir en la seguridad de base de datos de sonido.

La situacion

Durante una prueba de penetración de rutina, el Sr. Andrews realizó las búsquedas obligatorias de Google, la investigación de nombres de dominio, las huellas digitales del sistema operativo, y el escaneo de puertos, pero este sitio web en particular fue cerrada apretado. Pasando a la aplicación basada en la web que se ejecuta en el sistema, se enfrentó de inmediato con una página de inicio de sesión utilizando la autenticación de formularios con cifrado SSL.

Al marcar la fuente de la página web, se dio cuenta de que un oculto Nombre de la aplicación campo se está pasando a la aplicación cada vez que un usuario ha intentado iniciar sesión en el sitio. ¿Podría ser que los desarrolladores podrían haber dejado de realizar la validación de entrada correcta en este parámetro de aspecto inocente? La caza estaba en marcha.

El resultado

En primer lugar, que era el momento de montar el kit de herramientas. En el momento de esta prueba de penetración, el Sr. Andrews prefiere utilizar el siguiente: Paros Proxy, ajenjo, Caín Abel, Ladrón de datos, y el estudio de la gerencia de Microsoft SQL Server / SQL Server (Express Edition), todos los cuales están disponibles gratuitamente.

Para empezar, utilizó Paros Proxy para permitir un mayor control y visibilidad a las peticiones web realizados en el servidor web.

Después de spidering el sitio para páginas disponibles y llevar a cabo una comprobación de vulnerabilidad rápida para inyección SQL, se confirmó que la Nombre de la aplicación parámetro pareció causar la aplicación de una excepción de error 500, lo que indica un fallo de la aplicación. Pruebas de penetración son una de las raras ocasiones en que un fallo de la aplicación es un resultado deseable.

Debido a la falta de aplicación indica que el Sr. Andrews podría inyectar caracteres no deseados en el código SQL que se envían desde la aplicación a la base de datos, podría ver si se trataba de una situación vulnerable.

Una prueba común que funciona con bases de datos de Microsoft SQL Server es inyectar un comando, como WAITFOR RETRASO '00: 00: 10 ', que hace que el servidor de base de datos se pare durante 10 segundos. En una aplicación que normalmente devuelve una página en un segundo o menos, un constante retraso de 10 segundos es un buen indicador de que se puede inyectar comandos en el flujo SQL.

A continuación, el Sr. Andrews intentó utilizar la herramienta Ladrón de datos para atacar a la página de inicio de sesión. Esta herramienta intenta forzar la base de datos para utilizar una OPENROWSET comando para copiar datos de la base de datos de destino para la base de datos del señor Andrews se encuentra en Internet.

Esto suele ser un medio muy eficaz para desviar grandes cantidades de datos desde bases de datos vulnerables, pero en este caso, su ataque fue frustrado! El administrador de la base en el objetivo se había desactivado el OPENROWSET funcionalidad configurando correctamente la opción Desactivar Adhoc consultas distribuidas.

Con diligencia como su consigna, el Sr. Andrews persistió con el siguiente herramienta - ajenjo. Esta herramienta utiliza una técnica llamada inyección SQL ciega para hacer determinaciones acerca de los datos utilizando sí simple o no preguntas de la base de datos. Por ejemplo, la herramienta podría preguntar la base de datos si la primera letra de una tabla es menos de " L. "

Si es así, la aplicación puede hacer nada, pero si no, la aplicación podría lanzar una excepción. Usando esta lógica binaria simple, es posible utilizar esta técnica para revelar toda la estructura de base de datos e incluso los datos almacenados en el interior - aunque muy lentamente. Con la herramienta, se identificó una mesa de información confidencial de clientes y descargar cientos de registros para mostrar al cliente.

Finalmente, llegó el momento de intentar un último acto de dastardliness base de datos. En primer lugar, el Sr. Andrews carga la herramienta llamada Caín Abel y configurarlo para acceder al modo oler. Luego, utilizando Paros Proxy y el parámetro vulnerables ya identificadas, utilizó la xp_dirtree procedimiento almacenado extendido, que está disponible para los usuarios de bases de datos SQL Server, para tratar de mostrar un directorio en su máquina conectada a Internet mediante una ruta de Convención de nomenclatura universal.

Esto obligó a la base de datos de destino para intentar realidad para autenticarse contra el equipo del Sr. Andrews. Porque Caín Abel estaba escuchando en el alambre, se obtiene el hash del reto utilizado para autenticar el recurso compartido de archivos expuestos.

Con la aprobación de este hash con la galleta de la contraseña incorporado a Caín Abel, el Sr. Andrews tendría el nombre de usuario y la contraseña de la cuenta con la que los más vulnerables de SQL Server se ejecuta en sólo cuestión de tiempo.

¿Quieres utilizar esta cuenta hackeada la misma contraseña que la cuenta de administrador de la aplicación web? ¿Sería esta contraseña será la misma que la cuenta de administrador local en el host? Esas fueron las preguntas para otro día. Era el momento de reunir todos los datos recogidos, preparar un informe para el cliente, y poner las herramientas de distancia para otro día.

Viruta Andrews es un co-fundador de la firma de consultoría de seguridad de Operaciones Especiales de Seguridad, Inc. y propietario de SQLSecurity.com, que cuenta con múltiples recursos sobre seguridad de Microsoft SQL Server, incluyendo la herramienta SQLPing3. Un co-autor de varios libros sobre la seguridad de SQL Server y un presentador de Sombrero Negro, el Sr. Andrews ha estado promoviendo la seguridad de aplicaciones de SQL Server y desde el año 1999.