Automatizar la evaluación y explotación de vulnerabilidades de Inyección SQL con Sqlninja

 

https://www.onlinetis.com

Automatizar la evaluación y explotación de vulnerabilidades de Inyección SQL con Sqlninja

Sqlninja es una herramienta de pruebas de penetración incluida históricamente en distribuciones como Kali Linux. Su propósito principal es automatizar la evaluación y explotación de vulnerabilidades de Inyección SQL (SQLi) específicamente en entornos que utilizan Microsoft SQL Server (MS SQL) como base de datos de almacenamiento.

¿Cómo funciona conceptualmente?

Cuando una aplicación web no desinfecta adecuadamente las entradas del usuario antes de concatenarlas en una consulta a la base de datos, un atacante o auditor puede alterar la lógica de la consulta.

Sqlninja aprovecha estas fallas para realizar tareas como:

• Fingerprinting: Identificar la versión exacta y configuración de MS SQL Server.

• Escalada de privilegios: Detectar si el usuario de la base de datos tiene privilegios elevados (como sa).

• Extracción e integración: Automatizar el acceso a datos o ejecutar comandos en el sistema operativo subyacente si la función xp_cmdshell está habilitada en el servidor.

Prevención y Mitigación

Para proteger las bases de datos contra los ataques de inyección SQL que herramientas como Sqlninja evalúan, se deben aplicar las siguientes buenas prácticas en el código y la infraestructura:

1. Consultas Preparadas (Parameterized Queries):

   Es la medida defensiva más directa. Separa las instrucciones SQL de los datos proporcionados por el usuario, evitando que las entradas se interpreten como código.

   SQL

   -- Ejemplo seguro (sentencia preparada en C#)
   SqlCommand cmd = new SqlCommand("SELECT * FROM Users WHERE Username = @user", conn);
   cmd.Parameters.AddWithValue("@user", inputUsuario);
   

2. Principio de Mínimo Privilegio:

   Configurar el usuario de la base de datos con los permisos estrictamente necesarios. Deshabilitar procederes almacenados peligrosos en MS SQL Server como xp_cmdshell si no son indispensables.

3. Uso de ORM (Object-Relational Mapping):

   Frameworks modernos (como Entity Framework o Hibernate) manejan la parametrización de consultas de manera automática por defecto.

El proceso de bastionado (hardening) en Microsoft SQL Server busca reducir la superficie de ataque del gestor de base de datos y proteger tanto la información almacenada como el servidor host que la aloja.

A continuación se resumen los pilares y configuraciones clave recomendados por marcos de seguridad como los CIS Benchmarks (Center for Internet Security).

1. Gestión de Cuentas y Control de Acceso

• Cambiar el modo de autenticación a Windows Authentication Only:

  Siempre que sea posible, deshabilita la autenticación mixta para forzar el uso de Active Directory / Windows AD. Esto permite aplicar políticas de contraseñas complejas y autenticación multifactor (MFA).

• Deshabilitar o renombrar la cuenta sa:

  La cuenta de administrador por defecto (sa) es un objetivo principal en ataques de fuerza bruta. Si no es posible eliminarla, asígnale una contraseña extremadamente compleja de larga extensión y deshabilítala.

• Principio de mínimo privilegio:

  Evita otorgar el rol sysadmin a cuentas de servicio o aplicaciones web. Las aplicaciones deben conectarse utilizando cuentas dedicadas con permisos limitados explícitamente a las tablas, vistas o procedimientos almacenados estrictamente necesarios.

2. Desactivación de Características Sensibles

SQL Server incluye características avanzadas de integración con el sistema operativo que deben mantenerse deshabilitadas a menos que exista un requerimiento de negocio justificado:

• Deshabilitar xp_cmdshell:

  Permite la ejecución de comandos de consola de Windows desde SQL.

  SQL

  EXEC sp_configure 'show advanced options', 1;
  RECONFIGURE;
  EXEC sp_configure 'xp_cmdshell', 0;
  RECONFIGURE;
  

• Desactivar CLR Strict Security / OLE Automation / Ad Hoc Distributed Queries:

  Evita que se carguen ensamblados .NET no autorizados o se realicen consultas ad-hoc hacia fuentes de datos externas.

  SQL

  EXEC sp_configure 'Ole Automation Procedures', 0;
  RECONFIGURE;
  EXEC sp_configure 'Ad Hoc Distributed Queries', 0;
  RECONFIGURE;
  

3. Seguridad de Red e Infraestructura

• Cambiar el puerto por defecto (1433):

  Aunque el cambio de puerto no sustituye a la seguridad real, dificulta el escaneo automatizado en la red local.

• Deshabilitar el servicio SQL Server Browser:

  Este servicio responde a peticiones para enumerar instancias de SQL Server en la red. Si la instancia utiliza un puerto fijo, el servicio Browser no es necesario y debe detenerse.

• Forzar cifrado en tránsito (TLS/SSL):

  Configurar el servidor para exigir conexiones cifradas (Force Encryption = Yes) mediante certificados digitales válidos para proteger las credenciales y los datos en tránsito.

4. Protección de Datos y Auditoría

• Cifrado de datos en reposo (Transparent Data Encryption - TDE):

  Cifra las bases de datos de usuario, archivos de registros y respaldos (backups) a nivel de archivo sin modificar el código de las aplicaciones.

• Auditoría de SQL Server (SQL Server Audit):

  Configurar registros de auditoría para monitorizar eventos críticos como:

  • Intentos de inicio de sesión fallidos y exitosos.

  • Cambios en los roles de servidor o base de datos (sysadmin, db_owner).

  • Modificación de configuraciones a nivel de servidor (sp_configure).

Checklist Rápido de Verificación

Área	Configuración Recomendada
Autenticación	Windows Authentication Only
Cuenta sa	Deshabilitada y con contraseña compleja
Integración SO	xp_cmdshell = 0
Red	Puerto personalizado + TLS/SSL obligatorio
Auditoría	Monitoreo de inicios de sesión fallidos activado

https://www.onlinetis.com