13 marzo 2014

Análisis de inyección SQL crítica en Joomla < 3.2.2

En febrero saltó a la palestra una grave vulnerabilidad de inyección SQL que afectaba al gestor de contenidos Joomla!, reportada por killall-9. En esta ocasión, y a diferencia de lo que suele siempre ocurrir, la vulnerabilidad residía en el núcleo de la aplicación y no en módulos o plugins. Por lo que cualquier instalación de Joomla anterior a 3.2.2 es vulnerable por defecto.

Pues bien, ya tenemos más información acerca de la explotación y la causa de la vulnerabilidad, que por tratarse de una inyección SQL, ya se asumía que se trataba de un problema de validación de parámetros.

Preparamos nuestro entorno para disponer de un conjunto LAMP (Linux, Apache, MySQL, PHP) en el que instalaremos la versión 3.2.1 de Joomla afectada por esta vulnerabilidad. Realizamos una instalación por defecto llamando al portal "Joomla Test", cargándola con datos de prueba.

Página de inicio de la instalación de Joomla 3.2.1

Tal y como se ha reportado en diversas fuentes, la vulnerabilidad reside en el parámetro id de la siguiente URL sobre weblinks-categories:

http://URL/joomla/index.php/weblinks-categories?id=

En primer lugar, procedemos a introducir, en vez de un valor esperado (un entero a modo de índice), un carácter X, para provocar la excepción en la aplicación:

http://URL/joomla/index.php/weblinks-categories?id=X

Excepción en consulta del identificador dentro de weblinks-categories

El error muestra la siguiente información en la parte inferior:
0 SQL=SELECT `t`.`id` FROM `ls41c_tags` AS t INNER JOIN `ls41c_contentitem_tag_map` AS m ON `m`.`tag_id` = `t`.`id` AND `m`.`type_alias` = 'com_weblinks.categories' AND `m`.`content_item_id` IN ( X)      
En dicho error, nos quedamos con el prefijo establecido durante la instalación de Joomla para la nomenclatura de las tablas en base de datos, tras la sintaxis de INNER JOIN. En este caso, el prefijo corresponde con ls41c para la tabla contentitem_tag_map
...INNER JOIN `ls41c_contentitem_tag_map` ...
Este prefijo lo utilizaremos durante la explotación de la vulnerabilidad para conocer exactamente como se denomina a la tabla de usuarios dentro de la base de datos del sistema afectado. Por lo que, para consultar información de la tabla de usuarios de Joomla, tendremos que realizar sentencias sobre la tabla ls41c_users. La explotación es simple: incluiremos el UNION SELECT tras el identificador vulnerable, seleccionando el valor de username y posteriormente del password obteniendo su hash (más información sobre esta tabla en la documentación en Joomla), concatenando el carácter '#' entre ellos para su mejor distinción por pantalla:

http://192.168.70.134/joomla/index.php/weblinks-categories
?id=0) union select concat(CHAR(35),username,CHAR(35),password,CHAR(35)) from `ls41c_users`-- )

Mostrando información de la tabla de usuarios de Joomla de base de datos tras inyección SQL
La función que construye la sentencia utilizada se encuentra en el fichero helper.php en la siguiente ruta:

/joomla/modules/mod_tags_similar/helper.php

Cuya función getList de la clase ModTagssimilarHelper no valida correctamente el valor del identificador id, llevándose directamente a la construcción de la sentencia SQL:

Obtención del valor del parámetro id
El valor del parámetro se establece en $tagsToMatch
$tagsToMatch se introduce directamente en la query de base de datos que posteriormente se ejecutará

Se recomienda actualizar Joomla a su última versión disponible, que actualmente corresponde con la 3.2.3.

Y ya deberías saber que, para evitar que tras el robo de esta información sensible (como usuarios y contraseñas) pueda ser posteriormente utilizada, puedes proteger tu instalación de Joomla mediante Latch de ElevenPaths, añadiendo el plugin rápidamente siguiendo esta guía detallada para su integración con este CMS. Gracias a esta funcionalidad, además los usuarios podrán ser notificados en caso de que dichas cuentas obtenidas sean utilizadas por terceros.

[+] OSVDB 103126 : Joomla /modules/mod_tags_similar/helper.php ModTagssimilarHelper::getList() Method Parameter SQL Injection

10 comments :

jogampo dijo...

Yo tengo instalada la 2.5.x y lo he probado y no tengo este SQL injection. Supongo que lo mismo es por algún plugin.

ojovirtual dijo...

"Y ya deberías saber que, para evitar el robo de este tipo de información
sensible (usuarios, hashes de contraseñas) que posteriormente pueda ser
utilizada, puedes proteger tu instalación de Joomla mediante Latch"


Latch no evitará que se apliquen estas técnicas, sí serviría para evitar que alguien que consiga la contraseña pueda acceder, pero no que esta información no sea robada. Creo que esta frase final no está bien explicada.

Security By Default dijo...

Disculpad, se ha corregido la frase como bien indicas ojovirtual:

"Y ya deberías saber que, para evitar que tras el robo de esta información sensible (como usuarios y contraseñas) pueda ser posteriormente utilizada, puedes proteger tu instalación de Joomla mediante Latch"

Security By Default dijo...

Buenas Jogampo, en principio afecta a versiones anteriores pero de la rama 3.2.X

carlos dijo...

Si utiliza URL amigables ¿Hay forma de explotar la vulnerabilidad?

Ignacio Agulló dijo...

La información publicada es importante, pero entonces es falso lo de que "Por lo que cualquier instalación de Joomla anterior a 3.2.2 es vulnerable por defecto."

eddu dijo...

Otro "tratado" de ingeniería social
1ª parte
http://www.elladodelmal.com/2013/04/hackeando-al-vecino-hax0r-que-me-roba.html

2ª parte
http://www.elladodelmal.com/2013/04/hackeando-al-vecino-hax0r-que-me-roba_5.html

jogampo dijo...

Efectivamente Ignacio. Esa frase suscitó en mi la duda y por eso lo probé en mi joomla.

Fukigaeshi dijo...

La gente no se da cuenta que cuanto más escribe, más rastro deja y un dato por si solo no aporta nada, pero haciendo busquedas una pista te lleva a otra y al final consigues un montón de información.
Cuando todos nos llevamos bien que bonita es la vida, pero cuando te acosan y vienen a tocarte los cojones, ahi tienen material para arruinarte la vida y lo peor es que se lo has servido tu en bandeja

luisco100 dijo...

Buenas amigos de Security By Default, Excelente articulo. Tengo un pequeño comentario, mirando el codigo encontre que el Sqlinjection realmente se encuentra ubicado en el archivo "PATH_JOOMLA"/libraries/cms/helper/tags.php, Donde no se tiene ningun control sobre la variable $id como lo muestra la imagen adjunta.