Los firewalls de aplicaciones web (WAF) están diseñados para detener la inyección de SQL y otras técnicas de ataque comunes dirigidas a sitios web, aplicaciones en línea y servidores
La forma más nueva de ataque de inyección SQL que usa JSON puede eludir las protecciones tradicionales, amenazando a las organizaciones que usan WAF para proteger sus activos en línea.
"Los atacantes que utilizan esta técnica novedosa podrían acceder a una base de datos de back-end y usar vulnerabilidades y exploits adicionales para filtrar información a través del acceso directo al servidor o a través de la nube", indicó un informe de investigación emitido a principios de diciembre de 2022 por Claroty , un operador de tecnología operativa. firma de protección con sede en Nueva York y Tel Aviv.
"Esto es especialmente importante para las plataformas OT e IoT que se han trasladado a sistemas de gestión y monitorización basados en la nube", añade el informe. "Los WAF ofrecen una promesa de seguridad adicional desde la nube; un atacante capaz de eludir estas protecciones tiene un amplio acceso a los sistemas".
Cómo funciona un ataque de inyección SQL
Un ataque de inyección de SQL (SQLi) intenta engañar a una base de datos relacional que usa SQL (lenguaje de consulta estructurado) incorporando comandos SQL en las entradas de datos y esperando que el software del sistema de administración de base de datos relacional (RDBMS) que controla la base de datos, como MySQL, Microsoft SQL Servidor o PostgreSQL: no se da cuenta.
En lenguaje sencillo, los atacantes le dicen en secreto a la base de datos qué hacer mientras la alimentan con datos supuestamente inofensivos. Debido a que muchos sitios web y aplicaciones web que usan bases de datos basadas en SQL también permiten a los usuarios y visitantes ingresar datos, esto crea una gran oportunidad para los ataques de inyección SQL.
Por lo general, un atacante lanzaría un ataque SQLi ingresando datos maliciosos en un campo de formulario de una página web o en una aplicación web. En los casos más atroces, es posible que los atacantes solo necesiten modificar las cadenas de consulta de la base de datos, todo a la derecha del "?" en una URL: en las barras de direcciones del navegador.
Por ejemplo, si el software de administración de la base de datos espera un nombre como "Smith" como entrada, pero en su lugar recibe un comando SQL como ' DROP TABLE names; --, el software ejecutará el comando en lugar de tratarlo como una entrada. En este caso, el resultado podría ser la eliminación de una tabla completa de datos con la etiqueta "nombres".
Para tomar otro ejemplo, esta instrucción SQL buscaría en una base de datos todos los ejemplos de "Smith" o "smith": select * from person where name = 'smith'
Sin embargo, si alguien ingresara esta entrada en cualquier campo de nombre: ' or 1=1; -- entonces la declaración se convierte en select * from person where name = '' or 1=1; --'
Esta entrada obligará al software de gestión a devolver todos los nombres de la base de datos, lo que le dará al atacante una gran cantidad de datos confidenciales. (En la sintaxis SQL, "*" devuelve cualquier dato que cumpla con los parámetros de la instrucción; las comillas simples denotan el comienzo y el final de los parámetros; "1=1" es invariablemente verdadero; y el guión doble "--" indica que todos los siguientes el texto debe ser ignorado.)
Las versiones más complejas de este ataque podrían obligar a la base de datos a liberar números de tarjetas de crédito , contraseñas codificadas o cookies de sesión de usuario. Otros tipos de ataques de inyección SQL pueden engañar a las bases de datos en línea para que revelen sus estructuras y software de gestión. Los ataques SQLi más dañinos pueden agregar o eliminar datos o incluso agregar archivos al servidor de la base de datos.
Los ataques de inyección SQL se remontan al menos a 1998 . Muchos sistemas de administración de bases de datos han desarrollado mitigaciones contra ellos, como "desinfectar" las entradas para que no puedan analizarse como comandos. Sin embargo, los ataques siguen siendo comunes.
"Las inyecciones de SQL se presentan como la garantía más probable que tiene un atacante para obtener acceso fácil e ilegítimamente a un sitio web u otro sistema respaldado por SQL, simplemente en función de la probabilidad de éxito", declaró la empresa de seguridad de aplicaciones Invicti en su blog en 2013.
No ha cambiado mucho desde entonces. En la lista más reciente de los 10 principales riesgos de seguridad de aplicaciones web , compilada en 2021 por Open Web Application Security Project (OWASP), los ataques de inyección ocupan el tercer lugar, por debajo del primer lugar en 2017.
En otra publicación de blog, el equipo de seguridad de Invicti teoriza que SQLi persiste porque "las consultas de SQL no seguras son extremadamente fáciles de crear, y las consultas de SQL seguras aún son levemente complejas (o al menos más complejas que las genéricas y típicas en línea y a menudo consultas inseguras)."
Cómo los WAF detienen la inyección de SQL
Una de las formas más efectivas de minimizar las posibilidades de una inyección SQL exitosa es usar un firewall de aplicaciones web (WAF).
Si bien las organizaciones instalan firewalls de red regulares en el lado del cliente para defender a los usuarios y dispositivos, los WAF se implementan en el lado del servidor para proteger los sitios web y las aplicaciones web. Barracuda Networks, Cloudflare y F5 se encuentran entre los proveedores de WAF comerciales más conocidos, y también existen alternativas gratuitas de código abierto como ModSecurity.
"La funcionalidad principal de un WAF es filtrar los intentos de ataque web en tiempo real, mitigando las vulnerabilidades de las aplicaciones OWASP Top 10, como las inyecciones de SQL y las secuencias de comandos entre sitios (XSS) , así como el bloqueo de otros vectores de ataque", explicó Invicti en un blog . publicar _
Los WAF se pueden ejecutar desde dispositivos de red dedicados en las mismas instalaciones que los servidores que protegen o se pueden agregar al propio software del servidor. También hay WAF basados en la nube operados desde servidores de terceros. Todos funcionan mejor en combinación con sistemas de protección/detección de intrusos (IDS/IPS) y firewalls de última generación (NGFW) para proteger las redes.
Debido a que los WAF operan en la Capa 7 del modelo de red, tienen más información sobre qué tipo de datos ingresan que un firewall tradicional basado en la Capa 3. Los WAF monitorean y filtran las solicitudes HTTP GET y POST entrantes, bloqueando los paquetes de datos que consideran maliciosos. Pueden ser muy útiles para cumplir con las normas y estándares , como el estándar de seguridad de datos de la industria de tarjetas de pago (PCI DSS).
Algunos WAF incluyen en la lista blanca buenas direcciones de Protocolo de Internet (IP) conocidas y bloquean el resto, lo que funcionaría para aplicaciones web dedicadas a clientes específicos. Los WAF de cara al público generalmente incluyen en la lista negra las direcciones IP malas conocidas y filtran todo lo demás, un proceso que requiere más recursos que la lista blanca. Los WAF de "seguridad híbrida" combinan los dos enfoques.
Aunque cada marca y versión de WAF manejará las cosas de manera un poco diferente, generalmente bloquean los ataques de inyección de SQL mediante la detección de sintaxis SQL en los paquetes POST entrantes.
Se sabe que algunos fragmentos de sintaxis son maliciosos, por ejemplo, ' DROP TABLE xxxx; --como el anterior, y se bloquearán automáticamente. En otros casos, el WAF analizará la sintaxis de SQL para tratar de averiguar si podría ser malicioso. Puede agregar caracteres de "escape" a la sintaxis SQL para hacerla inofensiva, un método que también utilizan muchos sistemas de administración de bases de datos.
Cómo se pueden omitir las protecciones WAF
A veces, los WAF pueden ser superados. Mientras investigaban cnMaestro (una plataforma de administración de dispositivos inalámbricos) en busca de vulnerabilidades, los investigadores de Claroty notaron que un ataque de inyección SQL utilizado para la explotación exitosa con implementaciones locales de cnMaestro no funcionó en la versión en la nube.
Eso se debe a que el WAF integrado de Amazon Web Services (AWS) estaba deteniendo el ataque, como debería. No contentos con dejar que los perros durmientes mientan, los investigadores de Claroty probaron el WAF de Amazon para descubrir cómo reconocía la sintaxis SQL maliciosa.
"Esto desencadenó nuestro interés y planteó una importante pregunta de investigación: ¿Qué pasaría si pudiéramos encontrar una sintaxis SQL que ningún WAF reconocería?" se preguntaron los investigadores.
Descubrieron que, si bien Amazon WAF no tuvo problemas para detectar y bloquear la sintaxis SQL normal, no siempre reconoció las declaraciones escritas en notación de objetos JavaScript (JSON), un formato de intercambio de datos ampliamente utilizado que ayuda a los desarrolladores web a estructurar los datos.
Se puede abusar de JSON para montar ataques basados en JavaScript en páginas web, pero no se sabía que fuera un vector en los ataques SQLi. Sin embargo, debido a que JSON se usa con tanta frecuencia, muchos sistemas de administración de bases de datos relacionales ahora lo admiten junto con SQL.
Ahí está el problema. Los sistemas de administración de SQL más utilizados, incluidos Microsoft SQL Server, MySQL, PostgreSQL y SQLite, han agregado soporte para la sintaxis JSON durante la última década. Pero Amazon WAF no siempre vio la sintaxis JSON como un posible vector de ataque y, a veces, la ignoró.
"Si pudiéramos proporcionar una carga útil de SQLi que WAF no reconocería como SQL válido, pero el motor de la base de datos lo analizaría, podríamos lograr el bypass", dijo el informe de Claroty. "Resulta que JSON era exactamente esta discrepancia entre el analizador [Amazon] WAF y el motor de la base de datos. Cuando aprobamos declaraciones SQL válidas que usaban una sintaxis JSON menos frecuente, WAF en realidad no marcó la solicitud como maliciosa".
Más específicamente, el operador JSON @>"hizo que el WAF entrara en un bucle y nos permitió proporcionar cargas útiles SQLi maliciosas, lo que nos permitió eludir el WAF".
Utilizando un ataque de inyección SQL basado en JSON, los investigadores de Claroty pudieron robar con éxito una cookie de sesión de usuario administrativo de su propia aplicación web vulnerable alojada en AWS.
"Simplemente anteponiendo la sintaxis JSON simple al inicio de la solicitud [SQL]", dijeron los investigadores, "¡pudimos filtrar información confidencial utilizando nuestra vulnerabilidad SQLi en la nube!"
Para ser justos, es posible que los investigadores de Claroty no hayan sido los primeros en descubrir esta falla. El investigador de seguridad Ivan Novikov documentó un ataque teórico JSON-in-SQL en 2017, pero aparentemente no se actuó ampliamente sobre sus hallazgos.
Un problema generalizado
El equipo de Claroty descubrió que el mismo ataque JSON-in-SQL funcionó contra los WAF de Cloudflare, F5, Imperva y Palo Alto Networks. Un aviso emitido por el estado de Nueva Jersey el 15 de diciembre de 2022 los especificó como "Palo Alto Next-Generation Firewall, F5 Big-IP, Amazon AWS ELB, Cloudflare e Imperva". (CloudGuard AppSec de Check Point y su derivado de código abierto, open-appsec, no se vieron afectados por la vulnerabilidad).
"Si bien la compatibilidad con JSON es la norma entre los motores de bases de datos, no se puede decir lo mismo de los WAF", dijo el informe de Claroty. "Los proveedores han tardado en agregar compatibilidad con JSON, lo que nos permitió crear nuevas cargas útiles de inyección de SQL que incluyen JSON que omitieron la seguridad que brindan los WAF".
Claroty informó sus hallazgos a los cinco proveedores afectados, incluido Amazon, que parchó sus WAF agregando o mejorando el reconocimiento de sintaxis JSON antes de que Claroty revelara su investigación en la conferencia Black Hat Europe a principios de diciembre.
Pero lo más probable es que los ataques de inyección SQL basados en JSON también funcionen contra otros WAF. Claroty ha enviado sus hallazgos a la herramienta de prueba de penetración de código abierto SQLMap , y aunque ese cambio aún no se ha ingerido por completo , pronto cualquiera podrá probar este ataque contra una base de datos SQL.
"También tratamos de notificar a otros proveedores de WAF más pequeños, pero no nos respondieron", dijo Noam Moshe de Claroty a TechTarget en diciembre de 2022. "Sin embargo, dado que todos los principales proveedores de WAF ahora están bloqueando este tipo de ataques, sentimos que es el momento adecuado para publicar".
Si su organización utiliza un WAF, consulte con el proveedor o mantenedor del código para asegurarse de que se haya parcheado contra la vulnerabilidad JSON-in-SQL y actualice su software.
"Este es un desvío peligroso, especialmente a medida que más organizaciones continúan migrando más negocios y funcionalidades a la nube", dijo el informe de Claroty. "Los procesos de IoT y OT que se monitorean y administran desde la nube también pueden verse afectados por este problema, y las organizaciones deben asegurarse de que están ejecutando versiones actualizadas de las herramientas de seguridad para bloquear estos intentos de omisión".
Sin usted, esta web no existiria. Gracias por visitarme, espero que le haya gustado y vuelva. Muchas gracias ☺️
Fecha actualización el 2023-02-14. Fecha publicación el 2023-02-14. Autor: Oscar olg Mapa del sitio Fuente: scmagazine