jueves, 26 de febrero de 2015

0-day en Joomla (todas las versiones): leak del prefijo de la DB y posible Denegación del Servicio

¡Saludos!

  Hace ya un mes que encontré esta vulnerabilidad en el CMS Joomla, pero tras reportarla sin recibir respuesta al mitre para conseguir un CVE y a Joomla, procedo a hacer el disclosure. Doy por sentado que si no contestan, será que no les importa que haga el post.

  Probablemente al navegar por alguna web con Joomla habreis visto una cookie de este estilo:

912b085b9213021200bd7086c0dbccc9=5988204ef45811ad682e0a2fc2195b6

Son cookies de sesión que Joomla procede a almacenar  en la tabla "(prefijo)_session". Joomla no filtra el tamaño del valor de dicha cookie, por lo que nosotros podemos añadir tantos caracteres detrás como deseemos (mientras que no sean demasiados como para generar un error 400).

  Cada vez que navegamos por una web creada con Joomla, se realiza una consulta a la base de datos de tipo INSERT a la tabla (prefijo)_session donde se almacena el valor de la cookie y el momento actual. Teniendo en cuenta que no existe límite en el valor de la cookie, y que cada vez que navegamos se hace un INSERT con el valor de la cookie, parece obvio qué puede pasar: abusar de peticiones pesadas a la DB.

  Cual fue mi sorpresa cuando al hacer dos peticiones con un mismo string de más de 4 kilobytes, obtuve este mensaje de errror:


Sí, efectivamente, es la web de joomla.org. Y eso que se ve es un error de SQL. Very verbose, such vulnerability.

¿Qué ha pasado? La primera petición pesada (mi cookie de sesión + 4.000 "A") es insertada en la DB (ojo, la petición que gestiona MySQL es de más de 4kb consumiendo recursos, pero al tener el campo limitado sólo son insertados 64 bytes). En la segunda petición (con exactamente el mismo string como valor de la cookie) intenta volver a hacer el INSERT, pero al existir ya ese valor, suelta este error de entrada duplicada.

¿Y es interesante esta información obtenida?

  Bastante, la verdad. Debemos de tener en cuenta que una de las medidas para una correcta fortificación de cualquier CMS que instalemos es siempre modificar el prefijo por un string aleatorio con el objetivo de dificultar las inyecciones SQL (tener que sacar un blind o un time based sqli puede acortarse muchisimo en el tiempo teniendo si ya conocemos el nombre y prefijo de las tablas).  En el caso de joomla.org, vemos que todas las tablas tienen de prefijo mhnwc.

¿Y lo de la denegación de servicio?

 En las pruebas en local, y en servidores de hosting gratuitos, he conseguido tumbar el servicio. Pero no me atrevo a poner la mano en el fuego con servidores con más recursos: aunque en teoría debería de funcionar, no puedo aserverarlo. Si alguien lo prueba, que avise ;)

  La mayoría de denegaciones de servicio que he conseguido han sido tras un par de cientos de peticiones (tirando 10 hilos se hace realmente corto) y el error obtenido era de corrupción de la tabla (prefijo)_session. El resto, en menor cantidad (imagino que porque antes se corrompe la tabla), han sido por que la web no consigue conectar con el MySQL (éste está caído).

El PoC empleado para testear la denegación de servicio consiste en añadir a la cookie de sesión un string aleatorio de 4 kb en cada petición, de tal forma que en cada petición se realiza un insert de gran envergadura. En perl/python es sencillo implementar.

Las versiones testeadas han sido 1.5, 2.5 y 3.3. 

Byt3z!

5 0verl0ad Labs: febrero 2015 ¡Saludos!   Hace ya un mes que encontré esta vulnerabilidad en el CMS Joomla, pero tras reportarla...
< >