Análisis de inyección SQL

Análisis de malware

Análisis de inyección SQL

enero 27, por Frank Siemons

Una cosa es poder ejecutar un simple ataque de inyección SQL ; otra es hacer una investigación adecuada de tal ataque. Desafortunadamente, no hay mucha información sobre el análisis de inyección SQL. Este artículo ayudará a proporcionar algunas herramientas para la respuesta básica a incidentes. Se puede traducir con bastante facilidad para aplicarlo también al análisis de inyección de comandos.

¡Conviértete en un ingeniero inverso certificado!

Obtenga capacitación práctica en vivo sobre análisis de malware desde cualquier lugar y conviértase en un analista certificado de ingeniería inversa. Comienza a aprender

Hacer las preguntas correctas

Si trabaja en un equipo de respuesta a incidentes o en un centro de operaciones de seguridad y tiene la tarea de analizar un ataque de inyección SQL, deberá hacerse algunas preguntas para cubrir toda la información que pueda extraer. Primero enumeraré la pregunta principal y luego cubriré algunos ejemplos (técnicos).

Esta pregunta determinará cuál fue el resultado que intentó el atacante. Es importante comprender si se trató de un ataque dirigido a un servidor web específico o de un escaneo de tipo “disparar y olvidar” en un rango (aleatorio) de direcciones IP. En el primer caso específico, vale la pena investigar un ámbito más amplio de eventos de seguridad registrados para ver qué otros trucos intentó realizar el atacante. En el segundo caso, cuando el ataque no estaba dirigido, es posible que ni siquiera sea posible realizar un ataque de inyección SQL en los servicios en línea que proporciona el objetivo.

Un paso importante es rastrear al atacante hasta su origen lo más lejos posible. A veces, esto conducirá a una fuente fácilmente identificable, a veces incluso a un host interno, que puede identificar una alerta de falso positivo. Sin embargo, la mayoría de las veces esto apuntará a algún nodo de salida de TOR o a un host externo comprometido aleatoriamente. Eso significa que en muchos casos no es factible investigar más a fondo la fuente del ataque.

Para este paso, idealmente necesitará una captura de paquetes o, al menos, la solicitud URL GET/POST. Un dispositivo IDS y algunos cortafuegos capturarán el paquete desencadenante de eventos que coincida con el contenido de la regla de seguridad que debería contener la mayor parte de la información. Algunos dispositivos IDS/IPS también ofrecen la opción de capturar todo el tráfico alrededor del ataque, lo que ayuda enormemente a comprender la secuencia de los eventos de tráfico y el resultado.

Esta es probablemente la pregunta más importante a responder, pero requiere la mayor cantidad de información de registros y datos de captura de paquetes. Si un atacante llegó a un servidor vulnerable, ¿cuál fue el resultado? ¿Se filtró algún dato al atacante? ¿Dónde se crearon cuentas? ¿Se cargó malware externo? La respuesta a esta pregunta decidirá la ruta de escalada del incidente y los procedimientos a seguir, como el aislamiento del servidor.

Esta es una pregunta amplia, basada en el resultado de la investigación. Una buena investigación incluye una recomendación para una acción. Algunos ejemplos pueden ser parchear un servidor vulnerable, deshabilitar servicios no utilizados o bloquear una IP de origen. En el caso de repetidas alertas de falsos positivos, una recomendación puede ser “ajustar” la regla de alerta para excluir ciertas direcciones IP o modificar los parámetros de coincidencia del contenido de la regla.

Breve descripción general de la inyección SQL

La inyección SQL utiliza una vulnerabilidad de seguridad, generalmente dentro o a través de un servidor web, para explotar una base de datos SQL. Un ataque de inyección SQL exitoso puede provocar la filtración de datos de la base de datos SQL, la modificación de datos en la base de datos SQL, la ejecución de código malicioso o incluso un compromiso total de los servidores objetivo.

Un ataque de inyección SQL generalmente aprovecha un campo de entrada mal desinfectado en un formulario web. Partes de declaraciones SQL se introducen en un campo de formulario web, que luego llega al servidor de la base de datos donde se procesan. Un ejemplo de un ataque como este sería volcar el contenido de la base de datos en un archivo de acceso público o volver a la salida del sitio web.

Mi colega autor Dhakkan ha escrito un excelente artículo sobre los detalles de los ataques de inyección SQL, combinado con algunos ejemplos aquí .

Ejemplo de un ataque

Para este ejemplo, utilizamos el sitio DVWA incluido en Metasploitable . La máquina virtual Metasploitable está disponible públicamente para pruebas y existe una gran cantidad de documentación sobre la instalación y el uso en Internet.

Nota: Si sigue estos pasos, asegúrese de configurar el nivel de seguridad en “Bajo” a través del enlace “Seguridad DVWA” en el lado izquierdo.

Luego podemos abrir el enlace “Inyección SQL” en la barra lateral izquierda.

Comencemos ingresando un comando normal y válido para obtener el nombre de usuario para el ID 1.

Esto devuelve el nombre y el apellido del usuario con ID 1 como se esperaba:

Este artículo no pretende cubrir todos los secretos de la inyección SQL, pero si observamos la siguiente declaración SQL SELECT que utiliza este formulario, podemos idear un método de ataque:

$getid = “SELECCIONE nombre, apellido DE los usuarios DONDE user_id = ‘$id'”;

Cuando usamos nuestra entrada de ID=1, la declaración se verá así:

$getid = “SELECCIONE nombre, apellido DE los usuarios DONDE user_id = ‘1’”;

Se muestra el usuario con valor de ID 1, que coincide con la parte WHERE de la declaración.

¿Qué pasa si saltamos de ese comando con la siguiente entrada? (Cuidado con el espacio al final)

%’ o ‘0’=’0

La declaración se verá así:

$getid = “SELECCIONE nombre, apellido DE los usuarios DONDE user_id = ‘%’ o ‘0’=’0 ‘”;

Esto devolverá todos los valores donde el ID de usuario sea % (valor inventado no existente) O 0=0 (lo cual siempre es cierto). La declaración, si no es rechazada por algún tipo de validación de entrada, devolverá los detalles de cada ID en la base de datos porque todo coincide con la consulta.

El analisis

Este fue un ataque muy simple. En la vida real, verás muchos ataques más complejos, probablemente a diario. Sin embargo, comprenda que es esencial comprender el concepto de ataque antes de poder realizar un análisis adecuado del mismo.

Ahora, veamos qué podemos descubrir sobre este ataque a partir de nuestros registros y datos de captura de paquetes.

Cuando seguimos el archivo valogapache2access.log en el host Metasploitable, podemos ver que se registran la consulta normal y de ataque.

La IP del atacante, en este caso, es ” 192.168.1.13 “, que era mi cliente de prueba Kali. En un escenario de la vida real, esta IP podría brindarle algunos consejos interesantes sobre lo que está buscando. Recuerde: haga todas las preguntas correctas.

Podemos ver las solicitudes GET al servidor que contienen la información del campo del formulario. Esto le mostrará el ataque que se intentó y podría identificar una alerta de falso positivo debido, por ejemplo, a un error tipográfico del usuario. También puede conducir a una idea de lo que el atacante intentaba lograr. ¿Tenía el atacante una determinada aplicación y vulnerabilidad en mente para realizar el ataque? ¿Qué tan personalizado o dirigido fue el ataque?

La cadena del agente de usuario también es una fuente de información valiosa. ¿Qué cliente se utilizó para el ataque? En este caso IceWeasel 31.8.0 , que se suministra con Kali 2.0

El último punto a tener en cuenta es que el código de estado HTTP devuelto fue un valor ” “. La solicitud fue exitosa.

Los archivos de registro se limitan a mostrar los datos de la solicitud. Para profundizar más en el ataque, se requieren datos de captura de paquetes. Como se mencionó, muchos proveedores de firewalls y dispositivos IDS pueden proporcionar el paquete de activación o una ventana más grande de tráfico capturado para un análisis más detallado a través de varias interfaces.

En esta configuración de prueba, usaremos Wireshark para capturar nuestros datos.

Primero, configuraremos Wireshark en Kali Client para escuchar el tráfico:

El ataque se lanza nuevamente y Wireshark captura todo el tráfico hacia y desde el objetivo.

Encuentre el tráfico y ” Siga la transmisión ” como se muestra a continuación:

Ahora podemos volver a ver todos los datos de registro encontrados anteriormente. Pero hay más.

Esta vez podemos ver el tráfico del servidor devuelto y los resultados de la consulta. Esto permitirá al analista determinar el resultado y el impacto del ataque en el servidor de destino.

Ahora hemos realizado el análisis básico de un ataque de inyección SQL. El siguiente paso es escalar esta alerta de ataque o observar la regla del dispositivo o las opciones de ajuste de SIEM en caso de que resulte ser una alerta de falso positivo.

Una opción para un análisis más profundo, si es necesario, es contactar al propietario de la base de datos SQL para investigar qué sucedió desde su perspectiva. Deben tener acceso completo a la base de datos y registros de transacciones.

¡Conviértete en un ingeniero inverso certificado!

Obtenga capacitación práctica en vivo sobre análisis de malware desde cualquier lugar y conviértase en un analista certificado de ingeniería inversa. Comienza a aprender

Asegúrese de que, como mínimo, responda todas las preguntas con las que comencé. Esto no sólo conducirá a un análisis adecuado, sino que también le enseñará sobre nuevas formas de ataques de inyección SQL.