Los ataques de inyección SQL no son nada nuevo. De hecho, con el creciente aumento de malos actores y la proliferación de herramientas automatizadas diseñadas para descubrir los componentes que facilitan este vector de ataque, no existe una solución definitiva en el corto plazo para esta vulnerabilidad de SQL. Dada la poderosa naturaleza del lenguaje, el potencial de compromiso es alto y las consecuencias potencialmente graves.
Os presentamos el CVE-2014-3483, un ataque de inyección SQL en uno de los componentes de código abierto más populares.
- Nombre de la Vulnerabilidad: CVE-2014-3483
- Tipo de vulnerabilidad: Inyección SQL.
- Componentes afectados:
- ‘activerecord’ rubygem:
- Versión (es) a partir de 4.0.0.beta1 y superiores pero excluyendo 4.0.7.
- Versión (es) a partir de 4.1.0.beta1 y superiores pero excluyendo 4.1.3
Descripción de la vulnerabilidad:
Sin el curado suficiente en las sentencias de SQL, las consultas de SQL generadas pueden hacer que las entradas se interpreten como comandos de SQL en lugar de datos de usuarios normales por parte del motor de procesamiento. Esto se puede usar para alterar la lógica de consulta para omitir las comprobaciones de seguridad, insertar declaraciones adicionales que comprometan la base de datos back-end y, en el peor de los casos, la ejecución de comandos del sistema.
La mecánica de ataque:
La falta de higiene adecuada en el desarrollo,suele ser la causa de este ataque en particular, lo que permite la manipulación de código SQL que no está bien escrito, con el propósito de realizar ataques cibernéticos más avanzados. Si esto se combina con un componente software que no puede construir correctamente, todo o parte, de un comando de SQL o neutraliza incorrectamente (o falla al neutralizar) elementos específicos que podrían modificar dicho comando SQL, el problema se agrava.
Un ejemplo del mundo real:
Un ejemplo real de este ataque se puede ver en el siguiente video: http://play.sonatype.com/watch/w5eU3e57qEp9xC8B3e5r3v?
Para aquellos de ustedes que prefieren leer:
Repitamos el ataque del «mundo real» aquí paso a paso, pero un poco más simplificado.
En el código vulnerable (a la izquierda): los valores para el campo de rango no se escapan correctamente. En el código correcto (a la derecha) si que se escapan los valores del campo ‘rango’ antes de usarlos en las consultas SQL:
Detalle del código vulnerable en el cual los valores para el campo ‘rango’ no se escapan correctamente.
La mejor forma de solucionar el problema:
Tal como se ha explicado previamente, la forma más obvia de prevenir los ataques de inyección de SQL es tener una «higiene» adecuada para el desarrollo, además de no confiar ciegamente en el código que se ve sintácticamente correcto.
En términos de CVE-2014-3483, se recomienda actualizar a versiones no vulnerables de las versiones de los componentes 4.0.7 y 4.1.3 que están disponibles en los repositorios de descarga de rubygems.
Las organizaciones “nativas DevOps” con la capacidad de implementar continuamente nuevas versiones de su software cuentan con la ventaja de automatización lo que les permite estar un paso por delante de los piratas informáticos. Los clientes de Sonatype Nexus fueron notificados de CVE-2014-3483 a los pocos días del descubrimiento. Sus equipos de desarrollo recibieron automáticamente instrucciones sobre cómo remediar el riesgo.
Si no es un cliente de Sonatype y desea saber si está utilizando la versión vulnerable del registro activo en una aplicación específica, puede usar el escáner de vulnerabilidades Nexus, el cual es gratuito y podrá descubrirlo rápidamente.
Visite la página de Nexus Intelligence Insights para profundizar en otras vulnerabilidades como esta.
