Después de construir el contenedor, podemos acceder a Cacti navegando a http://localhost:80. El siguiente paso es actualizar Cacti a la versión 1.2.24. Puedes descargar el script de actualización aquí: https://pastebin.com/NfRiHLjR. Guarda el archivo en el mismo directorio que el archivo docker-compose.yml y renómbralo a upgrade_cacti.sh. Luego ejecuta estos 2 comandos:

Ahora ya estamos listos; vamos a sumergirnos en el código para ver qué es lo que permite que ocurra un ataque de inyección SQL. El archivo vulnerable es graph_view.php y solo necesitamos el usuario guest para acceder a este archivo, lo que permite que cualquiera pueda explotar esta vulnerabilidad. En este archivo, la función insegura es grow_right_pane_tree().

Antes de profundizar en esta función, necesitamos rastrear hacia atrás para saber cómo se ejecuta la función.

Del fragmento de código anterior, podemos ver que la función se ejecutará si $tree_id > 0. Todos los pasos se pueden explicar a continuación:

• Primero, el programa tomará el valor del parámetro action de la entrada del usuario y entrará en una declaración switch/case.

• En el caso tree_content, el código tomará el parámetro de solicitud node del usuario. A continuación, dividirá la entrada por el carácter -, la guardará en $part y, finalmente, comprobará si tree_anchor aparece en node. Si todas las condiciones coinciden, $tree_id se asignará como el segundo elemento de $part. Por ejemplo, tree_content-1 o 1-2-tree_content serán válidos y el valor de $tree_id se asignará en consecuencia.

Desde este punto, nuestra URL se verá así: http://localhost:80?action=tree_content&node=tree_anchor-1. Ahora es el momento de analizar la función grow_right_pane_tree() para explotar el fallo.

El parámetro vulnerable es rfilter, que se pasa directamente al operando RLIKE dentro de la cláusula WHERE. Lo que lo hace vulnerable es que rfilter está envuelto entre comillas dobles ", aunque el parámetro es verificado por la función html_validate_tree_vars(), que se ve así:

El tipo de filtro de rfilter se establece en FILTER_VALIDATE_IS_REGEX y se almacena dentro de $filters; luego, $filter se pasa a la función validate_store_request_vars(). Profundicemos en esta función; esto revelará el resto de nuestro análisis:

La función validate_store_request_vars() es responsable de validar la entrada del usuario. Cuando el tipo de filter es FILTER_VALIDATE_IS_REGEX, la función llama a la función validate_is_regex() con la función preg_match para verificar si nuestra entrada es válida. Según la documentación de PHP:

preg_match() devuelve 1 si el pattern coincide con el subject proporcionado, 0 si no coincide, o false en caso de error.

La declaración if utiliza comparación estricta, lo que significa que solo cuando se produce un error no podemos entrar en la declaración if. El $regex, que es nuestra entrada, está envuelto entre dos comillas simples '. La intención de los desarrolladores es evitar que el usuario inyecte la comilla simple ', que a menudo se utiliza para iniciar un ataque de inyección SQL. Esto parece una implementación de seguridad robusta, pero echemos un vistazo una vez más a cómo se pasa rfilter a la cláusula WHERE:

Oh-oh, el esfuerzo de validar la entrada del usuario se vuelve inútil, ya que rfilter está envuelto entre comillas dobles ", lo que permite a los atacantes inyectar fácilmente " para escapar de la declaración.

Habiendo entendido por qué es vulnerable, ahora profundizaremos en la consulta en la que se pasa $sql_where.

Una vez que se asigna $sql_where, el programa llamará a la función get_allowed_tree_header_graphs(). La función se verá así:

Aquí es donde $sql_where se pasa a una consulta. Ten en cuenta que a la variable se le asignan 2 valores más antes de pasarse: $sql_where = " AND ($sql_where)"; y $sql_where = "WHERE (gti.graph_tree_id=$tree_id AND gti.parent=$leaf_id)" . $sql_where;. Combinado con la primera asignación, así es como se crea finalmente $sql_where:

Después de estas 3 asignaciones, $sql_where se verá así:

La consulta en la que se introduce $sql_where parece abrumadora, pero podemos crear otra consulta simple con una estructura similar:

select * from users WHERE (TRUE) AND ((username RLIKE "' get_request_var('rfilter') '" -- something behind that isn't neccessary))

Para inyectar nuestro payload con éxito, necesitamos escapar de " y )). Por lo tanto, este payload podría funcionar: "));SELECT SLEEP(5) --. Nuestro payload se verá así: select * from users WHERE (TRUE) AND **((username RLIKE "'"));SELECT SLEEP(5) --. ¡Se ve bien! Probemos en Cacti

La razón por la que el servidor no duerme durante 2 segundos es porque provocamos un error en la función preg_match(). Veamos la función de nuevo

Esta función tomará nuestra entrada como regular expression. Y el ) se utiliza para agrupar un conjunto de caracteres. Como no está cerrado, la función devuelve un error. Por otro lado, si probamos "(());SELECT SLEEP(5) --, no podemos escapar de (( en la consulta SQL. Sin embargo, aquí hay un truco, y es "OR"(("));SELECT SLEEP(5) --. Déjame explicarlo: envuelvo (( entre comillas dobles para convertirlo en una cadena en la consulta SQL y uso OR para que coincida con el username anterior. La comilla doble " en la expresión regular, sin embargo, se considera solo un carácter normal, por eso podemos aprovechar esta característica para escapar de la consulta SQL.

Según el tiempo de respuesta, podemos asegurar que inyectamos SQL con éxito en la base de datos. Esta es una vulnerabilidad crítica de inyección SQL. El atacante puede aprovechar este fallo para tomar el control de la cuenta de administrador o incluso ejecutar comandos de forma remota.

Mitigación

Como es habitual, las vulnerabilidades de inyección en general se producen por la ausencia de validación de entrada. Sin embargo, en este caso, los desarrolladores aplicaron validaciones, pero de forma incorrecta. Para solucionarlo, simplemente envolvemos el parámetro rfilter entre comillas simples ' en lugar de comillas dobles ".

Con este sencillo arreglo, el esfuerzo de validar la entrada del usuario ahora funcionará correctamente. Probemos el payload de nuevo para ver si sigue siendo vulnerable.

Con el mismo payload, pero ahora la respuesta es muy rápida, lo que significa que ya no podemos inyectar comandos SQL.

De este análisis del CVE podemos aprender que incluso un pequeño error puede tener un resultado catastrófico. Debemos revisar cuidadosamente el código y probar nuestro sitio web con frecuencia para hacerlo cada vez más seguro. Este es el final del análisis, espero que hayas aprendido algo útil hoy. ¡Feliz hacking!