Enfoque de DataSunrise para Configurar Penalidades 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 las 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 penalidades 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 penalidades supera un umbral predefinido, DataSunrise toma medidas, ya sea registrando una advertencia (Regla de Auditoría) o bloqueando la consulta directamente (Regla de Seguridad).

Ejemplos de Patrones de Inyección SQL y Penalidades

Penalización por Comentarios

Una de las tareas básicas de un atacante cuando intenta realizar una inyección es cambiar radicalmente la solicitud. Para esto, necesita deshabilitar/cortar esa parte de la solicitud que no controla o que le impedirá realizar la inyección. Para ello, se agrega 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 iniciar sesión como admin:

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

SELECT * FROM members WHERE username = 'admin'--' AND password = 'password'

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

2 Ejemplo. Ejemplos Clásicos de Ataques de Inyección SQL con Comentarios en Línea

Valor de ID: 10; DROP TABLE members /*

Simplemente deshágase de otras cosas al final de la consulta. Igual que 10; DROP TABLE members –

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 se encuentran bastante a menudo en solicitudes legítimas. Por ejemplo, muchos IDEs utilizados por desarrolladores agregan automáticamente la hora actual al principio 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 members WHERE username = 'admin'--' AND password = 'password'

La palabra clave AND estaba comentada.

Penalización por Consultas Dobles (Apilamiento de Consultas)

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

SELECT * FROM members; DROP members--`

Si tiene éxito, esto terminará una consulta y comenzará otra.

No todas las bases de datos admiten la ejecución de dos o más expresiones en una consulta, pero donde se admite, dichos casos deben ser controlados.

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

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

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

Esto resulta en la consulta SQL:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

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

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 mostrado que los ciberatacantes usan 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 products where name = 'Gifts' UNION SELECT NULL, NULL from SYS.USERS --'

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

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

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

Si el número de nulos no coincide con el número de columnas, la base de datos devuelve un error, como:

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

Un atacante usa NULL como los valores devueltos por la consulta SELECT inyectada porque los tipos de datos en cada columna deben ser compatibles entre la consulta original y la inyectada. NULL es convertible a cada tipo de dato común, por lo que maximiza la posibilidad de que la carga sea exitosa cuando el número de columnas es correcto.

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

Conversión Sospechosa: Ataque de 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 probador información sobre la cual refinar su inyección.

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

‘ 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 usarse para ataques Ciegos basados en Errores cuando el atacante solo puede averiguar si hubo un error o no.

Probablemente el tipo de verificación más difícil desde el punto de vista de la implementación. La razón de esto es que hay un gran 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 ataques es escapar de los datos devueltos. Esto suele ser necesario cuando el contenido de la página atacada cambia con frecuencia, y el script de verificación automática de inyección debe usar marcadores especiales para encontrar la carga (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)

Dichos diseños son sospechosos para DataSunrise.

Llamada de Función Sospechosa

En cualquier aplicación de producción decente, generalmente no puedes ver respuestas de error en la página. Esto descarta la extracción de datos directamente a través de ataques UNION o 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 en función de 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 u similar.

En inyecciones ciegas normales, puedes usar declaraciones IF o abusar de cláusulas WHERE en 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 se usan a menudo en ataques.

Condición Sospechosa para Verificar Ataques Ciegos Booleanos

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 observando 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 a ciegas 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 distinguir de alguna manera entre dos ramas de ejecución de código. Para hacer esto, se ejecuta una solicitud en una de las ramas, que toma mucho tiempo. Por ejemplo, contar el número de filas en una unión de dos o más tablas. Al unir, las líneas se multiplican y se obtienen muchas líneas. Y COUNT se ejecuta lo suficientemente tiempo 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 un jardín de infancia.

Muchas personas ya han demostrado esto, y por esta razón, utilizan métodos más sofisticados en forma de COUNT+JOIN, que describimos anteriormente. En la práctica normal, dicha solicitud, que es parte de una solicitud más compleja, no se usa y, por lo tanto, esto puede servir como uno de los signos de inyección.

Conclusión

El enfoque de DataSunrise para configurar penalidades por detección de inyección SQL presenta una estrategia integral y proactiva para proteger las 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 intentos de inyección potenciales. A través de ejemplos que ilustran diferentes patrones de inyección SQL y penalidades asociadas, este artículo demuestra la versatilidad y efectividad de los mecanismos de detección de DataSunrise.

En esencia, la meticulosa configuración de penalidades de DataSunrise para la detección de inyección SQL subraya su compromiso de proporcionar soluciones robustas de seguridad para bases de datos. Al aprovechar técnicas avanzadas de detección y refinar continuamente su sistema de penalidades, DataSunrise capacita a las organizaciones para proteger eficazmente sus activos de datos críticos contra los ataques de inyección SQL.