SOC165 - Possible SQL Injection Payload Detected
Resumen
Esta alerta se trata sobre un posible ataque de Inyección SQL que se intentó
realizar hacia uno de los servidores de la empresa de LetsDefend. La alerta fue
creada el 25 de febrero de 2022, en el horario de las 11:34 AM. En caso de que
este ataque haya sido exitoso (más adelante se define la cuestión) podría causar
la visualización, edición y hasta la eliminación de datos confidenciales de los
consumidores/clientes de la empresa.
Detalles de la alerta
Tipo de alerta: Inyección SQL (también llamado SQLi)
Fecha y hora: Feb, 25, 2022, 11:34 AM
Fuente de la alerta: Herramienta SIEM, WAF (Web Application Firewall).
Descripción del evento: Posible inyección SQL realizado por una persona
externa (167.99.169.17) a la empresa dirigido hacia uno de los servidores de
LetsDefend (WebServer1001) (172.16.17.18)
Impacto potencial: Posible filtración de datos, robo de información, control de
base de datos afectada, ataque de DDoS, falta de integridad de la información.
Análisis:
Definiciones a saber
Antes de pasar a temas técnicos para el análisis del caso, es necesario entender un
par de conceptos para poder tener una imagen mas clara con el evento registrado.
Por lo que a continuación se describen estos temas: ¿Qué es una inyección SQL? Que
tipos existen? ¿Qué es la codificación en URL?
1. Una inyección SQL o (SQLI) es un tipo de ataque que se intenta explotar en
paginas webs inseguras. Esta misma consiste enviar código SQL malicioso a la
base de datos de la pagina web objetivo e interceptar la comunicación entre
estas. Existen diversos tipos de inyecciones SQL con diferentes payloads (cargas
útiles) que se pueden implementar.
2. Tipos de inyecciones
Ataque SQL Injection por error
Es el más común y el más fácil de explotar ya que es la propia aplicación que nos va
diciendo los errores que da la base de datos cuando vamos usando los ataques de
sql injection. Con este error es muy fácil conseguir cualquier cosa de la base de datos
(estructura, tablas, nombres de campos e incluso datos).
Ataque SQL Injection por unión
Este ataque consiste en que una pagina devuelve un resultado, es acá donde el
atacante añade al resultado original el resultado de otra query (consulta), por
ejemplo, todos los usuarios y passwords de la web, y hace que ambas querys salgan
en esa pagina de resultados.
Ataque SQL Injection ciego
Este ataque es el más complicado y avanzado, es la tercera vía, cuando ni el ataque
por error ni el ataque por unión funcionan, tenemos que ser creativos y tenemos que
ir preguntando a la base de datos mediante si o no todo lo que necesitemos saber.
Hay dos tipo de ataque ciego:
Basada en contenido, es decir, que muestre el resultado correcto, x contenido, si
tengo razón, sino la tengo no me los muestres.
Basada en tiempo, tarda 5 segundos en mostrarme x contenido si tengo razón,
sino los muestra al momento.
3. La codificación en URL (también conocida como URL encoding) es un método
estándar para representar caracteres especiales en una URL de manera que
puedan ser transmitidos correctamente a través de Internet. Por ejemplo, el
espacio en blanco se representa como %20 , y los caracteres especiales como
comillas simples ( ' ) o dobles ( " ) se representan con sus equivalentes
hexadecimales.
En el contexto de la inyección SQL, la codificación en URL se utiliza para:
Ocultar caracteres especiales: Los atacantes codifican los caracteres
especiales para evitar que sean filtrados por la aplicación web.
Evitar la detección: La codificación en URL puede dificultar la detección de
payloads maliciosos por los sistemas de prevención de intrusiones (IPS) o los
firewalls de aplicaciones web (WAF).
Una vez explicado esto, podemos seguir con la parte técnica como corresponde:
Técnico | Log Management
Como primer paso a seguir, es revisar la actividad que se registró en los logs del WAF
presente en la organización de LetsDefend. Por lo que ingresamos a este apartado en
búsqueda de información a cerca de la siguiente dirección IP -> 167.99.169.17
Y vemos que nos sale un total de 6 logs generados (es decir, la cantidad de veces
que la dirección IP externa tuvo contacto con la pagina de LetsDefend).
Como siguiente paso, debemos realizar una pequeña investigación para poder
entender o por lo menos tener un panorama mas amplio a cerca de lo que se registró
en nuestra herramienta SIEM. Un consejo, es que podemos tomar nota a cerca de
cada uno de estos logs para poder "pintar" la imagen completa. Este fue mi toma de
notas:
:30 - ingresó a la página.
:32 - Ingresó estos parámetros = "q=%27" - Tamaño de la respuesta: 948 con un
status de 500.
:32 - ingresó estos parámetros = "q=%27%20OR%20%271" mismo tamaño de
respuesta y status
:33 - ingresó estos parámetros = "q=%27%20OR%20%27x%27%3D%27x" mismo
tamaño de respuesta y status
:33 - ingresó estos parámetros = "q=1%27%20ORDER%20BY%203--%2B" mismo
tamaño de respuesta y status
:34 - Ingresó estos parámetros = "q=%22%20OR%201%20%3D%201%20--%20-"
mismo tamaño de respuesta y status
Podemos ver que el atacante intentó enviar código SQL malicioso para probar si la
pagina era vulnerable a este tipo de ataques.
Explicación
Este tipo de ataque se logra llevar a cabo debido a una falta de limpieza y
sanitización de entrada de datos hacia el servidor. Existen una serie de pasos (e
incluso software) que se encargan de analizar vulnerabilidades en páginas webs.
El primer paso que un atacante intenta realizar, es poder verificar si la pagina objetivo
es vulnerable ante dicho ataque, por lo que envía código SQL para poder afectar a la
lógica de la pagina.
Ahora, los que alguna vez jugaron o usaron alguna base de datos, usaron comandos
normalmente como "SELECT FROM x"... o "DELETE " (Por accidente jaja) y te
preguntarás porque se ve diferente en este caso?... Esto se debe a la codificación de
URL realizada en los comandos SQL maliciosos. Te lo explico de la siguiente manera:
q=%27%20OR%20%27x%27%3D%27x
Esta serie de porcentajes y números significa (se debe decodificar) -->
q=' OR 'x'='x
(Les dejo como tarea decodificar cada uno de los intentos del ciberdelincuente para
saber más a cerca de SQL)
Hice uso de una pagina que me otorga el servicio de codificar y decodificar URLs.
Por lo que pude entenderlo mejor de esta forma.
Un vez ya explicado el tema, sabemos que una persona definitivamente si intentó
enviar código malicioso...
Como siguiente paso es entender lo que significa que el status sea "500" y el tamaño
de la respuesta siempre fue la misma. El estatus registrado significa lo siguiente:
status 500 --> Internal server error | "El servidor encontró una situación que no sabe
como manejarlo"
El tamaño de respuesta fue siempre la misma, por lo que nos da un indicio de que lo
que logró ver el ciberdelincuente fue la misma respuesta diciendo una y otra vez,
"Internal Server Error".
Como siguiente paso, debemos analizar la dirección IP del atacante con nuestra serie
de herramientas que tenemos a disposición en Internet.
Como primera herramienta, usamos abuseIPDB con un resultado de 15035 veces
reportado.
Como segunda herramienta usamos VirusTotal, el cual marca 4 flags maliciosas,
reportado como phishing y malware.
Conclusiones
Mediante el análisis que se llevó a cabo durante la resolución de la alerta generada
por la herramienta SIEM, estamos seguros que se intentó ejecutar inyecciones SQL sin
éxito alguno.
Do You Need Tier 2 Escalation? --> No
Was the Attack Successful? --> No
What Is the Direction of Traffic? Internet → Company Network
Check If It Is a Planned --> Test Not Planned
What Is The Attack Type? --> SQL Injection
Is Traffic Malicious? --> Malicious
Playbook Note
Se realizo un intento de inyección SQL hacia nuestra pagina web con origen en el
servidor WebServer1001. El ataque no fue exitoso debido a que la pagina no supo que
responder ante la situación.
Respuesta
Acciones de contención: No se debe realizar ningún tipo de contención.
Acciones de erradicación: Se debe chequear que todas las entradas estén
sanitizadas y limpias para la entrada de datos por parte del usuario.
Acciones de prevención:
Uso de parámetros preparados: Siempre utilizar parámetros preparados o
consultas parametrizadas para evitar que los valores de entrada se interpreten
como parte de la consulta SQL.
Validación de entradas: Implementar una validación de todos los datos de
entrada para evitar caracteres no permitidos.
Principio de menor privilegio: Otorgar a los usuarios de la base de datos los
mínimos privilegios necesarios para realizar las tareas.
Mantener el software actualizado: Aplicar parches de seguridad a todas las
aplicaciones y sistemas.
Conceptos aprendidos
Inyección SQL
Codificación de URL
OR 1=1
Evidencia
Bibliografía:
VirusTotal. (n.d.-c). VirusTotal.
https://www.virustotal.com/gui/home/upload
Belcic, I. (2023, February 23). ¿Qué es la inyección de SQL y cómo funciona? ¿Qué Es
La Inyección De SQL Y Cómo Funciona?
https://www.avast.com/es-es/c-sql-injection
Tipos de ataque de SQL Injection. (2017, May 16). H1RD.COM.
https://www.h1rd.com/hacking/tipos-de-sql-injection
Codificador/Decodificador de URL | Herramientas de Site24x7. (n.d.).
https://www.site24x7.com/es/tools/url-encoder-decoder.html
Fernandes, H. M. (2021, December 12). ¿Qué es la codificación de URL y cómo
funciona? Henrique Marques Fernandes.
https://marquesfernandes.com/es/tecnologia-es/que-es-la-codificacion-de-url-y-
como-funciona/
