Enfoque de DataSunrise para Configurar Penalizaciones por Detección de Inyección SQL

La inyección SQL es una amenaza prevalente para la seguridad de las bases de datos, donde los atacantes manipulan consultas SQL para obtener acceso no autorizado a los datos. DataSunrise, una solución de seguridad para bases de datos, ofrece un mecanismo robusto para detectar y prevenir ataques de inyección SQL mediante un sistema de puntos de penalización. Este artículo explorará cómo DataSunrise configura las penalizaciones para diferentes tipos de patrones de inyección SQL y proporcionará ejemplos de cada uno.

Sistema de Puntos de Penalización

El sistema de puntos de penalización de DataSunrise asigna un valor numérico a varios componentes de una consulta SQL que pueden indicar una posible inyección. Cuando la suma de estas penalizaciones supera un umbral predefinido, DataSunrise toma medidas, ya sea registrando una advertencia (Regla de Auditoría) o bloqueando la consulta por completo (Regla de Seguridad).

Ejemplos de Patrones de Inyección SQL y Penalizaciones

Penalización por Comentario

Una de las tareas básicas para un atacante cuando intenta realizar una inyección es cambiar radicalmente la solicitud. Para ello, necesita desactivar/cortar esa parte de la solicitud que no controla o que le impedirá realizar la inyección. Para esto, se añade código a la inyección que comentará esa parte de la solicitud que se encuentra después del bloque inyectado. Aquí hay algunos ejemplos.

1 Ejemplo. Un ejemplo común es el inicio de sesión como administrador:

Inyección en el parámetro de nombre de usuario: admin’–

SELECT * FROM miembros WHERE nombre_de_usuario = 'admin'--' AND contraseña = 'contraseña'

Si tiene éxito, esto te iniciará sesión como el usuario administrador porque el resto de la consulta SQL después de ‘–’ será ignorada.

2 Ejemplo. Ejemplos Clásicos de Ataques de Inyección SQL con Comentarios Inline

valor de ID: 10; DROP TABLE miembros /*

Simplemente deshazte de otras cosas al final de la consulta. Igual que 10; DROP TABLE miembros –

Por lo tanto, la presencia de comentarios en la solicitud es uno de los signos de una posible inyección.

Una Palabra Clave en una Penalización por Comentario

Continuando con el tema de los comentarios en una solicitud, podemos decir que los comentarios ordinarios pueden encontrarse con bastante frecuencia en solicitudes legítimas. Por ejemplo, muchos IDE utilizados por los desarrolladores añaden automáticamente la hora actual al inicio de la solicitud en forma de comentario o la versión del IDE en la que se generó la solicitud u otra información meta. Por lo tanto, un signo adicional de que un comentario es sospechoso es la presencia de palabras clave SQL en él, como AND/OR/SELECT, etc.

Por ejemplo, en la expresión SQL discutida anteriormente

SELECT * FROM miembros WHERE nombre_de_usuario = 'admin'--' AND contraseña = 'contraseña'

La palabra clave AND fue comentada.

Penalización por Consulta Doble (Apilamiento de Consultas)

El apilamiento implica ejecutar más de una consulta en una transacción. Esta técnica puede ser útil pero solo funciona para algunas combinaciones de servidor de base de datos y métodos de acceso:

SELECT * FROM miembros; DROP miembros--`

Cuando tiene éxito, esto terminará una consulta e iniciará otra.

No todas las bases de datos soportan la ejecución de dos o más expresiones en una consulta, pero donde se soporta, tales casos necesitan ser controlados.

DataSunrise no genera errores si se usan expresiones de configuración (SET y similares) o consultas de declaración de variables en una expresión. Tales solicitudes no son inusuales.

Penalización por OR + Penalización por Expresión Constante

A menudo, para usar una u otra inyección, un atacante necesita crear una condición tal que sea verdadera (TRUE). Y para esto, la forma más simple puede ser una operación OR con un valor que siempre es TRUE. Por ejemplo, como en el ejemplo: https://insecure-website.com/products?category=Gifts’+OR+1=1–

Esto da como resultado la consulta SQL:

SELECT * FROM productos WHERE categoría = 'Gifts' OR 1=1--' AND lanzado = 1

En este caso, la consulta mostrará todas las categorías, y no solo las que debería.

Por supuesto, la operación OR es común y popular en el desarrollo de aplicaciones, pero junto con otros signos, puede ayudar a detectar la inyección. Lo mismo se aplica a las expresiones que siempre devuelven TRUE o FALSE.

Penalización por Unión

Nuestra investigación ha demostrado que los atacantes cibernéticos utilizan herramientas automatizadas que les ayudan a identificar la posibilidad teórica de explotar una vulnerabilidad particular. Si es posible agregar una expresión adicional a una consulta vulnerable, entonces generalmente se verifica la capacidad de acceder a otras tablas

select id, id from productos where nombre = 'Gifts' UNION SELECT NULL, NULL from SYS.USERS --'

Cuando realizas un ataque de inyección SQL UNION, hay dos métodos efectivos para determinar cuántas columnas están siendo devueltas por la consulta original.

Un método consiste en enviar una serie de cargas útiles de UNION SELECT especificando un número diferente de valores nulos:

' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT NULL,NULL,NULL–, etc.

Si la cantidad de valores nulos no coincide con la cantidad de columnas, la base de datos devuelve un error, como:

Todas las consultas combinadas utilizando un operador UNION, INTERSECT o EXCEPT deben tener un número igual de expresiones en sus listas de destino.

Un atacante usa NULL como los valores devueltos de la consulta SELECT inyectada porque los tipos de datos en cada columna deben ser compatibles entre la consulta original y las inyectadas. NULL es convertible a cada tipo de datos común, por lo que maximiza las probabilidades de que la carga útil tenga éxito cuando el recuento de columnas sea correcto.

Para reducir las posibilidades de detectar una inyección, DataSunrise detecta UNIÓN similares que se utilizan al escanear aplicaciones vulnerables y asigna puntos de penalización adicionales.

Conversión Sospechosa: Ataque por Error

La técnica de Inyección SQL basada en errores fuerza a la base de datos a generar un error, dando al atacante o al probador información sobre la cual afinar su inyección.

Para forzar a una aplicación a generar una solicitud que se ejecutará con un error, se usan muchas técnicas diferentes. Una de ellas son las operaciones que explícitamente o implícitamente intentan convertir un valor a un tipo al cual no puede ser convertido:

' and 1=convert(int,(select top 1 table_name from information_schema.tables))--

En este caso, se generará un error, cuyo texto incluirá un valor de texto de la tabla del sistema information_schema.tables.

Sin embargo, esta técnica no se limita a tales ataques. Esta técnica también puede ser utilizada para ataques Error-basados Ciegos cuando el atacante solo puede averiguar si hubo un error o no.

Probablemente el tipo más difícil de chequeo desde el punto de vista de la implementación. La razón de esto es que hay un enorme número de posibilidades para causar un error.

Concatenación de Caracteres Individuales para Muchos Tipos de Ataques

Otro patrón que se usa a menudo en los ataques es escapar los datos devueltos. Esto a menudo es necesario cuando el contenido de la página atacada cambia frecuentemente, y el script automático de verificación de inyección debe usar marcadores especiales para encontrar la carga útil (los datos valiosos que queremos extraer).

Por ejemplo,

AND 3516=CAST((CHR(113)||CHR(106)||CHR(122)||CHR(106)||CHR(113))||(SELECT (CASE WHEN (3516=3516) THEN 1 ELSE 0 END))::text||(CHR(113)||CHR(112)||CHR(106)||CHR(107)||CHR(113)) AS NUMERIC)

Diseños como este son sospechosos para DataSunrise.

Llamada a Función Sospechosa

En cualquier aplicación de producción decente, generalmente no se pueden ver respuestas de error en la página. Esto descarta extraer datos directamente a través de ataques UNION o ataques basados en errores. En estos casos, tienes que usar inyecciones SQL ciegas para extraer los datos. Hay dos tipos básicos de inyecciones SQL ciegas.

Inyecciones ciegas normales. No puedes ver la respuesta directamente en la página, pero aún puedes determinar el resultado de una consulta basada en una respuesta o código de estado HTTP.

Inyecciones totalmente ciegas. No puedes ver los efectos de tu inyección en ningún tipo de salida. Esto es menos común, por ejemplo, cuando estás inyectando en una función de registro o similar.

En inyecciones ciegas normales, puedes usar declaraciones IF o abusar de cláusulas WHERE en las consultas, lo cual es generalmente la ruta más fácil. Para inyecciones totalmente ciegas, necesitas usar algún tipo de función de espera y luego analizar los tiempos de respuesta.

Ejemplos de funciones de espera/tiempo de espera disponibles incluyen:

WAITFOR DELAY '0:0:10' en SQL Server
BENCHMARK() y sleep(10) en MySQL
pg_sleep(10) en PostgreSQL

DataSunrise asigna puntos de penalización adicionales si la solicitud contiene consultas similares que son frecuentemente usadas en ataques.

Condición Sospechosa para Comprobar Ataque Booleano Ciego

La inyección SQL ciega es un tipo de inyección SQL donde el atacante no recibe una respuesta obvia de la base de datos atacada y en su lugar reconstruye la estructura de la base de datos paso a paso al observar el comportamiento del servidor de la base de datos y la aplicación. La inyección SQL ciega también se llama inyección SQL inferencial.

Hay dos tipos de inyecciones SQL ciegas: basadas en booleanos y basadas en tiempo.

En este tipo de ataque, no puedes obtener el resultado completo. El atacante llega a obtener ciegamente el contenido de las tablas que le interesan, letra por letra. Esto puede ser muy largo y requiere una buena automatización.

Aquí hay un ejemplo de tal solicitud.

ORD(MID((SELECT grantee FROM(SELECT DISTINCT(grantee) FROM INFORMATION_SCHEMA.USER_PRIVILEGES LIMIT 0, 1) AS caou), 22, 1)) > 39--MnqX'

DataSunrise también emite puntos de penalización si se detectan signos de tales consultas.

Penalización por Conteo Sospechoso

Estos son los puntos que DataSunrise otorga por bloques sospechosos en SQL en la forma SELECT count(*) FROM t1,t2.

El punto es que si la Inyección SQL basada en tiempo está disponible, el atacante necesita diferenciar de alguna manera entre dos ramas de ejecución de código. Para hacer esto, se ejecuta una solicitud en una de las ramas, lo que toma mucho tiempo. Por ejemplo, contar el número de filas en una unión de dos o más tablas. En unión, las líneas se multiplican y se obtienen muchas líneas. Y COUNT se ejecuta lo suficientemente largo como para que el script lo note. Puedes leer más detalles aquí. En ese artículo, encontrarás el SLEEP(5), pero eso es solo el jardín de infancia.

Mucha gente ya ha demostrado esto, y por esta razón, usan métodos más sofisticados en la forma de COUNT+JOIN, que describimos anteriormente. En práctica normal, tal solicitud, que es parte de una solicitud más compleja, no se utiliza y por lo tanto esto puede servir como uno de los signos de inyección.

Conclusión

El enfoque de DataSunrise para configurar penalizaciones por detección de inyección SQL presenta una estrategia integral y proactiva para proteger bases de datos contra esta amenaza generalizada. Al emplear un sistema de puntos de penalización que evalúa varios aspectos de las consultas SQL, DataSunrise identifica y mitiga de manera efectiva los posibles intentos de inyección. A través de ejemplos que ilustran diferentes patrones de inyección SQL y las penalizaciones asociadas, este artículo demuestra la versatilidad y efectividad de los mecanismos de detección de DataSunrise.

En esencia, la meticulosa configuración de penalizaciones por detección de inyección SQL de DataSunrise subraya su compromiso de proporcionar soluciones sólidas de seguridad para bases de datos. Al aprovechar técnicas avanzadas de detección y refinar continuamente su sistema de penalización, DataSunrise empodera a las organizaciones para proteger de manera efectiva sus activos críticos de datos contra ataques de inyección SQL.